From nobody Wed Apr 1 18:35:22 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 24BC13A08B3 for ; Wed, 1 Apr 2020 18:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 vVUnhoTZqNJB for ; Wed, 1 Apr 2020 18:35:18 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2126.outbound.protection.outlook.com [40.107.93.126]) (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 C3DE13A08AF for ; Wed, 1 Apr 2020 18:35:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LzeTfMqJ3CikkKB71cVm1A4ptJ3oPsBm6StG3QH776DOlH2msu55pkHUBg8Sj2k4DaEWV2AnyOI5iw6zh3GuuU7wtoQD+RIJqtYdVm+1gwiMCMHoiSs77hcWUpRGJMjhZADKhYJcqq4OTLwbgbBWE0Sqd9Lm6cENgYJI2jT64Z7lXIv1fcf7WpbaGyXJ6i1800jDqgEDNsZuldhfk6OKSEPmGo0NckMNQtYtW8mFt5TCY7VhToDgC1UBZVaAmzxcrVheS8O7fURRGZEdbeiuziStQ7+g24xP560E/6Vl775r9xnUDi20wfMlGRxoBXQHgMDsIa6YRzaBFdxXwPfeiQ== 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=P+6CRLLVuov0SHCQOs1sOhU5GoZtW7IIMxk7E0m22iE=; b=NNKMkMdyYDrZwnY7DW8+5pC9sUQHq05cxBmusbY1MvCp3xrpMps9wjZVfSITrqg3Cm4h7vZm5MQ4pmWqR8Fj98t7FYsuEIe+C2MkLhsKv5wuERVKTa7NnxSc/tSzoYFrhUCtqKz4P50+h8Bhq2lOajwjORSaPrSWXkJC8DxVLTz6vgx6ZZB2U69Rz4jnbCWs52j6x3vAU4VYSNEYkKcyzhMTT2+RL4cohafoTChj/hwEdrL/p1nl/IEA9pFbOXPfAkeGgyfAJbLFNiB7aoqflF3th5voLHJpzqE18xKaO3ogi6KRFfC1G83SiVF9CJ8lhqvOPC2KbTOU1j3v1+pSEQ== 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=P+6CRLLVuov0SHCQOs1sOhU5GoZtW7IIMxk7E0m22iE=; b=iglI94UGs9ORDfNZwsPZfJkV8OtN7smw+K1vM5KOr9OnfIyplZJwKQ9pmj+iHMv3AY3Npxd5iSdcB2kHIaAhLCnNTumRV1Tp+gdbzJNka17N18+v9qvnO2jt/iqp/+XcfP52+MT5wDVGB/xncOUQvO6SI03/Zp9gAXMBK5bMQtU= Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by BL0PR2101MB1028.namprd21.prod.outlook.com (2603:10b6:207:34::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.0; Thu, 2 Apr 2020 01:35:15 +0000 Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::e5f4:bd2b:d304:bfc9]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::e5f4:bd2b:d304:bfc9%4]) with mapi id 15.20.2878.010; Thu, 2 Apr 2020 01:35:15 +0000 From: Dave Thaler To: "teep@ietf.org" Thread-Topic: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication Thread-Index: AdYIjsWAkp4hHTTyQpSZ0l0sLMZy8g== Date: Thu, 2 Apr 2020 01:35:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2601:600:9780:16f0:11d:e3f9:9ab6:60ec] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 19697790-861b-477d-d70e-08d7d6a61869 x-ms-traffictypediagnostic: BL0PR2101MB1028: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0361212EA8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR2101MB1027.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(2906002)(186003)(86362001)(9686003)(7696005)(71200400001)(8936002)(966005)(33656002)(53546011)(6916009)(6506007)(55016002)(10290500003)(82950400001)(8990500004)(66556008)(81156014)(81166006)(66476007)(5660300002)(8676002)(76116006)(64756008)(478600001)(52536014)(66446008)(82960400001)(316002)(66946007); DIR:OUT; SFP:1102; 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: t6+SyVawpDFq1XKwXsWDu2QrHn65/02+IbwwLAZ3XDbQQbghQPeabSWvPKPCmW2zvtAIIw9RtmClRX/6oBzh3B/EIs4jlZeR50SByOL2MmCwUJQzF2qrecwJOnJZLtQLqKyESZEGa0WiYpoGtLmA906BMMZB04uzUHccwxM4Ykic/os+1JTsVd10olwNAIK76axxAc4Hm3s9T/LYSGAbJfsDJjKmCt+IDi2WO3ctWdiwB8QPVHv29ECPstBFD5U7XbodpuB+Ue+cv+1/DJmlkAb/3NvXP9vwvyTGKFJFIvgPjE+qqNvMuli4LbIZ1rvoKW7lx1v9PXbG+gE+a6CHxZyr8IBjD30dZsfEzDXScOculseLeSATmJ/k8FeVZJfPgCDjiS7a9h1cZA/FUIJn4K1AVqBWe1ssD4H8Vo0fm+nqWlYqMPC0oy/dA5yhwqyZStR8Pjj/KpTql0lBB0kwW3KLVNm4hqU8s6C8dKy8Ncvl9gjk4AFTz0idAP1HE7Oj+o/UIW1hN71vIdhmRmn4Cw== x-ms-exchange-antispam-messagedata: ln1VDf7Nyj0sKI+YOk1siLMzrVI915yc8DrqLH6MRINF5pHLPuSHHVa3CToksyrMMjSNHEJkP8+CQd6QKd6QqX9XW/hlxuuyo+DMyjsRFFD/cwhuwanzpEBq04Jvgt0H8ekY8ygy+Xcs6Dt6z9kBX6Tl+aqJ0q4ckRZslM/ytXuqTPUS5ovBDOxqsCy257txy1LujSxiFDVRFe/A8gVK7g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19697790-861b-477d-d70e-08d7d6a61869 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2020 01:35:15.7549 (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: tjawmVXI2Akww94QafDeQdeo8+LyN7UnTRLhw4jMKcW/grA9CFY/1LZrr3daNWVVBoneB3ROtCIPq5Ls34Jly4mYFTR4SSiYwvr+wo6UgkI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1028 Archived-At: Subject: Re: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication 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, 02 Apr 2020 01:35:21 -0000 QXMgbm90ZWQgaW4gbXkgZWFybGllciByZXNwb25zZSwgSSByZWFjaGVkIG91dCB0byBNYXJrIE5v dHRpbmdoYW0gZm9yIGhpcyBhZHZpY2Ugb24gVGlydSdzIHBvaW50cyA0IGFuZCA3Lg0KQmVsb3cg aXMgaGlzIHJlc3BvbnNlLCBmb3J3YXJkZWQgd2l0aCBoaXMgcGVybWlzc2lvbiAodGhhbmtzIE1h cmshKS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcmsgTm90dGluZ2hh bSA8bW5vdEBtbm90Lm5ldD4gDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDEsIDIwMjAgNTo0NiBQ TQ0KVG86IERhdmUgVGhhbGVyIDxkdGhhbGVyQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBSZTog YmNwNTZiaXMgYWR2aWNlDQoNCkhleSwNCg0KPiBPbiAxIEFwciAyMDIwLCBhdCAxOjQzIHBtLCBE YXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gDQo+IDQpICAgIFdo ZW4gSFRUUFMgaXMgdXNlZCwgVExTIGNlcnRpZmljYXRlcyBNVVNUIGJlIGNoZWNrZWQgYWNjb3Jk aW5nIHRvIFtSRkMyODE4XS4NCj4gIA0KPiBDb21tZW50PiBSRkMyODE4IHJlZmVycyB0byBUTFMg MS4wIGFuZCBzZXZlcmFsIG9mIGl0cyBzZWN0aW9ucyBhcmUgb3V0ZGF0ZWQgaW4gY29tcGFyaXNv biB3aXRoIFRMUyAxLjMuDQo+IENvbW1lbnQ+IEZvciBleGFtcGxlLCB3aGVuIFRMUyAxLjMgaXMg dXNlZCwgaXMgMC1SVFQgc3VwcG9ydGVkID8NCj4gQ29tbWVudD4gUkZDMjgxOCByZWZlcnMgdG8g UkZDMjQ1OSBhbmQgaXMgb2Jzb2xldGVkIGJ5IFJGQzUyODAuDQo+IENvbW1lbnQ+IFdoYXQgVExT IHZlcnNpb25zIHNob3VsZCB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgc3VwcG9ydCAoSWYgVExTIDEu MiBuZWVkcyB0byBiZSBzdXBwb3J0ZWQsIHBsZWFzZSBhZGQgdGV4dCBkaXNjdXNzaW5nIHRoZSBw cml2YWN5IGFuZCBzZWN1cml0eSBpbXBsaWNhdGlvbnMpID8NCj4gIA0KPiBodHRwczovL25hbTA2 LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29s cy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLWh0dHBiaXMtYmNwNTZiaXMtMDklMjNzZWN0 aW9uLTQuMyZhbXA7ZGF0YT0wMiU3QzAxJTdDZHRoYWxlciU0MG1pY3Jvc29mdC5jb20lN0M5ZmEx YzJiYWRiZjE0NmExMmM0OTA4ZDdkNjlmMzZjMSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzcyMTM4NTE2MTgwMDkyNjUmYW1wO3NkYXRhPW45YlNyaTR0R1BY Z2RHQ3B6N2tRWXhveFdOWWJwUjlzQURUbCUyQlZNZHBWUSUzRCZhbXA7cmVzZXJ2ZWQ9MCBzYXlz Og0KPiA+ICAgbyAgQ2VydGlmaWNhdGVzIC0gQXBwbGljYXRpb25zIHVzaW5nIEhUVFAgc2hvdWxk IHNwZWNpZnkgdGhhdCBUTFMNCj4gPiAgICAgIGNlcnRpZmljYXRlcyBhcmUgdG8gYmUgY2hlY2tl ZCBhY2NvcmRpbmcgdG8gW1JGQzI4MThdIHdoZW4gSFRUUFMNCj4gPiAgICAgIGlzIHVzZWQuDQo+ ICANCj4gV2hpY2ggaXMgd2hhdCB0aGlzIGRvYyBzYXlzLiAgIERvIHlvdSB0aGluayB0aGF0IGJj cDU2YmlzIGlzIGRlZmljaWVudCBpbiBub3QgYXNraW5nIGFwcCBwcm90b2NvbHMgdG8NCj4gc2F5 IHdoYXQgVExTIHZlcnNpb25zIHNob3VsZCBiZSBzdXBwb3J0ZWQ/ICAgSWYgc28sIHlvdSBzaG91 bGQgcHJvdmlkZSB0aGF0IGZlZWRiYWNrIHNvb24gKGlmIHlvdSBkaWRu4oCZdCBhbHJlYWR5KSBz aW5jZSBpdOKAmXMNCj4gbGlzdGVkIGFzIFdHIENvbnNlbnN1czogV2FpdGluZyBmb3IgV3JpdGUt VXANCj4gIA0KPiBJ4oCZbSBoZXNpdGFudCB0byBhZGQgYW55IHRleHQgaGVyZSB3aXRob3V0IGEg c3BlY2lmaWMgcmVjb21tZW5kYXRpb24gZnJvbSB0aGF0IGRvYyBzaW5jZSBJ4oCZZCBwcm9iYWJs eSBnZXQgaXQgd3JvbmcuDQo+IExlYXZpbmcgaXQgc2lsZW50LCBvbiB0aGUgb3RoZXIgaGFuZCwg bWVhbnMgcGVvcGxlIHNob3VsZCBnZXQgdGhlIGFuc3dlciBmcm9tIGJjcDU2YmlzLCB3aGljaCBp cyByZWZlcmVuY2VkIGluIHRoZQ0KPiBTZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLiAg IEkgZG9u4oCZdCBrbm93IGlmIHRoYXTigJlzIHN1ZmZpY2llbnQgb3Igbm90LCBidXQgd291bGQg d2FudCBhZHZpY2UgZnJvbSBzb21lb25lIGxpa2UNCj4gTWFyay4NCg0KSSdkIHByb2JhYmx5IGhh bmRiYWxsIHRoaXMgdG8gdGhlIFNlY3VyaXR5IERpcmVjdG9yYXRlIG9yIHNpbWlsYXI7IHdlIGRp ZG4ndCBnbyB0aGVyZSBiZWNhdXNlIGl0J3Mgbm90IEhUVFAtc3BlY2lmaWMuDQoNCj4gNykgDQo+ ICAgIElmIGFueSBlcnJvciBvY2N1cnMgd2hlcmUgdGhlIFRFRVAvSFRUUCBTZXJ2ZXIgY2Fubm90 IGdldCBhIG1lc3NhZ2UNCj4gICAgYnVmZmVyIChlbXB0eSBvciBub3QpIGJhY2sgZnJvbSB0aGUg VEVFUCBpbXBsZW1lbnRhdGlvbiwgdGhlIFRFRVAvDQo+ICAgIEhUVFAgU2VydmVyIGdlbmVyYXRl cyBhbiBhcHByb3ByaWF0ZSBIVFRQIGVycm9yIHJlc3BvbnNlLg0KPiAgDQo+IENvbW1lbnQ+IEFu eSBzcGVjaWZpYyByZWFzb24gZm9yIG5vdCBzcGVjaWZ5aW5nIHRoZSBlcnJvciBjb2RlID8NCj4g IA0KPiBZZXMuICBUaGVyZSBhcmUgbWFueSBwb3NzaWJsZSBlcnJvciByZWFzb25zIGFuZCBsZWdh bCBIVFRQIGVycm9yIGNvZGVzIA0KPiBmb3IgdGhlbSwgc28gaXTigJlzIHVwIHRvIHRoZSBpbXBs ZW1lbnRhdGlvbiB0byBwaWNrIGFuIGFwcHJvcHJpYXRlIG9uZSBiYXNlZCBvbiBIVFRQIHNwZWNz Lg0KPiAgDQo+IGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtaHR0 cGJpcy1iY3A1NmJpcyZhbXA7ZGF0YT0wMiU3QzAxJTdDZHRoYWxlciU0MG1pY3Jvc29mdC5jb20l N0M5ZmExYzJiYWRiZjE0NmExMmM0OTA4ZDdkNjlmMzZjMSU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcyMTM4NTE2MTgwMDkyNjUmYW1wO3NkYXRhPUxPUDEx elhCUEpDdENRdnYzNkVia2hPRUh1ZiUyQkVBVGZhM2lndEJvb0xhWSUzRCZhbXA7cmVzZXJ2ZWQ9 MCBzYXlzOg0KPiAgICBJbnN0ZWFkLCBhcHBsaWNhdGlvbnMgdXNpbmcgSFRUUCBzaG91bGQgZGVm aW5lIHRoZWlyIGVycm9ycyB0byB1c2UNCj4gICAgdGhlIG1vc3QgYXBwbGljYWJsZSBzdGF0dXMg Y29kZSwgbWFraW5nIGdlbmVyb3VzIHVzZSBvZiB0aGUgZ2VuZXJhbA0KPiAgICBzdGF0dXMgY29k ZXMgKDIwMCwgNDAwIGFuZCA1MDApIHdoZW4gaW4gZG91YnQuICBJbXBvcnRhbnRseSwgdGhleQ0K PiAgICBzaG91bGQgbm90IHNwZWNpZnkgYSBvbmUtdG8tb25lIHJlbGF0aW9uc2hpcCBiZXR3ZWVu IHN0YXR1cyBjb2RlcyBhbmQNCj4gICAgYXBwbGljYXRpb24gZXJyb3JzLCB0aGVyZWJ5IGF2b2lk aW5nIHRoZSBleGhhdXN0aW9uIGlzc3VlIG91dGxpbmVkDQo+ICAgIGFib3ZlLg0KPiAgDQo+IEZZ SSwgd2hlbiBNTm90IHJldmlld2VkIHRoaXMgc3BlYyAoYXMgYXV0aG9yIG9mIGJjcDU2YmlzKSBo ZSBzYWlkIGl0IGxvb2tlZCBvay4NCg0KSXQgZG9lcy4gRldJVyBJIGRvbid0IHRoaW5rIGl0J3Mg aGFybWZ1bCB0byBzYXkgImluIHRoaXMgc2l0dWF0aW9uLCBzZXJ2ZXJzIHNob3VsZCB1c2Ugc3Rh dHVzIGNvZGUgWCwgYmVjYXVzZSB0aGF0J3MgdGhlIG1vc3QgYXBwcm9wcmlhdGUgb25lIGZvciB0 aG9zZSBzZW1hbnRpY3MuIiBXaGF0IHlvdSB3YW50IHRvIHN0YXkgYXdheSBmcm9tIGlzIHNheWlu ZyAiY2xpZW50cyByZWNlaXZlIHN0YXR1cyBjb2RlIFggY2FuIGluZmVyIFkuIiBVbmZvcnR1bmF0 ZWx5LCB0aGUgZGlmZmVyZW5jZSBpcyBzdWJ0bGUgYW5kIGVhc2lseSBtaXNyZWFkLg0KDQoNCj4g Q29tbWVudD4gV2h5IGlzIGlldGYtaHR0cGJpcy1iY3A1NmJpcyBhbiBJbmZvcm1hdGl2ZSByZWZl cmVuY2UgPw0KPiAgDQo+IEZhaXIgcXVlc3Rpb24uIEkgZG9u4oCZdCBoYXZlIGEgc3Ryb25nIHBy ZWZlcmVuY2UgZWl0aGVyIHdheS4NCj4gQ3VycmVudCBhbnN3ZXIgaXMgYmVjYXVzZSBpdOKAmXMg bm90IHVzZWQgaW4gYW55IHNlbnRlbmNlIGluIGEgbm9ybWF0aXZlIHdheS4NCg0KRldJVywgSSBk b24ndCB0aGluayBpdCdzIG5lY2Vzc2FyeSB0byByZWZlcmVuY2UgNTZiaXMgdW5sZXNzIHlvdSdy ZSByZWx5aW5nIG9uIGl0IGZvciBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvciB0aGUgbGlrZS4N Cg0KQ2hlZXJzLA0KDQotLQ0KTWFyayBOb3R0aW5naGFtDQoNCg== From nobody Wed Apr 1 18:40:45 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 651BB3A0900 for ; Wed, 1 Apr 2020 18:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qh0lSEDJH0E7 for ; Wed, 1 Apr 2020 18:40:42 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5250B3A08FE for ; Wed, 1 Apr 2020 18:40:42 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0321eVPf000552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Apr 2020 21:40:33 -0400 Date: Wed, 1 Apr 2020 18:40:31 -0700 From: Benjamin Kaduk To: Dave Thaler Cc: "Konda, Tirumaleswar Reddy" , "teep@ietf.org" Message-ID: <20200402014031.GC50174@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication 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, 02 Apr 2020 01:40:44 -0000 [quoting is a bit busted, since color doesn't make it into text/plain] On Wed, Apr 01, 2020 at 02:37:52AM +0000, Dave Thaler wrote: > > > > > From: TEEP On Behalf Of Konda, Tirumaleswar Reddy > Sent: Saturday, March 14, 2020 11:05 PM > To: teep@ietf.org > Subject: Re: [Teep] Working Group Last Call for HTTP Transport for Trusted > Execution Environment Provisioning: Agent-to-TAM Communication > > > 5) HTTP is susceptible to several attacks including pervasive monitoring, > any specific reason to support HTTP ? > > > > For debugging purposes before putting it into production. It's not really clear to me that we need to include something in the protocol spec that's just for debugging. Do we really think people will not figure out that they can use non-TLS HTTP for locally debugging an HTTPS-based protocol? > Also some argue that since TEEP already does its own security layer > inside, the value of multiple layers of security > > Is diminished, especially if you're a constrained node looking to reduce > code size. The text in the security consideration (IMO the multiple layers do different things and complement each other, in general. I guess I haven't looked at this specific protocol in detail yet but there's a general theme across protocols.) -Ben From nobody Thu Apr 2 17: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 F16F33A091B for ; Thu, 2 Apr 2020 17:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 kTs1hfg29ohv for ; Thu, 2 Apr 2020 17:13:57 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2135.outbound.protection.outlook.com [40.107.223.135]) (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 686E53A0900 for ; Thu, 2 Apr 2020 17:13:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GsY3AKb5UOYFOpgFtR2pdgGcmdNAVE6UtDps3qtmJKM3ZYO7SMGhyeMf3mGRsOZBavBxr7kEH7w0cmAQeKBlNTuO3PVcg6RIuIP97zVBad4weK2lYB1k2ZlQuC04DA9kfBM79/tNDQCzJN5Q47Op9bo1mkvFYlDGGgBK1TjR3Lt1VqiYTVeRQSrKnmgCcWrc3HHsllCGHur6fTscJ0QRi1RrIrjNEshDtuel1Vv0+1JzZdEGYqv9yknT9bPApXm0Bm6TUip7wMErw6o9jAr80GJwupYxcbzmKlXfCMX4dJEi+ZGYQa095LaR1LhOBPBs6NvNKlcvC3O3FEd68ABQMg== 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=nmI9THkT+d5nTQM1DjztZ73jzdCP4Zpg3DqrsFsUvz8=; b=FOM/TB2Am8a8fFuh5SEAaGnNVJMbOUGLqojjYXlSUXsygbVCmFAUWygtaKwqqTditb/hfYVMPZ2l5bEGZXiXoPq+wbOJGFXUYFb6JxaLZOX0Vhf50bDQfmyyqmx98n3feKmLb5E50zYw75fUcQRn9PlQDghtX1UkoXz5f8Ak24U0ZZa0tAvP/InG3H8n4IMOFyDiLAuPX5duzWnRh2g4O0gW5hNQ2OeZmJN6aiSpRWNOLhn0VNe31TPqMwY4Kz4qigZE274jcFhPn5ZNNePXOk32CIKp9x0EcWWra8oLONMZbh4IrSzGtRNibYr9PU54p2zpLLu4qstWJyP1N4qK9A== 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=nmI9THkT+d5nTQM1DjztZ73jzdCP4Zpg3DqrsFsUvz8=; b=QCoCMXe7xz9P3bOJFZsAU7LnnXFXRkkgHGl9QD29Jk0zxBCq7xOoqXWb5slsPLJdYyzfk/riGx8pvtDlo5I/Bd7krIx1BZxrdvNcIcVLbGWQSfPt/zOQdvpHKpobXlYoTPPqFsxPePekAL0491XbGTvmdJNusJIQlXnOBt6FPZQ= Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by BL0PR2101MB0915.namprd21.prod.outlook.com (2603:10b6:207:36::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.2; Fri, 3 Apr 2020 00:13:33 +0000 Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::e5f4:bd2b:d304:bfc9]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::e5f4:bd2b:d304:bfc9%4]) with mapi id 15.20.2878.010; Fri, 3 Apr 2020 00:13:33 +0000 From: Dave Thaler To: "teep@ietf.org" Thread-Topic: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication Thread-Index: AdYIjsWAkp4hHTTyQpSZ0l0sLMZy8gAvLK+A Date: Fri, 3 Apr 2020 00:13:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2601:600:9780:16f0:6893:5b01:eac2:20f6] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 824b4325-ed97-490e-90b1-08d7d763d8ad x-ms-traffictypediagnostic: BL0PR2101MB0915: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR2101MB1027.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(396003)(346002)(136003)(39860400002)(376002)(366004)(82950400001)(33656002)(9686003)(82960400001)(6506007)(76116006)(7696005)(478600001)(316002)(53546011)(8990500004)(71200400001)(52536014)(186003)(81156014)(8936002)(6916009)(966005)(2906002)(10290500003)(66446008)(66476007)(5660300002)(64756008)(55016002)(66556008)(81166006)(66946007)(86362001)(8676002); DIR:OUT; SFP:1102; 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: 0PK4Ew2d+3n8ttIKFhBP6XGhSPek/LYrsNXoGWXB7NmKfubey1d7+KSK2m9telTGgZ0poYtqBsZIiNsNJqHTn5JbRs+d+MQGN4QscOV79gwMdy8Rcy+YwqhMF1638+3qIgDEetx6XwdSqBJodKhUAx8WsoCf5QnpwQvubBC/CqrRMp57LwcpESiyTtxTtRFGfWGx6sASqD72H+XU7D9DhPfJWsi7ggTQQasmsYXAK204QaguxIJdH1GuTKB8qmQiECUVk1+x0nmJAIV/W/8X/uricPmattBIaSvCs6ZXXWlpvQQaFWP6pT2aTyn3Rtj27Nte4mKdcbMcuYq67P/1S+7DOlyz7cFSeYnGT8VbU/oRwrJUpbpm7t8DBtfux1BnStKWjg7yXhI2ieU/W+yCnAk8+qIn9I+4p1IQIfmPVE5/O4zsShVByKLEqRclMZM9afVAmiZo7iSARW1ZzjJFAtwjmvIfYNE2TEZMS+01ilzuKrq5NSfSkh33uZFHx0nRSMryMwAdipj9x4GmbqIS7w== x-ms-exchange-antispam-messagedata: 0x3SlU6xw2nsONeCFzZmJUTk5YHWWHIC6ncJBu5c118RzqxoCiAITVuNFDT/4seT/JT7hy9Alsmbdh86BKjSkG9yxDZotROQyKd+H5VH3yKl8xOzgomE9kh4eDMRZsIppK1+8FR4Mtwu4kD5PwZIGmjoJ97VowaDl/KfLQubAoliEq78H8UEEQ+JmzvK8ECuvApnStmP2UFFTBbA0LrwIA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 824b4325-ed97-490e-90b1-08d7d763d8ad X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 00:13:33.1583 (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: +kuyyqrs5lnh6baG+yG42IpdrG7+Oh8f+y0AgsCkQjOiyzTKY+DVzePgANIRQAesXJAxFQxT5BFgYkZW0Z4W0rU0D6eSZ1Tyw48GoRma8KM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB0915 Archived-At: Subject: Re: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication 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, 03 Apr 2020 00:14:08 -0000 Rm9yIHBvaW50IDQgKFRMUyBjb25zaWRlcmF0aW9ucyksIEkgZmlsZWQgaHR0cHM6Ly9naXRodWIu Y29tL2lldGYtdGVlcC9vdHJwLW92ZXItaHR0cC9pc3N1ZXMvMTAgYW5kDQpteSBwcm9wb3NhbCB0 byBhZGRyZXNzIGl0IGlzIGFzIGZvbGxvd3M6DQoNCk9MRDogV2hlbiBIVFRQUyBpcyB1c2VkLCBU TFMgY2VydGlmaWNhdGVzIE1VU1QgYmUgY2hlY2tlZCBhY2NvcmRpbmcgdG8gW1JGQzI4MThdLiAN Cg0KTkVXOiBXaGVuIEhUVFBTIGlzIHVzZWQsIFRMUyBjZXJ0aWZpY2F0ZXMgTVVTVCBiZSBjaGVj a2VkIGFjY29yZGluZyB0byBbUkZDMjgxOF0uIA0KTkVXOiBTZWUgW1JGQzc1MjVdIGZvciBhZGRp dGlvbmFsIFRMUyByZWNvbW1lbmRhdGlvbnMuICAgICAgDQoNClJhdGlvbmFsZSBpcyB0aGF0IFJG QyA3NTI1IChCQ1AgMTk1KSBpcyB3aGF0IGNvbnRhaW5zIHRoZSBhbnN3ZXJzIHRvIHF1ZXN0aW9u cyBsaWtlIFRpcnUgYXNrZWQgaW4gcG9pbnQgNCwgaW4gYSB3YXkgdGhhdCBpcw0Kbm90IHNwZWNp ZmljIHRvIFRFRVAsIGFuZCBhbHJlYWR5IGhhcyBJRVRGIGNvbnNlbnN1cy4gIEZvciBleGFtcGxl LCBzZWN0aW9uIDMuMS4xIG9mIHRoYXQgUkZDIGRlYWxzIHdpdGggVExTIHZlcnNpb25zDQphcyBU aXJ1IGFza2VkIGFib3V0IGluIHBvaW50IDQuICAgTXkgcHJvcG9zZWQgYXBwcm9hY2ggYWxzbyBt ZWFucyB3ZSBkb24ndCBuZWVkIHRvIGNvbWUgdXAgd2l0aCBURUVQLXNwZWNpZmljIHRleHQsDQpz aW5jZSBJIGRvbid0IGJlbGlldmUgdGhlcmUncyBhbnl0aGluZyBURUVQIHNwZWNpZmljIGhlcmUs IGdpdmVuIHRoYXQgVEVFUCBtZXNzYWdlcyBhcmUgc2VjdXJlZCBlbmQtdG8tZW5kIGluc2lkZSBz bw0KYW55dGhpbmcgcmVhbGx5IFRFRVAgc3BlY2lmaWMgdG8gc2F5IHdvdWxkIGJlIHVwIGluIHRo ZSBURUVQIHByb3RvY29sLg0KDQpEYXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBURUVQIDx0ZWVwLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBEYXZlIFRoYWxl cg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxLCAyMDIwIDY6MzUgUE0NClRvOiB0ZWVwQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW1RlZXBdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBIVFRQ IFRyYW5zcG9ydCBmb3IgVHJ1c3RlZCBFeGVjdXRpb24gRW52aXJvbm1lbnQgUHJvdmlzaW9uaW5n OiBBZ2VudC10by1UQU0gQ29tbXVuaWNhdGlvbg0KDQpBcyBub3RlZCBpbiBteSBlYXJsaWVyIHJl c3BvbnNlLCBJIHJlYWNoZWQgb3V0IHRvIE1hcmsgTm90dGluZ2hhbSBmb3IgaGlzIGFkdmljZSBv biBUaXJ1J3MgcG9pbnRzIDQgYW5kIDcuDQpCZWxvdyBpcyBoaXMgcmVzcG9uc2UsIGZvcndhcmRl ZCB3aXRoIGhpcyBwZXJtaXNzaW9uICh0aGFua3MgTWFyayEpLg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0Pg0KU2VudDog V2VkbmVzZGF5LCBBcHJpbCAxLCAyMDIwIDU6NDYgUE0NClRvOiBEYXZlIFRoYWxlciA8ZHRoYWxl ckBtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogUmU6IGJjcDU2YmlzIGFkdmljZQ0KDQpIZXksDQoN Cj4gT24gMSBBcHIgMjAyMCwgYXQgMTo0MyBwbSwgRGF2ZSBUaGFsZXIgPGR0aGFsZXJAbWljcm9z b2Z0LmNvbT4gd3JvdGU6DQo+IA0KPiA0KSAgICBXaGVuIEhUVFBTIGlzIHVzZWQsIFRMUyBjZXJ0 aWZpY2F0ZXMgTVVTVCBiZSBjaGVja2VkIGFjY29yZGluZyB0byBbUkZDMjgxOF0uDQo+ICANCj4g Q29tbWVudD4gUkZDMjgxOCByZWZlcnMgdG8gVExTIDEuMCBhbmQgc2V2ZXJhbCBvZiBpdHMgc2Vj dGlvbnMgYXJlIG91dGRhdGVkIGluIGNvbXBhcmlzb24gd2l0aCBUTFMgMS4zLg0KPiBDb21tZW50 PiBGb3IgZXhhbXBsZSwgd2hlbiBUTFMgMS4zIGlzIHVzZWQsIGlzIDAtUlRUIHN1cHBvcnRlZCA/ DQo+IENvbW1lbnQ+IFJGQzI4MTggcmVmZXJzIHRvIFJGQzI0NTkgYW5kIGlzIG9ic29sZXRlZCBi eSBSRkM1MjgwLg0KPiBDb21tZW50PiBXaGF0IFRMUyB2ZXJzaW9ucyBzaG91bGQgdGhlIGNsaWVu dCBhbmQgc2VydmVyIHN1cHBvcnQgKElmIFRMUyAxLjIgbmVlZHMgdG8gYmUgc3VwcG9ydGVkLCBw bGVhc2UgYWRkIHRleHQgZGlzY3Vzc2luZyB0aGUgcHJpdmFjeSBhbmQgc2VjdXJpdHkgaW1wbGlj YXRpb25zKSA/DQo+ICANCj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQt aWV0Zi1odHRwYmlzLWJjcDU2YmlzLTA5JTIzc2VjdGlvbi00LjMmYW1wO2RhdGE9MDIlN0MwMSU3 Q2R0aGFsZXIlNDBtaWNyb3NvZnQuY29tJTdDOWQ3NDFmNjBkNWFkNDUyZjA4Y2QwOGQ3ZDZhNjFl ZGMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MjEzODgx Mjk2MjI1OTU2JmFtcDtzZGF0YT1iRUo0c2JWbU8lMkZhbnEwRUNrVEhIekpuJTJCVjJTZmJ6MURG Q1laRDRRWSUyRnNjJTNEJmFtcDtyZXNlcnZlZD0wIHNheXM6DQo+ID4gICBvICBDZXJ0aWZpY2F0 ZXMgLSBBcHBsaWNhdGlvbnMgdXNpbmcgSFRUUCBzaG91bGQgc3BlY2lmeSB0aGF0IFRMUw0KPiA+ ICAgICAgY2VydGlmaWNhdGVzIGFyZSB0byBiZSBjaGVja2VkIGFjY29yZGluZyB0byBbUkZDMjgx OF0gd2hlbiBIVFRQUw0KPiA+ICAgICAgaXMgdXNlZC4NCj4gIA0KPiBXaGljaCBpcyB3aGF0IHRo aXMgZG9jIHNheXMuICAgRG8geW91IHRoaW5rIHRoYXQgYmNwNTZiaXMgaXMgZGVmaWNpZW50IGlu IG5vdCBhc2tpbmcgYXBwIHByb3RvY29scyB0bw0KPiBzYXkgd2hhdCBUTFMgdmVyc2lvbnMgc2hv dWxkIGJlIHN1cHBvcnRlZD8gICBJZiBzbywgeW91IHNob3VsZCBwcm92aWRlIHRoYXQgZmVlZGJh Y2sgc29vbiAoaWYgeW91IGRpZG7igJl0IGFscmVhZHkpIHNpbmNlIGl04oCZcw0KPiBsaXN0ZWQg YXMgV0cgQ29uc2Vuc3VzOiBXYWl0aW5nIGZvciBXcml0ZS1VcA0KPiAgDQo+IEnigJltIGhlc2l0 YW50IHRvIGFkZCBhbnkgdGV4dCBoZXJlIHdpdGhvdXQgYSBzcGVjaWZpYyByZWNvbW1lbmRhdGlv biBmcm9tIHRoYXQgZG9jIHNpbmNlIEnigJlkIHByb2JhYmx5IGdldCBpdCB3cm9uZy4NCj4gTGVh dmluZyBpdCBzaWxlbnQsIG9uIHRoZSBvdGhlciBoYW5kLCBtZWFucyBwZW9wbGUgc2hvdWxkIGdl dCB0aGUgYW5zd2VyIGZyb20gYmNwNTZiaXMsIHdoaWNoIGlzIHJlZmVyZW5jZWQgaW4gdGhlDQo+ IFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24uICAgSSBkb27igJl0IGtub3cgaWYgdGhh dOKAmXMgc3VmZmljaWVudCBvciBub3QsIGJ1dCB3b3VsZCB3YW50IGFkdmljZSBmcm9tIHNvbWVv bmUgbGlrZQ0KPiBNYXJrLg0KDQpJJ2QgcHJvYmFibHkgaGFuZGJhbGwgdGhpcyB0byB0aGUgU2Vj dXJpdHkgRGlyZWN0b3JhdGUgb3Igc2ltaWxhcjsgd2UgZGlkbid0IGdvIHRoZXJlIGJlY2F1c2Ug aXQncyBub3QgSFRUUC1zcGVjaWZpYy4NCg0KPiA3KSANCj4gICAgSWYgYW55IGVycm9yIG9jY3Vy cyB3aGVyZSB0aGUgVEVFUC9IVFRQIFNlcnZlciBjYW5ub3QgZ2V0IGEgbWVzc2FnZQ0KPiAgICBi dWZmZXIgKGVtcHR5IG9yIG5vdCkgYmFjayBmcm9tIHRoZSBURUVQIGltcGxlbWVudGF0aW9uLCB0 aGUgVEVFUC8NCj4gICAgSFRUUCBTZXJ2ZXIgZ2VuZXJhdGVzIGFuIGFwcHJvcHJpYXRlIEhUVFAg ZXJyb3IgcmVzcG9uc2UuDQo+ICANCj4gQ29tbWVudD4gQW55IHNwZWNpZmljIHJlYXNvbiBmb3Ig bm90IHNwZWNpZnlpbmcgdGhlIGVycm9yIGNvZGUgPw0KPiAgDQo+IFllcy4gIFRoZXJlIGFyZSBt YW55IHBvc3NpYmxlIGVycm9yIHJlYXNvbnMgYW5kIGxlZ2FsIEhUVFAgZXJyb3IgY29kZXMgDQo+ IGZvciB0aGVtLCBzbyBpdOKAmXMgdXAgdG8gdGhlIGltcGxlbWVudGF0aW9uIHRvIHBpY2sgYW4g YXBwcm9wcmlhdGUgb25lIGJhc2VkIG9uIEhUVFAgc3BlY3MuDQo+ICANCj4gaHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9v bHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi1odHRwYmlzLWJjcDU2YmlzJmFtcDtkYXRh PTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0LmNvbSU3QzlkNzQxZjYwZDVhZDQ1MmYwOGNk MDhkN2Q2YTYxZWRjJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNzIxMzg4MTI5NjIzNTkxMiZhbXA7c2RhdGE9MzBnczV2b2hldkRyZWNrTHp1YWhVcUNxbkhB TjMwYUtpSTV0dWpLQk1TTSUzRCZhbXA7cmVzZXJ2ZWQ9MCBzYXlzOg0KPiAgICBJbnN0ZWFkLCBh cHBsaWNhdGlvbnMgdXNpbmcgSFRUUCBzaG91bGQgZGVmaW5lIHRoZWlyIGVycm9ycyB0byB1c2UN Cj4gICAgdGhlIG1vc3QgYXBwbGljYWJsZSBzdGF0dXMgY29kZSwgbWFraW5nIGdlbmVyb3VzIHVz ZSBvZiB0aGUgZ2VuZXJhbA0KPiAgICBzdGF0dXMgY29kZXMgKDIwMCwgNDAwIGFuZCA1MDApIHdo ZW4gaW4gZG91YnQuICBJbXBvcnRhbnRseSwgdGhleQ0KPiAgICBzaG91bGQgbm90IHNwZWNpZnkg YSBvbmUtdG8tb25lIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHN0YXR1cyBjb2RlcyBhbmQNCj4gICAg YXBwbGljYXRpb24gZXJyb3JzLCB0aGVyZWJ5IGF2b2lkaW5nIHRoZSBleGhhdXN0aW9uIGlzc3Vl IG91dGxpbmVkDQo+ICAgIGFib3ZlLg0KPiAgDQo+IEZZSSwgd2hlbiBNTm90IHJldmlld2VkIHRo aXMgc3BlYyAoYXMgYXV0aG9yIG9mIGJjcDU2YmlzKSBoZSBzYWlkIGl0IGxvb2tlZCBvay4NCg0K SXQgZG9lcy4gRldJVyBJIGRvbid0IHRoaW5rIGl0J3MgaGFybWZ1bCB0byBzYXkgImluIHRoaXMg c2l0dWF0aW9uLCBzZXJ2ZXJzIHNob3VsZCB1c2Ugc3RhdHVzIGNvZGUgWCwgYmVjYXVzZSB0aGF0 J3MgdGhlIG1vc3QgYXBwcm9wcmlhdGUgb25lIGZvciB0aG9zZSBzZW1hbnRpY3MuIiBXaGF0IHlv dSB3YW50IHRvIHN0YXkgYXdheSBmcm9tIGlzIHNheWluZyAiY2xpZW50cyByZWNlaXZlIHN0YXR1 cyBjb2RlIFggY2FuIGluZmVyIFkuIiBVbmZvcnR1bmF0ZWx5LCB0aGUgZGlmZmVyZW5jZSBpcyBz dWJ0bGUgYW5kIGVhc2lseSBtaXNyZWFkLg0KDQoNCj4gQ29tbWVudD4gV2h5IGlzIGlldGYtaHR0 cGJpcy1iY3A1NmJpcyBhbiBJbmZvcm1hdGl2ZSByZWZlcmVuY2UgPw0KPiAgDQo+IEZhaXIgcXVl c3Rpb24uIEkgZG9u4oCZdCBoYXZlIGEgc3Ryb25nIHByZWZlcmVuY2UgZWl0aGVyIHdheS4NCj4g Q3VycmVudCBhbnN3ZXIgaXMgYmVjYXVzZSBpdOKAmXMgbm90IHVzZWQgaW4gYW55IHNlbnRlbmNl IGluIGEgbm9ybWF0aXZlIHdheS4NCg0KRldJVywgSSBkb24ndCB0aGluayBpdCdzIG5lY2Vzc2Fy eSB0byByZWZlcmVuY2UgNTZiaXMgdW5sZXNzIHlvdSdyZSByZWx5aW5nIG9uIGl0IGZvciBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBvciB0aGUgbGlrZS4NCg0KQ2hlZXJzLA0KDQotLQ0KTWFyayBO b3R0aW5naGFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpURUVQIG1haWxpbmcgbGlzdA0KVEVFUEBpZXRmLm9yZw0KaHR0cHM6Ly9uYW0wNi5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGVlcCZhbXA7ZGF0YT0wMiU3QzAxJTdDZHRoYWxl ciU0MG1pY3Jvc29mdC5jb20lN0M5ZDc0MWY2MGQ1YWQ0NTJmMDhjZDA4ZDdkNmE2MWVkYyU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcyMTM4ODEyOTYyMzU5 MTImYW1wO3NkYXRhPWVwaUNWc1V1QWFYOXk2YXN5Y2h4TyUyQjRXOW81d21RY1pTdWhhS2w4eXho USUzRCZhbXA7cmVzZXJ2ZWQ9MA0K From nobody Thu Apr 2 19:06:02 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 0119D3A0BD4 for ; Thu, 2 Apr 2020 19:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4TDX91g0pB4 for ; Thu, 2 Apr 2020 19:05:59 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66B93A0BD1 for ; Thu, 2 Apr 2020 19:05:59 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03325sT4022204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Apr 2020 22:05:56 -0400 Date: Thu, 2 Apr 2020 19:05:53 -0700 From: Benjamin Kaduk To: Dave Thaler Cc: "teep@ietf.org" Message-ID: <20200403020553.GB88064@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication 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, 03 Apr 2020 02:06:01 -0000 On Fri, Apr 03, 2020 at 12:13:33AM +0000, Dave Thaler wrote: > For point 4 (TLS considerations), I filed https://github.com/ietf-teep/otrp-over-http/issues/10 and > my proposal to address it is as follows: > > OLD: When HTTPS is used, TLS certificates MUST be checked according to [RFC2818]. > > NEW: When HTTPS is used, TLS certificates MUST be checked according to [RFC2818]. > NEW: See [RFC7525] for additional TLS recommendations. > > Rationale is that RFC 7525 (BCP 195) is what contains the answers to questions like Tiru asked in point 4, in a way that is > not specific to TEEP, and already has IETF consensus. For example, section 3.1.1 of that RFC deals with TLS versions > as Tiru asked about in point 4. My proposed approach also means we don't need to come up with TEEP-specific text, > since I don't believe there's anything TEEP specific here, given that TEEP messages are secured end-to-end inside so > anything really TEEP specific to say would be up in the TEEP protocol. Thanks, Dave, this sounds like a good plan. I note that we probably do want to pick up any future changes/updates to BCP 195, so we should probably cite that and not just RFC 7525. -Ben From nobody Fri Apr 3 01:35: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 B88C23A1473 for ; Fri, 3 Apr 2020 01:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=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=aist.go.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6D703RpUloa for ; Fri, 3 Apr 2020 01:35:45 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410081.outbound.protection.outlook.com [40.107.141.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DD43A146F for ; Fri, 3 Apr 2020 01:35:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CdWejKN0kIgCc2jSUA3WSLFGPWAoFvMkPqpMIjHO4EL7pqvyfoI0EWKA+xa2nlztW04lkbmsJ2FGtbsoYpl32LDFw/DYyL11j12rI+KIZ0ZsWuu2oPHd2383q83qElwR2xtTmUsaMO8k3th9WtF2DynQJs3KxwV9VoKUb+zzQ7Wvg/Fyq8bqiz2LsPLbT0NAtpvpcy2epyXteJ+gKcTI/02fW6HnLkqMGW0+2PVIfICevzMClgLrfwCRTeOETvGIjeslTAtNO7zc0Ovs9Ii/2d/HwQ8q1FdtjjSNc/QGo8cl9gA0phxmAn4BUdWmsLjCIRv2A58HDwHS6UtIu6fPpQ== 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=T3YdKjy1iTcszXxUfwVWIwLvKcSmWqcqT82yzkYg11w=; b=Ka2n988uv5ixrLXuIpQ61RgucZ6M4upQK2PHgmP+HsmnItwuLCHv3V0zpEpfGDP6auD/DauyGg1NshLHnyX+/iPZngpjKa2ACYB16CeadHn2arnkRdcgQcN2YmTwocp2KLfGrVxw+OkwGKEKuvuY7XL6RJ71h8KxBgcZRf1UtyrbopR++PDML90rOJ+uuyvLpIMW1PeCs/Pd58rAOpv4913PgOhkC57AEmpvh2amYakRUUfSN3eiggcBEqxW87oqwq/QBP6s1ft8bmE1vooFXktZTl96jEHUUQaURlskvewoZy7MX/NuG7RsBw3y6Un0WsZVwYaw7cFbUtPKLw+K5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T3YdKjy1iTcszXxUfwVWIwLvKcSmWqcqT82yzkYg11w=; b=kOtR/IYcdbkPRGtloMYy/XnMFywfZiOk7fyQh9YiOjBeIEWZbB9EAO1Ftd4r4OoayLEIBFmfPvrYVtIVyAUh8Yy8xjAONJSI9NUc+Y2CoppTpzIK5LY4Zt9epNcakoisRWfb82fOfw7tCxUM9nGXNISAkVZR1Dg7izH1YCErc4U= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akira.tsukamoto@aist.go.jp; Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com (20.178.140.147) by TYAPR01MB4046.jpnprd01.prod.outlook.com (20.178.136.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Fri, 3 Apr 2020 08:35:43 +0000 Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2]) by TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2%7]) with mapi id 15.20.2856.019; Fri, 3 Apr 2020 08:35:43 +0000 To: "teep@ietf.org" From: Akira Tsukamoto Message-ID: <9848943d-597d-8b11-5dd0-54beb97896a4@aist.go.jp> Date: Fri, 3 Apr 2020 17:35:42 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYAPR01CA0008.jpnprd01.prod.outlook.com (2603:1096:404::20) To TYAPR01MB3406.jpnprd01.prod.outlook.com (2603:1096:404:cc::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.123] (217.178.18.13) by TYAPR01CA0008.jpnprd01.prod.outlook.com (2603:1096:404::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Fri, 3 Apr 2020 08:35:42 +0000 X-Originating-IP: [217.178.18.13] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 78e4dee4-834a-4e51-09d4-08d7d7a9ff62 X-MS-TrafficTypeDiagnostic: TYAPR01MB4046: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0362BF9FDB X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3406.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(39860400002)(366004)(346002)(136003)(316002)(16576012)(6486002)(26005)(478600001)(31686004)(186003)(16526019)(66556008)(66476007)(66946007)(8936002)(2906002)(956004)(5660300002)(2616005)(44832011)(86362001)(52116002)(81156014)(31696002)(6916009)(8676002)(81166006)(4744005)(36756003); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sn4qYHjuWkTPeXf1LHU/Kx+CdZxTyL8Fe9HS+bYO4coqJVUzxfzwocogLCw53NebnqQ3V4ANQmzlzQby1JUMDY0ZAc73W1LFmA+/dGx6t4dOY8sI7obCg9+GPCHyisgpZ2VCKwKEG6aQuaf8nJFSjIvNNaRP/bim5XL/kBR1Svlvs5in96Va5CV+1oxgnJdBwwcE8m6679DpMeGu8HZvdn3CxUwD3zsdGlg6Oosyj/ipwrIA5FDwno4ymDBR4l32qXzqGCO6Jol4EYVQ60K3syNJ9dVqwPNkAuzn0rEMVhnqURPFvC3K6dMzYauk83+d45dvYJCC91/YkgxLqpLxojZmjF8ah2oL9IX6gUAA6YCvjd+8KV4YgGHSJuZHL7s3pLbv/EXhM90pbLW4S8sv+DpTZDSn+IlgByisW4qIIMYZ0V/cr4FatNMVdGuuCuAy X-MS-Exchange-AntiSpam-MessageData: oGvhkPWfmgaoqYBj5evLAveLoJfHjCmfhARdhZCSz6smZRtkUbksFIJiQSVb0m3Ht6NzsdHjFPjfTNGUWl1cHJPsrDx3f8oKrDcL7omFyiBGXwserI8CeHq2eSqYJvg2pypYWjKITxa6WWFH9hPfYA== X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 78e4dee4-834a-4e51-09d4-08d7d7a9ff62 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2020 08:35:43.1273 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: K7gKBv6mb85Cv/m0/mxTAhu7LQfEE2e2akXKZL4qUioHYPiJSt7705WztTHPKthz0WPx+Dh7Fbq/xoDDD8Bre8KGdtPs3EWH9teS1OKA/Nk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4046 Archived-At: Subject: [Teep] Size of NONCE in QueryRequest 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, 03 Apr 2020 08:35:47 -0000 Hi all, I would like to ask expertise in the mailing list. The QueryRequest has member of NONCE in representation of bstr in teep protocol draft. From the feedback from the virtual hackathon last week in Japan, I prefer using bstr less as possible and use number representation in int or uint since it reduces the size of the teep message and int/uint are more programing language friendly. Then I came across how large the integer could be to hold nonce in the member field. Currently it is: QueryRequest = { ... TOKEN : bstr, ... ? NONCE : bstr, ... } and would like to suggest QueryRequest = { ... TOKEN => uint .size 4, ... ? NONCE => uint .size 4, ... } but not sure the unsigned 32bit is large enough or not. The max of unsigned 32bit, 0x ff ff ff ff, is 4,294,967,295. And do we expect negative numbers here, if not would like to use uint instead of int? Any comments are welcome, Akira From nobody Fri Apr 3 03:55: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 5969D3A17AF for ; Fri, 3 Apr 2020 03:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=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=ziO/S9hb; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=ziO/S9hb Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdwsXuC0UncM for ; Fri, 3 Apr 2020 03:55:21 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00047.outbound.protection.outlook.com [40.107.0.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE203A17B1 for ; Fri, 3 Apr 2020 03:55:15 -0700 (PDT) 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=Sjg0lgVInxpfEzPEMy4r4MohnpGyMZUplbM8YnnbGBE=; b=ziO/S9hbU1A2jgB3/IqXHGiwu0dpnMh5+Sr73QkCkMZRvse1CvpUflUIjyKjrcOf1r288c0Vo/BNvD3ELwAPeEb/BO9icbZgZSB9L4OL7aDQ9d7IjbrK6pM6/9YL9d4wsv6BslEM+9Py5drzjc8CTic3f7Q5QTMK7aidt8kXRs8= Received: from DB6PR07CA0192.eurprd07.prod.outlook.com (2603:10a6:6:42::22) by AM6PR08MB3014.eurprd08.prod.outlook.com (2603:10a6:209:47::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.17; Fri, 3 Apr 2020 10:55:06 +0000 Received: from DB5EUR03FT056.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:42:cafe::7c) by DB6PR07CA0192.outlook.office365.com (2603:10a6:6:42::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.5 via Frontend Transport; Fri, 3 Apr 2020 10:55:06 +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.2856.17 via Frontend Transport; Fri, 3 Apr 2020 10:55:06 +0000 Received: ("Tessian outbound af37c2b81632:v50"); Fri, 03 Apr 2020 10:55:06 +0000 X-CR-MTA-TID: 64aa7808 Received: from b05c469252da.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C6871DDA-0151-4736-AA7D-0D788466738D.1; Fri, 03 Apr 2020 10:55:01 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b05c469252da.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Apr 2020 10:55:01 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H1scvo1zzbqWsxW6E2nW+0fuQXCDBRGZuHZHWx9CrBUtXwOTAFXOToONYnWYICO6rFJF2qeWUKWPVVvpMOnZVzS7PoHOIxeJqFAsdBMh8fLeLBh/LzLS3VRcCR95qXKiSm90J+4Gv3SXoWZBXoxBleNqealmNHS9rNeQtYOymVN0Sq3RmTmrrAxHfntQhvQWh2Itus7YqezB8J0W0btWTsBkd32aAuM3IY2PP382mow0+hRQQELomCa87PITEMe9aBnJTbzs0sXKG/vnzk1BzT7XRuPoZ0QXUmrGy7lrUyeAPY70qw+Gi3Nr9yzMH4Jokd4Y0c++YF0jNu6PCX/U2w== 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=Sjg0lgVInxpfEzPEMy4r4MohnpGyMZUplbM8YnnbGBE=; b=M056XlMzixTUeYZyFjZX8Lx515VcBUc1xNw1PSLEi+LntGHg2FfBXFQobnL1okLnYFal6F7/3OMwPLwd7v2sr5f47BW4DsjOHHQUdzzlnBuG2x7ZnglCGuiQEFHVoM7wu2XOCf4Bbsp+InS6fJ4L+6Zu6tMS3QVxWPvMavSUF4R/ablOP9K8eqnbHcKnra5p+TXM4SlXQpaCXVdtngL4Jru46n6YhKAAxW6NfdcyDtFTD8vgpHrPGbrQuANzVX+04k2OWqxuXWCatD1XXK330L6nLAMR+Ti5vjBWmkICsfTEiiOwLmYxCJiCiqTHHpVi02DaZnvqmXDD29kbkvXrWg== 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=Sjg0lgVInxpfEzPEMy4r4MohnpGyMZUplbM8YnnbGBE=; b=ziO/S9hbU1A2jgB3/IqXHGiwu0dpnMh5+Sr73QkCkMZRvse1CvpUflUIjyKjrcOf1r288c0Vo/BNvD3ELwAPeEb/BO9icbZgZSB9L4OL7aDQ9d7IjbrK6pM6/9YL9d4wsv6BslEM+9Py5drzjc8CTic3f7Q5QTMK7aidt8kXRs8= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0SPR01MB0077.eurprd08.prod.outlook.com (20.179.253.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Fri, 3 Apr 2020 10:55:00 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2878.018; Fri, 3 Apr 2020 10:55:00 +0000 From: Hannes Tschofenig To: Akira Tsukamoto , "teep@ietf.org" Thread-Topic: Nonce and Token ... was RE: [Teep] Size of NONCE in QueryRequest Thread-Index: AdYJpgCYNQqejMnoQse6d2Uo3YZ1iQ== Date: Fri, 3 Apr 2020 10:54:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 7ff3e445-70b4-435a-9d7e-c7c8bdd7e52c.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.214] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: adadb538-6f66-4e4a-880a-08d7d7bd7867 x-ms-traffictypediagnostic: AM0SPR01MB0077:|AM6PR08MB3014: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:2201;OLM:4502; x-forefront-prvs: 0362BF9FDB X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(136003)(396003)(366004)(39860400002)(376002)(66446008)(66556008)(5660300002)(53546011)(6506007)(55016002)(9686003)(66946007)(7696005)(64756008)(76116006)(86362001)(316002)(110136005)(8936002)(66476007)(71200400001)(478600001)(52536014)(966005)(81166006)(81156014)(186003)(8676002)(26005)(2906002)(33656002); DIR:OUT; SFP:1101; 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: 0JxhtLyuQdNwTjXw8p7KSiiBBtXY7F9NPmiw0vblxxeGMlWvmhlgusj19nET9mQhhtcufUTsLGMK+hK+q1seCBAHEDAZ98cLpAtUutVV6zm/zgEeVq7RjokmSvektZT2T5pHRAAxS9ZyWq1ONkqaMP8U4Nwv/mjPDOzq4btg/RrCG3edxCVKUOBkNk2Z1ygIYLXc+xPbxkvJWXwQPeLZZ/kthVu28O7FP4g3HyZVjdSahQwK8NEvt9BvfQnFF7FZY6R/beF85yzERtnMxnfI91UDwWgm2ygjRoBwotBe/xpyriNFHD5x7JMBPKEeFzwVqig9HAEoBdLSOcEZCmO+H2l3gLYgI9734uRQSigz7bzu60GAO4KW+kuggvhHBcWFPrFPn8d0bmlTsMjIpx1vkoM7PB3jGCYa1/T2fqPwOt1zqjlFjVMYbhxRF0p9o5rCArE2uAAOVnD78Aw8W+l+8LiQLY/BPTfXDfwOCY4cUPrQh9gZEyqDK8dGaUNgX5IiiB2lPFs2ka0DcwpkcoULag== x-ms-exchange-antispam-messagedata: bzqURR9IV5ToVMo0mGSdQ/lJc7HOnT+23acADLg+NEwHpMP4cgaabMCU02ZHwyUsOHTkWlk8Zr9hvvS2aPRmA+dOrvZWy7N9+xRCiOaXlOHbiJZinuGPKek3ZJmxNpyFqQ4Xwd7KxxyaDPaz06zQQw== 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: AM0SPR01MB0077 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; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(396003)(136003)(376002)(39860400002)(46966005)(26005)(53546011)(47076004)(8676002)(336012)(8936002)(52536014)(86362001)(356004)(186003)(5660300002)(110136005)(82740400003)(2906002)(316002)(478600001)(70206006)(9686003)(70586007)(81156014)(81166006)(26826003)(55016002)(7696005)(33656002)(966005)(6506007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 99c0262e-7cfe-4617-d7c7-08d7d7bd7491 X-Forefront-PRVS: 0362BF9FDB X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nh3ExSDIPr4C/uF6yHef0l2c0QoJfHn8oC/B6+gjT3nrri8HiGSSc8zTHYvrdYvQRErOcNs1foPLRqRN6IbFBztc9eNfeyAYpiksSLoOXm/qqzXWBKx7g9LksoA/QNVXQWr75ENoBrV57yCEK9LEN7+V5kbRV60OcK6s+RRWEKrIJhDBmDxxjjTDSbgK9+hf4g+ohiiMbIbh+Cgxo2qaLXBw7NPQEhUoiREugtxIMu4KUzC+xZTgtQ9yJa7Af7DSvn9vsmRG8Nq6OZgoq7fb1xWVE1FYIhUOyUsesCs4q8RPmFNyv3uZOoWHC6deWl1+iejEOZ8cKA+FVGT0GqHnWrQyQ/BjH+/dIZBh+/mfZnkevN4C1rJg8ghsLJshy7AgpK04LPrF62hUhWxmj4Cz5KavAD6drm11eJ1a4SaItuWQBkPMY3UW9u6gYvqOCAgiapKZs2N3wQgERtmhWs5tKus9749U0MaIqKzT9ZEY8QGyZVOAqyKK3pcAFiWZVMS6D3Ltma6i5v+W7mrAzNl3Jg72qpIN24nO8dkn5QdHr40Rag6L8qjfivTsTpDq/gO7You2Rq3eCgoVugQkKrCRAg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2020 10:55:06.4996 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: adadb538-6f66-4e4a-880a-08d7d7bd7867 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: AM6PR08MB3014 Archived-At: Subject: [Teep] Nonce and Token ... was RE: Size of NONCE in QueryRequest 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, 03 Apr 2020 10:55:38 -0000 Hi Akira The token is used to match the response to a request. Using an integer for = the token is fine. The nonce is used to providing freshness for the attestation token. The EAT= draft (see https://tools.ietf.org/html/draft-ietf-rats-eat-03#section-3.3)= says that it is a bstr (of size 8-64 bytes). I think it would be useful to align with the EAT draft when it comes to the= nonce. Ciao Hannes -----Original Message----- From: TEEP On Behalf Of Akira Tsukamoto Sent: Friday, April 3, 2020 10:36 AM To: teep@ietf.org Subject: [Teep] Size of NONCE in QueryRequest Hi all, I would like to ask expertise in the mailing list. The QueryRequest has member of NONCE in representation of bstr in teep prot= ocol draft. From the feedback from the virtual hackathon last week in Japan, I prefer = using bstr less as possible and use number representation in int or uint si= nce it reduces the size of the teep message and int/uint are more programin= g language friendly. Then I came across how large the integer could be to hold nonce in the memb= er field. Currently it is: QueryRequest =3D { .... TOKEN : bstr, .... ? NONCE : bstr, .... } and would like to suggest QueryRequest =3D { .... TOKEN =3D> uint .size 4, .... ? NONCE =3D> uint .size 4, .... } but not sure the unsigned 32bit is large enough or not. The max of unsigned 32bit, 0x ff ff ff ff, is 4,294,967,295. And do we expect negative numbers here, if not would like to use uint inste= ad of int? Any comments are welcome, Akira _______________________________________________ TEEP mailing list TEEP@ietf.org https://www.ietf.org/mailman/listinfo/teep 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 Fri Apr 3 04:27:41 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 358D43A0F28 for ; Fri, 3 Apr 2020 04:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 YzaO_Sqq11Ew for ; Fri, 3 Apr 2020 04:27:35 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 E78113A0F2B for ; Fri, 3 Apr 2020 04:27:26 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id j19so7294135wmi.2 for ; Fri, 03 Apr 2020 04:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Qi36l7RJNrLxAeEjXm61pcHO4bsimOmpIfDI7e7E2b8=; b=KetGKW/DVMKukNY2W9Bqv40irob93RC2VO29B68KJhM2CuZC7qVZFbKWEgHz+7504w e+3lHaUKPxL3yjp9d7D45lvk6Y513eOLgZ2chQe/GhBzt0YuKQwBSsbl2LXmykM9Xcq9 8SbgWp5RjhM51xpnqrJgHOL+kUJhO53wcxUN5LmEeU7+btx0XLqSt5FK09MwN9rQD471 aoCjjA0gd8Yvdwj5t1fHdBQN3piA+A9QrlCEcGCYFs5LNXdJHW4ctTfP2P9RYwI7f9PE Sx/sGIraDcnrv2o007Yffpce78HVBXKMMY+GYqgBNi3oIIWEgwOfdW6ZdU11v4zW2WzU Jh6g== 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:content-transfer-encoding; bh=Qi36l7RJNrLxAeEjXm61pcHO4bsimOmpIfDI7e7E2b8=; b=VrpSxzJp0L0p6p9GDKxM/Pwr+p5sx3AnHTKq6KVlzo7axGgk3D28z7wIV91FziFyWS 4YLqkIQo4+Ilj6Xwyakr0M2JguAM51QdGK9KRTWFRduuXEXZvOI8NJCcfvDSDKLzwBPX RaDWmusxR55knEYUyAG1S0qfm+5RErPKmCZBen2i1dokkDitijTbJaxwv5DSKBByA8Pr OFuk5z45KD906MS9VzUotp/kga0vB0A/JKsc2NvVm4oHSKL4+w11r0cmmopLSBV9eSIo TTEeCGmjqSTXObvl5KgtjTg997zrspyGmyOUeieChkhjiiKPR/WaQVCQ8HvIjlEObqMB MdTA== X-Gm-Message-State: AGi0Pua6FJW/rZY0aIiyjzLwKaDAOt5VWPDWdYOFRwsHKAAimPNNT5pg 0OJKGllHoj9ZSi49wYTHaOTV8YRCaWKKU50vB8c= X-Google-Smtp-Source: APiQypKEwGxui5GjXRu69qhpgxAfKueolhPswGuZ5ymGpWddmXEUzl86z8/Fug1rub4ShKo3uy2lvqGbxUqDPy14KOA= X-Received: by 2002:a1c:5401:: with SMTP id i1mr8434460wmb.172.1585913245076; Fri, 03 Apr 2020 04:27:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Akira Tsukamoto Date: Fri, 3 Apr 2020 20:27:14 +0900 Message-ID: To: Hannes Tschofenig Cc: Akira Tsukamoto , "teep@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Teep] Nonce and Token ... was RE: Size of NONCE in QueryRequest 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, 03 Apr 2020 11:27:40 -0000 Hi Hannes, Thanks for the clarification. Keeping the NONCE as the same with EAT draft sounds better. I will make the pull request or updating the token after I confirm the implementation. Thanks, -Akira On Fri, Apr 3, 2020 at 7:56 PM Hannes Tschofenig wrote: > > Hi Akira > > The token is used to match the response to a request. Using an integer fo= r the token is fine. > > The nonce is used to providing freshness for the attestation token. The E= AT draft (see https://tools.ietf.org/html/draft-ietf-rats-eat-03#section-3.= 3) says that it is a bstr (of size 8-64 bytes). > > I think it would be useful to align with the EAT draft when it comes to t= he nonce. > > Ciao > Hannes > > > > -----Original Message----- > From: TEEP On Behalf Of Akira Tsukamoto > Sent: Friday, April 3, 2020 10:36 AM > To: teep@ietf.org > Subject: [Teep] Size of NONCE in QueryRequest > > Hi all, > > I would like to ask expertise in the mailing list. > > The QueryRequest has member of NONCE in representation of bstr in teep pr= otocol draft. > > From the feedback from the virtual hackathon last week in Japan, I prefe= r using bstr less as possible and use number representation in int or uint = since it reduces the size of the teep message and int/uint are more program= ing language friendly. > > Then I came across how large the integer could be to hold nonce in the me= mber field. > > Currently it is: > > QueryRequest =3D { > ..... > TOKEN : bstr, > ..... > ? NONCE : bstr, > ..... > } > > and would like to suggest > > QueryRequest =3D { > ..... > TOKEN =3D> uint .size 4, > ..... > ? NONCE =3D> uint .size 4, > ..... > } > > but not sure the unsigned 32bit is large enough or not. > The max of unsigned 32bit, 0x ff ff ff ff, is 4,294,967,295. > And do we expect negative numbers here, if not would like to use uint ins= tead of int? > > Any comments are welcome, > > Akira > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://www.ietf.org/mailman/listinfo/teep > IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n any medium. Thank you. > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://www.ietf.org/mailman/listinfo/teep From nobody Fri Apr 3 04:31:59 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 5308B3A17D1 for ; Fri, 3 Apr 2020 04:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, 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=j11OPLNn; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=j11OPLNn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTgMiBXcUtBq for ; Fri, 3 Apr 2020 04:31:51 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2050.outbound.protection.outlook.com [40.107.20.50]) (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 7960C3A17CE for ; Fri, 3 Apr 2020 04:31:51 -0700 (PDT) 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=U3E3yYYO9RHcvkzHpEv14I0rcf+IpmNOQwjTDF/hEfI=; b=j11OPLNnowEKzByvWycw5x/L8jyHh+rm0oa42qntbCnC4u6/H0uGChUDsZYsXb7lw7gtEybHAa/Xo8pVEPo1mMvjtQ2NODkpHxE5nlXRWsahUkyZmf/n3dXMo4/5fJQaplK4TKdRYNuUb4yCAfleCbSC/MJZRZCAT1zckCVKh6E= Received: from AM6P192CA0037.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:82::14) by AM0PR08MB3220.eurprd08.prod.outlook.com (2603:10a6:208:57::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Fri, 3 Apr 2020 11:31:48 +0000 Received: from AM5EUR03FT052.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:82:cafe::c0) by AM6P192CA0037.outlook.office365.com (2603:10a6:209:82::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Fri, 3 Apr 2020 11:31:48 +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 AM5EUR03FT052.mail.protection.outlook.com (10.152.17.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Fri, 3 Apr 2020 11:31:47 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Fri, 03 Apr 2020 11:31:47 +0000 X-CR-MTA-TID: 64aa7808 Received: from a9d1f89af41c.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 855D4736-D0BD-4C64-93AE-1E4F9B357A0C.1; Fri, 03 Apr 2020 11:31:42 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a9d1f89af41c.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Apr 2020 11:31:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EU6l7RJR7DpUjo0V8rOw9Zmk+mqjp2gcqpnB4kjBlx548tTq7FXpoztHxhQWjSfsq1gEuNIWs24FayAZXg+0C/Mjnwef4GLvOMRv4HnRruZyaSDYoH3Hc3MuioFcNul5D4TVwi/UPl03x3DTU8ciWtygOj95OaCFtEy3sncX08AJ+NJQ4mJvVYfJNDZtzVb5fUWR7u3iQKDafIkEgsoGoXVB/+a7MZpOHg3eana2NnPrjL2FUrka898G7DLycua4XMD0AIy/1Y4VJw09LfGsjsyTCUTyC+O0+q/h803w1LZzlpvVLoXDKUBcyHEBrbmum7Txavf3eTff2bd56J6j/g== 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=U3E3yYYO9RHcvkzHpEv14I0rcf+IpmNOQwjTDF/hEfI=; b=ZzYs7KGrUxTz5nnsD9a4AHslQISh7/25BbtKS6b45OrVBgt3jHad32xXTL1/RspzleOKjvkbtnd6oJQQ5ZK0OlNveme/miTElqkd+5lMU6cTTrsKHrPVE8FOjS9+cEopPFdTpvgBZ3cIyiQ0Tbp/vwhhnQ9caflq+BYeKpF6dEzvmsdaX1CgBliJ0DhFXtsVTp6xYKqYTlqjloV+yjoV17FzVpkNxpWUjEWKPk9DMnasjk2ZANNw8F1SYJ3yCcDqRCmoojdxjUCfIxt2T8N+UlGogFapB8kDFyAKvEcUrzUgGb2/ijAJ0HwcKCbEEewenL043BCZzOCJpID3HTNVBw== 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=U3E3yYYO9RHcvkzHpEv14I0rcf+IpmNOQwjTDF/hEfI=; b=j11OPLNnowEKzByvWycw5x/L8jyHh+rm0oa42qntbCnC4u6/H0uGChUDsZYsXb7lw7gtEybHAa/Xo8pVEPo1mMvjtQ2NODkpHxE5nlXRWsahUkyZmf/n3dXMo4/5fJQaplK4TKdRYNuUb4yCAfleCbSC/MJZRZCAT1zckCVKh6E= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB5201.eurprd08.prod.outlook.com (10.255.29.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Fri, 3 Apr 2020 11:31:41 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2878.018; Fri, 3 Apr 2020 11:31:41 +0000 From: Hannes Tschofenig To: Akira Tsukamoto CC: Akira Tsukamoto , "teep@ietf.org" Thread-Topic: [Teep] Nonce and Token ... was RE: Size of NONCE in QueryRequest Thread-Index: AQHWCaraAygXhfrQ4kOFfIc5ogXHwahnQ4aw Date: Fri, 3 Apr 2020 11:31:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: dd842b56-b6be-4b4a-a989-afc6f303b5bd.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.214] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e893a5af-d96f-4dd3-c82f-08d7d7c29898 x-ms-traffictypediagnostic: AM0PR08MB5201:|AM0PR08MB3220: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6790;OLM:6790; x-forefront-prvs: 0362BF9FDB X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(396003)(366004)(376002)(39860400002)(346002)(6916009)(5660300002)(186003)(81166006)(9686003)(81156014)(8676002)(33656002)(26005)(2906002)(966005)(86362001)(52536014)(478600001)(66556008)(6506007)(53546011)(76116006)(64756008)(316002)(66446008)(4326008)(66946007)(7696005)(66476007)(71200400001)(8936002)(54906003)(55016002); DIR:OUT; SFP:1101; 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: qUUkunsIGBqurjmYKDuX1P5cWZB0+g8iBNasQ2W7Htcz0fp2nDOscaug7gOtJvcr2Lyyd6BZ1+i0y57O//78QooQV0uQnEoPfATTk4ytxDAVunRo3Uql4Gu8ctR8MYxSEyBy8LZfhek+NifsZhrEixDThvVwhtO0UkRbTom30SxqzjRAEYHd+krdeU72AiGjpgSKNd3XTsADAb0ivDRbucGAglvf7w6b0LHSDgUS2pdGXglRXhfp2VBZ9rHz2/bXCFUptOr9viw+Bd97NugZTYxsWPloGjDHueXZna8AOmNZmPraijBrH0fm2dm+sVY+us+alXQc0/RzmXz0VLpAt/SR9hSjjGX43tgwueD0toaqNBOhWwzsipHTff7DLMJObSdzmBgqTyX6K5HYa6E+3uUOBB+2KjWZ+ZwjWfRKXGqi+OnACjmDongzNwhaSOieV2vRqSLSklaVBetJk6iZhaoApYT0veTeW5/uxt4XluuT43ryJ/18wimPuJXO05xJ4EwlByYEBkTkJAbQaq4fKQ== x-ms-exchange-antispam-messagedata: /gD8uzrHb4+81c3jIjX5xngzXb7rYBw0zK8teEb+K6nfGFGRKqXTIelz+8a0JjehP7KFlgPKp7i8r6N3VS+MaFYYA5ihFt4egn1t/cHbgsgqc3Q0qLD3x+p/ndbl+kJFIcgxVq4Shy6cj+V6WxVC9A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5201 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT052.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(346002)(376002)(46966005)(316002)(26826003)(55016002)(53546011)(6862004)(6506007)(70206006)(336012)(4326008)(70586007)(7696005)(356004)(8936002)(54906003)(36906005)(81166006)(26005)(9686003)(86362001)(8676002)(5660300002)(966005)(2906002)(478600001)(82740400003)(81156014)(186003)(52536014)(33656002)(47076004); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 007d8513-4729-4718-c8c3-08d7d7c294b2 X-Forefront-PRVS: 0362BF9FDB X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZLBL47uvQQQsIupAOyV1fHw6oNVu7DQr9oomoq3xw1Efd1jxqLjpbEnL/VgX+9OktglEiMB+2rfjDVJCiMEx2TAIHU5U/nkk/B0ZDcwuPBdAYk4BQn7krmzwop2EPNCKawTYlwSd7rlLvntHbrFhDCLXUTE0CCTDvKeivK9zJSzGseNMKswpDUNCkn80p40iME02563sdI5qhqlKlqvEiK6hSAFfoLpHGmPlvQUlGMvIZBPlVuorQfWqgqaitBrNraJBeRkRdOBAsYXK3vvTlVlsR+mkkOQXkjT+OxF1nc+nN2AfeCDiqVlnluud70NVTq0K5jxBrPm//xZ+dImB5Lxn1rO4PuzTOP7Og88OFYCN4u5nDVE2LezNVO0VJrn96yanHpaYm2D6CdS7fV6uMzhj8kBg2NI23ejWWs2E+DiBq63RlVA413ewqcI6S1fD+SFeiu7Or/2mCOnSMZosbLF5lFVLRLyOQ+OWIZPKG1iqvKK6eC2LJKVzpusZhiISiwVyouXMDRHqiIPyln/LahXagrpigbqE0mPpSjFIrQfGUAyNlEXawfeN3p3svi9bH/fcXpQkETYZaSIR7ih+gQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2020 11:31:47.9240 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e893a5af-d96f-4dd3-c82f-08d7d7c29898 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: AM0PR08MB3220 Archived-At: Subject: Re: [Teep] Nonce and Token ... was RE: Size of NONCE in QueryRequest 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, 03 Apr 2020 11:31:57 -0000 VGhhbmtzLCBBa2lyYS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFraXJh IFRzdWthbW90byA8YWtpcmEudHN1a2Ftb3RvQGdtYWlsLmNvbT4NClNlbnQ6IEZyaWRheSwgQXBy aWwgMywgMjAyMCAxOjI3IFBNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2Zl bmlnQGFybS5jb20+DQpDYzogQWtpcmEgVHN1a2Ftb3RvIDxha2lyYS50c3VrYW1vdG9AYWlzdC5n by5qcD47IHRlZXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVGVlcF0gTm9uY2UgYW5kIFRva2Vu IC4uLiB3YXMgUkU6IFNpemUgb2YgTk9OQ0UgaW4gUXVlcnlSZXF1ZXN0DQoNCkhpIEhhbm5lcywN Cg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4NCg0KS2VlcGluZyB0aGUgTk9OQ0UgYXMg dGhlIHNhbWUgd2l0aCBFQVQgZHJhZnQgc291bmRzIGJldHRlci4NCg0KSSB3aWxsIG1ha2UgdGhl IHB1bGwgcmVxdWVzdCBvciB1cGRhdGluZyB0aGUgdG9rZW4gYWZ0ZXIgSSBjb25maXJtIHRoZSBp bXBsZW1lbnRhdGlvbi4NCg0KVGhhbmtzLA0KLUFraXJhDQoNCk9uIEZyaSwgQXByIDMsIDIwMjAg YXQgNzo1NiBQTSBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4g d3JvdGU6DQo+DQo+IEhpIEFraXJhDQo+DQo+IFRoZSB0b2tlbiBpcyB1c2VkIHRvIG1hdGNoIHRo ZSByZXNwb25zZSB0byBhIHJlcXVlc3QuIFVzaW5nIGFuIGludGVnZXIgZm9yIHRoZSB0b2tlbiBp cyBmaW5lLg0KPg0KPiBUaGUgbm9uY2UgaXMgdXNlZCB0byBwcm92aWRpbmcgZnJlc2huZXNzIGZv ciB0aGUgYXR0ZXN0YXRpb24gdG9rZW4uIFRoZSBFQVQgZHJhZnQgKHNlZSBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yYXRzLWVhdC0wMyNzZWN0aW9uLTMuMykgc2F5cyB0 aGF0IGl0IGlzIGEgYnN0ciAob2Ygc2l6ZSA4LTY0IGJ5dGVzKS4NCj4NCj4gSSB0aGluayBpdCB3 b3VsZCBiZSB1c2VmdWwgdG8gYWxpZ24gd2l0aCB0aGUgRUFUIGRyYWZ0IHdoZW4gaXQgY29tZXMg dG8gdGhlIG5vbmNlLg0KPg0KPiBDaWFvDQo+IEhhbm5lcw0KPg0KPg0KPg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBURUVQIDx0ZWVwLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBBa2lyYSBUc3VrYW1vdG8NCj4gU2VudDogRnJpZGF5LCBBcHJpbCAzLCAyMDIw IDEwOjM2IEFNDQo+IFRvOiB0ZWVwQGlldGYub3JnDQo+IFN1YmplY3Q6IFtUZWVwXSBTaXplIG9m IE5PTkNFIGluIFF1ZXJ5UmVxdWVzdA0KPg0KPiBIaSBhbGwsDQo+DQo+IEkgd291bGQgbGlrZSB0 byBhc2sgZXhwZXJ0aXNlIGluIHRoZSBtYWlsaW5nIGxpc3QuDQo+DQo+IFRoZSBRdWVyeVJlcXVl c3QgaGFzIG1lbWJlciBvZiBOT05DRSBpbiByZXByZXNlbnRhdGlvbiBvZiBic3RyIGluIHRlZXAg cHJvdG9jb2wgZHJhZnQuDQo+DQo+ICBGcm9tIHRoZSBmZWVkYmFjayBmcm9tIHRoZSB2aXJ0dWFs IGhhY2thdGhvbiBsYXN0IHdlZWsgaW4gSmFwYW4sIEkgcHJlZmVyIHVzaW5nIGJzdHIgbGVzcyBh cyBwb3NzaWJsZSBhbmQgdXNlIG51bWJlciByZXByZXNlbnRhdGlvbiBpbiBpbnQgb3IgdWludCBz aW5jZSBpdCByZWR1Y2VzIHRoZSBzaXplIG9mIHRoZSB0ZWVwIG1lc3NhZ2UgYW5kIGludC91aW50 IGFyZSBtb3JlIHByb2dyYW1pbmcgbGFuZ3VhZ2UgZnJpZW5kbHkuDQo+DQo+IFRoZW4gSSBjYW1l IGFjcm9zcyBob3cgbGFyZ2UgdGhlIGludGVnZXIgY291bGQgYmUgdG8gaG9sZCBub25jZSBpbiB0 aGUgbWVtYmVyIGZpZWxkLg0KPg0KPiBDdXJyZW50bHkgaXQgaXM6DQo+DQo+IFF1ZXJ5UmVxdWVz dCA9IHsNCj4gLi4uLi4NCj4gICAgICAgVE9LRU4gOiBic3RyLA0KPiAuLi4uLg0KPiAgICAgICA/ IE5PTkNFIDogYnN0ciwNCj4gLi4uLi4NCj4gfQ0KPg0KPiBhbmQgd291bGQgbGlrZSB0byBzdWdn ZXN0DQo+DQo+IFF1ZXJ5UmVxdWVzdCA9IHsNCj4gLi4uLi4NCj4gICAgICAgVE9LRU4gPT4gdWlu dCAuc2l6ZSA0LA0KPiAuLi4uLg0KPiAgICAgICA/IE5PTkNFID0+IHVpbnQgLnNpemUgNCwNCj4g Li4uLi4NCj4gfQ0KPg0KPiBidXQgbm90IHN1cmUgdGhlIHVuc2lnbmVkIDMyYml0IGlzIGxhcmdl IGVub3VnaCBvciBub3QuDQo+IFRoZSBtYXggb2YgdW5zaWduZWQgMzJiaXQsIDB4IGZmIGZmIGZm IGZmLCBpcyA0LDI5NCw5NjcsMjk1Lg0KPiBBbmQgZG8gd2UgZXhwZWN0IG5lZ2F0aXZlIG51bWJl cnMgaGVyZSwgaWYgbm90IHdvdWxkIGxpa2UgdG8gdXNlIHVpbnQgaW5zdGVhZCBvZiBpbnQ/DQo+ DQo+IEFueSBjb21tZW50cyBhcmUgd2VsY29tZSwNCj4NCj4gQWtpcmENCj4NCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVEVFUCBtYWlsaW5nIGxp c3QNCj4gVEVFUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RlZXANCj4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwg YW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2 aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUg b3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBURUVQIG1h aWxpbmcgbGlzdA0KPiBURUVQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGVlcA0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMg ZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBi ZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Fri Apr 3 06:57:44 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 BCFD23A0799 for ; Fri, 3 Apr 2020 06:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCrJqJMcBYY5 for ; Fri, 3 Apr 2020 06:57:42 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D2E3A079A for ; Fri, 3 Apr 2020 06:57:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C8C79300B09 for ; Fri, 3 Apr 2020 09:57:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CdmZxtWAnzn9 for ; Fri, 3 Apr 2020 09:57:38 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 9873F300A91; Fri, 3 Apr 2020 09:57:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: <9848943d-597d-8b11-5dd0-54beb97896a4@aist.go.jp> Date: Fri, 3 Apr 2020 09:57:40 -0400 Cc: "teep@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2532F840-7951-441F-B635-B784BD4F7592@vigilsec.com> References: <9848943d-597d-8b11-5dd0-54beb97896a4@aist.go.jp> To: Akira Tsukamoto X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Teep] Size of NONCE in QueryRequest 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, 03 Apr 2020 13:57:44 -0000 What is the NONCE supposed to do here? If it is replay protection, 4 = bytes is not enough. For example, OCSP uses up to 32 bytes. Russ > On Apr 3, 2020, at 4:35 AM, Akira Tsukamoto = wrote: >=20 > Hi all, >=20 > I would like to ask expertise in the mailing list. >=20 > The QueryRequest has member of NONCE in representation of bstr > in teep protocol draft. >=20 > =46rom the feedback from the virtual hackathon last week in Japan, > I prefer using bstr less as possible and use number representation > in int or uint since it reduces the size of the teep message and > int/uint are more programing language friendly. >=20 > Then I came across how large the integer could be to hold nonce > in the member field. >=20 > Currently it is: >=20 > QueryRequest =3D { > .... > TOKEN : bstr, > .... > ? NONCE : bstr, > .... > } >=20 > and would like to suggest >=20 > QueryRequest =3D { > .... > TOKEN =3D> uint .size 4, > .... > ? NONCE =3D> uint .size 4, > .... > } >=20 > but not sure the unsigned 32bit is large enough or not. > The max of unsigned 32bit, 0x ff ff ff ff, is 4,294,967,295. > And do we expect negative numbers here, if not would like to use uint = instead of int? >=20 > Any comments are welcome, >=20 > Akira From nobody Fri Apr 3 08:01: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 B5E813A16C8 for ; Fri, 3 Apr 2020 08:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_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=aCR4vPy7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=eJ3XlXvY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvEe8vZS4TyS for ; Fri, 3 Apr 2020 08:01:10 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEECC3A166F for ; Fri, 3 Apr 2020 08:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2784; q=dns/txt; s=iport; t=1585926069; x=1587135669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OGojkUMHS/bDnSSlQtD5YS0Olzx1t8N8ePdZsEZdHLc=; b=aCR4vPy7Ce8GzGePK4cBKfp6Lb5oVT6Bgmif1PULoyVdKKk3JC+fnpGI 8WQP7ospd1uN+ijuSApB2pn5MiNUcudYDgPaPamiPsK+yx5K9rqN6BMYt Rsj/wRBL7pkiaLQXiQVRxO7WO10lsOS5q8fwwDc7vH1J4Xn2cATWqTq4T g=; IronPort-PHdr: =?us-ascii?q?9a23=3AUeKxkRBc9mrtIs0R5BlrUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuKvXjajM7GstqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAABhTode/5xdJa1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFqAgEBAQELAYFTUAVsWCAECyoKhBGDRQOKZIJ?= =?us-ascii?q?fmB6CUgNUCgEBAQwBARgLCgIEAQGERAIXgi8kNwYOAgMBAQsBAQUBAQECAQU?= =?us-ascii?q?EbYVWDIVwAQEBAQIBAQEQEREMAQEpAwsBDwIBCBgCAiYCAgIlCxUQAgQBDQU?= =?us-ascii?q?igwQBgksDDiABDqNoAoE5iGJ1gTKCfwEBBYJFgnkYggwDBoEOKgGMMBqCAIE?= =?us-ascii?q?RJxyCHy4+gmcBAYF8gnsygiyRA58aeQqCPZclHZwAjzKcHQIEAgQFAg4BAQW?= =?us-ascii?q?BaCOBV3AVOyoBgj5QGA2OHQkDF4NQhRSFQXSBKY0ZAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.72,340,1580774400"; d="scan'208";a="472931609" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Apr 2020 15:01:09 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 033F18uD008636 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Apr 2020 15:01:08 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 10:01:08 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 3 Apr 2020 10:01:08 -0500 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.1497.2 via Frontend Transport; Fri, 3 Apr 2020 10:01:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CXQPuf67dCtKSh4LgH4gJB7ZUb6MMmh6Uvu5IUvM9+MVPDos2pV7159wG/Ff5630h3vHPuRi/nrVIiVHqKQEaxEkTPdaQ56Hh6XJsAnw/kGbVvw5sy8tik2xyKAplEZ52H8+WS9lHRxvOetDkeEKM0FrmR/FR99/tt6pYzVRHjFo3XEHygUHuY5sqkq1mGgvuYU9DzLcdlaSRR8FvtcrezZGyIYgs0ZTRt6LDB6FgmXcVGxOPeckf/9lqJIXcK6yR38Jmm1nemPRH6vFavyxyW5S4WFHznr49lpRjOPo3HKY29I9Yts59pZdcqy+UK18ut9M/miXO8sR0s87JInggA== 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=OGojkUMHS/bDnSSlQtD5YS0Olzx1t8N8ePdZsEZdHLc=; b=iaIL+ysJAsS/VDmZXsIUJp3I+o1pA3rrZFOzlbILZsw9zhElsLo8keEK0Fdu0HudDqh1oGDuJfFuHy1ypYVwteXnQVhRLRMVhGXAqxkR/9RrMvNDbSu5HxorGYQRTHwO1w35MeR4dTqzjx/zdNt3keGZ+xK2s0Spl5GPuH1ttDGDKBUSeHkCMRUBEvUJ1S5ZBPfEi5rLUZJ+RIuCuQ857soYW97ctEAlrinvswsmcohqeyf4+ctGHbqhB120l0ZvAWGHpTpsIyFg/9xFF5K0l44z2+ifUpHO6rF8aAnpHlP94Lf/SaDnRHBumNsHV3d+8tIwDd8AmPTZ9vgWZJVu7g== 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=OGojkUMHS/bDnSSlQtD5YS0Olzx1t8N8ePdZsEZdHLc=; b=eJ3XlXvY2H9yzLbedhgJ7tWzXIzijteExQ8bMqxdQWT++XlU3FgV1a/5Wjv+AQUwqGwNnY9OpW2yYNSuniDqFE8oIZkFd97pl3rgzxj4gMzZO9wDtD8kPTpB0aQmkwFAsPWZPO8w56fwKBNt+l4rhWiJ2eC/as4zqOB6sUhVrM8= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB4225.namprd11.prod.outlook.com (2603:10b6:a03:1ba::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.17; Fri, 3 Apr 2020 15:01:07 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::852d:fab4:18c1:72d2]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::852d:fab4:18c1:72d2%7]) with mapi id 15.20.2856.019; Fri, 3 Apr 2020 15:01:07 +0000 From: "Nancy Cam-Winget (ncamwing)" To: Russ Housley , Akira Tsukamoto CC: "teep@ietf.org" Thread-Topic: [Teep] Size of NONCE in QueryRequest Thread-Index: AQHWCZLm+wKwvUknwE2DYxgRFGsi8ahnbIcA//+cX4A= Date: Fri, 3 Apr 2020 15:01:06 +0000 Message-ID: References: <9848943d-597d-8b11-5dd0-54beb97896a4@aist.go.jp> <2532F840-7951-441F-B635-B784BD4F7592@vigilsec.com> In-Reply-To: <2532F840-7951-441F-B635-B784BD4F7592@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.14.200307 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 07f46e32-ae43-4c57-26fb-08d7d7dfd66d x-ms-traffictypediagnostic: BY5PR11MB4225: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(376002)(366004)(136003)(2906002)(66556008)(66946007)(71200400001)(64756008)(4326008)(966005)(66476007)(86362001)(76116006)(66446008)(6486002)(186003)(81156014)(26005)(6512007)(478600001)(110136005)(2616005)(8676002)(8936002)(33656002)(81166006)(53546011)(5660300002)(6506007)(316002)(36756003); DIR:OUT; SFP:1101; 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: tirJ0SNu/UYmUMAb9sWlLUo/yeTn5O+4ddqzxBvMcacFg2SQe1lmiYzny+bdUQ+hjRynwVGcHhcz34eYNj4DpSM/m1bd/3CUHKIKh8cJg5WvzOIZ/Z3zRTWGJnmdspnrhugq6F6mEYWsGk79iM8cFLU0F97M8aaaVeieQ2O04WaMf8A5C2m0Fkp/OPfVfNjxj5TN/u/IDeMVugca0SEHVEftfS5nhHdGCBtejApopaLT0XA37EYcrnTuqFWAjLCmlbXirURuMJKK8ZrH/l9pXH2oPuMG63Misk4qP0flPBu3n9nIxI2wh/uQjsNoMW2jzMC7A7nzjYgPqbMhFh2fu9cWCMy17/qfvRUmDmcFWqwltNOSga2LDnlVgd+R7HMTh5WkzTqWkxPHv45d5722sVimT1V8MEANkNemOgd0z994+O1wG7ZuGcCrb9Yx8lPkB/amA5gWRyjkOH2ZZs4Wm+edWUZJCcHZWmnUcfxkPurWI/W4k1y4RLXyhoccHjgGxFVeQMBFIhU/2Dff/ox84g== x-ms-exchange-antispam-messagedata: JvvagrhOhKHpwegiZfJ08fZEMrSb2bCBkAtJGfcXoLqkyuBY6gBmM79vCWE2ffEpOTRAM2P18O8OT6diYgA6j1p4MjdNP3LM7f9/A5hlKGCHvSZLZrlj1R9xsEM7lGP1mVfzZ3l/Z7o3xQGD4no/fw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 07f46e32-ae43-4c57-26fb-08d7d7dfd66d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 15:01:06.9622 (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: caEu3NkIQP57X26MyRgfg10X178srYr9Qx3AdK20/F+my/frjhkOfuWUdCszP+8fojH8JvLvTMRmSJDsZG1gXg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4225 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Teep] Size of NONCE in QueryRequest 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, 03 Apr 2020 15:01:13 -0000 SGkgUnVzcyBhbmQgQWtpcmEsDQpZZXMgdGhlIE5vbmNlIGlzIGZvciByZXBsYXkuLi5pbiBURUVQ IHRoZXJlIHdhcyBjb25zZW5zdXMgdG8gdXNlIFJBVHMgY2xhaW1zLiAgVGhhdCBzYWlkLCB0aGUg Tm9uY2UgY2xhaW0gaW4gUkFUUyBpcyBhIG1pbmltdW0gOGJ5dGVzIHdpdGggYSBtYXggb2YgNjQu ICBJIGFncmVlIHRoYXQgNCBpcyBub3QgZW5vdWdoLi4uLmJ1dCB3aGF0IGlzIHRoZSBhcHByb3By aWF0ZSBzaXplIGZvciBURUVQPyAgUGVyaGFwcyAxNj8NCg0KCU5hbmN5DQoNCu+7v09uIDQvMy8y MCwgNjo1NyBBTSwgIlRFRVAgb24gYmVoYWxmIG9mIFJ1c3MgSG91c2xleSIgPHRlZXAtYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0KDQog ICAgV2hhdCBpcyB0aGUgTk9OQ0Ugc3VwcG9zZWQgdG8gZG8gaGVyZT8gSWYgaXQgaXMgcmVwbGF5 IHByb3RlY3Rpb24sIDQgYnl0ZXMgaXMgbm90IGVub3VnaC4gIEZvciBleGFtcGxlLCBPQ1NQIHVz ZXMgdXAgdG8gMzIgYnl0ZXMuDQogICAgDQogICAgUnVzcw0KICAgIA0KICAgIA0KICAgID4gT24g QXByIDMsIDIwMjAsIGF0IDQ6MzUgQU0sIEFraXJhIFRzdWthbW90byA8YWtpcmEudHN1a2Ftb3Rv QGFpc3QuZ28uanA+IHdyb3RlOg0KICAgID4gDQogICAgPiBIaSBhbGwsDQogICAgPiANCiAgICA+ IEkgd291bGQgbGlrZSB0byBhc2sgZXhwZXJ0aXNlIGluIHRoZSBtYWlsaW5nIGxpc3QuDQogICAg PiANCiAgICA+IFRoZSBRdWVyeVJlcXVlc3QgaGFzIG1lbWJlciBvZiBOT05DRSBpbiByZXByZXNl bnRhdGlvbiBvZiBic3RyDQogICAgPiBpbiB0ZWVwIHByb3RvY29sIGRyYWZ0Lg0KICAgID4gDQog ICAgPiBGcm9tIHRoZSBmZWVkYmFjayBmcm9tIHRoZSB2aXJ0dWFsIGhhY2thdGhvbiBsYXN0IHdl ZWsgaW4gSmFwYW4sDQogICAgPiBJIHByZWZlciB1c2luZyBic3RyIGxlc3MgYXMgcG9zc2libGUg YW5kIHVzZSBudW1iZXIgcmVwcmVzZW50YXRpb24NCiAgICA+IGluIGludCBvciB1aW50IHNpbmNl IGl0IHJlZHVjZXMgdGhlIHNpemUgb2YgdGhlIHRlZXAgbWVzc2FnZSBhbmQNCiAgICA+IGludC91 aW50IGFyZSBtb3JlIHByb2dyYW1pbmcgbGFuZ3VhZ2UgZnJpZW5kbHkuDQogICAgPiANCiAgICA+ IFRoZW4gSSBjYW1lIGFjcm9zcyBob3cgbGFyZ2UgdGhlIGludGVnZXIgY291bGQgYmUgdG8gaG9s ZCBub25jZQ0KICAgID4gaW4gdGhlIG1lbWJlciBmaWVsZC4NCiAgICA+IA0KICAgID4gQ3VycmVu dGx5IGl0IGlzOg0KICAgID4gDQogICAgPiBRdWVyeVJlcXVlc3QgPSB7DQogICAgPiAuLi4uDQog ICAgPiAgICAgVE9LRU4gOiBic3RyLA0KICAgID4gLi4uLg0KICAgID4gICAgID8gTk9OQ0UgOiBi c3RyLA0KICAgID4gLi4uLg0KICAgID4gfQ0KICAgID4gDQogICAgPiBhbmQgd291bGQgbGlrZSB0 byBzdWdnZXN0DQogICAgPiANCiAgICA+IFF1ZXJ5UmVxdWVzdCA9IHsNCiAgICA+IC4uLi4NCiAg ICA+ICAgICBUT0tFTiA9PiB1aW50IC5zaXplIDQsDQogICAgPiAuLi4uDQogICAgPiAgICAgPyBO T05DRSA9PiB1aW50IC5zaXplIDQsDQogICAgPiAuLi4uDQogICAgPiB9DQogICAgPiANCiAgICA+ IGJ1dCBub3Qgc3VyZSB0aGUgdW5zaWduZWQgMzJiaXQgaXMgbGFyZ2UgZW5vdWdoIG9yIG5vdC4N CiAgICA+IFRoZSBtYXggb2YgdW5zaWduZWQgMzJiaXQsIDB4IGZmIGZmIGZmIGZmLCBpcyA0LDI5 NCw5NjcsMjk1Lg0KICAgID4gQW5kIGRvIHdlIGV4cGVjdCBuZWdhdGl2ZSBudW1iZXJzIGhlcmUs IGlmIG5vdCB3b3VsZCBsaWtlIHRvIHVzZSB1aW50IGluc3RlYWQgb2YgaW50Pw0KICAgID4gDQog ICAgPiBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUsDQogICAgPiANCiAgICA+IEFraXJhDQogICAg DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICBURUVQIG1haWxpbmcgbGlzdA0KICAgIFRFRVBAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RlZXANCiAgICANCg0K From nobody Fri Apr 3 19:26:51 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 43ECB3A0640 for ; Fri, 3 Apr 2020 19:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 j9rt52zAYDoC for ; Fri, 3 Apr 2020 19:26:47 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2108.outbound.protection.outlook.com [40.107.243.108]) (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 195273A05A7 for ; Fri, 3 Apr 2020 19:26:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nq2tZrgbZIEItNcCtJBJKK8kmPzN4wx/uB4eQYC4gbaGaKPWqA+XMmJTf57a8bu2HzD6Zil+Qd7HuT4QLBpkdCfem7QVXogqAK4EbK0N+rWwji1V3phFaKpjPz4C7hXxLb36OmMTUFQ/tie21BL+jIU6EIVRebhM3Y6/Jw/kd4tJdYfmZvblUM1pHPi105G+MblqB1zCSiMBjjnMgSjDwwSaDgsi3NpHEUEE/IacIVO1y3QahR/EUx0C2J1c0Y8ZF57884mslBc5GiB1DdRb/t0Myn6Hgh1eWiqqVW8h+hR99GPQN2Pd5eXzEN4WGz5QhaQCPnjsw+XjoHzbJHTNbg== 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=6ltPFRI//G2fcVtAAEIO5hpJWp8pEmEVkhps+vq3Ulw=; b=Dz3yqC/Q7n5IIPOj/cbYu5rBHUzmmumwRHHIf5tfGRtW6+R2HbRmMGS+6I0au4UjraP0mE9GyQlB1RK6/3Awfpwt/3NS5jHARNvyDxtJ8e+sw5KRELf+MTgkR7qy+hnM0gpLPshTTHy+PALZbbc9YB0vc9F2ogR7SDOGmZNz4atLo9bJB8cd8JGCg0WnFL5vxtTI2hwXLgjw0PszT2SHY7yiZZQDju1C0S+5FtemVRAQhJg+33gD1hzLZznNoIcqsj64TEhxmSeDL4ZMtVcN7/aF7drO8GWFr8PVp3QTlGDQFXW4ATXxmpJbOxQZYoHOOYT5T6loHU+VG+fgA3b9Gw== 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=6ltPFRI//G2fcVtAAEIO5hpJWp8pEmEVkhps+vq3Ulw=; b=SFdFVCj6xIWarW15JRRXWyoN7DNU6pJG6LVGSyYIh2GvphT+Chhm46lO9KLsM06eMZkhdfwV4AbQZltIlTNd3Ycb8hGsIksekmsQxU0zj4sVT4wWfA9iZ5UbypGe7ako9NUln6JsL+lNzAe9TDSla40FA5gh2TBVqCTyLNhFvfk= Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by BL0PR2101MB1331.namprd21.prod.outlook.com (2603:10b6:208:92::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.2; Sat, 4 Apr 2020 02:26:45 +0000 Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::e5f4:bd2b:d304:bfc9]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::e5f4:bd2b:d304:bfc9%5]) with mapi id 15.20.2900.012; Sat, 4 Apr 2020 02:26:45 +0000 From: Dave Thaler To: "Nancy Cam-Winget (ncamwing)" , Russ Housley , Akira Tsukamoto CC: "teep@ietf.org" Thread-Topic: [Teep] Size of NONCE in QueryRequest Thread-Index: AQHWCZLjM+0S3ytUD0qsNMKhnG52s6hnbIcAgAARuQCAAL9wsA== Date: Sat, 4 Apr 2020 02:26:45 +0000 Message-ID: References: <9848943d-597d-8b11-5dd0-54beb97896a4@aist.go.jp> <2532F840-7951-441F-B635-B784BD4F7592@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2601:600:9780:16f0:9e4:140:d378:ab70] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d60f21f9-25e0-4794-6a11-08d7d83f9ef1 x-ms-traffictypediagnostic: BL0PR2101MB1331: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03630A6A4A x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR2101MB1027.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10019020)(4636009)(136003)(396003)(366004)(346002)(39860400002)(376002)(9686003)(4326008)(82950400001)(82960400001)(110136005)(8990500004)(81156014)(2906002)(52536014)(76116006)(86362001)(81166006)(6506007)(53546011)(8936002)(33656002)(55016002)(966005)(66446008)(64756008)(478600001)(66476007)(10290500003)(66946007)(7696005)(186003)(5660300002)(71200400001)(66556008)(316002)(8676002); DIR:OUT; SFP:1102; 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: 9ssfDybEMpkNdiGf9z4V0CU72ph6RHfWA5j67qUwabn5yeuULJE9XwACCGdMt41w2ZjesjEU1FMrbCBFQiHty5Q+UeaGuSrGn/XohLOGTlcloQ4Bzbmt6mgPnn3VXHz2hJHnP0rcToNJiI6/ys1ToQV+ue31nM2DSAOxVacLAxrU/06bN+33G5YLQZDrsXnmxagY91nfoDb9TINQBr2f2nWhXZvRwGyKNybETytQCgQcCzDHJhj8hLmeDLFOgAG0Uzn4f3RI67ql70hor3t8jbTBRJRKXS9NOaY9YwvHoOUXZN6vVNUL3DZNAamaAjvkIUtngPRxWu7EoxifBWTc6t/uUzt5hzegLO9RQO3feqQ7rvJtGqTkma9fX3mHIhSpBmmML+HQ71CbfI2vpsdSycPz+p52eiSbQyqua98jfTM3FPN3Iz6ZrWKeIW2FiJSPH0ev6hlIeoPZxCMzu4XhEBMONjdRkcrnQeIpn9cpdM//lHjOIgUAK4BQf3Ex0ixkGB3P2kxG78LQjnBwTADF0Q== x-ms-exchange-antispam-messagedata: hdfd7WizUWW2LT43S3LiPTtiUz9yhrBijF3xx/hZQE78y27770QFJFFfGvKVbyxR+Z1XK4ly3WsoVE2DAKOKNfED4k5diG79pQyDQ2YfhjJbo43KjKfjyGRAWd2CW161mOkCK1arJ1D7aopVHdYEH4g6WoFrFY7yjfztUCwgdwYIRDHAGAdoE8ks7xeO85GFDr/2C9Vfj7Io3kWcAsMYlA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: d60f21f9-25e0-4794-6a11-08d7d83f9ef1 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2020 02:26:45.6375 (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: 8Yt8Ox423nQbg0nRRb+4BeCcwTvB0ZqWjI+s8K7dtlf5eEXW6B59bwikrVUZLRxpR8Fzh0cxRsUfjhXStEkEVYa2VJFsf0XE9GS2tOdtLCA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1331 Archived-At: Subject: Re: [Teep] Size of NONCE in QueryRequest 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: Sat, 04 Apr 2020 02:26:50 -0000 SW4gbXkgaW1wbGVtZW50YXRpb24gSSBhbSBjdXJyZW50bHkgdXNpbmcgYSBVVUlELCB3aGljaCBp cyAxNiBieXRlcy4NCg0KRGF2ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog VEVFUCA8dGVlcC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTmFuY3kgQ2FtLVdpbmdl dCAobmNhbXdpbmcpDQpTZW50OiBGcmlkYXksIEFwcmlsIDMsIDIwMjAgODowMSBBTQ0KVG86IFJ1 c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+OyBBa2lyYSBUc3VrYW1vdG8gPGFraXJh LnRzdWthbW90b0BhaXN0LmdvLmpwPg0KQ2M6IHRlZXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb VGVlcF0gU2l6ZSBvZiBOT05DRSBpbiBRdWVyeVJlcXVlc3QNCg0KSGkgUnVzcyBhbmQgQWtpcmEs DQpZZXMgdGhlIE5vbmNlIGlzIGZvciByZXBsYXkuLi5pbiBURUVQIHRoZXJlIHdhcyBjb25zZW5z dXMgdG8gdXNlIFJBVHMgY2xhaW1zLiAgVGhhdCBzYWlkLCB0aGUgTm9uY2UgY2xhaW0gaW4gUkFU UyBpcyBhIG1pbmltdW0gOGJ5dGVzIHdpdGggYSBtYXggb2YgNjQuICBJIGFncmVlIHRoYXQgNCBp cyBub3QgZW5vdWdoLi4uLmJ1dCB3aGF0IGlzIHRoZSBhcHByb3ByaWF0ZSBzaXplIGZvciBURUVQ PyAgUGVyaGFwcyAxNj8NCg0KCU5hbmN5DQoNCu+7v09uIDQvMy8yMCwgNjo1NyBBTSwgIlRFRVAg b24gYmVoYWxmIG9mIFJ1c3MgSG91c2xleSIgPHRlZXAtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgaG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0KDQogICAgV2hhdCBpcyB0aGUgTk9O Q0Ugc3VwcG9zZWQgdG8gZG8gaGVyZT8gSWYgaXQgaXMgcmVwbGF5IHByb3RlY3Rpb24sIDQgYnl0 ZXMgaXMgbm90IGVub3VnaC4gIEZvciBleGFtcGxlLCBPQ1NQIHVzZXMgdXAgdG8gMzIgYnl0ZXMu DQogICAgDQogICAgUnVzcw0KICAgIA0KICAgIA0KICAgID4gT24gQXByIDMsIDIwMjAsIGF0IDQ6 MzUgQU0sIEFraXJhIFRzdWthbW90byA8YWtpcmEudHN1a2Ftb3RvQGFpc3QuZ28uanA+IHdyb3Rl Og0KICAgID4gDQogICAgPiBIaSBhbGwsDQogICAgPiANCiAgICA+IEkgd291bGQgbGlrZSB0byBh c2sgZXhwZXJ0aXNlIGluIHRoZSBtYWlsaW5nIGxpc3QuDQogICAgPiANCiAgICA+IFRoZSBRdWVy eVJlcXVlc3QgaGFzIG1lbWJlciBvZiBOT05DRSBpbiByZXByZXNlbnRhdGlvbiBvZiBic3RyDQog ICAgPiBpbiB0ZWVwIHByb3RvY29sIGRyYWZ0Lg0KICAgID4gDQogICAgPiBGcm9tIHRoZSBmZWVk YmFjayBmcm9tIHRoZSB2aXJ0dWFsIGhhY2thdGhvbiBsYXN0IHdlZWsgaW4gSmFwYW4sDQogICAg PiBJIHByZWZlciB1c2luZyBic3RyIGxlc3MgYXMgcG9zc2libGUgYW5kIHVzZSBudW1iZXIgcmVw cmVzZW50YXRpb24NCiAgICA+IGluIGludCBvciB1aW50IHNpbmNlIGl0IHJlZHVjZXMgdGhlIHNp emUgb2YgdGhlIHRlZXAgbWVzc2FnZSBhbmQNCiAgICA+IGludC91aW50IGFyZSBtb3JlIHByb2dy YW1pbmcgbGFuZ3VhZ2UgZnJpZW5kbHkuDQogICAgPiANCiAgICA+IFRoZW4gSSBjYW1lIGFjcm9z cyBob3cgbGFyZ2UgdGhlIGludGVnZXIgY291bGQgYmUgdG8gaG9sZCBub25jZQ0KICAgID4gaW4g dGhlIG1lbWJlciBmaWVsZC4NCiAgICA+IA0KICAgID4gQ3VycmVudGx5IGl0IGlzOg0KICAgID4g DQogICAgPiBRdWVyeVJlcXVlc3QgPSB7DQogICAgPiAuLi4uDQogICAgPiAgICAgVE9LRU4gOiBi c3RyLA0KICAgID4gLi4uLg0KICAgID4gICAgID8gTk9OQ0UgOiBic3RyLA0KICAgID4gLi4uLg0K ICAgID4gfQ0KICAgID4gDQogICAgPiBhbmQgd291bGQgbGlrZSB0byBzdWdnZXN0DQogICAgPiAN CiAgICA+IFF1ZXJ5UmVxdWVzdCA9IHsNCiAgICA+IC4uLi4NCiAgICA+ICAgICBUT0tFTiA9PiB1 aW50IC5zaXplIDQsDQogICAgPiAuLi4uDQogICAgPiAgICAgPyBOT05DRSA9PiB1aW50IC5zaXpl IDQsDQogICAgPiAuLi4uDQogICAgPiB9DQogICAgPiANCiAgICA+IGJ1dCBub3Qgc3VyZSB0aGUg dW5zaWduZWQgMzJiaXQgaXMgbGFyZ2UgZW5vdWdoIG9yIG5vdC4NCiAgICA+IFRoZSBtYXggb2Yg dW5zaWduZWQgMzJiaXQsIDB4IGZmIGZmIGZmIGZmLCBpcyA0LDI5NCw5NjcsMjk1Lg0KICAgID4g QW5kIGRvIHdlIGV4cGVjdCBuZWdhdGl2ZSBudW1iZXJzIGhlcmUsIGlmIG5vdCB3b3VsZCBsaWtl IHRvIHVzZSB1aW50IGluc3RlYWQgb2YgaW50Pw0KICAgID4gDQogICAgPiBBbnkgY29tbWVudHMg YXJlIHdlbGNvbWUsDQogICAgPiANCiAgICA+IEFraXJhDQogICAgDQogICAgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBURUVQIG1haWxpbmcgbGlz dA0KICAgIFRFRVBAaWV0Zi5vcmcNCiAgICBodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZ0ZWVwJmFtcDtkYXRhPTAyJTdDMDElN0NkdGhhbGVyJTQwbWljcm9zb2Z0 LmNvbSU3QzMzYWY2MzU4MzBmMTQ0OTI4NTQzMDhkN2Q3ZGZkZGNjJTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzIxNTIyODgzMzU3MTAzOCZhbXA7c2RhdGE9 QXhmNWt1Z2g2Q0QzOUVNaXNaUURDT0toUHo4VXdLd0pZWTclMkZ1bHc5OWJjJTNEJmFtcDtyZXNl cnZlZD0wDQogICAgDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpURUVQIG1haWxpbmcgbGlzdA0KVEVFUEBpZXRmLm9yZw0KaHR0cHM6Ly9uYW0wNi5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lmll dGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGVlcCZhbXA7ZGF0YT0wMiU3QzAxJTdDZHRo YWxlciU0MG1pY3Jvc29mdC5jb20lN0MzM2FmNjM1ODMwZjE0NDkyODU0MzA4ZDdkN2RmZGRjYyU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzcyMTUyMjg4MzM1 NzEwMzgmYW1wO3NkYXRhPUF4ZjVrdWdoNkNEMzlFTWlzWlFEQ09LaFB6OFV3S3dKWVk3JTJGdWx3 OTliYyUzRCZhbXA7cmVzZXJ2ZWQ9MA0K From nobody Fri Apr 3 19:31:00 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 AAABA3A0766 for ; Fri, 3 Apr 2020 19:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=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=aist.go.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpqEvSR8U262 for ; Fri, 3 Apr 2020 19:30:55 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410055.outbound.protection.outlook.com [40.107.141.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4043A0755 for ; Fri, 3 Apr 2020 19:30:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cuM/8QNhOKX26HsYwnpfzCJ6U4V+w206FSaX/wiF9oF2qOc/l0uAWYLh4RgAikh1fZdiQafCJN+4sfbtix5E47BH3DO/ReAHNndGfgijLjK7QwBCYF0NQebCqGZhnrv8xlFO6rGNLqb770RmL6x1dDsI6OlpKj6jvroN/I4DXZJ9RYsCTxjlp1CS0j8YXyiCBK9ZtsSHoGUvi/v42H0ELYnaa3K6CQ3oZzs633/25wvtS49GUCwqYY7/ccsXAlpDbQpnaSyyqu138o4fwd60OPouux94VB5NVC2Oro6EylnJWKkPgcrc1CBUwQaeVMsWHXd9VnNhlX4KIZdY+UcelA== 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=HsWpHoom2HWGZQYjz9+hsTuKzjzpVyYSMEyEEq33v9o=; b=kenFFUcV9Lck4iZ4KHwAMgDaRm46BW32Vqr9xci4TcNSj4JVO6iFp+YvGurLQJ4t5XaBfBFDzOSQuLVz3Bb6ljPL7BJkW48GHRDtx1D35c7rLtMd7jC9zjIObPiVjncTEjiTaIqJiM/8zc+ovIuI0H9v/sWStN6o9ehuBasjJSDCCyQyjTDqPwAxGleSD5eHzgwmou+RNEQFoxN9VMi01xBLAZXbPEz/kjxPCJf9uNhAO/xhW+7m5brSy+jFEgg8+vCnZu0yGM/wDlAfpHHfjSeC7i0aJ7ypcyWS7Q0ov7mqRUSaB9Tt14wtQkpSeE5PDF3RcBEy5t+0StA3ihoF4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HsWpHoom2HWGZQYjz9+hsTuKzjzpVyYSMEyEEq33v9o=; b=tSA2T+p57Eb4yaaS9uLq5nyNrxF4Or+Nw+ms6hBE+WyfKfhyGDasH0txIMvX/1xadTagd+hd46+GBNzZ448dPJWfhRo7YUXgweKv0rkdhD7XVAPX0J9YnIytaYWolYdDav1/AVmHkthMuujbAHKQTXYP/4XFTU2cleC4cQiHOW8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akira.tsukamoto@aist.go.jp; Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com (20.178.140.147) by TYAPR01MB2845.jpnprd01.prod.outlook.com (20.177.103.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Sat, 4 Apr 2020 02:30:52 +0000 Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2]) by TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2%7]) with mapi id 15.20.2878.018; Sat, 4 Apr 2020 02:30:52 +0000 From: Akira Tsukamoto To: "Nancy Cam-Winget (ncamwing)" , Russ Housley Cc: "teep@ietf.org" , Hannes Tschofenig References: <9848943d-597d-8b11-5dd0-54beb97896a4@aist.go.jp> <2532F840-7951-441F-B635-B784BD4F7592@vigilsec.com> Message-ID: Date: Sat, 4 Apr 2020 11:30:51 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TY2PR02CA0069.apcprd02.prod.outlook.com (2603:1096:404:e2::33) To TYAPR01MB3406.jpnprd01.prod.outlook.com (2603:1096:404:cc::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.123] (217.178.18.13) by TY2PR02CA0069.apcprd02.prod.outlook.com (2603:1096:404:e2::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Sat, 4 Apr 2020 02:30:52 +0000 X-Originating-IP: [217.178.18.13] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: aacdf8f1-80bf-428b-d9eb-08d7d8403208 X-MS-TrafficTypeDiagnostic: TYAPR01MB2845: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 03630A6A4A X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3406.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(396003)(376002)(346002)(31696002)(53546011)(5660300002)(81166006)(81156014)(54906003)(8676002)(16576012)(66476007)(110136005)(86362001)(8936002)(36756003)(66556008)(2906002)(316002)(66946007)(4326008)(6486002)(45080400002)(966005)(52116002)(16526019)(44832011)(186003)(2616005)(478600001)(26005)(31686004)(956004); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QJE6FhLdMdXdR4+6XT40SJLVy+A323LbI7fS1A8gyzqxZWlL6I/MIMpcLWxbBgOjQwKAGu5FmsWDeOkRg/oo/YOpP/hpOamCcHFqnGZgNtiymtG9V161VMY2pdJnqirUUfhV0nFJSnoexgGSe/X1RMN59huKCzBdg4fFlKIZvPR/S0+TqINZ2f3FtkpWZE097xtoP2ozrIcK13b2fwQT/ouXC6/JJtLq8RnXteLCbPpbUuRQSTQcqrWmwwhz68gGoZFTzo1pfx3anTDWyhtZWxh1sFD7fbjsbNaGhdybXVhfUnqEl+kEGx+XgwXlSlJHmwU1fxeb0hcbWd2CzToHLxG+CPBtzoWJ89Yje2F1iWednFQJRz5GONiezW4XWJJOVOop/kb+ukN/EZmzTgCZ7xivhJL+t4BE7x3swBAfiNUO+SP7lB+qV7xbUUAWlkubLWcffoFfVclkn9GJWxtL68GQRlN2pFQFcR298D7stS4lIllmxjKM9WPIdLrcjYeTPZNCLzD+vvZCAj8yfTJGJw== X-MS-Exchange-AntiSpam-MessageData: Cj6ypHc5XExm1aAiO8jahmP8qHMpTU3lzSwTJekUFKqmEH7l/wZq/ZlcyVWm26cYq1bJuxRtilHpbxzE9kgR3+gDn0H443xMxiC3/9T6yrNZxYj2XOgIh0OAcdTm6dVT2b001h69qkfY6plY0QsnFg== X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: aacdf8f1-80bf-428b-d9eb-08d7d8403208 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2020 02:30:52.6191 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: k00foZus2XS5JKQLqY9m+iTSIn3ZCcoKhY+ePdxq+W8heRv3kKyDV0TpD2PEEMroFereX4jT7u89EnhW4Vyalv8itKM1O6g+XUU7FSKAe70= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB2845 Archived-At: Subject: Re: [Teep] Size of NONCE in QueryRequest 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: Sat, 04 Apr 2020 02:30:58 -0000 Hi Russ, Nancy and Hannes, Thanks for your comments. I would like to use the same representative of NONCE in TEEP as EAT which is `bstr .size (8..64)` , minimum 8 bytes, max 64 bytes, as Hannes mentioned instead or int or uint which I mentioned earlier. The int/uint could have only up to 8 bytes maximum. While bstr could have variable length. 8 bytes in decimal max: 18446744073709551615 uint .size 8 in hex is: 1B FF FF FF FF FF FF FF FF bstr .size 8 in hex is: 58 08 FF FF FF FF FF FF FF FF The uint representation is only one byte smaller while bstr could go up to 64 bytes in decimal max: 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084095 uint .size 64 <- not possible bstr .size 64 in hex is: 58 40 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF Using the same type of NONCE in TEEP and RATS would make the implementation easier and having less chance of having bug. Now I have concrete idea of NONCE representation, thanks, -Akira On 4/4/2020 12:01 AM, Nancy Cam-Winget (ncamwing) wrote: > Hi Russ and Akira, > Yes the Nonce is for replay...in TEEP there was consensus to use RATs claims. That said, the Nonce claim in RATS is a minimum 8bytes with a max of 64. I agree that 4 is not enough....but what is the appropriate size for TEEP? Perhaps 16? > > Nancy > > On 4/3/20, 6:57 AM, "TEEP on behalf of Russ Housley" wrote: > > What is the NONCE supposed to do here? If it is replay protection, 4 bytes is not enough. For example, OCSP uses up to 32 bytes. > > Russ > > > > On Apr 3, 2020, at 4:35 AM, Akira Tsukamoto wrote: > > > > Hi all, > > > > I would like to ask expertise in the mailing list. > > > > The QueryRequest has member of NONCE in representation of bstr > > in teep protocol draft. > > > > From the feedback from the virtual hackathon last week in Japan, > > I prefer using bstr less as possible and use number representation > > in int or uint since it reduces the size of the teep message and > > int/uint are more programing language friendly. > > > > Then I came across how large the integer could be to hold nonce > > in the member field. > > > > Currently it is: > > > > QueryRequest = { > > .... > > TOKEN : bstr, > > .... > > ? NONCE : bstr, > > .... > > } > > > > and would like to suggest > > > > QueryRequest = { > > .... > > TOKEN => uint .size 4, > > .... > > ? NONCE => uint .size 4, > > .... > > } > > > > but not sure the unsigned 32bit is large enough or not. > > The max of unsigned 32bit, 0x ff ff ff ff, is 4,294,967,295. > > And do we expect negative numbers here, if not would like to use uint instead of int? > > > > Any comments are welcome, > > > > Akira > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7Cc51e52e8276d4717dc4408d7d7dfd8c8%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637215228724902874&sdata=Z26DiQp%2BxGFGWia508C3mzbemgri3pDyxrHlaLxrePg%3D&reserved=0 > > From nobody Sat Apr 4 11:05:43 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 866543A1231; Sat, 4 Apr 2020 11:05:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teep@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: teep@ietf.org Message-ID: <158602352946.27159.8573658681120745566@ietfa.amsl.com> Date: Sat, 04 Apr 2020 11:05:29 -0700 Archived-At: Subject: [Teep] I-D Action: draft-ietf-teep-architecture-08.txt 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: Sat, 04 Apr 2020 18:05:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Trusted Execution Environment Provisioning WG of the IETF. Title : Trusted Execution Environment Provisioning (TEEP) Architecture Authors : Mingliang Pei Hannes Tschofenig Dave Thaler David Wheeler Filename : draft-ietf-teep-architecture-08.txt Pages : 29 Date : 2020-04-04 Abstract: A Trusted Execution Environment (TEE) is an environment that enforces that any code within that environment cannot be tampered with, and that any data used by such code cannot be read or tampered with by any code outside that environment. This architecture document motivates the design and standardization of a protocol for managing the lifecycle of trusted applications running inside such a TEE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teep-architecture-08 https://datatracker.ietf.org/doc/html/draft-ietf-teep-architecture-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teep-architecture-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 4 11:12:32 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 625AE3A1286; Sat, 4 Apr 2020 11:12:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teep@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: teep@ietf.org Message-ID: <158602393733.27236.15093381933712811@ietfa.amsl.com> Date: Sat, 04 Apr 2020 11:12:17 -0700 Archived-At: Subject: [Teep] I-D Action: draft-ietf-teep-otrp-over-http-06.txt 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: Sat, 04 Apr 2020 18:12:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Trusted Execution Environment Provisioning WG of the IETF. Title : HTTP Transport for Trusted Execution Environment Provisioning: Agent-to- TAM Communication Author : Dave Thaler Filename : draft-ietf-teep-otrp-over-http-06.txt Pages : 14 Date : 2020-04-04 Abstract: The Trusted Execution Environment Provisioning (TEEP) Protocol is used to manage code and configuration data in a Trusted Execution Environment (TEE). This document specifies the HTTP transport for TEEP communication where a Trusted Application Manager (TAM) service is used to manage TEEs in devices that can initiate communication to the TAM. An implementation of this document can (if desired) run outside of any TEE, but interacts with a TEEP implementation that runs inside a TEE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teep-otrp-over-http/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teep-otrp-over-http-06 https://datatracker.ietf.org/doc/html/draft-ietf-teep-otrp-over-http-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teep-otrp-over-http-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 4 11:18:11 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 3B9563A010D for ; Sat, 4 Apr 2020 11:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, 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 gmlYoHNTCOcI for ; Sat, 4 Apr 2020 11:18:06 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AFFD3A00D5 for ; Sat, 4 Apr 2020 11:18:05 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id n17so10317217lji.8 for ; Sat, 04 Apr 2020 11:18:05 -0700 (PDT) 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=F/nNq/3pRm6H3On+Zf+54E/P9roxbkBw/3G+Vnvcidg=; b=JV91JfEKsYKwbFeDV8hYRGXurEB6HGwHp7O4cP8HcTh/F77meNKEXleMk8LUV40qOe JH78/k9GbMHyBTNxTMov9YMT+fPjfwxYcSYAOjiOfES+ZHkIzAW+qmp1y9+EomlfhCn3 6AjUBkuTM1X6xOVOfmzZqRsDOecJB9CJZ7R8g= 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=F/nNq/3pRm6H3On+Zf+54E/P9roxbkBw/3G+Vnvcidg=; b=Ndr+PHRvtsZgC0jzL25s8iB3xBRkIeWyudE/lbVjYDic8ypzd0I6D/FqF454IiUoqX 0+RANVnvpMcjQAUCz+PIHJ4cnTZr+x4zBBzF2abB3/DDqUCZO9DJ7BnEYueRgsL8v44K Z/msIPlJamj2BhsM4NkESJexsbGUWZatgk5XfaXsEHCNPfTaMK7eh6BmN2FenWs+GQxr D5D4BdjVi+sI2QEt1iqIrEodc/aC3X31sErPk3/VEe9ccE4ghip8pZIgVqeTDnZesOW7 elugnffyUtIREDqnPrVH2GteBj3lPvKQaNx/MOfVt0VgzU9Cw07UmLhosc0a0hWgYLuV eYTg== X-Gm-Message-State: AGi0PuauhpEh1g3mNHT+SsMFE0i5vbO1BMZJCHKFNt52DWHgYbNPYtSR HBMHhJub/hx9XWhVpGfvqvAj2oruof7nOJxnxBeQ1w== X-Google-Smtp-Source: APiQypLZTbwG8pg70eDUXWrHKvGEVcgmCHZH/HfEvE0kHCOs+k5qAnpYuMXaNPjBHxKS3TsgPdIx44mb7pVfrnqlvIk= X-Received: by 2002:a2e:9616:: with SMTP id v22mr7557166ljh.107.1586024283872; Sat, 04 Apr 2020 11:18:03 -0700 (PDT) MIME-Version: 1.0 References: <9848943d-597d-8b11-5dd0-54beb97896a4@aist.go.jp> <2532F840-7951-441F-B635-B784BD4F7592@vigilsec.com> In-Reply-To: From: Mingliang Pei Date: Sat, 4 Apr 2020 11:17:52 -0700 Message-ID: To: Akira Tsukamoto Cc: "Nancy Cam-Winget (ncamwing)" , Russ Housley , Hannes Tschofenig , "teep@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000000f278d05a27b0e1d" Archived-At: Subject: Re: [Teep] Size of NONCE in QueryRequest 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: Sat, 04 Apr 2020 18:18:08 -0000 --0000000000000f278d05a27b0e1d Content-Type: multipart/alternative; boundary="0000000000000be15705a27b0ec5" --0000000000000be15705a27b0ec5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> Using the same type of NONCE in TEEP and RATS would make the implementation easier and having less chance of having bug. A compelling argument for me to take this approach. Concur on this change. Thanks, Ming On Fri, Apr 3, 2020 at 7:31 PM Akira Tsukamoto wrote: > Hi Russ, Nancy and Hannes, > > Thanks for your comments. > > I would like to use the same representative of NONCE in TEEP as EAT which > is `bstr .size (8..64)` , minimum 8 bytes, max 64 bytes, as Hannes > mentioned > instead or int or uint which I mentioned earlier. > > The int/uint could have only up to 8 bytes maximum. > While bstr could have variable length. > > 8 bytes in decimal max: 18446744073709551615 > uint .size 8 in hex is: 1B FF FF FF FF FF FF FF FF > bstr .size 8 in hex is: 58 08 FF FF FF FF FF FF FF FF > > The uint representation is only one byte smaller while bstr could go up t= o > > 64 bytes in decimal max: > > 1340780792994259709957402499820584612747936582059239337772356144372176403= 007354697680187429816690342769003185818648605085375388281194656994643364900= 6084095 > > uint .size 64 <- not possible > bstr .size 64 in hex is: > 58 40 > FF FF FF FF FF FF FF FF > FF FF FF FF FF FF FF FF > FF FF FF FF FF FF FF FF > FF FF FF FF FF FF FF FF > FF FF FF FF FF FF FF FF > FF FF FF FF FF FF FF FF > FF FF FF FF FF FF FF FF > FF FF FF FF FF FF FF FF > > Using the same type of NONCE in TEEP and RATS would make the implementati= on > easier and having less chance of having bug. > > Now I have concrete idea of NONCE representation, thanks, > > -Akira > > > On 4/4/2020 12:01 AM, Nancy Cam-Winget (ncamwing) wrote: > > Hi Russ and Akira, > > Yes the Nonce is for replay...in TEEP there was consensus to use RATs > claims. That said, the Nonce claim in RATS is a minimum 8bytes with a ma= x > of 64. I agree that 4 is not enough....but what is the appropriate size > for TEEP? Perhaps 16? > > > > Nancy > > > > =EF=BB=BFOn 4/3/20, 6:57 AM, "TEEP on behalf of Russ Housley" < > teep-bounces@ietf.org on behalf of housley@vigilsec.com> wrote: > > > > What is the NONCE supposed to do here? If it is replay protection, > 4 bytes is not enough. For example, OCSP uses up to 32 bytes. > > > > Russ > > > > > > > On Apr 3, 2020, at 4:35 AM, Akira Tsukamoto < > akira.tsukamoto@aist.go.jp> wrote: > > > > > > Hi all, > > > > > > I would like to ask expertise in the mailing list. > > > > > > The QueryRequest has member of NONCE in representation of bstr > > > in teep protocol draft. > > > > > > From the feedback from the virtual hackathon last week in Japan, > > > I prefer using bstr less as possible and use number representati= on > > > in int or uint since it reduces the size of the teep message and > > > int/uint are more programing language friendly. > > > > > > Then I came across how large the integer could be to hold nonce > > > in the member field. > > > > > > Currently it is: > > > > > > QueryRequest =3D { > > > .... > > > TOKEN : bstr, > > > .... > > > ? NONCE : bstr, > > > .... > > > } > > > > > > and would like to suggest > > > > > > QueryRequest =3D { > > > .... > > > TOKEN =3D> uint .size 4, > > > .... > > > ? NONCE =3D> uint .size 4, > > > .... > > > } > > > > > > but not sure the unsigned 32bit is large enough or not. > > > The max of unsigned 32bit, 0x ff ff ff ff, is 4,294,967,295. > > > And do we expect negative numbers here, if not would like to use > uint instead of int? > > > > > > Any comments are welcome, > > > > > > Akira > > > > _______________________________________________ > > TEEP mailing list > > TEEP@ietf.org > > > https://clicktime.symantec.com/3B9CV59AdeoPLksjdX1hMLm7Vc?u=3Dhttps%3A%2F= %2Fjpn01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fww= w.ietf.org%252Fmailman%252Flistinfo%252Fteep%26data%3D02%257C01%257Cakira.t= sukamoto%2540aist.go.jp%257Cc51e52e8276d4717dc4408d7d7dfd8c8%257C18a7fec865= 2f409b8369272d9ce80620%257C0%257C0%257C637215228724902874%26sdata%3DZ26DiQp= %252BxGFGWia508C3mzbemgri3pDyxrHlaLxrePg%253D%26reserved%3D0 > > > > > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > > https://clicktime.symantec.com/32Hq3e1YQd8YgMJFEtDoneQ7Vc?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep > --0000000000000be15705a27b0ec5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>> Using the same type of NONCE in TEEP and RAT= S would make the implementation easier and having less chance of having bug= .

A compelling argument for me to take this approa= ch. Concur on this change. Thanks,

Ming
=

On Fri, Apr 3, 2020 at 7:31 PM Akira Tsukamoto <akira.tsukamoto@aist.go.jp> wrote:
Hi Russ, Nancy an= d Hannes,

Thanks for your comments.

I would like to use the same representative of NONCE in TEEP as EAT which is `bstr .size (8..64)` , minimum 8 bytes, max 64 bytes, as Hannes mentione= d
instead or int or uint which I mentioned earlier.

The int/uint could have only up to 8 bytes maximum.
While bstr could have variable length.

8 bytes in decimal max: 18446744073709551615
uint .size 8 in hex is: 1B FF FF FF FF FF FF FF FF
bstr .size 8 in hex is: 58 08 FF FF FF FF FF FF FF FF

The uint representation is only one byte smaller while bstr could go up to<= br>
64 bytes in decimal max:
134078079299425970995740249982058461274793658205923933777235614437217640300= 735469768018742981669034276900318581864860508537538828119465699464336490060= 84095

uint .size 64 <- not possible
bstr .size 64 in hex is:
58 40
FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF

Using the same type of NONCE in TEEP and RATS would make the implementation=
easier and having less chance of having bug.

Now I have concrete idea of NONCE representation, thanks,

-Akira


On 4/4/2020 12:01 AM, Nancy Cam-Winget (ncamwing) wrote:
> Hi Russ and Akira,
> Yes the Nonce is for replay...in TEEP there was consensus to use RATs = claims.=C2=A0 That said, the Nonce claim in RATS is a minimum 8bytes with a= max of 64.=C2=A0 I agree that 4 is not enough....but what is the appropria= te size for TEEP?=C2=A0 Perhaps 16?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Nancy
>
> =EF=BB=BFOn 4/3/20, 6:57 AM, "TEEP on behalf of Russ Housley"= ; <teep-bounc= es@ietf.org on behalf of housley@vigilsec.com> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 What is the NONCE supposed to do here? If it is re= play protection, 4 bytes is not enough.=C2=A0 For example, OCSP uses up to = 32 bytes.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 Russ
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 > On Apr 3, 2020, at 4:35 AM, Akira Tsukamoto &= lt;akira.ts= ukamoto@aist.go.jp> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Hi all,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I would like to ask expertise in the mailing = list.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The QueryRequest has member of NONCE in repre= sentation of bstr
>=C2=A0 =C2=A0 =C2=A0 > in teep protocol draft.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > From the feedback from the virtual hackathon = last week in Japan,
>=C2=A0 =C2=A0 =C2=A0 > I prefer using bstr less as possible and use = number representation
>=C2=A0 =C2=A0 =C2=A0 > in int or uint since it reduces the size of t= he teep message and
>=C2=A0 =C2=A0 =C2=A0 > int/uint are more programing language friendl= y.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Then I came across how large the integer coul= d be to hold nonce
>=C2=A0 =C2=A0 =C2=A0 > in the member field.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Currently it is:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > QueryRequest =3D {
>=C2=A0 =C2=A0 =C2=A0 > ....
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0TOKEN : bstr,
>=C2=A0 =C2=A0 =C2=A0 > ....
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0? NONCE : bstr,
>=C2=A0 =C2=A0 =C2=A0 > ....
>=C2=A0 =C2=A0 =C2=A0 > }
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > and would like to suggest
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > QueryRequest =3D {
>=C2=A0 =C2=A0 =C2=A0 > ....
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0TOKEN =3D> uint .size 4= ,
>=C2=A0 =C2=A0 =C2=A0 > ....
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0? NONCE =3D> uint .size= 4,
>=C2=A0 =C2=A0 =C2=A0 > ....
>=C2=A0 =C2=A0 =C2=A0 > }
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > but not sure the unsigned 32bit is large enou= gh or not.
>=C2=A0 =C2=A0 =C2=A0 > The max of unsigned 32bit, 0x ff ff ff ff, is= 4,294,967,295.
>=C2=A0 =C2=A0 =C2=A0 > And do we expect negative numbers here, if no= t would like to use uint instead of int?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Any comments are welcome,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Akira
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 _______________________________________________ >=C2=A0 =C2=A0 =C2=A0 TEEP mailing list
>=C2=A0 =C2=A0 =C2=A0 TEEP@ietf.org
>=C2=A0 =C2=A0 =C2=A0 https://clicktime= .symantec.com/3B9CV59AdeoPLksjdX1hMLm7Vc?u=3Dhttps%3A%2F%2Fjpn01.safelinks.= protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmail= man%252Flistinfo%252Fteep%26data%3D02%257C01%257Cakira.tsukamoto%2540aist.g= o.jp%257Cc51e52e8276d4717dc4408d7d7dfd8c8%257C18a7fec8652f409b8369272d9ce80= 620%257C0%257C0%257C637215228724902874%26sdata%3DZ26DiQp%252BxGFGWia508C3mz= bemgri3pDyxrHlaLxrePg%253D%26reserved%3D0
>=C2=A0 =C2=A0 =C2=A0
>

_______________________________________________
TEEP mailing list
TEEP@ietf.org
https://clicktime.symantec.com/32Hq3e1YQd8YgMJFEtDoneQ7Vc?u= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
--0000000000000be15705a27b0ec5-- --0000000000000f278d05a27b0e1d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQRQYJKoZIhvcNAQcCoIIQNjCCEDICAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg2aMIIE6DCCA9CgAwIBAgIOSBtqCRO9gCTKXSLwFPMwDQYJKoZIhvcNAQELBQAwTDEgMB4GA1UE CxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMT Ckdsb2JhbFNpZ24wHhcNMTYwNjE1MDAwMDAwWhcNMjQwNjE1MDAwMDAwWjBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tpZok2X9LAHsYqMNVL+Ly6RDkaKar7GD8rVtb9nw6tzPFnvXGeOEA4X5xh9wjx9sScVpGR5wkTg1 fgJIXTlrGESmaqXIdPRd9YQ+Yx9xRIIIPu3Jp/bpbiZBKYDJSbr/2Xago7sb9nnfSyjTSnucUcIP ZVChn6hKneVGBI2DT9yyyD3PmCEJmEzA8Y96qT83JmVH2GaPSSbCw0C+Zj1s/zqtKUbwE5zh8uuZ p4vC019QbaIOb8cGlzgvTqGORwK0gwDYpOO6QQdg5d03WvIHwTunnJdoLrfvqUg2vOlpqJmqR+nH 9lHS+bEstsVJtZieU1Pa+3LzfA/4cT7XA/pnwwIDAQABo4IBtTCCAbEwDgYDVR0PAQH/BAQDAgEG MGoGA1UdJQRjMGEGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwkGCisGAQQBgjcUAgIGCisG AQQBgjcKAwQGCSsGAQQBgjcVBgYKKwYBBAGCNwoDDAYIKwYBBQUHAwcGCCsGAQUFBwMRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFGlygmIxZ5VEhXeRgMQENkmdewthMB8GA1UdIwQYMBaA FI/wS3+oLkUkrk1Q+mOai97i3Ru8MD4GCCsGAQUFBwEBBDIwMDAuBggrBgEFBQcwAYYiaHR0cDov L29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3Js Lmdsb2JhbHNpZ24uY29tL3Jvb3QtcjMuY3JsMGcGA1UdIARgMF4wCwYJKwYBBAGgMgEoMAwGCisG AQQBoDIBKAowQQYJKwYBBAGgMgFfMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNp Z24uY29tL3JlcG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQConc0yzHxn4gtQ16VccKNm4iXv 6rS2UzBuhxI3XDPiwihW45O9RZXzWNgVcUzz5IKJFL7+pcxHvesGVII+5r++9eqI9XnEKCILjHr2 DgvjKq5Jmg6bwifybLYbVUoBthnhaFB0WLwSRRhPrt5eGxMw51UmNICi/hSKBKsHhGFSEaJQALZy 4HL0EWduE6ILYAjX6BSXRDtHFeUPddb46f5Hf5rzITGLsn9BIpoOVrgS878O4JnfUWQi29yBfn75 HajifFvPC+uqn+rcVnvrpLgsLOYG/64kWX/FRH8+mhVe+mcSX3xsUpcxK9q9vLTVtroU/yJUmEC4 OcH5dQsbHBqjMIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNV BAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5BngiFvXAg7aE yiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X17YUhhB5 uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmmKPZpO/bL yCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hpsk+QLjJg 6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7DWzgVGkW qQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBLQNvAUKr+ yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25sbwMpjjM5 RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV3XpYKBov Hd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyrVQ4PkX42 68NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E7gUJTb0o 2HLO02JQZR7rkpeDMdmztcpHWD9fMIIFRzCCBC+gAwIBAgIMJplVpW1Hq+2ySMVcMA0GCSqGSIb3 DQEBCwUAMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMwHhcNMjAwMjIxMTM1 NjQ5WhcNMjMwMjIxMTM1NjQ5WjCBkDELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5hdGFrYTES MBAGA1UEBxMJQmFuZ2Fsb3JlMRYwFAYDVQQKEw1Ccm9hZGNvbSBJbmMuMRYwFAYDVQQDEw1NaW5n bGlhbmcgUGVpMSkwJwYJKoZIhvcNAQkBFhptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALnj+oLejidhAhfIueq2R6kYf0xTddM81r4s9meY /vZiDe5epFRqRGhg8qsgW+LX2vtv5qe0r507+X2VQsqdL1dSQx8M0kMLqddYl9s9fYj12Qz191+J BI196cW/js96aA0aHpvT2jHIZ8n1+L0r9g4uKFt+VV1Z6ZfECZlMC8EZtCv8KXfBfH2dFJ10k+Qg dV+/KUMC2CYgdiIOynoP5Y9FQTcMM0dg8ToVGkdb7gqODxvU8zKuzBF7AY4YdNs03WCZAa5I+84n DiOJCQwyp+y3WJ7BkQq96LxuuJNS6X0YMhujGmUCdlc4BCX9O+8ICz/jTWGhpq+BLGt4hakkdTEC AwEAAaOCAdEwggHNMA4GA1UdDwEB/wQEAwIFoDCBngYIKwYBBQUHAQEEgZEwgY4wTQYIKwYBBQUH MAKGQWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMnNo YTJnM29jc3AuY3J0MD0GCCsGAQUFBzABhjFodHRwOi8vb2NzcDIuZ2xvYmFsc2lnbi5jb20vZ3Nw ZXJzb25hbHNpZ24yc2hhMmczME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIB FiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hh MmczLmNybDAlBgNVHREEHjAcgRptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTATBgNVHSUEDDAK BggrBgEFBQcDBDAfBgNVHSMEGDAWgBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAdBgNVHQ4EFgQUpStv 0AghsERl1TBx5BXhBfzYSicwDQYJKoZIhvcNAQELBQADggEBAFfbbvFJ0WbPYEGcnklrQKfu9s9k KNImqVdomu0FZ6RxOMLGXBmxRTY4Qy0K4rFKkQ+aYT2iWIBBZrHYs6b+xbLAusU8U4WaO+twZeDC IbMNGJ0PCCHe9IYMy1oOK1M7YqufFR3ZGom/ElDbPPBeBt5P6IfZmm+maiU3vOjI15ZIItZKbBlO O6xVaIUhmfNI6jeHo9qRM2JD+PFUDysuPBEI+udCfjCF1jOP+coa/xLFckMJAhHZw8jJGn1Ja1CC p23PR6TUH/Lxkcj5Y+oyx5sGusPp4jW30ONNtGo5+v6UavWPW4/0LMVJGma3LEJ29R18FOu9Fe/s 1NCEczpRDycxggJvMIICawIBATBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0g RzMCDCaZVaVtR6vtskjFXDANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgjtIJ5Bmq lSWM9Kdxmnge2Ze6oA9nHL9HKLFlQ+i4ZXUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMjAwNDA0MTgxODA0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG 9w0BAQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBABNl5mSwY46Il9nVH5xfAQogHZ2n 8wnYUSy5OGk3zpxYT1rPiVb5ZqdrrVfO5QH/ViHNX0awr1irEP2okIenXYRdPE9If42bS9xpAmOK VEl+Ssu5GlQipcpyxZrLrDx/RFE6q+uMe7ZBK6YLA/Uy5yfBJecoiwl769x+U+r0cDoNHL9sDT0f n1Q+PK2SmPNR/F6/U8wfWSqCZX6Tsd+16ZdmEnxO8f6aZIrVCacZTmGjyZufjvW6LGcIa/kC2biL u9wIVh6UTNkF8TUBC2Yl/pbsQjSwI4qsqjffnKapdtzzo763FY+16FsC3XSC6gHprItmwf7Xbxe3 JLPGJyVgJ7I= --0000000000000f278d05a27b0e1d-- From nobody Sun Apr 5 23:54:28 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 B2F673A0793 for ; Sun, 5 Apr 2020 23:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=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=aist.go.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6Hg6bqw8tVm for ; Sun, 5 Apr 2020 23:54:23 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410089.outbound.protection.outlook.com [40.107.141.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE453A0791 for ; Sun, 5 Apr 2020 23:54:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aX2NRnVI+Fe9wVNeYXm5janQIL8vSbmbzPkI87eHnUbrjTGYOb03Iaumad6LkHZjw0POx7F9/5xYQOfdkCy6l/6AoI0obX12aDZSiwK5ek6AQd3YJKCtOGm/apldPQI7Oa/cLHPz3i7gL2eJHrikq76mHyjKcSx4XxCzG63CHF9DJdk8dExrWSyhqjolOop348fxxRydf2kfWh8Np8w1L2sp2D+XwqFL4dDIEjzeIKhYt/V4/kRZAJSUKr048AvEaJO5ZulmIOOxPSk5gDF/+AkhROAs0sxS/ZdJ8uGTY3Sg9RrFEcUccoVXXuowWHbqxtMrDyMlstinJXf4CYS1mA== 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=ud3MjH1GmpjEfOOMgRWlV5G1mg5n8Z2+RTBS9bkkfIc=; b=DYEpWWM0jhpd2ms8RLGFPTK6TFHu1kq5kdWgHihmLVu72s2FFol+QZnNxjsJ7RYWSEVSao1DM8pSqZU6oWSlS2dADm6c+dSUMRA1JS5YQA0BDqdgbVXE+h2mch0sHewrZHvEU8Fghc1whdfBitmQTv6zcCzHrdIy+pJSZ86+apR6cyeQltShjrseSU/vWS1CyLHw92Hy1KiAKvS45eEXgV74ORJ1ps5Jkln0uRMQPY14YR1Q3XhqYM7FiIR5ZurmYJ/A+9cZMf9hBauSa1l/lnujTfzhQh5H0jGBOO2MmqMP57VSYX04BiPBjIO1HA3CMfU92CkjMngM/WSPTtOOLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ud3MjH1GmpjEfOOMgRWlV5G1mg5n8Z2+RTBS9bkkfIc=; b=jUQ15RhivesYDRvL7EEXdwAY7jvSqMUVi6Og+FY8v9m9ExVQa7eSiRdkttwvBuh9Idc4PJYpaUNKL2PSoMoHPuOAEvFbR/2yAI7JdocxgB2Poz1aT1+9qeR4t26UsbuSouRQRfc0n/mwR6W/KZx9z7xnt3nZ91C3nkvnnlxF+6Y= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akira.tsukamoto@aist.go.jp; Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com (20.178.140.147) by TYAPR01MB3744.jpnprd01.prod.outlook.com (20.178.138.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Mon, 6 Apr 2020 06:54:20 +0000 Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2]) by TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 06:54:20 +0000 To: "teep@ietf.org" , Hannes Tschofenig , "Nancy Cam-Winget (ncamwing)" , Russ Housley , Mingliang Pei , Dave Thaler From: Akira Tsukamoto Message-ID: Date: Mon, 6 Apr 2020 15:54:20 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYAPR01CA0127.jpnprd01.prod.outlook.com (2603:1096:404:2d::19) To TYAPR01MB3406.jpnprd01.prod.outlook.com (2603:1096:404:cc::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.100.202] (153.231.217.65) by TYAPR01CA0127.jpnprd01.prod.outlook.com (2603:1096:404:2d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20 via Frontend Transport; Mon, 6 Apr 2020 06:54:19 +0000 X-Originating-IP: [153.231.217.65] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 23220f41-992c-4921-cba3-08d7d9f754ce X-MS-TrafficTypeDiagnostic: TYAPR01MB3744: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3968; X-Forefront-PRVS: 0365C0E14B X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3406.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(376002)(136003)(39860400002)(396003)(346002)(44832011)(6666004)(5660300002)(956004)(316002)(66476007)(16576012)(66946007)(66556008)(86362001)(478600001)(110136005)(31696002)(6486002)(81166006)(2906002)(52116002)(2616005)(31686004)(186003)(16526019)(36756003)(81156014)(8676002)(26005)(8936002); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tSSA25qVpz1Jp6cG9lpOS2ZWrXmP//z3iLQ9/T7GmAYssUqzv/1L3nlNG98y8NCnd/j8ne0vln5wDl8/voEVxSa/f4C/inxyIt+XZIFqYNHa/R3f57aWvXRFv6H1y7Pn4Jqu65DbZqnLBVA8SFz/PFp1q8zDCR1XNc89PDw3coKO0sqN9Uafk7h4St+cA9RH2jO9A+zMToQmR/YWf902k4OAzYmUSEuM57IL0L/ScdCfp+Ln62twNr/ffp6Q8cgzcwqhQ6A8+RZ4Z5TbxdTgouZesmihQWLJ1LPuFmnV0XCjhR+l40erz7xpkywEafVRdZGKbQnjyXEf6iAO+YogClIfzh1CXuyynUff/jy1RUywwAbiG4CDbhysWqYdWjqCmiN69fm6K0f4BEwLKfzYlQ8+MW4tbCG3vOuYMJkGE7o84FFf4/Osy/PhHeu4UD4o X-MS-Exchange-AntiSpam-MessageData: hh1Q55Ww267bopTd6ZfltmJfu0wkq+awsOsMLzWsxpYnV7dVnBF3Q8MOROGG3GT8rhe+5wOxYZ8rx183EcIs4iJnnVn9AD64NtwAi3BLaz8FzuBmaPa2N2sxQQkSU3O71h3WCxH60uhAdnhcr1UVqw== X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 23220f41-992c-4921-cba3-08d7d9f754ce X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 06:54:20.0551 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 3urdUkw0PVon8FGM4Ut8A6JIf3LO3nOWd1l5EX6w7U6LSzqnserFGMrQhMfNzv0sqlXYvOFDTGBrdc30j28+YJWhdADPjiSAYKVSqfEuDs4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB3744 Archived-At: Subject: [Teep] Review request for TEEP cddl format. 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 Apr 2020 06:54:26 -0000 Hi all, This is based on the work of virtual hackathon. I tried to remove bstr in the teep message as much as possible, since cbor is all about the size reduction comparing the other binary formats. Would you mind reviewing the revised TEEP cddl format? We only managed until TEEP_QueryRequest and TEEP_QueryResponse. I tried to remove ambiguity as much as possible from the implementation perspective. I will reflect the comments on the first two messages and apply to the rest of TrustedAppInstall and etc. ``` TEEP_msg-authenc-wrapper = 1 TEEP_message = 2 TEEP_Msg_AuthEnc_Wrapper = [ *(COSE_Mac_Tagged / COSE_Sign_Tagged / COSE_Mac0_Tagged / COSE_Sign1_Tagged)] TEEP_Outer_Wrapper = { TEEP_msg-authenc-wrapper => bstr .cbor TEEP_Msg_AuthEnc_Wrapper / nil, TEEP-message => bstr .cbor (TEEP_QueryRequest / TEEP_QueryResponse / TEEP_TrustedAppInstall / TEEP_TrustedAppDelete / TEEP_Error / TEEP_Success ), } TEEP_TYPE_QueryRequest = 1 TEEP_TYPE_QueryResponse = 2 TEEP_TYPE_TrustedAppInstall = 3 TEEP_TYPE_TrustedAppDelete = 4 TEEP_TYPE_TEEP_Error = 5 TEEP_TYPE_TEEP_Success = 6 TEEP_attestation = 1 TEEP_trusted_apps = 2 TEEP_extensions = 3 TEEP_suit_commands = 4 TEEP_REQUEST_COMMAND /= TEEP_attestation TEEP_REQUEST_COMMAND /= TEEP_trusted_apps TEEP_REQUEST_COMMAND /= TEEP_extensions TEEP_REQUEST_COMMAND /= TEEP_suit_commands TEEP_AES-CCM-16-64-128_HMAC256/256_X25519_EdDSA = 1 TEEP_AES-CCM-16-64-128_HMAC256/256_P-256_ES256 = 2 TEEP_suite /= TEEP_AES-CCM-16-64-128_HMAC256/256_X25519_EdDSA TEEP_suite /= TEEP_AES-CCM-16-64-128_HMAC256/256_P-256_ES256 TEEP_version = uint .size 4 TEEP_TYPE = 1 TEEP_TOKEN = 2 TEEP_REQUEST = 3 TEEP_CIPHER_SUITE = 4 TEEP_NONCE = 5 TEEP_VERSION = 6 TEEP_OCSP_DATA = 7 TEEP_QueryRequest = { TEEP_TYPE => uint .size 1 TEEP_TYPE_QueryRequest, TEEP_TOKEN => uint .size 4, TEEP_REQUEST => uint .size 1 TEEP_REQUEST_COMMAND, ? TEEP_CIPHER_SUITE => uint .size 1 [+TEEP_suite], ? TEEP_NONCE => bstr .size (8..64), ? TEEP_VERSION => [+TEEP_version], ? TEEP_OCSP_DATA => bstr, * $$extensions } TEEP_install = 1 TEEP_delete = 2 TEEP_update = 3 TEEP_DEVICE_DESIRE /= TEEP_install TEEP_DEVICE_DESIRE /= TEEP_delete TEEP_DEVICE_DESIRE /= TEEP_update TEEP_SELECTED_CIPHER_SUITE = 8 TEEP_SELECTED_VERSION = 9 TEEP_EAT = 10 TEEP_TA_LIST = 11 TEEP_EXT_LIST = 12 TEEP_QueryResponse = { TEEP_TYPE => uint .size 1 TEEP_TYPE_QueryResponse, TEEP_TOKEN => uint .size 4, ? TEEP_DEVICE_REQUEST => uint .size 1 TEEP_DEVICE_DESIRE, ? TEEP_SELECTED_CIPHER_SUITE => uint .size 1 TEEP_suite, ? TEEP_SELECTED_VERSION => TEEP_version, ? TEEP_EAT => bstr, ? TEEP_TA_LIST => [+bstr], ? TEEP_EXT_LIST => [+ext_info], * $$extensions } ``` By the way, is the COSE_Mac*_Tagged/COSE_Sign*_Tagged defined somewaher? I tried to look into IANA and other rfc but could not find the exact place. Best, -Akira From nobody Mon Apr 6 00:58: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 38DCD3A0A4E for ; Mon, 6 Apr 2020 00:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=KsYewO9W; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=KsYewO9W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foMybU7XtRMA for ; Mon, 6 Apr 2020 00:56:04 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70043.outbound.protection.outlook.com [40.107.7.43]) (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 4F9483A0A1D for ; Mon, 6 Apr 2020 00:50:52 -0700 (PDT) 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=3G/IpGVv0ShkrsfosSWr9JbPKpxDSR0jPDeLKTOoFBs=; b=KsYewO9WGcUWRfyuZYcI8w16F25ZAuc99c73hrbARvTj6cEIvu7ZGm3CkhW+jUPVj69DzqUfMSR4jMMX/kgAD573iWYcLFNKulpb7ZYXBrIy56A9GTwMZGin3LVe0I5+4UmRw7sR2wKKbiwhzFZh6/XDyxLAEMJU9b2+i/TPW74= Received: from DB8PR09CA0009.eurprd09.prod.outlook.com (2603:10a6:10:a0::22) by DB7PR08MB3209.eurprd08.prod.outlook.com (2603:10a6:5:1e::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 07:50:48 +0000 Received: from DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:a0:cafe::e5) by DB8PR09CA0009.outlook.office365.com (2603:10a6:10:a0::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Mon, 6 Apr 2020 07:50:48 +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 DB5EUR03FT043.mail.protection.outlook.com (10.152.20.236) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 6 Apr 2020 07:50:48 +0000 Received: ("Tessian outbound 1425309d4c0b:v50"); Mon, 06 Apr 2020 07:50:48 +0000 X-CR-MTA-TID: 64aa7808 Received: from 3287fb84288b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 564FCC4F-3278-4735-A564-9459EF3D7166.1; Mon, 06 Apr 2020 07:50:43 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 3287fb84288b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Apr 2020 07:50:43 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lutVgaxMrYLnCeKz8RhdnLT7i1VBYJ2uUMy/9+/RXqL0tmoM7dlb5Ia86D1oYL5Y2KHqcqPepi2gUgtZ0KkbEZE0vBMvFCKj7UByxukRRhOcQyLX55MhwNuOwmBSBUBeUzNV1ehBDt+joVF/VqOAEzDzuaZbsexqHHAXb4DuxxNWSvCjE2svE7ag3OHCid1VcLucDWHW+rDFAzoW91m4cX9lwjEZKsk0wlJYi6vXSv5FtDpmigqGgx/7UDMnpCs/wk8BPNG/NfwbO6ZjbAIQQUaTTsM8jUsj0uVepMVdV5gaeDE1bFH80CP34K/EmXMpg7RMEcZv65jlArKpvl4Asg== 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=3G/IpGVv0ShkrsfosSWr9JbPKpxDSR0jPDeLKTOoFBs=; b=EZghk2DLo+R+XpZLPbP5hpVpAX/lzNQhdZsCYjiRQjLwKRdFS0UN/ZI694p4lOVaxhDqmqIaciMIJzp2llahGt2aXncBWZF+jleeSXEihg9ZrxSeV4/WCpl5sTf2GXdqGvnXOs7JGvtWiBJHWo2OhWVeC+AkS3KRKgYtuxxoIB6rAIL5qu7OOUS9U9n3AQLtFPkgaw8cYLIZgoTs5UfsDE2KPtIz9mSgyeQutxq074C3bDl0laL2ABOre3oa7iH7HfYUsl7cQuURpiy2BmDb+N1kO/7309DzwcpY103h8J1K8vS9uG/S1JLdfqaK53LEltTwbBrywh4nyKzbICfGIA== 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=3G/IpGVv0ShkrsfosSWr9JbPKpxDSR0jPDeLKTOoFBs=; b=KsYewO9WGcUWRfyuZYcI8w16F25ZAuc99c73hrbARvTj6cEIvu7ZGm3CkhW+jUPVj69DzqUfMSR4jMMX/kgAD573iWYcLFNKulpb7ZYXBrIy56A9GTwMZGin3LVe0I5+4UmRw7sR2wKKbiwhzFZh6/XDyxLAEMJU9b2+i/TPW74= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB3074.eurprd08.prod.outlook.com (52.134.94.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 07:50:41 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 07:50:41 +0000 From: Hannes Tschofenig To: Akira Tsukamoto , "teep@ietf.org" , "Nancy Cam-Winget (ncamwing)" , Russ Housley , Mingliang Pei , Dave Thaler Thread-Topic: Review request for TEEP cddl format. Thread-Index: AQHWC+A2suuL3FBsdkWAchjeCrJCNahruA3A Date: Mon, 6 Apr 2020 07:50:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 6b4bcf36-257b-4fa4-9b58-21d7f5434119.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.119] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 33b9aa70-57b4-4424-68ac-08d7d9ff3881 x-ms-traffictypediagnostic: AM0PR08MB3074:|DB7PR08MB3209: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:4125;OLM:7691; x-forefront-prvs: 0365C0E14B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(376002)(366004)(136003)(39850400004)(396003)(5660300002)(66476007)(71200400001)(8936002)(76116006)(81166006)(8676002)(66946007)(81156014)(186003)(26005)(9686003)(2906002)(55016002)(110136005)(478600001)(6506007)(52536014)(53546011)(7696005)(66556008)(66446008)(316002)(33656002)(64756008)(86362001); DIR:OUT; SFP:1101; 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: iul4n2cFQK+BJdkDC1/28onpCqGh68Zg8R3p+PO5lmy/xtsVJ4Ec8HqtyNnvLQF9Q68XidkSbBciG7MKm5cj91wxP6xAQgl8UaIzqR7yN7UxYu6xqQz+Gi8gaI0fYiYJ+kzJaW1o56nr1kneGCkH6kA0Kn8pCyxH0dDP8zTr4H9RyaZ/UPP8SsedlF0N+JSVh5g5gxGtINZSnn5B4IG3PYmf1F149nfoYDj01UoPLUNeS26pGA16p7aEEtwCFqvIzZyslpnY3SsqUMWz4AEfb7SU2gw/nbzuZ5Q6+w8MUFliXWFS/aUzHmt48VPNgAo6Esc0tsj84i4TcQ1/YmjCQ4wQyV7XshmGgkqN2Cvnm/MmjSetA8P7UvLN2B+zyFX3nVLO0gtOSkCuylBaPIFzHSdQDySgXXiJp0r1tKxSdQ3zWWpi207DxOTVRV+IQiTe x-ms-exchange-antispam-messagedata: 5WDkNfhT6xaLyhm2L/iFXoP5b+D3JOJ3M3AwKCzAZAypgfkviT/btjHy5rz2Yw5AczA585KiIECcsVd43bsdMu1pIdC7c7QLgJmgOUDUi/852CRsMKTyxSWmxUhLVEMT6N0K5PkHYjyXiIgkYU9Hfg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3074 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT043.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(376002)(346002)(46966005)(47076004)(86362001)(81156014)(336012)(478600001)(82740400003)(8676002)(45080400002)(55016002)(33656002)(26826003)(9686003)(70206006)(110136005)(52536014)(81166006)(26005)(53546011)(70586007)(356004)(2906002)(8936002)(6506007)(7696005)(5660300002)(186003)(316002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 582b494e-94b2-4bc5-c864-08d7d9ff34a3 X-Forefront-PRVS: 0365C0E14B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: b/ppkceYzZ3Eqt4r1xiT4cwvwKxTArdXzCh5NNWfu1XXHxo+CZRv/QvseRO1MySK8kzNs+Phds3gJc9h1Hxkc4MUlGbmApFKRZmFxHky2OFa0WJQ+chk4BP55sWgMbnG7+cV9/2LrfIIZGFdBO/XJeDbuQEsoFeEywZYoDfOJ58XwQq7litZU/pYS+7zCeB19N6Rs7VrftMyoSnfKBS3vbJQZI4ZdAf4hQeOI2rDbx1q9n6s3yexaOdkxc1GUUnIDTOyLgXfWWQoSp662NnXvCS1rXQLxcw7t5Gf6fMOXAfouHjl6Isv0wazyjM74LQ//b1z1n4BdB0/SoZpHUnaQZYU4wKiw+qjKyTmWWGL0cTr71vz+B/0tXdIPaZG+tGCW9nHjlLeB0MVkIDkNUIHNLuXCrsa8Kk8ABED3O94lKZGktqFmAcjh0WCiqnmQmzv8/EfhX47AqpS4M1gx4hvBGdFWvBwb6PIvasJ2LMgNcMKTX+1rZb3qOaAf5EgEM/lKyj/k4bZ8RFEqv9GuC7YHQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 07:50:48.4047 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 33b9aa70-57b4-4424-68ac-08d7d9ff3881 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: DB7PR08MB3209 Archived-At: Subject: Re: [Teep] Review request for TEEP cddl format. 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 Apr 2020 07:56:25 -0000 SGkgQWtpcmEsDQoNCnRvIGFuc3dlciB5b3VyIHF1ZXN0aW9uOiBUaGUgQ09TRSBzdHJ1Y3R1cmVz IGNhbiBiZSBmb3VuZCBpbiB0aGUgQ09TRSBzcGVjaWZpY2F0aW9uIGJ1dCBJIG5vdGljZWQgdGhh dCB0aGUgY3VycmVudGx5IGxpc3RlZCB0YWdzIGFyZSBlaXRoZXIgbm90IGFwcGxpY2FibGUgYW55 bW9yZSBvciBsZXNzIHRoYW4gaWRlYWwuIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCBhbnkgdGFnZ2Vk IENPU0Ugc3RydWN0dXJlcyBub3IgZG8gd2UgbmVlZCB0byB1c2UgYW55dGhpbmcgb3RoZXIgdGhh biBDT1NFX1NpZ24xLg0KDQpDaWFvDQpIYW5uZXMNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEFraXJhIFRzdWthbW90byA8YWtpcmEudHN1a2Ftb3RvQGFpc3QuZ28uanA+DQpT ZW50OiBNb25kYXksIEFwcmlsIDYsIDIwMjAgODo1NCBBTQ0KVG86IHRlZXBAaWV0Zi5vcmc7IEhh bm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPjsgTmFuY3kgQ2FtLVdp bmdldCAobmNhbXdpbmcpIDxuY2Ftd2luZ0BjaXNjby5jb20+OyBSdXNzIEhvdXNsZXkgPGhvdXNs ZXlAdmlnaWxzZWMuY29tPjsgTWluZ2xpYW5nIFBlaSA8bWluZ2xpYW5nLnBlaUBicm9hZGNvbS5j b20+OyBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPg0KU3ViamVjdDogUmV2aWV3 IHJlcXVlc3QgZm9yIFRFRVAgY2RkbCBmb3JtYXQuDQoNCkhpIGFsbCwNCg0KVGhpcyBpcyBiYXNl ZCBvbiB0aGUgd29yayBvZiB2aXJ0dWFsIGhhY2thdGhvbi4NCg0KSSB0cmllZCB0byByZW1vdmUg YnN0ciBpbiB0aGUgdGVlcCBtZXNzYWdlIGFzIG11Y2ggYXMgcG9zc2libGUsIHNpbmNlIGNib3Ig aXMgYWxsIGFib3V0IHRoZSBzaXplIHJlZHVjdGlvbiBjb21wYXJpbmcgdGhlIG90aGVyIGJpbmFy eSBmb3JtYXRzLg0KDQpXb3VsZCB5b3UgbWluZCByZXZpZXdpbmcgdGhlIHJldmlzZWQgVEVFUCBj ZGRsIGZvcm1hdD8NCldlIG9ubHkgbWFuYWdlZCB1bnRpbCBURUVQX1F1ZXJ5UmVxdWVzdCBhbmQg VEVFUF9RdWVyeVJlc3BvbnNlLg0KSSB0cmllZCB0byByZW1vdmUgYW1iaWd1aXR5IGFzIG11Y2gg YXMgcG9zc2libGUgZnJvbSB0aGUgaW1wbGVtZW50YXRpb24gcGVyc3BlY3RpdmUuDQoNCkkgd2ls bCByZWZsZWN0IHRoZSBjb21tZW50cyBvbiB0aGUgZmlyc3QgdHdvIG1lc3NhZ2VzIGFuZCBhcHBs eSB0byB0aGUgcmVzdCBvZiBUcnVzdGVkQXBwSW5zdGFsbCBhbmQgZXRjLg0KDQpgYGANCg0KICAg IFRFRVBfbXNnLWF1dGhlbmMtd3JhcHBlciA9IDENCiAgICBURUVQX21lc3NhZ2UgPSAyDQoNCiAg ICBURUVQX01zZ19BdXRoRW5jX1dyYXBwZXIgPSBbICooQ09TRV9NYWNfVGFnZ2VkIC8NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ09TRV9TaWduX1RhZ2dlZCAvDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENPU0VfTWFjMF9UYWdnZWQgLw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDT1NFX1NpZ24xX1RhZ2dlZCldDQoNCiAgICBURUVQ X091dGVyX1dyYXBwZXIgPSB7DQogICAgICAgIFRFRVBfbXNnLWF1dGhlbmMtd3JhcHBlciAgICA9 PiBic3RyIC5jYm9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBURUVQ X01zZ19BdXRoRW5jX1dyYXBwZXIgLyBuaWwsDQogICAgICAgIFRFRVAtbWVzc2FnZSAgICAgICAg ICAgICAgICA9PiBic3RyIC5jYm9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAoVEVFUF9RdWVyeVJlcXVlc3QgLw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFRFRVBfUXVlcnlSZXNwb25zZSAvDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVEVFUF9UcnVzdGVkQXBwSW5zdGFsbCAvDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgVEVFUF9UcnVzdGVkQXBwRGVsZXRlIC8NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBURUVQX0Vycm9yIC8NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBURUVQX1N1Y2Nlc3MgKSwNCiAgICB9DQoNClRF RVBfVFlQRV9RdWVyeVJlcXVlc3QgICAgICA9IDENClRFRVBfVFlQRV9RdWVyeVJlc3BvbnNlICAg ICA9IDINClRFRVBfVFlQRV9UcnVzdGVkQXBwSW5zdGFsbCA9IDMNClRFRVBfVFlQRV9UcnVzdGVk QXBwRGVsZXRlICA9IDQNClRFRVBfVFlQRV9URUVQX0Vycm9yICAgICAgICA9IDUNClRFRVBfVFlQ RV9URUVQX1N1Y2Nlc3MgICAgICA9IDYNCg0KVEVFUF9hdHRlc3RhdGlvbiAgID0gMQ0KVEVFUF90 cnVzdGVkX2FwcHMgID0gMg0KVEVFUF9leHRlbnNpb25zICAgID0gMw0KVEVFUF9zdWl0X2NvbW1h bmRzID0gNA0KDQpURUVQX1JFUVVFU1RfQ09NTUFORCAvPSBURUVQX2F0dGVzdGF0aW9uIFRFRVBf UkVRVUVTVF9DT01NQU5EIC89IFRFRVBfdHJ1c3RlZF9hcHBzIFRFRVBfUkVRVUVTVF9DT01NQU5E IC89IFRFRVBfZXh0ZW5zaW9ucyBURUVQX1JFUVVFU1RfQ09NTUFORCAvPSBURUVQX3N1aXRfY29t bWFuZHMNCg0KVEVFUF9BRVMtQ0NNLTE2LTY0LTEyOF9ITUFDMjU2LzI1Nl9YMjU1MTlfRWREU0Eg PSAxDQpURUVQX0FFUy1DQ00tMTYtNjQtMTI4X0hNQUMyNTYvMjU2X1AtMjU2X0VTMjU2ICA9IDIN Cg0KVEVFUF9zdWl0ZSAvPSBURUVQX0FFUy1DQ00tMTYtNjQtMTI4X0hNQUMyNTYvMjU2X1gyNTUx OV9FZERTQQ0KVEVFUF9zdWl0ZSAvPSBURUVQX0FFUy1DQ00tMTYtNjQtMTI4X0hNQUMyNTYvMjU2 X1AtMjU2X0VTMjU2DQoNClRFRVBfdmVyc2lvbiA9IHVpbnQgLnNpemUgNA0KDQpURUVQX1RZUEUg ICAgICAgICA9IDENClRFRVBfVE9LRU4gICAgICAgID0gMg0KVEVFUF9SRVFVRVNUICAgICAgPSAz DQpURUVQX0NJUEhFUl9TVUlURSA9IDQNClRFRVBfTk9OQ0UgICAgICAgID0gNQ0KVEVFUF9WRVJT SU9OICAgICAgPSA2DQpURUVQX09DU1BfREFUQSAgICA9IDcNCg0KICAgIFRFRVBfUXVlcnlSZXF1 ZXN0ID0gew0KICAgICAgICAgVEVFUF9UWVBFID0+IHVpbnQgLnNpemUgMSBURUVQX1RZUEVfUXVl cnlSZXF1ZXN0LA0KICAgICAgICAgVEVFUF9UT0tFTiA9PiB1aW50IC5zaXplIDQsDQogICAgICAg ICBURUVQX1JFUVVFU1QgPT4gdWludCAuc2l6ZSAxIFRFRVBfUkVRVUVTVF9DT01NQU5ELA0KICAg ICAgICAgPyBURUVQX0NJUEhFUl9TVUlURSA9PiB1aW50IC5zaXplIDEgWytURUVQX3N1aXRlXSwN CiAgICAgICAgID8gVEVFUF9OT05DRSA9PiBic3RyIC5zaXplICg4Li42NCksDQogICAgICAgICA/ IFRFRVBfVkVSU0lPTiA9PiBbK1RFRVBfdmVyc2lvbl0sDQogICAgICAgICA/IFRFRVBfT0NTUF9E QVRBID0+IGJzdHIsDQogICAgICAgICAqICQkZXh0ZW5zaW9ucw0KICAgIH0NCg0KVEVFUF9pbnN0 YWxsID0gMQ0KVEVFUF9kZWxldGUgID0gMg0KVEVFUF91cGRhdGUgID0gMw0KDQpURUVQX0RFVklD RV9ERVNJUkUgLz0gVEVFUF9pbnN0YWxsDQpURUVQX0RFVklDRV9ERVNJUkUgLz0gVEVFUF9kZWxl dGUNClRFRVBfREVWSUNFX0RFU0lSRSAvPSBURUVQX3VwZGF0ZQ0KDQpURUVQX1NFTEVDVEVEX0NJ UEhFUl9TVUlURSA9IDgNClRFRVBfU0VMRUNURURfVkVSU0lPTiAgICAgID0gOQ0KVEVFUF9FQVQg ICAgICAgICAgICAgICAgICAgPSAxMA0KVEVFUF9UQV9MSVNUICAgICAgICAgICAgICAgPSAxMQ0K VEVFUF9FWFRfTElTVCAgICAgICAgICAgICAgPSAxMg0KDQogICAgVEVFUF9RdWVyeVJlc3BvbnNl ID0gew0KICAgICAgICAgVEVFUF9UWVBFID0+ICB1aW50IC5zaXplIDEgVEVFUF9UWVBFX1F1ZXJ5 UmVzcG9uc2UsDQogICAgICAgICBURUVQX1RPS0VOID0+IHVpbnQgLnNpemUgNCwNCiAgICAgICAg ID8gVEVFUF9ERVZJQ0VfUkVRVUVTVCA9PiB1aW50IC5zaXplIDEgVEVFUF9ERVZJQ0VfREVTSVJF LA0KICAgICAgICAgPyBURUVQX1NFTEVDVEVEX0NJUEhFUl9TVUlURSA9PiB1aW50IC5zaXplIDEg VEVFUF9zdWl0ZSwNCiAgICAgICAgID8gVEVFUF9TRUxFQ1RFRF9WRVJTSU9OID0+IFRFRVBfdmVy c2lvbiwNCiAgICAgICAgID8gVEVFUF9FQVQgPT4gYnN0ciwNCiAgICAgICAgID8gVEVFUF9UQV9M SVNUICA9PiBbK2JzdHJdLA0KICAgICAgICAgPyBURUVQX0VYVF9MSVNUID0+IFsrZXh0X2luZm9d LA0KICAgICAgICAgKiAkJGV4dGVuc2lvbnMNCiAgICB9DQoNCmBgYA0KDQpCeSB0aGUgd2F5LCBp cyB0aGUgQ09TRV9NYWMqX1RhZ2dlZC9DT1NFX1NpZ24qX1RhZ2dlZCBkZWZpbmVkIHNvbWV3YWhl cj8NCkkgdHJpZWQgdG8gbG9vayBpbnRvIElBTkEgYW5kIG90aGVyIHJmYyBidXQgY291bGQgbm90 IGZpbmQgdGhlIGV4YWN0IHBsYWNlLg0KDQpCZXN0LA0KLUFraXJhDQpJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBh bnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Mon Apr 6 00:58:22 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 D26563A08BE for ; Mon, 6 Apr 2020 00:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=vQpdF5h6; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=vQpdF5h6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLTP464c3ghD for ; Mon, 6 Apr 2020 00:50:35 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2047.outbound.protection.outlook.com [40.107.20.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180353A0A3B for ; Mon, 6 Apr 2020 00:48:15 -0700 (PDT) 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=i7YacJ1LEPFYTZh03Yzxc5oIkq7HIOY1YaiHBLeneNA=; b=vQpdF5h6odLaRT+rVcYA0KMjcykcf2wqg2jncVL+ZUMI0f6mDxdDRrrB8Sur0NICHVAt7/Hp2tL9okUkl/s/3uyXp4/851txc7kipqS9qDV758gDss0bFHz9w9IBmbceuhuo3NOkQZt5vZU40U2DuDwazth9O8LPZ3DeT9oRjfs= Received: from AM6PR10CA0059.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:80::36) by AM0PR08MB4369.eurprd08.prod.outlook.com (2603:10a6:208:13e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.17; Mon, 6 Apr 2020 07:48:08 +0000 Received: from VE1EUR03FT005.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:80:cafe::df) by AM6PR10CA0059.outlook.office365.com (2603:10a6:209:80::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Mon, 6 Apr 2020 07:48:08 +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 VE1EUR03FT005.mail.protection.outlook.com (10.152.18.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 6 Apr 2020 07:48:07 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Mon, 06 Apr 2020 07:48:07 +0000 X-CR-MTA-TID: 64aa7808 Received: from 17e353730483.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A1A434A2-7B6D-4E32-9757-1E21AC434B61.1; Mon, 06 Apr 2020 07:48:02 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 17e353730483.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Apr 2020 07:48:02 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HRwt/LIV/DSNxnavpsUQmeEu12NVra/IDcN2Pu933CusmwY8A5LiNdcMpykkAjTKLhJ3U68jACBMbzysj875LGvnSHA9e0MhAyV/TEIxnUuRu47ZSSROedAaRLCN53PLSva0CpNyO8UE4KHU/wv02L5QYoCQK26HYELWeVKhxszVX+lnLgbypuoPqEOHDkXRg7wGp1v8Kagx4jpNc7x3kgK6V68b5E7sTYX4jcw7it7cJ3am3OgoSxarhdDR4CGnu9GQ7Ss1jKJwII9nKyvNANIUfFmSRzVoNwRnjAPmYto21u9rBIB97fyNPc5HQ8KEB8HHw65usGtFKQ0jT4pWzg== 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=i7YacJ1LEPFYTZh03Yzxc5oIkq7HIOY1YaiHBLeneNA=; b=cfZ1u63aKwgLBLCHVeVB2ssgAVoUPFfoy1VQQsqC3IP6bXwNEZQs/KbxXblhZT8IYQI4cp41YQ0uNQelWdfazzKpIYgHWE8D/tWacs3pE06PTaLKmLWOQbHD9+eFKIBVj3CbVv4ZdRErPrQmp5Ib9Ws8h2k7pne92wy6U/ZzWrJ5hFrndjy6AfHiCVDxtGyaw8ZL7N6ry02mjzNRSHaHaT7hYj2C1ANahCYLr3tJqcEkfYekqlFyRqERtwxJfNRkYNLA0wOZShEMmZxi4R687tnGd3wFOb1ve6o8zIANX2Suxh7sQRaX8SPcbzJ6s3I2phJ0Utj9Tikxkul/YdPuOA== 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=i7YacJ1LEPFYTZh03Yzxc5oIkq7HIOY1YaiHBLeneNA=; b=vQpdF5h6odLaRT+rVcYA0KMjcykcf2wqg2jncVL+ZUMI0f6mDxdDRrrB8Sur0NICHVAt7/Hp2tL9okUkl/s/3uyXp4/851txc7kipqS9qDV758gDss0bFHz9w9IBmbceuhuo3NOkQZt5vZU40U2DuDwazth9O8LPZ3DeT9oRjfs= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB4404.eurprd08.prod.outlook.com (20.179.32.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Mon, 6 Apr 2020 07:48:01 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 07:48:01 +0000 From: Hannes Tschofenig To: Akira Tsukamoto , "teep@ietf.org" , "Nancy Cam-Winget (ncamwing)" , Russ Housley , Mingliang Pei , Dave Thaler Thread-Topic: Review request for TEEP cddl format. Thread-Index: AQHWC+A2suuL3FBsdkWAchjeCrJCNahrt3TA Date: Mon, 6 Apr 2020 07:48:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: d12bfd4a-0bd1-4253-8f19-d238cb48efd1.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.119] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: a64391ac-15d7-4f05-f0e2-08d7d9fed8bf x-ms-traffictypediagnostic: AM0PR08MB4404:|AM0PR08MB4369: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:2803;OLM:7691; x-forefront-prvs: 0365C0E14B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(346002)(136003)(376002)(39860400002)(396003)(110136005)(66946007)(478600001)(52536014)(81166006)(53546011)(6506007)(7696005)(2906002)(316002)(86362001)(66476007)(66556008)(64756008)(66446008)(76116006)(55016002)(5660300002)(9686003)(186003)(81156014)(8936002)(33656002)(71200400001)(8676002)(26005); DIR:OUT; SFP:1101; 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: 1Y7bTX5l7JuFk+zEZ+pz3t6ChLd4veq9y9jYMQsAQUwvbH7siOo5NHDTl0jS7mHxpY4SLEe93HZn/KnQ0Dma0RYbRzBWQJ9KBCiLa9hmjNw53xBv/RxvD0jMLyGYiLsAaLDA6IvpMJ+pSidFc2muy9kAutPbFovlG3gAKQK9sAMJTMIqfVdbOn+6fDoJF2hBRgM+DlhoKAc/ACpe9qUHvu+RHSAQZT/EXPis+DNEa45iQsQb8u91erpMmumEGr7unJZaoT+sdbLyw8JKS9dv99lyWVqc+iu3tKW6fZ80MxzC7hXErWi430UV5OEDCNhAHOF8uYhe5+J7GCFVvIpSWynQnt43SW4OJS3mVWJgZ6t4tRHK1DHTNWdmtRQGeOzvrqzdx326JQXpwdB7FEk40lTxwlLqBUA6c/n2LXV0Yr9Gblt7rhS45Bu2BpYpWSnx x-ms-exchange-antispam-messagedata: S+Vnl5dRMazuV/l8oWq8gKhvvxcx0RMskypY0xa6ixRPvaonf5d9kov8xJ47GfXQsBLJgQU8DQI3k7Bv9NLC/HLtCMnO8hRKzkWfkipMtrkl0F5xTu1fRBMR/w9rnczH2Swa9wPY7MRzWHBbfGC+bQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4404 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT005.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(346002)(136003)(39850400004)(396003)(46966005)(336012)(53546011)(7696005)(52536014)(9686003)(47076004)(82740400003)(316002)(26005)(70206006)(36906005)(70586007)(186003)(110136005)(5660300002)(81166006)(2906002)(26826003)(6506007)(86362001)(55016002)(8936002)(33656002)(45080400002)(356004)(8676002)(81156014)(478600001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 3ea8cb03-c0ff-4a3d-7817-08d7d9fed509 X-Forefront-PRVS: 0365C0E14B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: M3VnR9YVPvnzSYo3qPTstSh13TigXyg9yTz5OEsQvzmjop/yci8jQF6fmB0dSef1IGSK+ZnMyi/F//hFwKA/bopiBAuCL1eotxii667AeGXZLC9rR0i5LhX7f3gBrY1JhcA3ynnKrUMpJ35G/mJ+xdlr0B4GouewTIkP2padPh0qqKN2P6QkKEc09jpxIj/pm6tQ5nEOF9EndM6voYoqjQJdP9UTz0YpARzSAYilzWuR//LOHF+O4qi8xG7Vpxi4tCn9gBilcBs5TOxIAkNBIIAOUQjPtdZd/F3qpe4WxWB1UzUhpMnyEBXMmQysisUzugj8vyyCiv/PyiZp7YDxtgLyXTelqrhRcvEqP8HLfylMdxv2wj7scY++K2rDBUrmSq4+0NTV/V6vbmqYEmY9rU8VTOD3XO0xM2+KDKQfpz6OapLJ4JraQmJODKBTvZweLwT7UEeiwjBALrNCt0Kn/oD8hZVgCqF+mnBAGwt1VVZ+5XzIvyWtGsw17BsVxC4pKEipQ0pX0KljnJzPpZSnAg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 07:48:07.6261 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a64391ac-15d7-4f05-f0e2-08d7d9fed8bf 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: AM0PR08MB4369 Archived-At: Subject: Re: [Teep] Review request for TEEP cddl format. 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 Apr 2020 07:51:34 -0000 X-List-Received-Date: Mon, 06 Apr 2020 07:51:34 -0000 SGkgQWtpcmEsDQoNClRoYW5rcyBmb3IgdGhpcyB3b3JrLiBJIGNyZWF0ZWQgYW4gaXNzdWUgb24g R2l0aHViIGZvciBkaXNjdXNzaW9uIHRvZGF5Lg0KDQpDaWFvDQpIYW5uZXMNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEFraXJhIFRzdWthbW90byA8YWtpcmEudHN1a2Ftb3Rv QGFpc3QuZ28uanA+DQpTZW50OiBNb25kYXksIEFwcmlsIDYsIDIwMjAgODo1NCBBTQ0KVG86IHRl ZXBAaWV0Zi5vcmc7IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29t PjsgTmFuY3kgQ2FtLVdpbmdldCAobmNhbXdpbmcpIDxuY2Ftd2luZ0BjaXNjby5jb20+OyBSdXNz IEhvdXNsZXkgPGhvdXNsZXlAdmlnaWxzZWMuY29tPjsgTWluZ2xpYW5nIFBlaSA8bWluZ2xpYW5n LnBlaUBicm9hZGNvbS5jb20+OyBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPg0K U3ViamVjdDogUmV2aWV3IHJlcXVlc3QgZm9yIFRFRVAgY2RkbCBmb3JtYXQuDQoNCkhpIGFsbCwN Cg0KVGhpcyBpcyBiYXNlZCBvbiB0aGUgd29yayBvZiB2aXJ0dWFsIGhhY2thdGhvbi4NCg0KSSB0 cmllZCB0byByZW1vdmUgYnN0ciBpbiB0aGUgdGVlcCBtZXNzYWdlIGFzIG11Y2ggYXMgcG9zc2li bGUsIHNpbmNlIGNib3IgaXMgYWxsIGFib3V0IHRoZSBzaXplIHJlZHVjdGlvbiBjb21wYXJpbmcg dGhlIG90aGVyIGJpbmFyeSBmb3JtYXRzLg0KDQpXb3VsZCB5b3UgbWluZCByZXZpZXdpbmcgdGhl IHJldmlzZWQgVEVFUCBjZGRsIGZvcm1hdD8NCldlIG9ubHkgbWFuYWdlZCB1bnRpbCBURUVQX1F1 ZXJ5UmVxdWVzdCBhbmQgVEVFUF9RdWVyeVJlc3BvbnNlLg0KSSB0cmllZCB0byByZW1vdmUgYW1i aWd1aXR5IGFzIG11Y2ggYXMgcG9zc2libGUgZnJvbSB0aGUgaW1wbGVtZW50YXRpb24gcGVyc3Bl Y3RpdmUuDQoNCkkgd2lsbCByZWZsZWN0IHRoZSBjb21tZW50cyBvbiB0aGUgZmlyc3QgdHdvIG1l c3NhZ2VzIGFuZCBhcHBseSB0byB0aGUgcmVzdCBvZiBUcnVzdGVkQXBwSW5zdGFsbCBhbmQgZXRj Lg0KDQpgYGANCg0KICAgIFRFRVBfbXNnLWF1dGhlbmMtd3JhcHBlciA9IDENCiAgICBURUVQX21l c3NhZ2UgPSAyDQoNCiAgICBURUVQX01zZ19BdXRoRW5jX1dyYXBwZXIgPSBbICooQ09TRV9NYWNf VGFnZ2VkIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ09TRV9TaWduX1Rh Z2dlZCAvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENPU0VfTWFjMF9UYWdn ZWQgLw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDT1NFX1NpZ24xX1RhZ2dl ZCldDQoNCiAgICBURUVQX091dGVyX1dyYXBwZXIgPSB7DQogICAgICAgIFRFRVBfbXNnLWF1dGhl bmMtd3JhcHBlciAgICA9PiBic3RyIC5jYm9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBURUVQX01zZ19BdXRoRW5jX1dyYXBwZXIgLyBuaWwsDQogICAgICAgIFRFRVAt bWVzc2FnZSAgICAgICAgICAgICAgICA9PiBic3RyIC5jYm9yDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAoVEVFUF9RdWVyeVJlcXVlc3QgLw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFRFRVBfUXVlcnlSZXNwb25zZSAvDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVEVFUF9UcnVzdGVkQXBwSW5zdGFsbCAvDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVEVFUF9UcnVzdGVkQXBwRGVs ZXRlIC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBURUVQX0Vycm9y IC8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBURUVQX1N1Y2Nlc3Mg KSwNCiAgICB9DQoNClRFRVBfVFlQRV9RdWVyeVJlcXVlc3QgICAgICA9IDENClRFRVBfVFlQRV9R dWVyeVJlc3BvbnNlICAgICA9IDINClRFRVBfVFlQRV9UcnVzdGVkQXBwSW5zdGFsbCA9IDMNClRF RVBfVFlQRV9UcnVzdGVkQXBwRGVsZXRlICA9IDQNClRFRVBfVFlQRV9URUVQX0Vycm9yICAgICAg ICA9IDUNClRFRVBfVFlQRV9URUVQX1N1Y2Nlc3MgICAgICA9IDYNCg0KVEVFUF9hdHRlc3RhdGlv biAgID0gMQ0KVEVFUF90cnVzdGVkX2FwcHMgID0gMg0KVEVFUF9leHRlbnNpb25zICAgID0gMw0K VEVFUF9zdWl0X2NvbW1hbmRzID0gNA0KDQpURUVQX1JFUVVFU1RfQ09NTUFORCAvPSBURUVQX2F0 dGVzdGF0aW9uIFRFRVBfUkVRVUVTVF9DT01NQU5EIC89IFRFRVBfdHJ1c3RlZF9hcHBzIFRFRVBf UkVRVUVTVF9DT01NQU5EIC89IFRFRVBfZXh0ZW5zaW9ucyBURUVQX1JFUVVFU1RfQ09NTUFORCAv PSBURUVQX3N1aXRfY29tbWFuZHMNCg0KVEVFUF9BRVMtQ0NNLTE2LTY0LTEyOF9ITUFDMjU2LzI1 Nl9YMjU1MTlfRWREU0EgPSAxDQpURUVQX0FFUy1DQ00tMTYtNjQtMTI4X0hNQUMyNTYvMjU2X1At MjU2X0VTMjU2ICA9IDINCg0KVEVFUF9zdWl0ZSAvPSBURUVQX0FFUy1DQ00tMTYtNjQtMTI4X0hN QUMyNTYvMjU2X1gyNTUxOV9FZERTQQ0KVEVFUF9zdWl0ZSAvPSBURUVQX0FFUy1DQ00tMTYtNjQt MTI4X0hNQUMyNTYvMjU2X1AtMjU2X0VTMjU2DQoNClRFRVBfdmVyc2lvbiA9IHVpbnQgLnNpemUg NA0KDQpURUVQX1RZUEUgICAgICAgICA9IDENClRFRVBfVE9LRU4gICAgICAgID0gMg0KVEVFUF9S RVFVRVNUICAgICAgPSAzDQpURUVQX0NJUEhFUl9TVUlURSA9IDQNClRFRVBfTk9OQ0UgICAgICAg ID0gNQ0KVEVFUF9WRVJTSU9OICAgICAgPSA2DQpURUVQX09DU1BfREFUQSAgICA9IDcNCg0KICAg IFRFRVBfUXVlcnlSZXF1ZXN0ID0gew0KICAgICAgICAgVEVFUF9UWVBFID0+IHVpbnQgLnNpemUg MSBURUVQX1RZUEVfUXVlcnlSZXF1ZXN0LA0KICAgICAgICAgVEVFUF9UT0tFTiA9PiB1aW50IC5z aXplIDQsDQogICAgICAgICBURUVQX1JFUVVFU1QgPT4gdWludCAuc2l6ZSAxIFRFRVBfUkVRVUVT VF9DT01NQU5ELA0KICAgICAgICAgPyBURUVQX0NJUEhFUl9TVUlURSA9PiB1aW50IC5zaXplIDEg WytURUVQX3N1aXRlXSwNCiAgICAgICAgID8gVEVFUF9OT05DRSA9PiBic3RyIC5zaXplICg4Li42 NCksDQogICAgICAgICA/IFRFRVBfVkVSU0lPTiA9PiBbK1RFRVBfdmVyc2lvbl0sDQogICAgICAg ICA/IFRFRVBfT0NTUF9EQVRBID0+IGJzdHIsDQogICAgICAgICAqICQkZXh0ZW5zaW9ucw0KICAg IH0NCg0KVEVFUF9pbnN0YWxsID0gMQ0KVEVFUF9kZWxldGUgID0gMg0KVEVFUF91cGRhdGUgID0g Mw0KDQpURUVQX0RFVklDRV9ERVNJUkUgLz0gVEVFUF9pbnN0YWxsDQpURUVQX0RFVklDRV9ERVNJ UkUgLz0gVEVFUF9kZWxldGUNClRFRVBfREVWSUNFX0RFU0lSRSAvPSBURUVQX3VwZGF0ZQ0KDQpU RUVQX1NFTEVDVEVEX0NJUEhFUl9TVUlURSA9IDgNClRFRVBfU0VMRUNURURfVkVSU0lPTiAgICAg ID0gOQ0KVEVFUF9FQVQgICAgICAgICAgICAgICAgICAgPSAxMA0KVEVFUF9UQV9MSVNUICAgICAg ICAgICAgICAgPSAxMQ0KVEVFUF9FWFRfTElTVCAgICAgICAgICAgICAgPSAxMg0KDQogICAgVEVF UF9RdWVyeVJlc3BvbnNlID0gew0KICAgICAgICAgVEVFUF9UWVBFID0+ICB1aW50IC5zaXplIDEg VEVFUF9UWVBFX1F1ZXJ5UmVzcG9uc2UsDQogICAgICAgICBURUVQX1RPS0VOID0+IHVpbnQgLnNp emUgNCwNCiAgICAgICAgID8gVEVFUF9ERVZJQ0VfUkVRVUVTVCA9PiB1aW50IC5zaXplIDEgVEVF UF9ERVZJQ0VfREVTSVJFLA0KICAgICAgICAgPyBURUVQX1NFTEVDVEVEX0NJUEhFUl9TVUlURSA9 PiB1aW50IC5zaXplIDEgVEVFUF9zdWl0ZSwNCiAgICAgICAgID8gVEVFUF9TRUxFQ1RFRF9WRVJT SU9OID0+IFRFRVBfdmVyc2lvbiwNCiAgICAgICAgID8gVEVFUF9FQVQgPT4gYnN0ciwNCiAgICAg ICAgID8gVEVFUF9UQV9MSVNUICA9PiBbK2JzdHJdLA0KICAgICAgICAgPyBURUVQX0VYVF9MSVNU ID0+IFsrZXh0X2luZm9dLA0KICAgICAgICAgKiAkJGV4dGVuc2lvbnMNCiAgICB9DQoNCmBgYA0K DQpCeSB0aGUgd2F5LCBpcyB0aGUgQ09TRV9NYWMqX1RhZ2dlZC9DT1NFX1NpZ24qX1RhZ2dlZCBk ZWZpbmVkIHNvbWV3YWhlcj8NCkkgdHJpZWQgdG8gbG9vayBpbnRvIElBTkEgYW5kIG90aGVyIHJm YyBidXQgY291bGQgbm90IGZpbmQgdGhlIGV4YWN0IHBsYWNlLg0KDQpCZXN0LA0KLUFraXJhDQpJ TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3Ro ZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBp bmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Mon Apr 6 04:40:42 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 4DAB23A0F50 for ; Mon, 6 Apr 2020 04:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_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 7hHawf9Agzlw for ; Mon, 6 Apr 2020 04:40:39 -0700 (PDT) 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 D5A7E3A0F51 for ; Mon, 6 Apr 2020 04:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1586173237; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HvuytAiSjVajCUIChrVv93qKDcr+Hpp4fWnHAI3TaF0=; b=dbSc5UlAy+P52ixBQIHyfQe1B9ccfC2E6FDLmWdNl1y6l3qw+lrxCW/M9Ywp8ObHbpV+/T kTyyCMpQgjghFyf9UUWJ4qf2uJMbyBC/XLuJPvxqUJjNafWrD7j1FaFJjq8C/WD2yYpsht fikOGBd1XHULpW189wF0vxhuSJ3oEcQ= 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-447-K30KfzQrN7amX51CRJuauQ-1; Mon, 06 Apr 2020 07:40:36 -0400 X-MC-Unique: K30KfzQrN7amX51CRJuauQ-1 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (2603:10b6:903:d4::12) by CY4PR1601MB1237.namprd16.prod.outlook.com (2603:10b6:903:d4::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 11:40:34 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::8172:432c:9870:d8fc]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::8172:432c:9870:d8fc%5]) with mapi id 15.20.2878.021; Mon, 6 Apr 2020 11:40:34 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk , Dave Thaler CC: "teep@ietf.org" Thread-Topic: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication Thread-Index: AdXgu0iSExhAZRZISA2YiaXw3QSuswZ06BMAA04PiqAAMiKwgADd33mg Date: Mon, 6 Apr 2020 11:40:34 +0000 Message-ID: References: <20200402014031.GC50174@kduck.mit.edu> In-Reply-To: <20200402014031.GC50174@kduck.mit.edu> 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: [185.221.69.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f847035-555d-41b7-9d53-08d7da1f51cf x-ms-traffictypediagnostic: CY4PR1601MB1237: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1601MB1254.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(366004)(396003)(39860400002)(136003)(376002)(32952001)(55016002)(478600001)(5660300002)(316002)(81166006)(2906002)(33656002)(66476007)(66556008)(66446008)(9686003)(110136005)(52536014)(81156014)(64756008)(76116006)(66946007)(71200400001)(8936002)(4326008)(8676002)(26005)(186003)(86362001)(7696005)(53546011)(6506007)(85282002); DIR:OUT; SFP:1101; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3NOmG1ctoIlIoE9tpD58WPXOnwS7XterGnJ3q5CQV2chJgdpqCjyDHnp0dAKOe5if97eBonwzP8pfxUxViQfS6S+/QPEUc4dVIXEpQXlgA56R7ifEousozSIkw4XNvi1drnhLPsHPfiwaw0lsFDScATUoGM5FQKicKZKvojTlXOGp1jxNWK+89MDzn0KQ7V0SjbmrEcZJG8SQ3ENNJ4S5sClsGolnAAaulA62SiWOoJTl2/aOebUqBhWaMdAh64Slx7d/rW3sO26pbxW5C6xO2kynCDAimqzYea1KC5MMtZQZyqmNyeGelPF6We1xd9abVg5Nw+hizOjr3AuBaGFbNpkqzSMe/a68qE7uw6ShdxjwL3OjZ0qSuhJzdpM+fJqv8iCCjqZOGgaRqro9uhjMVfh21db+OhqtA7ezkiyuz0VRMpLQvjv3EMpyEVvUF6Eq1mh3L4Fr116L3hr1jw2qwjo72P4VuzzH/PBJyb2Se1YixL0Z7sHQHslR/R+r5qadmqeeHGS40c+Q2pyn2FSmQ== x-ms-exchange-antispam-messagedata: u8cltDNLFl+Y2jvKvWPswaAS7wgOxueKjrxWOuvusANc7WY0tbsWTw4Gjukzc7R0WbSgn0y3SkGPgGau9tcm/EPDPLJ6bNaflp19Aejxlbbsrwq+GBd0siCrvYHTQ+kHngCaD8yEWL5ln2hZu9B9jg== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f847035-555d-41b7-9d53-08d7da1f51cf X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 11:40:34.6896 (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: meiee+L3txma+cKXFQtvkPNY/Viucnp0R8VRVbXAgo/p/tS8n7xbqSw03R6vdmKPGd6Myd0v+1sF4yrMHr4FTO37OtjGnxkojGINgubTKxEmfiZIGMojy8DhqplqfqIa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1237 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Teep] Working Group Last Call for HTTP Transport for Trusted Execution Environment Provisioning: Agent-to-TAM Communication 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 Apr 2020 11:40:40 -0000 Agree with Ben. I don't see a need to include debugging as a reason to disc= uss HTTP in the document. User-Agent, URL, HTTP version and other headers i= n clear text can be used for pervasive monitoring (for example, identifying= the device, TAM provider etc.). Further, the document discusses QUIC for = future use and QUIC mandates TLS 1.3.=20 -Tiru > -----Original Message----- > From: Benjamin Kaduk > Sent: Thursday, April 2, 2020 7:11 AM > To: Dave Thaler > Cc: Konda, Tirumaleswar Reddy ; > teep@ietf.org > Subject: Re: [Teep] Working Group Last Call for HTTP Transport for Truste= d > Execution Environment Provisioning: Agent-to-TAM Communication >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 > [quoting is a bit busted, since color doesn't make it into text/plain] >=20 > On Wed, Apr 01, 2020 at 02:37:52AM +0000, Dave Thaler wrote: > > > > > > > > > > From: TEEP On Behalf Of Konda, Tirumaleswar > Reddy > > Sent: Saturday, March 14, 2020 11:05 PM > > To: teep@ietf.org > > Subject: Re: [Teep] Working Group Last Call for HTTP Transport for > Trusted > > Execution Environment Provisioning: Agent-to-TAM Communication > > > > > > 5) HTTP is susceptible to several attacks including pervasive monit= oring, > > any specific reason to support HTTP ? > > > > > > > > For debugging purposes before putting it into production. >=20 > It's not really clear to me that we need to include something in the prot= ocol > spec that's just for debugging. Do we really think people will not figur= e out > that they can use non-TLS HTTP for locally debugging an HTTPS-based > protocol? >=20 > > Also some argue that since TEEP already does its own security layer > > inside, the value of multiple layers of security > > > > Is diminished, especially if you're a constrained node looking to re= duce > > code size. The text in the security consideration >=20 > (IMO the multiple layers do different things and complement each other, i= n > general. I guess I haven't looked at this specific protocol in detail ye= t but > there's a general theme across protocols.) >=20 > -Ben From nobody Mon Apr 6 09:35:34 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 1D1363A0783 for ; Mon, 6 Apr 2020 09:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=aNdB1/6N; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dY+lAj7x Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFyGdNea41VH for ; Mon, 6 Apr 2020 09:35:20 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 362AB3A076E for ; Mon, 6 Apr 2020 09:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3629; q=dns/txt; s=iport; t=1586190920; x=1587400520; h=from:to:subject:date:message-id:mime-version; bh=00l5bozZ4eCOiRj2O0Os5FP2PJQpM0i7JgoDyjOydaY=; b=aNdB1/6NtKhwOzZ20GE0YH4UpqUflhRAeurAwim8NgIuZ7I5ydln7Nu0 iIKypQhf1lQ4wqEhtDfVkirh2VtTqa45Ih40Irem8Zo5FWT7EbhKUMFZs QdkxO8BtwjciyQnLS+4kaS3O+xPWqeL5G56wSsfkOi2v1J3bJwWZshFKh o=; IronPort-PHdr: =?us-ascii?q?9a23=3A9adsSB3Ea/SIGLEqsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQD0byKeHraSMSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6DgAuWYte/4ENJK1mgkGBJS9QBWx?= =?us-ascii?q?YIAQLKgqEEYNFA4pmToFsk2KEYYEugSQDVAoBAQEMAQEtAgQBAYRdgjIkNQg?= =?us-ascii?q?OAgMBAQsBAQUBAQECAQUEbYVWAQuGCREdAQE4EQEMPgIEMCcENYMEAYF+TQM?= =?us-ascii?q?uAaVYAoE5iGJ1gTKCfwEBBYJFgnQYgg0JgTiFI4cQGoIAgREnDBCKazKCLIJ?= =?us-ascii?q?IiyJRgkmGBIJmlzQKgj2XKh2cAo83nCUCBAIEBQIOAQEFgVQCNYFXcBVlAYI?= =?us-ascii?q?+UBgNkhCKVXSBKYtiBIEvAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.72,351,1580774400"; d="scan'208,217";a="751908891" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Apr 2020 16:35:18 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 036GZI7q015287 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Apr 2020 16:35:19 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 11:35:18 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 11:35:18 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 6 Apr 2020 12:35:18 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tbm7tB60bZrfXNgcZYivx4w8t2M4xas0UBudGxZ1WK5kp0QTbA2lyqMd9r/lrYAZc0+x3W+F69kgeqhuoe3uPe1z9h6BulTv7+09qzjyj6fyaUjMpO035V+r/2CKGD1N2EvNDK9sJ+PnclLTYjIXBdMEgirHQ6D+/MmD0ggUGozfFylw7Z9BTUn5tf1duNf8SLfDociMFn8nJ40io3zHWDuWwceXmettRolW3RVzaKc5T0+TRqwpg8lUYrwXhr8E1kpg5QAZhH4DWJ5nJVtvitg2jJVroCIwXVy/o/j/7hIV4Zs0ryOWn4cS69nVn8RzHnWVFnJLcuCj8eLoGRXR5Q== 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=00l5bozZ4eCOiRj2O0Os5FP2PJQpM0i7JgoDyjOydaY=; b=AdMGgN4vQM1mSMzjFrC65VUWUIOSQ6oJ+p2vjlCNrPZDwCe6HNuIxWyRIsN1jUEN8NgoMs6IgkMhK44xk/S656McvbbtojBrx8NtFg7M4hN5Oxy/Gbt4cKVMYXqwtyCplQeMAfOR7JbvHpj6hieOpEMsoXfbPuDgKQThk8Sjr67UeOUeGoda+DGiVew243k3qhvBb7ZlG8MKdM9VKw43jJPX71edUlVZLXZ709Nh9qRXxuInA3azeL1omEfl5Uhh32OJDicXrtpf6qQgDjQK2SzMQ0LCxtxzhG68I50I7/kALPfkz4QAKTtez1b+vv84RlgXWh6j3Tn+Y59dTr23+w== 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=00l5bozZ4eCOiRj2O0Os5FP2PJQpM0i7JgoDyjOydaY=; b=dY+lAj7xT0SYhg7X8D5U8hUfAgjBwDI9fYZ87YBYYQ9A32QVADWZ1dB0HP0zKMMtP2Z8nL16+OT27La6j7WptL31IOqfcBLdqcbhU9zM2KOh9tVS5C1UHZbRv4BAxLlg/q02+CJXgdxgrS1JeaPfH39QuOksqR9SLHqIsDbtSaQ= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB3878.namprd11.prod.outlook.com (2603:10b6:a03:182::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Mon, 6 Apr 2020 16:35:17 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::852d:fab4:18c1:72d2]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::852d:fab4:18c1:72d2%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 16:35:17 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "teep@ietf.org" Thread-Topic: April 7 Virtual Interim CANCELLED Thread-Index: AQHWDDFaaEAMV+IU10SAamMXfYTdXw== Date: Mon, 6 Apr 2020 16:35:17 +0000 Message-ID: <1238DE98-5020-4E0C-837E-1C159187A2BC@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.14.200307 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b7fea38-4410-426f-b05a-08d7da487d88 x-ms-traffictypediagnostic: BY5PR11MB3878: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0365C0E14B x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(366004)(136003)(39860400002)(396003)(346002)(76116006)(26005)(71200400001)(6486002)(81166006)(81156014)(8676002)(558084003)(36756003)(5660300002)(2906002)(8936002)(6506007)(186003)(2616005)(66556008)(66446008)(478600001)(316002)(66946007)(6512007)(86362001)(66476007)(6916009)(33656002)(64756008); DIR:OUT; SFP:1101; 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: 9I/k6lo4igDtm5CNPVIBsyzTjZJRmIFpcHDRHtEDtVBizeZBchM0XOJ7rpqcbc/TNtOIDIuSkG/ShQlstAw1nJUG7K1b/O3unkNdtPr7uL8OKyNJTbmmFQYhb/qNOkfQO65sE5MGQtZ+n8I9AonICWzgUTyOecpzLHJ94bjJ8jZNdjHbxUs/wx2lOcY3x6RktghExkZajOmoeU1Xrg8fAc/63sekgNNNVr/lc6S/JT2dMmVyojV8ds6JodBxLsNssS0J8BvrHHyKweCivkNEy/UG3TDZbLrnlQOnQQQOiQgNvSN/AUJ5rj43M/+MZUsGS+hrit+y0X2HHFPJ65QttSmNMiwxrYSEcXTXF9AUrethbxfkOLwdm2+VE+hOrww0vHwK0zjuijXdBrvLgaqOZ6+nH/R/jFz44JBGcGrHr4p5O5wyndYu5JoesRziwTm9 x-ms-exchange-antispam-messagedata: qJxa6/nTtDcDtjdVmba3aG4SXGvPASj2vi8byMF2pqdv/6tnlf9jeShJzDFIb6cRPhuYLHztbS4S5M+ls3g8TY0vpZeUb+KIH4vBIq9oUYjRHtv+fuogCqSYKS28Vp5TKxekAhBbTXi8aQYXh7MBqg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1238DE9850204E0C837E1C159187A2BCciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2b7fea38-4410-426f-b05a-08d7da487d88 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 16:35:17.2886 (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: wT5F9lBGg+Y3nThRx43K81k2+3yHOLc8FlvbQeGo4KSD8jcMLeSzrhTzO5GPcboVs1m2a0buFU4q6uAbzl5FMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3878 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: [Teep] April 7 Virtual Interim CANCELLED 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 Apr 2020 16:35:22 -0000 --_000_1238DE9850204E0C837E1C159187A2BCciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gVEVFUCBwYXJ0aWNpcGFudHMsDQpUaGFuayB5b3UgYWxsIHdobyBwYXJ0aWNpcGF0ZWQg aW4gdG9kYXnigJlzIFZpcnR1YWwgaW50ZXJpbTsgYXMgd2Ugd2VyZSBhYmxlIHRvIGNvdmVyIGFs bCBpdGVtcyB0b2RheSwgd2UgZG8gbm90IG5lZWQgdG8gaG9sZCBvdXIgc2Vjb25kIHNlc3Npb24g dG9tb3Jyb3cuDQoNClRoZXJlZm9yZSwgdGhlIHZpcnR1YWwgaW50ZXJpbSBzY2hlZHVsZWQgZm9y IHRvbW9ycm93IEFwcmlsIDcgaXMgY2FuY2VsbGVkLg0KDQpUaGFua3MsIE5hbmN5DQo= --_000_1238DE9850204E0C837E1C159187A2BCciscocom_ 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 emU6MTEuMHB0Ij5IZWxsbyBURUVQIHBhcnRpY2lwYW50cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhh bmsgeW91IGFsbCB3aG8gcGFydGljaXBhdGVkIGluIHRvZGF54oCZcyBWaXJ0dWFsIGludGVyaW07 IGFzIHdlIHdlcmUgYWJsZSB0byBjb3ZlciBhbGwgaXRlbXMgdG9kYXksIHdlIGRvIG5vdCBuZWVk IHRvIGhvbGQgb3VyIHNlY29uZCBzZXNzaW9uIHRvbW9ycm93LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlcmVmb3JlLCB0aGUgdmlydHVhbCBpbnRlcmltIHNj aGVkdWxlZCBmb3IgdG9tb3Jyb3cgQXByaWwgNyBpcyBjYW5jZWxsZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsIE5hbmN5PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1238DE9850204E0C837E1C159187A2BCciscocom_-- From nobody Mon Apr 6 09:54:55 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 8CB843A0895; Mon, 6 Apr 2020 09:54:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: teep-chairs@ietf.org, teep@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158619207348.23963.15931002143025826743@ietfa.amsl.com> Date: Mon, 06 Apr 2020 09:54:33 -0700 Archived-At: Subject: [Teep] Trusted Execution Environment Provisioning (teep) WG Interim Meeting Cancelled (was 2020-04-07) 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: Mon, 06 Apr 2020 16:54:34 -0000 The Trusted Execution Environment Provisioning (teep) virtual interim meeting for 2020-04-07 from 07:00 to 09:00 America/Los_Angeles has been cancelled. From nobody Mon Apr 6 18:11:02 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 4AA063A10F3 for ; Mon, 6 Apr 2020 18:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=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=aist.go.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8e8jfMfOntY for ; Mon, 6 Apr 2020 18:10:58 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410088.outbound.protection.outlook.com [40.107.141.88]) (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 797643A10F0 for ; Mon, 6 Apr 2020 18:10:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PkC2bBc5XddBDA/TKayOiaGWlqsPvDg5L06SXzHy/4c3lUVOKcf1BPHHzgZfVYOtjdzH2ny3SLS9EdcYqp1J2z0w8ykN/bOuHg+u0Zemh5aiU8Sav6K34RUR+Vyuhwk5KFfcL2R0YzGpNtgPGTG8qlhWJQLlKmz/fx6bXHpash5tcq3TKktQWDbslDpkadkDpcglP37QBdV+7+HOjVglymJgOtu5Q0F2gICYgdsTHp3rhggBEEiFgsM/u/9XR7TBNqu44xjnSvkvNpEifPB9GUHx1pm2ityIonDN9UpRsUcvEPKKUX0P+L3gonnyK3IR39tX2Htew2gppBq9aDSMAA== 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=4bfxYiaR6E8+v49HWnTRD6+DC+QEmdG1LjcpaZXC8Ps=; b=XG/6WCVhSBOBtODzNLiiCOsrXJizDCq7G9a+98VoBA+v/IZAsGOKgdfjf2D+iV1026NdLuyNX1i/dEkOhRa/+WZeZDie9TXEyZ2QHAToqcjT2HEXkesB1dXzRE9jmQUUXQuna/horQiGdpt7fJM7wqh6XUH9Hfeg2Vc4qsUfYFNFjcGWVslq2zcFdSRCKEg0poa5PBNqcu+DpqXOGjqcLdZ8ZIrSFuukJ5ogM+Ew0wgEnRV7Sp/G8nqWXn1mDXsctUdSLb0m1vyv/ZI+CaoB18+EVN9XDpZQYLNokzYl8e3pKmBbRFUVWyhJSvPDovL2pDxq2lqRvAbYTxDCpc4+Fg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4bfxYiaR6E8+v49HWnTRD6+DC+QEmdG1LjcpaZXC8Ps=; b=Cex/oMoud/NP0lud0bL6ZJWYJws3oSpkJWo1X8SYm58dlI36koG+YYULs1qu73SJE1ZMH1LXPTHcJq0BTNgDVoNHPySeGhR5uUo9WFMQ8ppHtqX+q45+0qNDjfXb+HwQ364bPhiaW7o2naHkOS521EXZWmNVSHpfaRgzc9nTHEk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akira.tsukamoto@aist.go.jp; Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com (20.178.140.147) by TYAPR01MB4080.jpnprd01.prod.outlook.com (20.178.139.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Tue, 7 Apr 2020 01:10:54 +0000 Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2]) by TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2%7]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 01:10:54 +0000 To: Hannes Tschofenig , "teep@ietf.org" , "Nancy Cam-Winget (ncamwing)" , Russ Housley , Mingliang Pei , Dave Thaler References: From: Akira Tsukamoto Message-ID: <7db7cbbf-670e-83b7-cf0d-55b9770d89e5@aist.go.jp> Date: Tue, 7 Apr 2020 10:10:54 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYAPR03CA0017.apcprd03.prod.outlook.com (2603:1096:404:14::29) To TYAPR01MB3406.jpnprd01.prod.outlook.com (2603:1096:404:cc::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.100.200] (153.231.217.65) by TYAPR03CA0017.apcprd03.prod.outlook.com (2603:1096:404:14::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.12 via Frontend Transport; Tue, 7 Apr 2020 01:10:53 +0000 X-Originating-IP: [153.231.217.65] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: a85314c6-1396-4d50-5d67-08d7da908515 X-MS-TrafficTypeDiagnostic: TYAPR01MB4080: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-Forefront-PRVS: 036614DD9C X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3406.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(366004)(136003)(396003)(346002)(39850400004)(31696002)(956004)(86362001)(44832011)(478600001)(2616005)(966005)(16526019)(45080400002)(186003)(26005)(5660300002)(316002)(52116002)(66556008)(8676002)(53546011)(6486002)(36756003)(66946007)(81166006)(31686004)(81156014)(16576012)(110136005)(8936002)(2906002)(66476007); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hC1G3o+Oa0ZrG2UQb12nk4uOD29IL+hHAqAfCLLeFU702ESSbaeBNweMgby2JtcJ/i1m0QD0GD0klGJwofOscBOhCIj2ugULLlf1TiJBZ71XedM+pUbYUOKN4dCDM/3LA5YtyBzJgPzrSkHzJj3w1mn7jPv/B+gCPoW/1Z/MAVibj52f24nCAgyC/1qoeb9nd6A4fCXBKbQIYlXl6J64WyFWkzHDtw+UoXiaeDPRn5zftPiIK5oIZLfTNFQFYczo7k4mHBlSWVi29dvvysRIyxsuaQ+DXjuG3S477Hhmg0JnQxiu/Zv/ZUBjWPS8UWBK1AzcTJ+h8X2YLPjgNWRUwP+sCBR4tqZZ3/Z9AcNec/geoOkMINEZ5dgo7Ap4Ia81XX+tGux1d70FBZNegT4CoimKvAkwmIEmtepUgF0z9MVK6bT/5pnwXYnaQ7K7b5V1uHbYsLIDSCpof0FQmIzCR2sH6pJi5m0BaaTjbfwkqbNAb5HnOw0ltVye1fwJcDniVc4Mx1tw+z5Wf6LBxB6tQw== X-MS-Exchange-AntiSpam-MessageData: I1JJKGIJsXMVwBOVw2VJ/cuLyaAqlpYbzHJfqrLH3Ke/BrjgL0vJN8pHfgZF1ApW1HWrM6Ry1jTs1Ux4UiFed75ti7xypGe5hi6MwZTWperEZ+0YUXDK0j/WI+GdsHfNojhQWHHmkR2gj3EaJ3g91Q== X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: a85314c6-1396-4d50-5d67-08d7da908515 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 01:10:54.2178 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: p0dZS6pT/uzgrvkgJkPHvdMO6jmiJjlKqqTD1qFUdSrJwDZClqfLd8OBvkMHq9v4OD+2XXtEckJCvAYtOW9QIDA0CoIDDpUSCo42h8U6q+U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4080 Archived-At: Subject: Re: [Teep] Review request for TEEP cddl format. 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 Apr 2020 01:11:00 -0000 Hi Hannes, Thanks, this is the link for who is reading this email thread. https://github.com/ietf-teep/teep-protocol/issues/21 -Akira On 4/6/20 16:48, Hannes Tschofenig wrote: > Hi Akira, > > Thanks for this work. I created an issue on Github for discussion today. > > Ciao > Hannes > > -----Original Message----- > From: Akira Tsukamoto > Sent: Monday, April 6, 2020 8:54 AM > To: teep@ietf.org; Hannes Tschofenig ; Nancy Cam-Winget (ncamwing) ; Russ Housley ; Mingliang Pei ; Dave Thaler > Subject: Review request for TEEP cddl format. > > Hi all, > > This is based on the work of virtual hackathon. > > I tried to remove bstr in the teep message as much as possible, since cbor is all about the size reduction comparing the other binary formats. > > Would you mind reviewing the revised TEEP cddl format? > We only managed until TEEP_QueryRequest and TEEP_QueryResponse. > I tried to remove ambiguity as much as possible from the implementation perspective. > > I will reflect the comments on the first two messages and apply to the rest of TrustedAppInstall and etc. > > ``` > > TEEP_msg-authenc-wrapper = 1 > TEEP_message = 2 > > TEEP_Msg_AuthEnc_Wrapper = [ *(COSE_Mac_Tagged / > COSE_Sign_Tagged / > COSE_Mac0_Tagged / > COSE_Sign1_Tagged)] > > TEEP_Outer_Wrapper = { > TEEP_msg-authenc-wrapper => bstr .cbor > TEEP_Msg_AuthEnc_Wrapper / nil, > TEEP-message => bstr .cbor > (TEEP_QueryRequest / > TEEP_QueryResponse / > TEEP_TrustedAppInstall / > TEEP_TrustedAppDelete / > TEEP_Error / > TEEP_Success ), > } > > TEEP_TYPE_QueryRequest = 1 > TEEP_TYPE_QueryResponse = 2 > TEEP_TYPE_TrustedAppInstall = 3 > TEEP_TYPE_TrustedAppDelete = 4 > TEEP_TYPE_TEEP_Error = 5 > TEEP_TYPE_TEEP_Success = 6 > > TEEP_attestation = 1 > TEEP_trusted_apps = 2 > TEEP_extensions = 3 > TEEP_suit_commands = 4 > > TEEP_REQUEST_COMMAND /= TEEP_attestation TEEP_REQUEST_COMMAND /= TEEP_trusted_apps TEEP_REQUEST_COMMAND /= TEEP_extensions TEEP_REQUEST_COMMAND /= TEEP_suit_commands > > TEEP_AES-CCM-16-64-128_HMAC256/256_X25519_EdDSA = 1 > TEEP_AES-CCM-16-64-128_HMAC256/256_P-256_ES256 = 2 > > TEEP_suite /= TEEP_AES-CCM-16-64-128_HMAC256/256_X25519_EdDSA > TEEP_suite /= TEEP_AES-CCM-16-64-128_HMAC256/256_P-256_ES256 > > TEEP_version = uint .size 4 > > TEEP_TYPE = 1 > TEEP_TOKEN = 2 > TEEP_REQUEST = 3 > TEEP_CIPHER_SUITE = 4 > TEEP_NONCE = 5 > TEEP_VERSION = 6 > TEEP_OCSP_DATA = 7 > > TEEP_QueryRequest = { > TEEP_TYPE => uint .size 1 TEEP_TYPE_QueryRequest, > TEEP_TOKEN => uint .size 4, > TEEP_REQUEST => uint .size 1 TEEP_REQUEST_COMMAND, > ? TEEP_CIPHER_SUITE => uint .size 1 [+TEEP_suite], > ? TEEP_NONCE => bstr .size (8..64), > ? TEEP_VERSION => [+TEEP_version], > ? TEEP_OCSP_DATA => bstr, > * $$extensions > } > > TEEP_install = 1 > TEEP_delete = 2 > TEEP_update = 3 > > TEEP_DEVICE_DESIRE /= TEEP_install > TEEP_DEVICE_DESIRE /= TEEP_delete > TEEP_DEVICE_DESIRE /= TEEP_update > > TEEP_SELECTED_CIPHER_SUITE = 8 > TEEP_SELECTED_VERSION = 9 > TEEP_EAT = 10 > TEEP_TA_LIST = 11 > TEEP_EXT_LIST = 12 > > TEEP_QueryResponse = { > TEEP_TYPE => uint .size 1 TEEP_TYPE_QueryResponse, > TEEP_TOKEN => uint .size 4, > ? TEEP_DEVICE_REQUEST => uint .size 1 TEEP_DEVICE_DESIRE, > ? TEEP_SELECTED_CIPHER_SUITE => uint .size 1 TEEP_suite, > ? TEEP_SELECTED_VERSION => TEEP_version, > ? TEEP_EAT => bstr, > ? TEEP_TA_LIST => [+bstr], > ? TEEP_EXT_LIST => [+ext_info], > * $$extensions > } > > ``` > > By the way, is the COSE_Mac*_Tagged/COSE_Sign*_Tagged defined somewaher? > I tried to look into IANA and other rfc but could not find the exact place. > > Best, > -Akira > 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 the information in any medium. Thank you. > From nobody Mon Apr 6 18:19:54 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 9BC023A11C4 for ; Mon, 6 Apr 2020 18:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=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=aist.go.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeI0IaQRU17f for ; Mon, 6 Apr 2020 18:19:50 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400058.outbound.protection.outlook.com [40.107.140.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AF83A11B5 for ; Mon, 6 Apr 2020 18:19:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I2bBJfwP1dMNAmJDBSZh2Zl0uBFNHgKivOlzvCXgizR4k/HhxeIBzepJmBxCOe7Ph7iqATW1TTj2Zb0ffN0L0ALoACNAsGwKr0Ix7B0upnSwAHH87Ccv5SOvyOXoaXav3ubtV1SUO99I3x9IJq8c/mHt/ySJIxYx7w4ET3FCqK455u4wW1umOKFtnUWzayfRAn9NODP+GQo/ZdUo2fl09+llMRdjaED1TnA9vUybXtQx6/eRcdsViwfpIs8LJ6AT1MqnDcoxOh/RLmAEBNs4F/oRKHAeztKrAHSSx7XOMY6qlrebBdpoMyOjlzRjFsUwykierg7xjpIeMX9YpTGOag== 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=s5H8O6ksBhwv9wK/OiuPAbgl9DL4+9lQeN1UCNGD3bc=; b=ikBCcyKbZ1Vey38bDu9BsiTfFzsn6ed/AUJHpD1csSy8YzjjfQrpzY89nvrEjxdji46N65gljagm4S0o/21YZqsqz982bDdbrskUA+BZVTk34rkgStEP7aaben0caDWSGBdLI6KmBnD0LRzF0J7LMTvi3/caAWqKeARGoZm7GzyiY8AgWPs4SbRzM4eXIgXmXNBfejAqjkhamIyWhWIlEu/pB5kQJUruyhAA6Yyu/AKj6RKE15QxnzleACSldl7DroGzWGVjQUPNA8YxhhslYOuXZ+FcbfrhnVFCiFjtnoNEqho5TxbIWocwub763tIPiQ+7sDjSbpRjG6mOgVoiIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s5H8O6ksBhwv9wK/OiuPAbgl9DL4+9lQeN1UCNGD3bc=; b=i2IoGDa06J5G1pCmbz0Dn/BANJjrTcJXDg1ngc6KfSHx1ErI1QBABxOfVUJqxMHJhtnsGsNzVurUSsBEqxbcAPs9xt3xuoOICT6EyomdsXMZ8stGmJR/sCjxKbldEzu0Y/liKwgWu8UdmaZ10NRNWLfgKvvbFu99MgPx4bXIsSw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akira.tsukamoto@aist.go.jp; Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com (20.178.140.147) by TYAPR01MB5133.jpnprd01.prod.outlook.com (20.179.173.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.17; Tue, 7 Apr 2020 01:19:47 +0000 Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2]) by TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2%7]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 01:19:47 +0000 To: Hannes Tschofenig , "teep@ietf.org" , "Nancy Cam-Winget (ncamwing)" , Russ Housley , Mingliang Pei , Dave Thaler References: From: Akira Tsukamoto Message-ID: Date: Tue, 7 Apr 2020 10:19:48 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TY1PR01CA0157.jpnprd01.prod.outlook.com (2603:1096:402:1::33) To TYAPR01MB3406.jpnprd01.prod.outlook.com (2603:1096:404:cc::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.100.200] (153.231.217.65) by TY1PR01CA0157.jpnprd01.prod.outlook.com (2603:1096:402:1::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Tue, 7 Apr 2020 01:19:47 +0000 X-Originating-IP: [153.231.217.65] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 3270a6a3-50dd-4653-ca48-08d7da91c326 X-MS-TrafficTypeDiagnostic: TYAPR01MB5133: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7691; X-Forefront-PRVS: 036614DD9C X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3406.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(346002)(396003)(366004)(136003)(39850400004)(8676002)(956004)(81166006)(53546011)(2616005)(6486002)(81156014)(66946007)(16526019)(44832011)(26005)(186003)(316002)(16576012)(2906002)(8936002)(966005)(45080400002)(31686004)(66476007)(86362001)(110136005)(31696002)(478600001)(36756003)(5660300002)(66556008)(52116002); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 80XTvlk5BWvDg11m5BbViXZZNmJDFHzg9CFzzUg00ufuZQusswbNieY/TNCG2yonzOSEFgJh6tR5V37j7c+GLXQN5TFJIle+k7izb1jE3eJwLOOy7+z7EgG+yxnLTAXtK/NuIcu2YVgOTxbPIZi5XIOM547yGO07XHTwAJdq+HtyVhwKFuqD9ckD2enegW9P4SLp5txk2/wLsuQWdbgpgQvihzswv2d56wabT3/UVmY3DjgS8xxS5D6UTpXQWrscYz2Jg1qkDMLRGHhgJBCj01yW4TL3l8YTkvBTWyhViWATuThAf96WrQnWjEbgWfKRXB/pwlsnOuKLhn1dSLr8k1kVdMAbqbo6iT8BcW85b+Vr/Z7SYHp7qDhUO0d4Gh6p0PW9HEwe6ldndT804PWRJtjvx7dPGX7vwCnZ0q3irqqbrQI4v2WgpRtZfGxCUfnnN+muV5uqjI1O61+Q/M9k/dVeoGRt31MVm3Sa73DJGDlUanKJQth8yUv6tv2YEQmPhK5zoUuF4v3zrRpIVZ4Ciw== X-MS-Exchange-AntiSpam-MessageData: jD3K0u3FfEB0LpFhGyw4kN126m/R5KH5WdqOlFW6RCyuZYMSvNw7tKpLchpqQHDNm5p7zDgP8pwzbpHeijfDGd5JWpqpjp6mnPlgXStZsl1nO+6J0DAqeYOmRRzZzn7Tsh4Inn63Fp7Iyi2hclPjgA== X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 3270a6a3-50dd-4653-ca48-08d7da91c326 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 01:19:47.6516 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 8haM+0GMWwcJ4Yz2Uv1R6S8jRDb37YqL5PQ+ly0GRqo8bwo+Cz6WX3ZXjk6C86wQMSd+WfLihlT2daMQ2e3Q9o+yZnmX/xSebGhGJQCeeyQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB5133 Archived-At: Subject: Re: [Teep] Review request for TEEP cddl format. 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 Apr 2020 01:19:53 -0000 Hi, The link to the pull request which Hannes made on the COSE tag discussion. https://github.com/ietf-teep/teep-protocol/pull/19/files -Akira On 4/6/20 16:50, Hannes Tschofenig wrote: > Hi Akira, > > to answer your question: The COSE structures can be found in the COSE specification but I noticed that the currently listed tags are either not applicable anymore or less than ideal. I don't think we need any tagged COSE structures nor do we need to use anything other than COSE_Sign1. > > Ciao > Hannes > > -----Original Message----- > From: Akira Tsukamoto > Sent: Monday, April 6, 2020 8:54 AM > To: teep@ietf.org; Hannes Tschofenig ; Nancy Cam-Winget (ncamwing) ; Russ Housley ; Mingliang Pei ; Dave Thaler > Subject: Review request for TEEP cddl format. > > Hi all, > > This is based on the work of virtual hackathon. > > I tried to remove bstr in the teep message as much as possible, since cbor is all about the size reduction comparing the other binary formats. > > Would you mind reviewing the revised TEEP cddl format? > We only managed until TEEP_QueryRequest and TEEP_QueryResponse. > I tried to remove ambiguity as much as possible from the implementation perspective. > > I will reflect the comments on the first two messages and apply to the rest of TrustedAppInstall and etc. > > ``` > > TEEP_msg-authenc-wrapper = 1 > TEEP_message = 2 > > TEEP_Msg_AuthEnc_Wrapper = [ *(COSE_Mac_Tagged / > COSE_Sign_Tagged / > COSE_Mac0_Tagged / > COSE_Sign1_Tagged)] > > TEEP_Outer_Wrapper = { > TEEP_msg-authenc-wrapper => bstr .cbor > TEEP_Msg_AuthEnc_Wrapper / nil, > TEEP-message => bstr .cbor > (TEEP_QueryRequest / > TEEP_QueryResponse / > TEEP_TrustedAppInstall / > TEEP_TrustedAppDelete / > TEEP_Error / > TEEP_Success ), > } > > TEEP_TYPE_QueryRequest = 1 > TEEP_TYPE_QueryResponse = 2 > TEEP_TYPE_TrustedAppInstall = 3 > TEEP_TYPE_TrustedAppDelete = 4 > TEEP_TYPE_TEEP_Error = 5 > TEEP_TYPE_TEEP_Success = 6 > > TEEP_attestation = 1 > TEEP_trusted_apps = 2 > TEEP_extensions = 3 > TEEP_suit_commands = 4 > > TEEP_REQUEST_COMMAND /= TEEP_attestation TEEP_REQUEST_COMMAND /= TEEP_trusted_apps TEEP_REQUEST_COMMAND /= TEEP_extensions TEEP_REQUEST_COMMAND /= TEEP_suit_commands > > TEEP_AES-CCM-16-64-128_HMAC256/256_X25519_EdDSA = 1 > TEEP_AES-CCM-16-64-128_HMAC256/256_P-256_ES256 = 2 > > TEEP_suite /= TEEP_AES-CCM-16-64-128_HMAC256/256_X25519_EdDSA > TEEP_suite /= TEEP_AES-CCM-16-64-128_HMAC256/256_P-256_ES256 > > TEEP_version = uint .size 4 > > TEEP_TYPE = 1 > TEEP_TOKEN = 2 > TEEP_REQUEST = 3 > TEEP_CIPHER_SUITE = 4 > TEEP_NONCE = 5 > TEEP_VERSION = 6 > TEEP_OCSP_DATA = 7 > > TEEP_QueryRequest = { > TEEP_TYPE => uint .size 1 TEEP_TYPE_QueryRequest, > TEEP_TOKEN => uint .size 4, > TEEP_REQUEST => uint .size 1 TEEP_REQUEST_COMMAND, > ? TEEP_CIPHER_SUITE => uint .size 1 [+TEEP_suite], > ? TEEP_NONCE => bstr .size (8..64), > ? TEEP_VERSION => [+TEEP_version], > ? TEEP_OCSP_DATA => bstr, > * $$extensions > } > > TEEP_install = 1 > TEEP_delete = 2 > TEEP_update = 3 > > TEEP_DEVICE_DESIRE /= TEEP_install > TEEP_DEVICE_DESIRE /= TEEP_delete > TEEP_DEVICE_DESIRE /= TEEP_update > > TEEP_SELECTED_CIPHER_SUITE = 8 > TEEP_SELECTED_VERSION = 9 > TEEP_EAT = 10 > TEEP_TA_LIST = 11 > TEEP_EXT_LIST = 12 > > TEEP_QueryResponse = { > TEEP_TYPE => uint .size 1 TEEP_TYPE_QueryResponse, > TEEP_TOKEN => uint .size 4, > ? TEEP_DEVICE_REQUEST => uint .size 1 TEEP_DEVICE_DESIRE, > ? TEEP_SELECTED_CIPHER_SUITE => uint .size 1 TEEP_suite, > ? TEEP_SELECTED_VERSION => TEEP_version, > ? TEEP_EAT => bstr, > ? TEEP_TA_LIST => [+bstr], > ? TEEP_EXT_LIST => [+ext_info], > * $$extensions > } > > ``` > > By the way, is the COSE_Mac*_Tagged/COSE_Sign*_Tagged defined somewaher? > I tried to look into IANA and other rfc but could not find the exact place. > > Best, > -Akira > 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 the information in any medium. Thank you. > From nobody Tue Apr 7 02:59:02 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 9E15B3A1A23 for ; Tue, 7 Apr 2020 02:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=sgfkvouk; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=sgfkvouk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkFY7Xwbbi2K for ; Tue, 7 Apr 2020 02:58:58 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70052.outbound.protection.outlook.com [40.107.7.52]) (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 EEDE13A1A22 for ; Tue, 7 Apr 2020 02:58:57 -0700 (PDT) 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=w7INTiUtckQ+MXFWDJxFaVaUC1o/DBZqskyBNZ+8Jrg=; b=sgfkvouk1BXUgxe7XnxTRlnT1cytbEb339wbx/6n9yzOI4ItzniTYHAPWFDAxNPLvE3ATRTNaIgFg74XwZPdKFF+GQ01F9eCkUnTz7l8WCMzph1LTX6XPI9B6glinfc8nAmPuqJ9lQnVbKg5ktxtCss7j7JAgXlg8+3r3nuBiUo= Received: from AM5PR06CA0030.eurprd06.prod.outlook.com (2603:10a6:206:2::43) by VE1PR08MB4767.eurprd08.prod.outlook.com (2603:10a6:802:a6::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Tue, 7 Apr 2020 09:58:55 +0000 Received: from AM5EUR03FT014.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:2:cafe::99) by AM5PR06CA0030.outlook.office365.com (2603:10a6:206:2::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Tue, 7 Apr 2020 09:58:55 +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 AM5EUR03FT014.mail.protection.outlook.com (10.152.16.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Tue, 7 Apr 2020 09:58:54 +0000 Received: ("Tessian outbound e2c88df8bbbe:v50"); Tue, 07 Apr 2020 09:58:54 +0000 X-CR-MTA-TID: 64aa7808 Received: from 29b53faa7994.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 90B296F5-39A1-48EE-ABD1-5CB721BF8A40.1; Tue, 07 Apr 2020 09:58:49 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 29b53faa7994.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 07 Apr 2020 09:58:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m6f5YupJ4OB2lqmYVItihvFg5gvY+SJw/BrtvU/obgD2oXWxaXTn1d5QMxL/U6RE4tpjyGudWg0fWy3KEQMQ3ZUNic/tT1GTfA67bHyoITcRKbnRln2VbyaiBdg+e9F25icIspRi6Xd+sRN18g1m0lqSv4iBiqoTLDrXcVcmF9nujly/Rbr9Dwgte2J+DJLgQNcHfJMzqM0Of3Y9gVE4iDgrDqPaAWdvOLm6FPeuo5FG6cTj29L1RtJ3S0h2T+820YrP0pdZKd0CpvdjIewwetUsVlWBYra91r/f5zchkGCzBHYLQ/X3Nl6Cb9FTrG1K548v6wpH9LmXwqt+mB3rgw== 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=w7INTiUtckQ+MXFWDJxFaVaUC1o/DBZqskyBNZ+8Jrg=; b=I0Co0BMcBZQO6kjaIEtUx1KlM0/rVTKzSiHAmZYS+IuI02eXUG+s1cYQviBvUsOvXcd6K4iEWouEIbHltRpr+VJKYmImC9T+X0/xv6gWNHrqbpYllvI6TQ2Plo5wbwmglWISY09kORbDwiWKiaDLJUAxBAeNO4mbVhZZnAZ2bMy61LmAWF2/+4XChJoc6Rw7QHjGpgQr0gl80IK16VeAg8QynopPEooq+LKvROcVJJ/W88kmMUd27PDqwdbJ4CrnCqBQ4xi2YJcqxJkvICVvThUaJ9ASLVLCh2H6z9WgwERe9BAF6JEV52JtHo+Rxh4N7BacFJGgy3bWmzYeFghZLA== 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=w7INTiUtckQ+MXFWDJxFaVaUC1o/DBZqskyBNZ+8Jrg=; b=sgfkvouk1BXUgxe7XnxTRlnT1cytbEb339wbx/6n9yzOI4ItzniTYHAPWFDAxNPLvE3ATRTNaIgFg74XwZPdKFF+GQ01F9eCkUnTz7l8WCMzph1LTX6XPI9B6glinfc8nAmPuqJ9lQnVbKg5ktxtCss7j7JAgXlg8+3r3nuBiUo= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB5090.eurprd08.prod.outlook.com (10.255.29.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Tue, 7 Apr 2020 09:58:47 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 09:58:47 +0000 From: Hannes Tschofenig To: "teep@ietf.org" Thread-Topic: Formatting of the TEEP messages Thread-Index: AdYMwto0g6r36PFDSaSaQO1l0tlFdw== Date: Tue, 7 Apr 2020 09:58:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: ee1daf59-e6ac-4d06-ad2f-544d2d686130.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.119] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 524bcb9b-4677-45a5-4123-08d7dada483e x-ms-traffictypediagnostic: AM0PR08MB5090:|VE1PR08MB4767: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8273;OLM:10000; x-forefront-prvs: 036614DD9C X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(396003)(346002)(136003)(366004)(39860400002)(316002)(33656002)(186003)(26005)(66446008)(15650500001)(8676002)(64756008)(66556008)(66476007)(66946007)(76116006)(966005)(86362001)(8936002)(478600001)(81166006)(81156014)(2906002)(6916009)(6506007)(5660300002)(71200400001)(52536014)(55016002)(7696005)(9686003); DIR:OUT; SFP:1101; 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: cFbnB6ImBRpRKidTssiIWYCggoK2KmKjnx9ZLH8yYNjnWcQP86/yyzT4m3yowskROpZ87TTlTj4KImtU8XxugRIWKSokJj31jBfehQBYEh1FdkGPX9tT8jEXLRxw0g6glLBDpBRnYyQIcZ4jShV8xtgzZeZQtYUVFaVviOvNxwRgWdP6h6ETEmqWuQs1610D8C48HpaTmb9av7/fZZiyDGQqWvATybJ33B7qoXMjlv8cxOqXp7DufrYc8dhhSRYEb6TjNJa5Noa2rhhhRhTPxACvL97Arq0TdHgS7MBo78eE0LJBw5oWEgm/x7cHa5+f/hDH+9jEnc98VszIi8tBnCc9lsIFDz2lIlRk3mkcZq+ApxpwhBlCrBJeOQ4vo1CvAqYZ0ZUFJDZHHEoB5V5ZCI80VQlee6Y7D4TQfB1gEMzrG/MBQBFzMMIyAHMa5CfhRCov6hT01LiiTveVM+7QtoTiMinPbKBQckT+ECRMn5dZGgUS2ZRq4Hzxf9xaRsWfTNaKcgthhfRH2JF413mwKw== x-ms-exchange-antispam-messagedata: 2lqiEKrBJBP4e5YA8cTdBimepM0OYP16+7sjK//Q01Be3AarTX2k8NOrpWpDnKDojaQ6b7Q5Vty3VUwNZFgeQt7fi+lZILBpan6y8CcrNFVXWD5xoM3g8j0aBgx7MjMi9UbHBejJZwonAYiOAfeL8w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB3716EC86266D9325B021C7F7FAC30AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5090 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT014.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(39860400002)(46966005)(26826003)(7696005)(81156014)(26005)(81166006)(8676002)(33656002)(356004)(86362001)(15650500001)(336012)(6916009)(8936002)(82740400003)(9686003)(55016002)(966005)(47076004)(186003)(478600001)(52536014)(36906005)(70206006)(70586007)(316002)(6506007)(5660300002)(2906002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 660134da-0a4c-435e-6b2b-08d7dada43c3 X-Forefront-PRVS: 036614DD9C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: v/+49RQBmZZamxfh36ZdEvXTLEIhniI/w1ub9ZMjOl7YKxf5UpFqq5icO4iSs5QVUN8UvIJn+eB7Db6X/JpYS7+IORTYeINsaibN+WauXsHlP4TLIv+YQs42zLKzKKa4TeG9mKkztc4Zv7AcSNC6lhRgPYg1SNzfhnxjUBDwuZ0PWDAwEyUkkWMB8TsRKtVopKp5w8MfMjDTerIUU2n2/FcBK8rEESAPjDE4IEGXuxGbUUoe2aEsg1RpnbR3Nplku8agpetq2ehtrPIJiAKFqc+INFNBhFZltO4XN0zuV48Y0YwAHF8DRVKwpbImM6a4RtXjNYK6fvtz5lp8dnqKuKbuJ3PrOX9lvxoffs5OPKv7lfa/Lia5sBeeT1LTM5XY1dHDkXgMhjhAYo+EPZbVAhgQTgDsNqtFgb8+WlBVanYKAxzPCN5M7Q4dblgsEkDW3N/m/TFTmglh60EIp+HFK+GDdT/NIztWxPC/gvANu2AQGcjaEmS41LJVbQeB9ffgpK2zE8l4MqXmymQOqbuEDfXJ5/iHnSr0OVWsnYInQROMP9H1egqCNer3n80rLqAwTAtw0CQW73EX10qOHx3vgg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 09:58:54.5329 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 524bcb9b-4677-45a5-4123-08d7dada483e 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: VE1PR08MB4767 Archived-At: Subject: [Teep] Formatting of the TEEP messages 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 Apr 2020 09:59:01 -0000 --_000_AM0PR08MB3716EC86266D9325B021C7F7FAC30AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I am posting this topic to the list (although it is also discussed in a Git= hub issue at https://github.com/ietf-teep/teep-protocol/issues/21) because = it blocks any implementation activity going forward. I want to make sure that I understand the tentative conclusion from our vir= tual interim meeting yesterday correctly. The suggestion is to use an array= for the mandatory fields of the requests and to use a map for the rest. In the QueryRequest the first 3 elements of the array are type, token, requ= ested (which are parameters defined in the TEEP protocol spec) followed by = the last array entry, which is a map containing the optional parameters fou= nd in the QueryRequest message. Here is an example: [1, h'1C76CB4EF2665BC68B9198E76EE21C71', [2], {3 : 1, 5 : 1}] Is my understanding correct? Ciao Hannes 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_AM0PR08MB3716EC86266D9325B021C7F7FAC30AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I am posting this topic to the list (although it is = also discussed in a Github issue at https://gi= thub.com/ietf-teep/teep-protocol/issues/21) because it blocks any imple= mentation activity going forward.

I want t= o make sure that I understand the tentative conclusion from our virtual int= erim meeting yesterday correctly. The suggestion is to use an array for the mandatory fields of the requests and to use a m= ap for the rest.

In the QueryRequest the first 3 elements of the array are t= ype, token, requested (which are parameters defined in the TEEP protocol sp= ec) followed by the last array entry, which is a map containing the optional parameters found in the QueryRequest mess= age.

Here is an example:
[1, h'1C76CB4EF2665BC68B9198E76EE21C71', [2], {3 : 1, 5 : 1}]

Is my understanding correct?

Ciao

Hannes

 

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_AM0PR08MB3716EC86266D9325B021C7F7FAC30AM0PR08MB3716eurp_-- From nobody Tue Apr 7 04:59:25 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 6B49F3A043F for ; Tue, 7 Apr 2020 04:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=2.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, PDS_BTC_ID=0.499, 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=aist.go.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz6mt2szkvS7 for ; Tue, 7 Apr 2020 04:59:21 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410043.outbound.protection.outlook.com [40.107.141.43]) (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 B2BDD3A0410 for ; Tue, 7 Apr 2020 04:59:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ePOGTnYjXyQ1eyOYIiY5cJnH8Mj67BP5JbrqnYzSKVPkr3eUUFe3oCiqEVAihO1O9+cHUpd3SwDSy7jDBY/Psoc0J4G8QCoO3BT4awxM+JYAP885vmf8LY9IxSKOB1Z7g7AXjauIFkmqfCkHLl5Lxic6rdY0yQFVFxSU+KU7jCzwAg9bUDypsqZt+enmaMqM16sJKdooikGvGmHzR/LMRU+XuK3T9mpLtC+B9lxT35STJkER16R+LAiy7mCrs7y7/5DKW5Wzc8vCV9Cs7vZz/XJiaf9zxGE8F4K9t1MmdG3Qk7PhTec2i3m5gvpYTzjEH5oz3f+v5RRorsLIkbKc5w== 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=U2wOLG5KZKQ2EfG1xBqw7jvWoFOU7xxOzQCO/lacqpM=; b=XAEMyK5hLZ3k9hEi17oWfAHPFrtKv1e+sxeuPoGNHEVromPuhdcHOgny6sr3vbfNVgG50ETpbE0CzmfIgZ8gXXUWdnpnUMJ5mmSxOsYMfijC3hIvYcL9cxe2Jids6/yvx7tSpfEF2Nd8jUgHLDAp9s0mLCXQqKnmgGrSVTM3buPZGNkH94gdbOnBRPsOB8vddbE83ho4HNFUZ5jGwjRou61ZY9hcnMVWq3Vvm/fi8aEt3MZAgV+6Ul8eNBcjYlrBT3fwKvHfKztSbAJUbKabghoJ5J/m/8ySEC6WwWYIrVzITk3QgG4ZTZ+2knLNziU/mxRKAUbn+FW5iKNHbRALnQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U2wOLG5KZKQ2EfG1xBqw7jvWoFOU7xxOzQCO/lacqpM=; b=levkmryl4qlqKkweaQDBaFzbZ585unIKlv4EbtoGo15uIVmSc3It5H5QicIk3xoAfb5pgS2kHxGdrKOLK9NUCjuFc17eA8w1nu/9/3ph9826pcIDnp5POjehVFfj2f10osObPMs1tMZQ0OSfJ/6SuRWcQqanp7BNbzBiwhWDsPM= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akira.tsukamoto@aist.go.jp; Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com (20.178.140.147) by TYAPR01MB3390.jpnprd01.prod.outlook.com (20.178.140.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Tue, 7 Apr 2020 11:59:19 +0000 Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2]) by TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2%7]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 11:59:19 +0000 To: Hannes Tschofenig , "teep@ietf.org" References: From: Akira Tsukamoto Message-ID: Date: Tue, 7 Apr 2020 20:59:18 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYAPR04CA0009.apcprd04.prod.outlook.com (2603:1096:404:15::21) To TYAPR01MB3406.jpnprd01.prod.outlook.com (2603:1096:404:cc::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.153] (217.178.18.13) by TYAPR04CA0009.apcprd04.prod.outlook.com (2603:1096:404:15::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Tue, 7 Apr 2020 11:59:19 +0000 X-Originating-IP: [217.178.18.13] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b4666b48-89fb-4371-4674-08d7daeb1a79 X-MS-TrafficTypeDiagnostic: TYAPR01MB3390: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 036614DD9C X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3406.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(366004)(396003)(346002)(136003)(39860400002)(110136005)(86362001)(16526019)(16576012)(316002)(5660300002)(26005)(66556008)(186003)(52116002)(66946007)(66476007)(31686004)(53546011)(478600001)(81166006)(8676002)(2616005)(966005)(15650500001)(8936002)(6486002)(81156014)(44832011)(31696002)(45080400002)(2906002)(36756003)(956004); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NKIGs72g8quBqR++61lJ45+CmvbsRztK1WHU/KDsA0AcnilsHvv5RUh98jHKGGLooHtDwE8l1/LX6EeL8eyxKQN8WRjJ6bK4ZT7q56hLEdbgFMq53PzqWe1Y7qKMS+8ZWIiTM9IoroVQhTJTphW8YM/Egdfyz/GtiNXp8PzEoxpFEel4SgvkOGryBBIXjz8ymafjz9MmnBxtxw3DItXw1g+PjnbheQzOYwIBQTF2Jh5zkA/iYQklDVSVuQkzCvnQhLfe8fBFZygZVV2DeWtKERmhYMcuuGpXG1vQe0JetafC93X7Hwnu3qbPfWfvqHoq/vqg54WrzblsVbas1ZlunWMfWJW2u4JbFxDmfYaSwO2ndJonHd0t//9t0wUlGrQovIRLKzAsFENLuFaxlSDkYJFV+5v6nFIuPpjv7WvrGLxyPcZH7fudXIbuu9sPilbr/M9GxU3vQ9Jm7CdA9VN4gama12jX/Rk6PTqF7aDnWlIYYBQ2mWQgPjt/ZDuXkcqeAmHJSRyZvJ9n9H7/cXdXgw== X-MS-Exchange-AntiSpam-MessageData: wHNyhDBGSabOkPG40+WJKL0TJL6TYT7XaQAk0gpdQETtlkHTdAXR03NqPk8dZkk/cbFIgMOMPw+nHfNkfUAH2aMnmZugXHKBV0Ty86w9wUHWIozGMUq/MdnUmIdkj+4+665rzpvLvDaPY4AlDNfZWw== X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: b4666b48-89fb-4371-4674-08d7daeb1a79 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 11:59:19.4348 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: bdGFbQyrdPP22z5uypJ+nfyUCIxZPL2Wp9catprhca9gXZH7F7w9HGXAkMNb6+p7o4MtltHb4ogTUFlUlUd/+x7okGFP9Jd/F2H285T0/MY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB3390 Archived-At: Subject: Re: [Teep] Formatting of the TEEP messages 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 Apr 2020 11:59:23 -0000 Hi, I just post current example in binary format with my hand binary encoding at the github. https://github.com/ietf-teep/teep-protocol/issues/21 Which the QueryRequest = { TYPE : int, // TYPE is 1 for QueryRequest TOKEN : bstr, // TOKEN using 1C76CB4EF2665BC68B9198E76EE21C71 REQUEST : [+data_item], // using 2 here as an example ... will be something similar to A4 // the map is A? and number of members, so if it has four members then it will be A4 58 04 45 95 05 54 // h'45950554' // TYPE label name in bstr will be embedded in map 01 // 1 for TYPE value 58 05 45 F4 B4 54 E4 // h'45F4B454E4' // TOKEN label name in bstr will be embedded in map 58 10 1C 76 CB 4E F2 66 5B C6 8B 91 98 E7 6E E2 1C 71 // h'1C76CB4EF2665BC68B9198E76EE21C71' // value for TOKEN in bstr 81 // the array is 8? and number of members, so if it has one member then it will be 81 02 and ... I will probably come back to this topic next week. Best, -Akira On 4/7/20 18:58, Hannes Tschofenig wrote: > Hi all, > > I am posting this topic to the list (although it is also discussed in a Github issue at https://github.com/ietf-teep/teep-protocol/issues/21 ) because it blocks any implementation activity going forward. > > I want to make sure that I understand the tentative conclusion from our virtual interim meeting yesterday correctly. The suggestion is to use an array for the mandatory fields of the requests and to use a map for the rest. > > In the QueryRequest the first 3 elements of the array are type, token, requested (which are parameters defined in the TEEP protocol spec) followed by the last array entry, which is a map containing the optional parameters found in the QueryRequest message. > > Here is an example: > [1, h'1C76CB4EF2665BC68B9198E76EE21C71', [2], {3 : 1, 5 : 1}] > > Is my understanding correct? > > Ciao > > Hannes > > 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 the information in any medium. Thank you. > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C5365f219da914118e7b308d7dada5068%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637218503508534866&sdata=kqxqbjmv0%2BX%2BUZNAti8zaVamr4HN9BmE11bOAHAaIOs%3D&reserved=0 > From nobody Tue Apr 7 05:09:05 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 0F0613A058F for ; Tue, 7 Apr 2020 05:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hPufPRIi01t for ; Tue, 7 Apr 2020 05:09:00 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43EE3A0542 for ; Tue, 7 Apr 2020 05:09:00 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48xR5l1CfQzyxN; Tue, 7 Apr 2020 14:08:59 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 7 Apr 2020 14:08:58 +0200 Cc: "teep@ietf.org" X-Mao-Original-Outgoing-Id: 607954138.587293-6e3c2d5784e176301925a5d9250231be Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Teep] Formatting of the TEEP messages 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 Apr 2020 12:09:03 -0000 On 2020-04-07, at 11:58, Hannes Tschofenig = wrote: >=20 > [1, h'1C76CB4EF2665BC68B9198E76EE21C71', [2], {3 : 1, 5 : 1}] >=20 > Is my understanding correct? If you ignore that token was supposed to be a uint yesterday: That=E2=80=99= s similar to what I would do. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Apr 7 05:09: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 AF1243A0542 for ; Tue, 7 Apr 2020 05:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_BTC_ID=0.499, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=khM7Dc+H; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=khM7Dc+H Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05_8k813NIuS for ; Tue, 7 Apr 2020 05:09:28 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2054.outbound.protection.outlook.com [40.107.20.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 647C23A052C for ; Tue, 7 Apr 2020 05:09:27 -0700 (PDT) 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=DZhvor2SUiYaOCrFS0LAmGZKiWcgt+NDf2eSfoIx690=; b=khM7Dc+HhGKqKMvdd+QWVWCtIi5XqulZucPkdqFv1z//pF12dc3izu1hLRqQlxAaakZa5Ruj6BHwQa+yvC6OBqB0hCOeU04WvyoxGm34eShTQknsB9YUKVwql3IpVNqWyRO0jmS+s18hUfMx8t+Hsr/FY5GNlta4ODgU+pcbCoc= Received: from AM5PR06CA0021.eurprd06.prod.outlook.com (2603:10a6:206:2::34) by HE1PR0801MB2027.eurprd08.prod.outlook.com (2603:10a6:3:4f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.17; Tue, 7 Apr 2020 12:09:25 +0000 Received: from AM5EUR03FT030.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:2:cafe::75) by AM5PR06CA0021.outlook.office365.com (2603:10a6:206:2::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Tue, 7 Apr 2020 12:09:25 +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 AM5EUR03FT030.mail.protection.outlook.com (10.152.16.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Tue, 7 Apr 2020 12:09:24 +0000 Received: ("Tessian outbound 1425309d4c0b:v50"); Tue, 07 Apr 2020 12:09:24 +0000 X-CR-MTA-TID: 64aa7808 Received: from b7a02a6a4c1a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 50E23194-8BB6-4D4B-A085-F19B6FF65AD9.1; Tue, 07 Apr 2020 12:09:19 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b7a02a6a4c1a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 07 Apr 2020 12:09:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AcwqARnDSlGmwVJXR/uhaAxn3KB4Ttk3XJk3EdFR9oibvvOgn7zu/AmF97Ftq4xUtQYuQtJgDKfkOBdt3Jm5tCjQxzl9VOel9lmEEHiP4QKtl9hYnIXyHikgZ8dsLWJg+V5YtCvDTOVdGTe2gMgyX49zF40mryTSdmCvChyJNUeg2PwUhydYsBjzoDXrbBTZpcOpKC7Dw7wQmLSTCUsYbL/foftn8POs2ykCwjpt+IntXFKE/lObfnSfDVMFEDo5cUaA1Yotg1EVrGe+2rTkA0UtMx34uuiSr4d6S1yTb1RxzE6D2Xo4aoGLcNhikmd43teHgZhML0FZwdKcrfdpIw== 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=DZhvor2SUiYaOCrFS0LAmGZKiWcgt+NDf2eSfoIx690=; b=UJwZvXqo/dHKaWOK98WwcMYnoF3OwswmhjmXGt6r7Q30N85rslasGcaHPRM3HR8dUHADEWklO2SCPb6GfIf/W/SnPuV1+Rbflf/lm1mGH5yUTkSCyr+63SQWl2HNtD4KEYO139f3SYFJ68pdLHw9JYUmZoosRS9YJEsKKYOAXMp8Vazh7/MVYqVVhH4OeJnxlzTuaALzCv3aqEHaspEyipjJW9cYxDb14t7h4ZL4qq2b9xrcaoW4t1cWvxLpsv2HCcFYFJh//KHbVU2xdQUOVS1D7qyuoMobKlljlBhvCpoT4yeBBcaeXLvkoQ3JarqkZLuTQak+7c28VsEM8GZi1w== 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=DZhvor2SUiYaOCrFS0LAmGZKiWcgt+NDf2eSfoIx690=; b=khM7Dc+HhGKqKMvdd+QWVWCtIi5XqulZucPkdqFv1z//pF12dc3izu1hLRqQlxAaakZa5Ruj6BHwQa+yvC6OBqB0hCOeU04WvyoxGm34eShTQknsB9YUKVwql3IpVNqWyRO0jmS+s18hUfMx8t+Hsr/FY5GNlta4ODgU+pcbCoc= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB3108.eurprd08.prod.outlook.com (52.134.93.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Tue, 7 Apr 2020 12:09:18 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 12:09:18 +0000 From: Hannes Tschofenig To: Akira Tsukamoto , "teep@ietf.org" Thread-Topic: [Teep] Formatting of the TEEP messages Thread-Index: AdYMwto0g6r36PFDSaSaQO1l0tlFdwAER0MAAABNW+A= Date: Tue, 7 Apr 2020 12:09:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 551bb2a5-c840-4a72-b4b7-987004680430.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.119] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 5f97d376-2740-446c-41e4-08d7daec8328 x-ms-traffictypediagnostic: AM0PR08MB3108:|HE1PR0801MB2027: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 036614DD9C X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(366004)(396003)(376002)(346002)(39860400002)(81156014)(26005)(53546011)(6506007)(2906002)(966005)(86362001)(8676002)(76116006)(45080400002)(8936002)(33656002)(316002)(7696005)(81166006)(15650500001)(55016002)(186003)(478600001)(66946007)(110136005)(71200400001)(9686003)(5660300002)(66476007)(64756008)(66446008)(52536014)(66556008); DIR:OUT; SFP:1101; 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: /xXTuJ3zgrKJa9JUl2JP5MEYYaYNclqyByUJCLJE4pPyvSLLJzkV2zJlMugI9pvdX0ZUeEYEkus+bwrcEBH61MSX9XGjYl07aV2dpKwC6vBZKejqrUtp+4RD6gQkASE0kSwiJmp+HYUY+M4n6874AB6K01qCiOaqraXdIyBynjdLhAIaCxd1W8ooB7/zf6ikMqe4ZAsiyta3Sjw9jjKtu7piSlQzpLJqiL5yspLRf1bJpdXG++GSBjfGOX4oz4aRLAm1m44kdW0JcIY9RCf6kHPaSXV2xh8ic1kAxJ6hZ/6RSMcxScmbbpiFR0ZC91h9ruw+0qpoRROwx9/mfKZ3DD7CFaFZUSKpvDkNOn8XMPRaTqiFy6gAFPwqQfJZRupjNupo8iUw/Ej5DMZa2/Dfdr7VyQqPznbpYi2uhUjh3w7PjvS6vTUqabMf/CxnwMFW5ChTDZehcnBZwhIJAasXQjJccKjAiDG6hz/FP6Ty0Nvm+SBSH7eVchSidqItBks1i4ahAg6g+i5s+lsV786qrA== x-ms-exchange-antispam-messagedata: Pj+QHLk5+XpQVGCcjL281BZxbfFJSu8cqyqSwlYdYPOjOv+EQuWpWHeZZFhh7jKG7rbCMJOqxYJ/KmJHFbS6/W5B4l9nywuAXy1QCMyvYsytUAXVQgPXN35+LnjDz9WgiPD/sEeBLrhaSdxaTSOFcA== 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: AM0PR08MB3108 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT030.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(39860400002)(396003)(136003)(346002)(46966005)(186003)(336012)(52536014)(86362001)(356004)(26005)(33656002)(55016002)(36906005)(2906002)(26826003)(966005)(110136005)(478600001)(45080400002)(6506007)(8936002)(15650500001)(70586007)(8676002)(70206006)(9686003)(316002)(53546011)(82740400003)(7696005)(81166006)(47076004)(5660300002)(81156014); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 9be33f79-8fac-472f-2815-08d7daec7f67 X-Forefront-PRVS: 036614DD9C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fgt0Z9ESook0nEy4rlRmY250TWFfzuqPfVNlfQ1I9nhKXq2IYpeCQhXCJBd/tDlVwk/REfnxp9L+vL4LotgDUwngy198H7YyI9R2004JpxMilKBQprmmV/lkbHsF2oxNxEskl+qqRtJ4ebMwGxDerhjq6uiCSTz+mTIENkpo4SZWdbcNIKmagJFsMf6Wdw65UGfQ2ZAEvLSWihcGP5Z+vDJFx0X5y+rPWUe6N4LVhB+/1s+l5MIL6S/wBxyQTuedafx70G/HzYBGqV7cmQ7LkUceDCXB9FFo4o9sG/TeRyzwSwSSYHHIN0cGM/ZZP+ZvI6LKVhdkvv+P4NDIcuQQRm+s73IsBeN0IwPaeqtSaglVtZBuLmMQbbAIFL7T/qg54x0UGIylbhj2ariqRzJTYdLHoFx6Q3QLWN4wxJVPhP9dvMKGZp1sAtQKyLpuWXV4+NsoMadBLh1+Hmjxi+IxLlqxx0nteADU7FjfTVJmOOE2jmplCytCKzIeBe4YgUTec7ozjvs7Lzthh6ikYe7Jt6Sye4ODBm2d7yqxYKa/7PJlpbr8wJWUouA0PHccQ3aqZlTZHSG7vA1P9CDK5znuFA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 12:09:24.3164 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5f97d376-2740-446c-41e4-08d7daec8328 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: HE1PR0801MB2027 Archived-At: Subject: Re: [Teep] Formatting of the TEEP messages 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 Apr 2020 12:09:31 -0000 Hi Akira, In your example you still use a map instead of an array and for the type yo= u should use the unsigned int instead of int. That's at least what was prop= osed yesterday in the virtual interim meeting. Ciao Hannes -----Original Message----- From: Akira Tsukamoto Sent: Tuesday, April 7, 2020 1:59 PM To: Hannes Tschofenig ; teep@ietf.org Subject: Re: [Teep] Formatting of the TEEP messages Hi, I just post current example in binary format with my hand binary encoding a= t the github. https://github.com/ietf-teep/teep-protocol/issues/21 Which the QueryRequest =3D { TYPE : int, // TYPE is 1 for QueryRequest TOKEN : bstr, // TOKEN using 1C76CB4EF2665BC68B9198E76EE21C71 REQUEST : [+data_item], // using 2 here as an example ... will be something similar to A4 // the map is A? and number of members, so if it has four members then i= t will be A4 58 04 45 95 05 54 // h'45950554' // TYPE label name in bstr will be embedde= d in map 01 // 1 for TYPE value 58 05 45 F4 B4 54 E4 // h'45F4B454E4' // TOKEN label name in bstr will be e= mbedded in map 58 10 1C 76 CB 4E F2 66 5B C6 8B 91 98 E7 6E E2 1C 71 // h'1C76CB4EF2665BC6= 8B9198E76EE21C71' // value for TOKEN in bstr 81 // the array is 8? and number of members, so if it has one member then = it will be 81 02 and ... I will probably come back to this topic next week. Best, -Akira On 4/7/20 18:58, Hannes Tschofenig wrote: > Hi all, > > I am posting this topic to the list (although it is also discussed in a G= ithub issue at https://github.com/ietf-teep/teep-protocol/issues/21 ) because it blocks any implementation activity= going forward. > > I want to make sure that I understand the tentative conclusion from our v= irtual interim meeting yesterday correctly. The suggestion is to use an arr= ay for the mandatory fields of the requests and to use a map for the rest. > > In the QueryRequest the first 3 elements of the array are type, token, re= quested (which are parameters defined in the TEEP protocol spec) followed b= y the last array entry, which is a map containing the optional parameters f= ound in the QueryRequest message. > > Here is an example: > [1, h'1C76CB4EF2665BC68B9198E76EE21C71', [2], {3 : 1, 5 : 1}] > > Is my understanding correct? > > Ciao > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n any medium. Thank you. > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://jpn01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fteep&data=3D02%7C01%7Cakira.tsukamoto%40= aist.go.jp%7C5365f219da914118e7b308d7dada5068%7C18a7fec8652f409b8369272d9ce= 80620%7C0%7C0%7C637218503508534866&sdata=3Dkqxqbjmv0%2BX%2BUZNAti8zaVam= r4HN9BmE11bOAHAaIOs%3D&reserved=3D0 > 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 Tue Apr 7 05:10:37 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 53BA03A052C for ; Tue, 7 Apr 2020 05:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_BTC_ID=0.499, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=dVN8v5+X; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=dVN8v5+X Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxzI9bn3-bKi for ; Tue, 7 Apr 2020 05:10:35 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2073.outbound.protection.outlook.com [40.107.20.73]) (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 C2AF83A0542 for ; Tue, 7 Apr 2020 05:10:34 -0700 (PDT) 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=UFkeETZ8MeZrCEbVzRIZUCW+/gQnDlq1FVhHqNF4d9I=; b=dVN8v5+XLYNB7LrPQ86ucBcdx2WHOEgGdlVqrdikTOnB5ZhZ03YqxK//FH6EKrBVaGqu6WMSUSeTjTAZ7rbmj/8UhVIDofDx5WOSmrB2YloF2evgs9/v5wewEpW84Tw12Sct5QTDxpTgxT9zFp4lFN2wXOU3P1E5YhRfb3eYJZg= Received: from VI1PR0802CA0043.eurprd08.prod.outlook.com (2603:10a6:800:a9::29) by AM6PR08MB3286.eurprd08.prod.outlook.com (2603:10a6:209:40::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Tue, 7 Apr 2020 12:10:30 +0000 Received: from VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com (2603:10a6:800:a9:cafe::7e) by VI1PR0802CA0043.outlook.office365.com (2603:10a6:800:a9::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.17 via Frontend Transport; Tue, 7 Apr 2020 12:10:30 +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 VE1EUR03FT041.mail.protection.outlook.com (10.152.19.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Tue, 7 Apr 2020 12:10:30 +0000 Received: ("Tessian outbound 5345ff401cf8:v50"); Tue, 07 Apr 2020 12:10:30 +0000 X-CR-MTA-TID: 64aa7808 Received: from c25c2e0d36d3.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 8ED4211C-3C39-408B-B28F-364F66E9089C.1; Tue, 07 Apr 2020 12:10:25 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c25c2e0d36d3.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 07 Apr 2020 12:10:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hZOWJR5+lWIUtHRZAp+bkYb22MlR48AYPKiuennAfkfNQBtbk9UO5gtFfGFMfvFfp8LvZlJl5na0odOqQvjqBlkbXvYtMEQwtRClECjfFrZ6oAe4Dhr7Lv2l+V8EfXoU0oFL1tanTIcdlephFjRWxvcWE5OucKt40aoTH3EW/iibtN91NKTDzqzwcvVi6Scb+zr5gqOPA+84paRonwwglSgcHv7Vt5nsjMo0F/SsURfbhEWhQc7FlnPIusq+xWIvniHga2+n0u4GdwhDEP1ySVVKONnkBAAszxEunT4OcPrCR8XvvG8LARSme+yDFM07pT+gAfnWvCyoGRfyvtmVlg== 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=UFkeETZ8MeZrCEbVzRIZUCW+/gQnDlq1FVhHqNF4d9I=; b=ljb4ZDMUr1RPXRrfSq3BElu2utOIvrwevNPLNzaHXn6p+gAQGL6dep+Px+REpLDjz0zMuEOxP2CKgzf8gyI9dXlimpSSkvGCTeEZV8d0RCuB7HQylw39Ejj8Int43H1FyHYC5a1uKrNhZaxLeWlV6fPvWy08PghFaZpSgE3bvhGfBt2Eq/xesbb4BWJf1sMxaxIdPFYKQzhVJpYK9KgwTX4y5qQiy0wTIkLAmM7s2ljwIzbLp3LQBqqrWoeQXVYbI0bKrtH8zpkmaiI8iZ7VTmjP796FMDZBeMCrd4GgRaO0qsuDN8SR70tipNWi/JGokZ3HHkh7fMUFMfHbwpp6/Q== 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=UFkeETZ8MeZrCEbVzRIZUCW+/gQnDlq1FVhHqNF4d9I=; b=dVN8v5+XLYNB7LrPQ86ucBcdx2WHOEgGdlVqrdikTOnB5ZhZ03YqxK//FH6EKrBVaGqu6WMSUSeTjTAZ7rbmj/8UhVIDofDx5WOSmrB2YloF2evgs9/v5wewEpW84Tw12Sct5QTDxpTgxT9zFp4lFN2wXOU3P1E5YhRfb3eYJZg= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB3108.eurprd08.prod.outlook.com (52.134.93.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Tue, 7 Apr 2020 12:10:24 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 12:10:24 +0000 From: Hannes Tschofenig To: Carsten Bormann CC: "teep@ietf.org" Thread-Topic: [Teep] Formatting of the TEEP messages Thread-Index: AdYMwto0g6r36PFDSaSaQO1l0tlFdwAEnbAAAAAGmKA= Date: Tue, 7 Apr 2020 12:10:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: d45faa3d-7dda-47ac-adc8-2c4f0785c883.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.119] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e9c00f6e-63da-4a1c-7731-08d7daecaa7d x-ms-traffictypediagnostic: AM0PR08MB3108:|AM6PR08MB3286: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000; x-forefront-prvs: 036614DD9C X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(366004)(396003)(376002)(346002)(39860400002)(81156014)(26005)(53546011)(6506007)(2906002)(86362001)(8676002)(76116006)(8936002)(33656002)(316002)(7696005)(81166006)(15650500001)(55016002)(186003)(478600001)(66946007)(71200400001)(9686003)(5660300002)(4744005)(4326008)(66476007)(64756008)(6916009)(66446008)(52536014)(66556008); DIR:OUT; SFP:1101; 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: ctrLw9/1HP5Yjva3Yg0iXMCxb7bBL/O31O8xEHpqo07wpiGHLxTaaF3qtLjTICSRv4+m7n8nUBzQGB9TjxYJuNGmDkQpoPlJm5E9pYf5FpUMbD1U0R+VZvZGy8as9km3kaeRr+wYUEinH2wMyKD8Xo09L8IimcAekM+4WgPB5FytV19nV6v6+oIaQTOdCyYeD4lHCqKMrwx3swiQb8gwl0Jsvbb3FP34Q0RRR1+9wimGF8CgVPtOxXaY2e5/9qh1GmtxRPb6b6wvHgE354dzDt1EcDWzmmzLECHM06FdMstCJBOB7e4LLfUzGEVw7nhwbsXhYjzMnMBXsFbXFxy3ddivwA02JY2cjB7riNR8kQYGRtmoCOEEm7S9lLkNfEAs72vBOWrQBQVElaZp5rzVtbFAhOg7NukH7CybRSg/dGI++hx83o4iYM5DZ2Zdk/Wc x-ms-exchange-antispam-messagedata: PNgPv9DzNSS4Mlf5L4Xfn/++a0vnGrM4O7A0RV2mGNOMDtcSfdOlLQG9JFjocnQXsK9POFoKvegVVUhtUfuHvwSOb3ly53UM4Y+NjS+Pij+ZbUsoDLhTRAaVZMtgcl4fJtlsA9Du1C9Z0hOG5717Pg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3108 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT041.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(136003)(376002)(46966005)(7696005)(82740400003)(26826003)(478600001)(9686003)(186003)(55016002)(81166006)(81156014)(356004)(8676002)(4744005)(8936002)(47076004)(52536014)(6862004)(33656002)(15650500001)(5660300002)(70206006)(4326008)(2906002)(26005)(70586007)(53546011)(86362001)(316002)(6506007)(336012)(36906005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: cbf41e79-4a2c-4302-4c62-08d7daeca6ed X-Forefront-PRVS: 036614DD9C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: D4aH9o/fkBwHmFyev7JuBU722xL/UcJ9z9J1ayF9PKz79d00lYXOU3Ws+MZLKTIbCVCKpOfBMokINeXKPsJ3f8Ob6r4qIf/ZreADGFlJygy8ht8D81ZERA48k1O+AYBJz7vP4ffRWGAbdDQBe5GGxEyzQPfrxDN0yqhVVoAi2JKLXrcm62CSqX/6gjr8s+lY/ZGtC+CmY+q6dqOxAst5b+rBAUVqDl98dKzDA6lh0Hf0pu5Z+wYb3wzmaQERHdxWJiAROUWhFL80IE5cpiTVbfsxwGeJ95nB0hyOp1Ht1xlMuvDioAuK7EmOJOKS9cTW3zexT/Zmx9jn4W33opqawCUWxuPCzQz5iH/dzlgXT5QfglV3TtXsLUMvUgpOo23J3Xx3yye/pHotCfPY6d9TubrfeUKZ3iFUexGDtiKMnj9apKfHYnJp6JDZiof3YnDA7JLe4NA/l+KbfG/BWTtY+VwUOpxNC125IEtRZmaNcxKyCs3jNNEPm62oDHlY2mKNQbR8wuuy+TZ0VQy40/cEdQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 12:10:30.2629 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e9c00f6e-63da-4a1c-7731-08d7daecaa7d 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: AM6PR08MB3286 Archived-At: Subject: Re: [Teep] Formatting of the TEEP messages 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 Apr 2020 12:10:36 -0000 VGhhbmtzLCB0aGF0IGhlbHBzLiBJZiBub2JvZHkgb2JqZWN0cyB3ZSB3aWxsIG1ha2UgdGhlIGNo YW5nZSB0byB0aGUgc3BlYy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENh cnN0ZW4gQm9ybWFubiA8Y2Fib0B0emkub3JnPg0KU2VudDogVHVlc2RheSwgQXByaWwgNywgMjAy MCAyOjA5IFBNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b20+DQpDYzogdGVlcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUZWVwXSBGb3JtYXR0aW5nIG9m IHRoZSBURUVQIG1lc3NhZ2VzDQoNCk9uIDIwMjAtMDQtMDcsIGF0IDExOjU4LCBIYW5uZXMgVHNj aG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4gd3JvdGU6DQo+DQo+IFsxLCBoJzFD NzZDQjRFRjI2NjVCQzY4QjkxOThFNzZFRTIxQzcxJywgWzJdLCB7MyA6IDEsIDUgOiAxfV0NCj4N Cj4gSXMgbXkgdW5kZXJzdGFuZGluZyBjb3JyZWN0Pw0KDQpJZiB5b3UgaWdub3JlIHRoYXQgdG9r ZW4gd2FzIHN1cHBvc2VkIHRvIGJlIGEgdWludCB5ZXN0ZXJkYXk6IFRoYXTigJlzIHNpbWlsYXIg dG8gd2hhdCBJIHdvdWxkIGRvLg0KDQpHcsO8w59lLCBDYXJzdGVuDQoNCklNUE9SVEFOVCBOT1RJ Q0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNv bmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5 IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVz ZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGlu IGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Tue Apr 7 05:36:32 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 E92F43A0820 for ; Tue, 7 Apr 2020 05:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_BTC_ID=0.499, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts-Gs_cjnz1W for ; Tue, 7 Apr 2020 05:36:28 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD2383A07E0 for ; Tue, 7 Apr 2020 05:36:28 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48xRjQ3q0SzyxN; Tue, 7 Apr 2020 14:36:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Tue, 7 Apr 2020 14:36:26 +0200 Cc: "teep@ietf.org" X-Mao-Original-Outgoing-Id: 607955785.9901609-3787b8585e4720f99284f2374b6a0b0c Content-Transfer-Encoding: quoted-printable Message-Id: <6AEAFCE8-F16E-4049-BB62-B84B17FCF3AB@tzi.org> References: To: Hannes Tschofenig X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Teep] Formatting of the TEEP messages 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 Apr 2020 12:36:31 -0000 I converted the draft to markdown so =E2=80=94 there are no longer XML build errors =E2=80=94 I can contribute to the draft. PR #25 (you can ignore #24 then). Gr=C3=BC=C3=9Fe, Carsten > On 2020-04-07, at 14:10, Hannes Tschofenig = wrote: >=20 > Thanks, that helps. If nobody objects we will make the change to the = spec. >=20 > -----Original Message----- > From: Carsten Bormann > Sent: Tuesday, April 7, 2020 2:09 PM > To: Hannes Tschofenig > Cc: teep@ietf.org > Subject: Re: [Teep] Formatting of the TEEP messages >=20 > On 2020-04-07, at 11:58, Hannes Tschofenig = wrote: >>=20 >> [1, h'1C76CB4EF2665BC68B9198E76EE21C71', [2], {3 : 1, 5 : 1}] >>=20 >> Is my understanding correct? >=20 > If you ignore that token was supposed to be a uint yesterday: That=E2=80= =99s similar to what I would do. >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > 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 = the information in any medium. Thank you. From nobody Tue Apr 7 05:41: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 0DCFA3A0860 for ; Tue, 7 Apr 2020 05:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=2.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, PDS_BTC_ID=0.499, 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=aist.go.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovym6dcoacEn for ; Tue, 7 Apr 2020 05:41:10 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400057.outbound.protection.outlook.com [40.107.140.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C453A085E for ; Tue, 7 Apr 2020 05:41:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a5P/m1g/62ySj7owdCertHND/4AWpJwsR5amcde8+v8BStKt9VtxGBbn1CkBB2UB7Ocll3Hd92vFvVB8aMSKzHkRQ2yGLPjNDsFA1RcMKD77TSNjJY6RJISRoTj/hKKsw3Zw4dOSysybqvHlkS/fzgKBU4KBlxDWQUeyl2Ic6I/lVL03pnrHei5sUmy3id0bQycihBaHXlN8Muxs8bGjwrWwzybG6DWhqhHdwQnXujh6GAoxU7HTaTE0uNtngD177KQdqZocRAeGiqk99Bq3F/hVBQJBavjAYEVf/6AbBuiOwpS6bgWRZhoruaKSHHphXC1nkQfBVrPVVcgm2sPb4w== 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=ntuun6nqQSc3DWq3pXtzsq7IppN+X1VCW1qZzvhOlkE=; b=nZia4JiuTqq1lHLohFESdQQK/wiAlPTugicDH3gGJUUOfKvxuMovJ6rU3Mid4y82Xg4l/LpWWzeKEEcsm2sj/f+iXZ5X6HlPfqAX8+jecMi4akwIj16jYC0EULevYK8Jy40+xoFG3w6Y2asgTjMlqzYIDDqGW6Olmns8p57XKNDnm+9ezh/mt5JP02LwoPp5Rvm5fSZcP1KuM0o578D6gVc/K/r02x1CUStgg1bTQQFyqZxnnVy1SzMxlEXkP0uztMb2JZccGajDehUd4xkw0CPg+ljzx/7HtZMmQN5wlYp6HOa58GF8YGgErUjiQDowiViVL2EFWmlfPRRyEJtqmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ntuun6nqQSc3DWq3pXtzsq7IppN+X1VCW1qZzvhOlkE=; b=J7kyjraiUlozp4xZcuVjzXauqSEd1tYhDHlUahQOm4e8GuoA3MUo7g6GJ+J8aWxFVsuZk0GZjK5pn1QHIn/XyQHVO0e6T9WrGCK5Q9cnucFSSeC2UjMtKa+V04bKdoy5pTk8nCXxrwGO4tDjyHmhlwPsra4VzSNlbrEbp+TwlF8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akira.tsukamoto@aist.go.jp; Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com (20.178.140.147) by TYAPR01MB2269.jpnprd01.prod.outlook.com (52.133.177.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Tue, 7 Apr 2020 12:41:07 +0000 Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2]) by TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2%7]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 12:41:07 +0000 To: Hannes Tschofenig , "teep@ietf.org" References: From: Akira Tsukamoto Message-ID: <34e91e42-1d67-666a-402c-5931ebe9c69e@aist.go.jp> Date: Tue, 7 Apr 2020 21:41:07 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYAPR01CA0149.jpnprd01.prod.outlook.com (2603:1096:404:7e::17) To TYAPR01MB3406.jpnprd01.prod.outlook.com (2603:1096:404:cc::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.153] (217.178.18.13) by TYAPR01CA0149.jpnprd01.prod.outlook.com (2603:1096:404:7e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20 via Frontend Transport; Tue, 7 Apr 2020 12:41:07 +0000 X-Originating-IP: [217.178.18.13] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 10daf1c0-5fbe-4e5e-bc8a-08d7daf0f15b X-MS-TrafficTypeDiagnostic: TYAPR01MB2269: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 036614DD9C X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3406.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(346002)(366004)(39860400002)(136003)(53546011)(81156014)(316002)(81166006)(16576012)(36756003)(8936002)(8676002)(6486002)(110136005)(15650500001)(45080400002)(31686004)(66946007)(16526019)(186003)(956004)(26005)(2616005)(44832011)(5660300002)(86362001)(478600001)(66476007)(966005)(31696002)(2906002)(66556008)(52116002); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +bY58XcrsdOOm03diHVsUqBUHwBSwIFRJCT5x72kaN/Uy8PCTWOifmOqcc4ZTOVH3kLTVLwQclmgegAhmgg3v+WG3TDIrUj+Vt5sBT6rz9A+rD2+bn7g5fUiOx3pNOrule+46wguPlz7rudhUmwiwtRZ5Y6HtJrF6wXkbUJR6wCgKKzeJVkzHkYbalKiBRygjKELsPqzN/BFrqJ+5KtQZLz3hOPgoozsKyeYz6NkXtLBfNAr6BXE57aQ3X0/CRyokHAt5TXNRrfP9KV/cdMLsTM3rqkaOAdoFajHiq5QZtCn169JSK5qOa4hUAK7LEcwJs8qEmo1bqzfa29RmSOF00OMFpOMTLAcXmpIw+7maMv8aEeO96TMOsbX1utVLHgD2YQ+mDFm3H06SaC2VRCbSjI6NlTPp/GeperK5kK4DRMKHv5RMJYYN94U2Vq1bEQZhT9oTO3bg3g+VkugjwYdN2WzICHAChGonR0MtmdAqmVdZdtrYsRPBMyCIgTa66lPSCUGIXVlXmCUZx+etisdwQ== X-MS-Exchange-AntiSpam-MessageData: amHszZxb6h02O/2vESp19IaUUa//4Zkk0fHbLvtaj653FKobLUrh92ItPjHBQfxVecyqI9VPtnqE6gbFTRqICCDeH1TI8wfEkw7LHeG0Wq9O7/FCtvOvGXYjWoPOESEoqSGNEeM3XIsuli798GbQMw== X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 10daf1c0-5fbe-4e5e-bc8a-08d7daf0f15b X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 12:41:07.3761 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dXx91iR88NVEujCunV2+oI266cGSa8217AXO9xvy47e2yby55+YpuwFD8VOb2thuG5pGlGELNFpdIWOvmsiRM7iBcIz9XOT03ZP0KQ68Z+s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB2269 Archived-At: Subject: Re: [Teep] Formatting of the TEEP messages 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 Apr 2020 12:41:12 -0000 Hi Hannes, Yes, I know, my email was something similar to express the reason behind the array and uint are good choice what we discussed last night, for who was not attending the interim meeting... Because the TOKEN was in bstr, and I thought it was the discussion of explanation... Best, -Akira On 4/7/20 21:09, Hannes Tschofenig wrote: > Hi Akira, > > In your example you still use a map instead of an array and for the type you should use the unsigned int instead of int. That's at least what was proposed yesterday in the virtual interim meeting. > > Ciao > Hannes > > -----Original Message----- > From: Akira Tsukamoto > Sent: Tuesday, April 7, 2020 1:59 PM > To: Hannes Tschofenig ; teep@ietf.org > Subject: Re: [Teep] Formatting of the TEEP messages > > Hi, > > I just post current example in binary format with my hand binary encoding at the github. > > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues%2F21&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7Cb8eafc62e3ac4be7f38008d7daec8ad2%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637218581788571186&sdata=TjApvLZb0fp89L3BIZMjQJkMedcZgQFNelkhg4TLKj0%3D&reserved=0 > > Which the > > QueryRequest = { > TYPE : int, // TYPE is 1 for QueryRequest > TOKEN : bstr, // TOKEN using 1C76CB4EF2665BC68B9198E76EE21C71 > REQUEST : [+data_item], // using 2 here as an example > ... > > will be something similar to > > A4 // the map is A? and number of members, so if it has four members then it will be A4 > 58 04 45 95 05 54 // h'45950554' // TYPE label name in bstr will be embedded in map > 01 // 1 for TYPE value > 58 05 45 F4 B4 54 E4 // h'45F4B454E4' // TOKEN label name in bstr will be embedded in map > 58 10 1C 76 CB 4E F2 66 5B C6 8B 91 98 E7 6E E2 1C 71 // h'1C76CB4EF2665BC68B9198E76EE21C71' // value for TOKEN in bstr > 81 // the array is 8? and number of members, so if it has one member then it will be 81 > 02 > and ... > > I will probably come back to this topic next week. > > Best, > > -Akira > > On 4/7/20 18:58, Hannes Tschofenig wrote: >> Hi all, >> >> I am posting this topic to the list (although it is also discussed in a Github issue at https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues%2F21&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7Cb8eafc62e3ac4be7f38008d7daec8ad2%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637218581788571186&sdata=TjApvLZb0fp89L3BIZMjQJkMedcZgQFNelkhg4TLKj0%3D&reserved=0 ) because it blocks any implementation activity going forward. >> >> I want to make sure that I understand the tentative conclusion from our virtual interim meeting yesterday correctly. The suggestion is to use an array for the mandatory fields of the requests and to use a map for the rest. >> >> In the QueryRequest the first 3 elements of the array are type, token, requested (which are parameters defined in the TEEP protocol spec) followed by the last array entry, which is a map containing the optional parameters found in the QueryRequest message. >> >> Here is an example: >> [1, h'1C76CB4EF2665BC68B9198E76EE21C71', [2], {3 : 1, 5 : 1}] >> >> Is my understanding correct? >> >> Ciao >> >> Hannes >> >> 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 the information in any medium. Thank you. >> >> _______________________________________________ >> TEEP mailing list >> TEEP@ietf.org >> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7Cb8eafc62e3ac4be7f38008d7daec8ad2%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637218581788571186&sdata=g0W9kaf8cHoXqVZ7AHrnFYk6vnOZ8jWrZsYPlBZpj64%3D&reserved=0 >> > 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 the information in any medium. Thank you. > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7Cb8eafc62e3ac4be7f38008d7daec8ad2%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637218581788571186&sdata=g0W9kaf8cHoXqVZ7AHrnFYk6vnOZ8jWrZsYPlBZpj64%3D&reserved=0 > From nobody Tue Apr 7 06:58:56 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 E5A903A0A50 for ; Tue, 7 Apr 2020 06:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=2.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, PDS_BTC_ID=0.499, 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=aist.go.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JIlf479Re5X for ; Tue, 7 Apr 2020 06:58:54 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410077.outbound.protection.outlook.com [40.107.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D80C3A0A48 for ; Tue, 7 Apr 2020 06:58:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mlg1l4+nv3YMYW6zXcg9TebRIxN5pyG9EU2JbPgM0JmWoZmB/rX92oD6stKXnOElgZxDeD/JFbI8NhaA04hVVTf1dbB/lixdS8k3/AZVc12TyKgLYh3rUwvRsIPsLCZ9Z74O5A2rOMw9vj6BaiQMMNdHxKP5QYlz6YrH4nSOzjtJ7lHScrEtCK2KZaGqH8PoM+l2qu4tOZPQuij+HL9lz24J3nXFnh89iaEzx9imBx/zC8b3UR3Xox3bcd2veyoMtk2uuU7daFOiQFwKl5BAIrM55NT721mNJC2gtWWZsFJ33DQVWftXsOyVfcB7J1ePf1vJ4QMPSXBMdYHC7kE8ew== 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=0WRkgUFmiC6DLQ2K8zokLRav+dw4VQyC3fICOT0jWCE=; b=mwmaJx0nOZKaJxXJILqTtP39n29BGVpP0QxmwoN3Mjlq98z5t+RPmAUMPBOy2W5MYMUYBpRupXUjNzjJVf0vvTPHonMcVsfDfl/RS+e3B2gGlSrlca60AicQLB6VkJ+KMB5kIm6NtyVect/+hkyG90IRFisWGbOhjS5CC0BxdVWh0vByFnV+M6HlDrXmmfJU8HeGfXkuclX7v9qs5yokDx+JJvWI+TY/r/OTxHb5rJ97rREAWVLp71qIBD4Ciuop27RVDZsrrBjG7DnEmsW0nbF+ekahzFY6oc4gYLxvlXczcCDlkcFKAUblO43tOmJ82Hc9+vNMnpWJbEN6muahIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0WRkgUFmiC6DLQ2K8zokLRav+dw4VQyC3fICOT0jWCE=; b=k+hiUkHX6lqaKxBRmTsztzvVXkvfL8Jq3lMUCZvg5fJP6vy+B1hWY04AInWofrBmhNNln3dn7br0negPzcAgK0P6ITj9AGUxzJormrXJ8GhikCNO/3bm+Xj0+qa92yUwKzFYBRScU9rbz5MdcDrkaXoaQCzQpBLLn/6WCnfw6U8= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akira.tsukamoto@aist.go.jp; Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com (20.178.140.147) by TYAPR01MB4317.jpnprd01.prod.outlook.com (20.179.173.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Tue, 7 Apr 2020 13:58:51 +0000 Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2]) by TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2%7]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 13:58:51 +0000 From: Akira Tsukamoto To: Hannes Tschofenig , "teep@ietf.org" References: <34e91e42-1d67-666a-402c-5931ebe9c69e@aist.go.jp> Message-ID: <8b31d98f-8d89-0ab2-5c3d-6ce2f15fa41e@aist.go.jp> Date: Tue, 7 Apr 2020 22:58:51 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 In-Reply-To: <34e91e42-1d67-666a-402c-5931ebe9c69e@aist.go.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYCPR01CA0097.jpnprd01.prod.outlook.com (2603:1096:405:4::13) To TYAPR01MB3406.jpnprd01.prod.outlook.com (2603:1096:404:cc::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.153] (217.178.18.13) by TYCPR01CA0097.jpnprd01.prod.outlook.com (2603:1096:405:4::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.17 via Frontend Transport; Tue, 7 Apr 2020 13:58:51 +0000 X-Originating-IP: [217.178.18.13] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 979d15aa-40e9-4ff0-60e3-08d7dafbcd55 X-MS-TrafficTypeDiagnostic: TYAPR01MB4317: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 036614DD9C X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3406.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(346002)(376002)(366004)(6486002)(16526019)(66476007)(26005)(186003)(86362001)(316002)(8676002)(31696002)(110136005)(66946007)(66556008)(15650500001)(16576012)(36756003)(5660300002)(966005)(956004)(81156014)(81166006)(31686004)(2906002)(52116002)(478600001)(2616005)(53546011)(44832011)(45080400002)(8936002); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wlQeVZgKnFsh10p0lQACU22jZ1tLheB704gsXs5IfaPH5Uhy3ryECDxaSqzqt4gpOYWzff63tswMQYp8Xu3dzWDnI7auT/XiqGbCZOJ/IuckT2+kJuYd6Tbq+XZpAh0aOF388tqfYmmx41D8x51KY4rqcNNtuLmC0MX583pQ2dlGS20ZPWL02imiogakU8Oqs0flgGB/+P0IO3kFw8IVAcajyH/Lh+mJh/THZIDMxcSKSr7eKOuB7gwRHC43ftCSdqkg+3SMCKecqEbwpJYU/PCR8xGN4fLXK/fcE1qavGmcfB5R5fQB+64H3VKDYo9dNSJJSjj6p95mhO+ehLxCl143hYiOSLmlzNgeBDOwdKpiSOkEihiFSmrZIOoK5n1ezgR62PGF6FKOrC4VTcAKPS46g06NIjsmrmKP2U5wqHbZiTnGKotrTa4gl63bJJsGQwHFRinIRDz/ken057dTKKSilD22vEv1h/wlvYe/JLNJEHevInOJGO4aHbrGdnkfF5/3NmaYUNoGkL7/bv8yzw== X-MS-Exchange-AntiSpam-MessageData: w+lesCsmw99Sb+xDXlm/v0wYD/YrHggA5Lb+RI+1OGV4xVMg7fvFuUjx61APKk1+WUNxJUjWatyRYmVNA8NGapyckUMWt/M+APWHdjO8+ga2Dl/ZFTwxtuXVHh5rcTA4QpuCA8CkPT2TPSYp9hJl9g== X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 979d15aa-40e9-4ff0-60e3-08d7dafbcd55 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Apr 2020 13:58:51.5084 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QtrknaC6nq+I+GQ0a1Vl8yBBf1O8WQwQ9XQ4ockPofQd3AlG8IS0WTKwmWs54OZi3Gf7c75CZP2vRGjQ7oHaKbD6Z69n8ofs4LQzQf3Lkak= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4317 Archived-At: Subject: Re: [Teep] Formatting of the TEEP messages 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 Apr 2020 13:58:56 -0000 Hi all, This is trying to replicate the discussion at the interim meeting last night for moving on to use array and uint in teep as Hannes and Dave mentioning at previous email. I am not sure this is the right cddl format in array but let me try. I need help from Carsten here. :) TEEP_TYPE = uint .size 1 TEEP_TYPE_QueryRequest TEEP_TOKEN = uint .size 8 // 1C76CB4E TEEP_REQUEST /= uint .size 1 TEEP_attestation TEEP_REQUEST /= uint .size 1 TEEP_trusted_apps TEEP_REQUEST /= uint .size 1 TEEP_extensions TEEP_REQUEST /= uint .size 1 TEEP_suit_commands TEEP_QueryRequest = [ TEEP_TYPE, // 1 for TYPE value of QueryRequest TEEP_TOKEN, +TEEP_REQUEST, // 2 is TEEP_trusted_apps ... ] 84 // the array is 8? and number of members, so if it has four members then it will be A4 01 // 1 for TYPE value 1B 1C 76 CB 4E // TOKEN being '1C76CB4E' in 4bytes uint 02 // 2 is TEEP_trusted_apps ... Looks really nice in binary. I think I need to sleep since it was late last night but one last comment. I also post the same on the github. Best, -Akria On 4/7/20 21:41, Akira Tsukamoto wrote: > Hi Hannes, > > Yes, I know, > my email was something similar to express the reason behind the array and uint are good choice what we discussed last night, for who was not attending the interim meeting... > Because the TOKEN was in bstr, and I thought it was the discussion of explanation... > > Best, > -Akira > > On 4/7/20 21:09, Hannes Tschofenig wrote: >> Hi Akira, >> >> In your example you still use a map instead of an array and for the type you should use the unsigned int instead of int. That's at least what was proposed yesterday in the virtual interim meeting. >> >> Ciao >> Hannes >> >> -----Original Message----- >> From: Akira Tsukamoto >> Sent: Tuesday, April 7, 2020 1:59 PM >> To: Hannes Tschofenig ; teep@ietf.org >> Subject: Re: [Teep] Formatting of the TEEP messages >> >> Hi, >> >> I just post current example in binary format with my hand binary encoding at the github. >> >> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues%2F21&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C28d7f565a86a4ba0f17708d7daf0f822%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637218600800220558&sdata=fLM1DD6DOpGs6jRgGX4dkhKW7YB1C%2FjkxRTuqHeW5uo%3D&reserved=0 >> >> Which the >> >> QueryRequest = { >>        TYPE : int,  // TYPE is 1 for QueryRequest >>        TOKEN : bstr, // TOKEN using 1C76CB4EF2665BC68B9198E76EE21C71 >>        REQUEST : [+data_item], // using 2 here as an example >>       ... >> >> will be something similar to >> >> A4 // the map is A? and number of members, so if it has four members then it will be A4 >> 58 04 45 95 05 54 // h'45950554' // TYPE label name in bstr will be embedded in map >> 01 // 1 for TYPE value >> 58 05 45 F4 B4 54 E4 // h'45F4B454E4' // TOKEN label name in bstr will be embedded in map >> 58 10 1C 76 CB 4E F2 66 5B C6 8B 91 98 E7 6E E2 1C 71 // h'1C76CB4EF2665BC68B9198E76EE21C71' // value for TOKEN in bstr >> 81 //  the array is 8? and number of members, so if it has one member then it will be 81 >> 02 >> and ... >> >> I will probably come back to this topic next week. >> >> Best, >> >> -Akira >> >> On 4/7/20 18:58, Hannes Tschofenig wrote: >>> Hi all, >>> >>> I am posting this topic to the list (although it is also discussed in a Github issue at https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues%2F21&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C28d7f565a86a4ba0f17708d7daf0f822%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637218600800220558&sdata=fLM1DD6DOpGs6jRgGX4dkhKW7YB1C%2FjkxRTuqHeW5uo%3D&reserved=0 ) because it blocks any implementation activity going forward. >>> >>> I want to make sure that I understand the tentative conclusion from our virtual interim meeting yesterday correctly. The suggestion is to use an array for the mandatory fields of the requests and to use a map for the rest. >>> >>> In the QueryRequest the first 3 elements of the array are type, token, requested (which are parameters defined in the TEEP protocol spec) followed by the last array entry, which is a map containing the optional parameters found in the QueryRequest message. >>> >>> Here is an example: >>> [1, h'1C76CB4EF2665BC68B9198E76EE21C71', [2], {3 : 1, 5 : 1}] >>> >>> Is my understanding correct? >>> >>> Ciao >>> >>> Hannes >>> >>> 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 the information in any medium. Thank you. >>> >>> _______________________________________________ >>> TEEP mailing list >>> TEEP@ietf.org >>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C28d7f565a86a4ba0f17708d7daf0f822%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637218600800230554&sdata=NCVr7CmQNN9h1plxsv13OAKeNfr5b%2BavZHJHKMYOCrQ%3D&reserved=0 >>> >> 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 the information in any medium. Thank you. >> >> _______________________________________________ >> TEEP mailing list >> TEEP@ietf.org >> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C28d7f565a86a4ba0f17708d7daf0f822%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637218600800230554&sdata=NCVr7CmQNN9h1plxsv13OAKeNfr5b%2BavZHJHKMYOCrQ%3D&reserved=0 >> > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C28d7f565a86a4ba0f17708d7daf0f822%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637218600800230554&sdata=NCVr7CmQNN9h1plxsv13OAKeNfr5b%2BavZHJHKMYOCrQ%3D&reserved=0 From nobody Tue Apr 7 11:26: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 0F2943A0C72 for ; Tue, 7 Apr 2020 11:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=SdbbO/WU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gYI6JgBY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luGemturg22V for ; Tue, 7 Apr 2020 11:26:49 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517A33A0C64 for ; Tue, 7 Apr 2020 11:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3495; q=dns/txt; s=iport; t=1586283976; x=1587493576; h=from:to:subject:date:message-id:mime-version; bh=WlKlJFIIqxZwvAD2/rcJufdLEmoOjylPQ7s7vxHGZyA=; b=SdbbO/WUvCCYKR9BmtVv6gqZR8ozSjUAyRJ4r6XOxHEItTCCb3W1aZfc tcG1+d7EUSYZnrNqdoYe1e47gedvNcAvR8xxgfsOXaDaoags2fycSAU4M 7ICqqralS8kr2peK6ofzcpceu/ZkoTPQ8InJh3et/I1HBy9YwtwFDvJHk o=; IronPort-PHdr: =?us-ascii?q?9a23=3AY/20whC1bvRrswDLK0MaUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuKvXjajM7GstqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkDwAwxYxe/4gNJK1mgkGBJS9QBWx?= =?us-ascii?q?YIAQLKgqEEoNFA4ppTpVRhGGBLoEkA1QKAQEBDAEBIwoCBAEBhEQZgW4kNQg?= =?us-ascii?q?OAgMBAQsBAQUBAQECAQUEbYVWAQuGCREdAQE4EQEMPgIEMCcENYMEAYF+TQM?= =?us-ascii?q?uAQ6lYgKBOYhidYEygn8BAQWCRYMAGIINAwaBOIUjhxAaggCBESccgThng1M?= =?us-ascii?q?CAhqBdoJlMoIskQuGBZogCoI9lzAdnAePO5woAgQCBAUCDgEBBYFUAjWBV3A?= =?us-ascii?q?VZQGCPlAYDZUVilV0AoEnjRsBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.72,356,1580774400"; d="scan'208,217";a="475149980" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Apr 2020 18:26:15 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 037IQFbF006783 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Apr 2020 18:26:15 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 7 Apr 2020 13:26:15 -0500 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.1497.2; Tue, 7 Apr 2020 13:26:14 -0500 Received: from NAM04-CO1-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.1497.2 via Frontend Transport; Tue, 7 Apr 2020 14:26:14 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FP/7kw5XjIka7U2P3di+L3w09cPkjS74GAgEtPjqdTMIH4AsHntPuo068BBF8BI+RFV5MdCJz5v11NKjbM35cZZ5PwAw+i4jYUDyU9Q/byz170xJVPOI2vXHDrI8y/YvBGDOrg8N7/DwK0aAdfr+M0RlBKvqdp0YkI4HX7mU7JpSZfZyBlZjEPwAJWBhFobbzU4ENDBbNnzxOkU+io/uWWVXWCp2go9qAGyp0XRNNAbtgpjTCjdQ1HD6ElFGZBQ83bkIANPV4FNurh+CapNlJpayUT0JdLhKmf93HewTg/tpscBBCiO13Ft3UQShAvl3OqabDPRlPpUPysPEtNuXJA== 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=WlKlJFIIqxZwvAD2/rcJufdLEmoOjylPQ7s7vxHGZyA=; b=QT2LfT+eaw5e0/eKgiFO1aGfVlhGa5W8D03sjrRrJNxMd/S3XRzQj+pZWO4KMLMiPfirr/BJNLWtRVfieF9axZMqSNMTd7J6ku9YkGIpqv2XdiyD/QopVbzSD+jsVeCRWq+h0dZfPSAflHRgWH269Nlc6FTJ5FYBSvhdiX2YO/v3U+ByQK0nRdLE0BRTXhh3bux+J0Arrrh+29svwio4wbym1AFoldmV4ZZ5UqegCAJeUla4zhPRnQAOaxMPcnGaP0VjY6ke9SOXDfVHyqer5ZKS8cB8db6AX0Nq9huKldGpGMthInJS9ainjials6deIyKG9CHIXtUfc0b8I5b+fw== 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=WlKlJFIIqxZwvAD2/rcJufdLEmoOjylPQ7s7vxHGZyA=; b=gYI6JgBYTByCX9fJMJfkLusf0vptKBH70QC5oKfT9MQS6e9oNN+vBI0wUMKaoovSIUorlKcPXzc33B68CmdhwMv7BzF/AkQMe/plaiR+n6AHpGfyNSv215Nfq6rKKxM5NcgJCpPvwOVHI1qPA4iApB4BYl5bfNCBTqS0UieOCTo= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB4258.namprd11.prod.outlook.com (2603:10b6:a03:1c2::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Tue, 7 Apr 2020 18:26:13 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::852d:fab4:18c1:72d2]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::852d:fab4:18c1:72d2%7]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 18:26:13 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "teep@ietf.org" Thread-Topic: TEEP Apr 6 Virtual Interim recording posted Thread-Index: AQHWDQoEF/6eQLRHP0G3jbxcyKp7KA== Date: Tue, 7 Apr 2020 18:26:13 +0000 Message-ID: <98DB5DF3-3C41-4CE6-B761-528C55A99963@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.14.200307 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bf4782c9-0378-4605-3149-08d7db21271c x-ms-traffictypediagnostic: BY5PR11MB4258: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 036614DD9C x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(376002)(396003)(366004)(71200400001)(8936002)(26005)(8676002)(6506007)(558084003)(186003)(86362001)(2616005)(81156014)(5660300002)(966005)(6916009)(478600001)(76116006)(66556008)(2906002)(316002)(66476007)(6512007)(66946007)(6486002)(33656002)(36756003)(81166006)(64756008)(66446008); DIR:OUT; SFP:1101; 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: 03A36Z/RD/+epUColwBibsix3hfzbr3a8i32hSip6eBCGwQMS+WH+PttDgkXP1PNOIsGe3o3TDIDLL80cMhSv3mtekJE7HJlye0GQ77sVDiBIrR1Au9ieIA/shH9YJmvPcODIqNoMEDzDs2e/7RhtcJpURxr1GgYwtOrb4ajveSWisCk+ONIcSz6DVikY1lhSpJHN3u1zID9h4WPbBE7QovcONjXYLSA18Ni5nSDEcv3QCtVwfVM8CiV7b99R9Bxc61q4ocdTq9B9VDPFESkhPofHxgue0cw3auD2HGMyX/FltNkckad/B1/2CXsOyXaQ1VKnS//FcybdTyap/LHLrc4vY82sAHxbTr1EIPnI9ql9w32LVWDcVL4puQXLpRX9bMOvg+o/kPvzISvVGq71hD0p0HJJfzc+fN6UUW38vTyeyjOCX7F7GfVGA0TvCKnf8r/cvths8y1nDpLkoqCB9DW/gaBG64zR8tG3VTSWSeOxjwVn9j4T9eZsGkf8u/AWd2iUNjhz2xyCmXH/WCUjw== x-ms-exchange-antispam-messagedata: HJLItXH0QvJPvcOtC6+QXagFcIbzafgc9y4D2UJIFajgUn6Ntknmz0Vk7f6pVsSwtJzQ7VlYJiUqyKK4ailTcEL1ywi7n5/8wnv+i/EK5KCyPTR6cct38mc2A2ZIjSCKredc377UcF8cFVB/sxD+WA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_98DB5DF33C414CE6B761528C55A99963ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bf4782c9-0378-4605-3149-08d7db21271c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 18:26:13.0718 (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: Iwm0dbDsV37/LCOiFkhw+rg7uwTM2bWWzXCxSQVcLnqplHzN/WdfZgqQst0HlewxuMtjBGoUKAeRQhYlFA97tA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4258 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: [Teep] TEEP Apr 6 Virtual Interim recording posted 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 Apr 2020 18:26:55 -0000 --_000_98DB5DF33C414CE6B761528C55A99963ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gVEVFUCBwYXJ0aWNpcGFudHMsDQoNClRoZSB3ZWJleCByZWNvcmRpbmcgb2Ygb3VyIEFw ciA2LCAyMDIwIFZpcnR1YWwgSW50ZXJpbSBtZWV0aW5nIGhhcyBiZWVuIHBvc3RlZCwgeW91IGNh biBmaW5kIGl0IGluOg0KaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1HTWRDcjR6Z1B4 YyZmZWF0dXJlPXlvdXR1LmJlDQoNCkJlc3QsIE5hbmN5DQo= --_000_98DB5DF33C414CE6B761528C55A99963ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <47A11568015130418E9F1380D5557B74@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 emU6MTEuMHB0Ij5IZWxsbyBURUVQIHBhcnRpY2lwYW50cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSB3ZWJleCByZWNvcmRpbmcgb2Ygb3VyIEFwciA2LCAy MDIwIFZpcnR1YWwgSW50ZXJpbSBtZWV0aW5nIGhhcyBiZWVuIHBvc3RlZCwgeW91IGNhbiBmaW5k IGl0IGluOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhy ZWY9Imh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9R01kQ3I0emdQeGMmYW1wO2ZlYXR1 cmU9eW91dHUuYmUiPmh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9R01kQ3I0emdQeGMm YW1wO2ZlYXR1cmU9eW91dHUuYmU8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkJlc3QsIE5hbmN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_98DB5DF33C414CE6B761528C55A99963ciscocom_-- From nobody Thu Apr 9 04:07: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 DCE3F3A07F5; Thu, 9 Apr 2020 04:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLpd8PHi5Xg2; Thu, 9 Apr 2020 04:07:24 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F22B43A07EC; Thu, 9 Apr 2020 04:07:23 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48yddj6pVzzyqc; Thu, 9 Apr 2020 13:07:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: Date: Thu, 9 Apr 2020 13:07:21 +0200 Cc: Akira Tsukamoto , Jim Schaad , "suit@ietf.org" , teep X-Mao-Original-Outgoing-Id: 608123241.423031-689d619fb9e8d21ddce7f60dbe1bb923 Content-Transfer-Encoding: quoted-printable Message-Id: <799C44A6-515B-40A7-88C5-ACED609BE6A0@tzi.org> References: <4e6db9fe-c0c7-7ca0-95c7-843ebc164a4c@aist.go.jp> <05ef01d60e21$4bdd1ce0$e39756a0$@augustcellars.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Teep] [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged 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 Apr 2020 11:07:27 -0000 On 2020-04-09, at 10:40, Hannes Tschofenig = wrote: >=20 > Hi Akira, Hi Jim, >=20 > based on our TEEP conference call we reduced the size of options down = to COSE_Sign1. Hence, the rest is gone. > That should make things easier and COSE_Sign1 is defined in the COSE = spec itself. >=20 > I posted a PR with the new CDDL at = https://github.com/ietf-teep/teep-protocol/pull/26 Thanks, Hannes. Based on this, Henk and I have done some additional = cleanup. We plan to have a first version of a PR by 1300Z. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 9 05:08: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 BC21C3A09C7; Thu, 9 Apr 2020 05:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=IFpN1TB0; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=IFpN1TB0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUZB6PT-pR9K; Thu, 9 Apr 2020 05:08:05 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80070.outbound.protection.outlook.com [40.107.8.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95ABC3A09C6; Thu, 9 Apr 2020 05:07:51 -0700 (PDT) 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=JZS4FqCexbmhbwBlCc+aqdgKlALP/jJ4v/M5SPMgH9s=; b=IFpN1TB0BCKMs4bMDZ1IoEae71c8eGggraOcugS2KpSFUCaioqv3rZ4eaDY3jFFvwlYzbhJ9QEEHknyTVAAkYAbfsM7k+v22TxEyolnUv4SvuzNQPqMvs53E7LRVDhQgpW1Un+gyBWA38mxqaEKGis8NAseJtknydZricPAQh/g= Received: from AM6P191CA0072.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:7f::49) by AM6PR08MB3864.eurprd08.prod.outlook.com (2603:10a6:20b:8e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.16; Thu, 9 Apr 2020 12:07:48 +0000 Received: from AM5EUR03FT030.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:7f:cafe::2c) by AM6P191CA0072.outlook.office365.com (2603:10a6:209:7f::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.17 via Frontend Transport; Thu, 9 Apr 2020 12:07:48 +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 AM5EUR03FT030.mail.protection.outlook.com (10.152.16.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Thu, 9 Apr 2020 12:07:48 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Thu, 09 Apr 2020 12:07:47 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 4603364f2f17df2b X-CR-MTA-TID: 64aa7808 Received: from 7db3b03909aa.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 961F9A51-5401-42F5-A86F-B4579FCDE97A.1; Thu, 09 Apr 2020 12:07:42 +0000 Received: from EUR02-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 7db3b03909aa.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 09 Apr 2020 12:07:42 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=au6FD7LPIPdTLbd3MtK/1pDK0XUXm8tbPx76ayz6pet1OsubSRsHL4d5NlC5E3ZXrRkYAlv1KRoup5XIwLN24YagFY83YwwjCKHGzjfkkh+JEem/ho9vKvVvNBEKQVCFDGQi8fhOckRzUBN482wt2I2Xvn+jXaTpnnAkvAG03YprbK3VH7ybgyAA0DHMit9wnX3zDXB7fI8VfKMNJy9L00fe2NlS623dNkbFNC57uWTAUrtTAnnzIAaJmU9jh33NCkSM4+94dOqdYY1P9petWlEIN3cH3kX6BoKwT8cpM05CQtVttLBCy594eWjOWNUhkxZqtfUCnjw0NQEYbVzm/g== 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=JZS4FqCexbmhbwBlCc+aqdgKlALP/jJ4v/M5SPMgH9s=; b=BMIji8WfAjTbBJlS9q4OxcwyA6U5jzjIam5NLquOU+LEaTowglPBHx3cKdZ8kABhixFNYicrT7Hnj/YZ3XVNjb6EClk2uytFzsKDib1cCavIgBfZkiK/aK/bTa7XGR7RmzlvLH7hW9T7twwbT0t+WOD97QipC9vcvbfysmFLDx+XcwkEH9HWzQcFDf4TAYa9SSOfEINewbA8GtmWuDoo4FHc3ksK/NtXAe1bRFcxENiGrRDO6jt5xfmSpag9mccw9DERkZvmAFcQmL8eouS93Y00MvORn/iaCweaKxTOf7YAMvOP9TP++V2GN7kGfBTp5ZicchOkKyiWHwwzeUOu7g== 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=JZS4FqCexbmhbwBlCc+aqdgKlALP/jJ4v/M5SPMgH9s=; b=IFpN1TB0BCKMs4bMDZ1IoEae71c8eGggraOcugS2KpSFUCaioqv3rZ4eaDY3jFFvwlYzbhJ9QEEHknyTVAAkYAbfsM7k+v22TxEyolnUv4SvuzNQPqMvs53E7LRVDhQgpW1Un+gyBWA38mxqaEKGis8NAseJtknydZricPAQh/g= Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM6PR08MB5029.eurprd08.prod.outlook.com (2603:10a6:20b:e7::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 9 Apr 2020 12:07:40 +0000 Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::7960:8949:a754:4288]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::7960:8949:a754:4288%7]) with mapi id 15.20.2878.022; Thu, 9 Apr 2020 12:07:40 +0000 From: Brendan Moran To: Carsten Bormann CC: Hannes Tschofenig , Akira Tsukamoto , Jim Schaad , teep , "suit@ietf.org" Thread-Topic: [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged Thread-Index: AQHWDhJ/nRre/QRyPk2cdRSJzMz+NKhwJm6AgAA0pwCAAB2vAIAAKSuAgAAQ2gA= Date: Thu, 9 Apr 2020 12:07:40 +0000 Message-ID: <70520B88-66B4-48DD-A3A8-9129B3C14D31@arm.com> References: <4e6db9fe-c0c7-7ca0-95c7-843ebc164a4c@aist.go.jp> <05ef01d60e21$4bdd1ce0$e39756a0$@augustcellars.com> <799C44A6-515B-40A7-88C5-ACED609BE6A0@tzi.org> In-Reply-To: <799C44A6-515B-40A7-88C5-ACED609BE6A0@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; x-originating-ip: [81.101.7.188] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 9b9dc279-c491-4a51-de96-08d7dc7e9ea3 x-ms-traffictypediagnostic: AM6PR08MB5029:|AM6PR08MB5029:|AM6PR08MB3864: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000; x-forefront-prvs: 0368E78B5B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(376002)(396003)(346002)(39860400002)(66556008)(6486002)(6916009)(4326008)(81166007)(2616005)(66476007)(66946007)(33656002)(53546011)(6512007)(76116006)(186003)(5660300002)(66446008)(64756008)(91956017)(26005)(6506007)(86362001)(966005)(81156014)(36756003)(8676002)(54906003)(478600001)(2906002)(71200400001)(316002)(8936002); DIR:OUT; SFP:1101; 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: uxKPt1XyY/ruJPEj573ChkGRZLS6oypWk2Vhwq2sO0jr38rKOwCZbZjECxw5K/9eUZLHQ+weDnYw3P4+fsZpmOaOTrQtdLydZxs80+O3VWt9SHwJEQwXI3EWoLdYhm6i71+TVVLhd8cHVaueqvitBC8kNY/o3UYe9yASzpRvTN5pR072+4lwmoMQaldmXnKl04fnfhTIxmPlE9prHB6T4yVCAy3Hw8aOo39Es/Yq72cT8F7F2qwr/Y8XrmgT7TbmAjDZtCoPb+oNl5vnV02iMe3YOKyJJUlS3DrrXxTGB3hMUE/hQVNteE3PF9SdxOblKp8zKVrrQavRQa4FEoGDvAisbJshBH+JcKrnjdAG30td4fiAw6eLLKRf+apQfs76wu6VcAt+65ZKCxEAp+yOqXLgcZx50YPAxOBgmhGPAyN8WU6W5N1A4fMFCJYfhc7Fp6re4qsjUAke9co+BITrLDJNvBxGpCwT66N2IaRttAY4ly+J2j1lz8Dhw/FYPJYj7NelWeajhJqCaV8xCmqWVQ== x-ms-exchange-antispam-messagedata: Yl5ayVwvQibtNjaqnQgKhHoQqSznHTRS5fTi0vE+OlTNTfvOoYLykZFpxXJg3fRtiA0Q+F81ZmQxlfO5j9C4qE/9fMXMPO3XyRY2z/MEifGeeL5CwK1PoHYyXvMAZjDdwHtNfvygPAldUqudgi9KuA== Content-Type: text/plain; charset="utf-8" Content-ID: <23E7DC73D740CE4794ABB267CBE8FEDF@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5029 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT030.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(39860400002)(346002)(136003)(46966005)(47076004)(26826003)(5660300002)(70586007)(6862004)(6506007)(70206006)(966005)(4326008)(6512007)(450100002)(81166007)(82740400003)(316002)(2906002)(81156014)(356004)(54906003)(6486002)(478600001)(53546011)(8676002)(36906005)(36756003)(33656002)(86362001)(336012)(8936002)(186003)(26005)(2616005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: b8522114-3b19-4779-8737-08d7dc7e9a4b X-Forefront-PRVS: 0368E78B5B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: R+dXBWT+agGtD04D6ctnQT52csUj9h2GHLxUc9dmiVvSioGWaOf+tBcDeYQj0+hSpu3WG/u1h5EYzLFvFn4LYkqt1dy7F8c62vb8z3qg0u0A5d2AusyMmXxOHeAJ4jdFU82gp1oRgabeG6wvBNmg3zwZ3EAz9pxN2BCJsfTVEV4vqTkIdgn7G4qdQ1AOVN14o4IMZUrzJjEDy1/k4ifIQ66sS28NWV8jfaeSkzMSsA1LPbiewX4Zf6uQUS8UByupViA0HF1xbPrOQWI3ZSEtpSrqo+CBHwmh64RiK7y1v8IwYQU211y87kITXEdQH+suK+WKc6TR7w00YjIj2ND8Y5I+2/DrDjPgOIQMuXxCFP+7HrIWmUSI+gNJJxVAnKEk3FIL0Nv3kl2JcgnxiJWvwYe+MhBwnjKrYWkhZn0vsNAK4lZJuXXARBG/3CdOfNd8hWhBqSMbVOFUIhiBllFWAjdVYaQJpPM4HC1A9SDELDFr7W2q/ZYm+CRMOoxqR7+yphWSuS2ZSFtPbnIrvdFnZQKEdml3BfqQry7Rl078+pHhh5xetA62hbm9lYTOBQQGvRN+bNXBy3QPvre+9CTFAw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2020 12:07:48.0943 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9b9dc279-c491-4a51-de96-08d7dc7e9ea3 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: AM6PR08MB3864 Archived-At: Subject: Re: [Teep] [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged 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 Apr 2020 12:08:08 -0000 RnJvbSBhIFNVSVQgcGVyc3BlY3RpdmUsIEnigJltIHN0aWxsIGluY2xpbmVkIHRvIG1ha2Ugc3Vy ZSB0aGF0IHRoaXMgaXMgdGFnZ2VkIGFzIHRoYXQgYWxsb3dzIGZvciB1c2UtY2FzZXMgdGhhdCB3 ZSBtYXkgbm90IGhhdmUgY29uc2lkZXJlZC4NCg0KQmVzdCBSZWdhcmRzLA0KQnJlbmRhbg0KDQo+ IE9uIDkgQXByIDIwMjAsIGF0IDEyOjA3LCBDYXJzdGVuIEJvcm1hbm4gPGNhYm9AdHppLm9yZz4g d3JvdGU6DQo+DQo+IE9uIDIwMjAtMDQtMDksIGF0IDEwOjQwLCBIYW5uZXMgVHNjaG9mZW5pZyA8 SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4gd3JvdGU6DQo+Pg0KPj4gSGkgQWtpcmEsIEhpIEpp bSwNCj4+DQo+PiBiYXNlZCBvbiBvdXIgVEVFUCBjb25mZXJlbmNlIGNhbGwgd2UgcmVkdWNlZCB0 aGUgc2l6ZSBvZiBvcHRpb25zIGRvd24gdG8gQ09TRV9TaWduMS4gSGVuY2UsIHRoZSByZXN0IGlz IGdvbmUuDQo+PiBUaGF0IHNob3VsZCBtYWtlIHRoaW5ncyBlYXNpZXIgYW5kIENPU0VfU2lnbjEg aXMgZGVmaW5lZCBpbiB0aGUgQ09TRSBzcGVjIGl0c2VsZi4NCj4+DQo+PiBJIHBvc3RlZCBhIFBS IHdpdGggdGhlIG5ldyBDRERMIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9pZXRmLXRlZXAvdGVlcC1w cm90b2NvbC9wdWxsLzI2DQo+DQo+IFRoYW5rcywgSGFubmVzLiAgQmFzZWQgb24gdGhpcywgSGVu ayBhbmQgSSBoYXZlIGRvbmUgc29tZSBhZGRpdGlvbmFsIGNsZWFudXAuDQo+IFdlIHBsYW4gdG8g aGF2ZSBhIGZpcnN0IHZlcnNpb24gb2YgYSBQUiBieSAxMzAwWi4NCj4NCj4gR3LDvMOfZSwgQ2Fy c3Rlbg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBTdWl0IG1haWxpbmcgbGlzdA0KPiBTdWl0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VpdA0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29u dGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwg YW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90 IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFu eSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVt LiBUaGFuayB5b3UuDQo= From nobody Thu Apr 9 05:12:19 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 82F263A09D4; Thu, 9 Apr 2020 05:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMhGLFjegNt5; Thu, 9 Apr 2020 05:12:13 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09663A09D3; Thu, 9 Apr 2020 05:12:12 -0700 (PDT) Received: from [172.16.42.112] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48yg4S3Btbz10CP; Thu, 9 Apr 2020 14:12:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <70520B88-66B4-48DD-A3A8-9129B3C14D31@arm.com> Date: Thu, 9 Apr 2020 14:12:07 +0200 Cc: Akira Tsukamoto , Jim Schaad , Hannes Tschofenig , "suit@ietf.org" , teep X-Mao-Original-Outgoing-Id: 608127127.617555-b8f32b41570defc8a66889535d818547 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4e6db9fe-c0c7-7ca0-95c7-843ebc164a4c@aist.go.jp> <05ef01d60e21$4bdd1ce0$e39756a0$@augustcellars.com> <799C44A6-515B-40A7-88C5-ACED609BE6A0@tzi.org> <70520B88-66B4-48DD-A3A8-9129B3C14D31@arm.com> To: Brendan Moran X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Teep] [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged 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 Apr 2020 12:12:17 -0000 On 2020-04-09, at 14:07, Brendan Moran wrote: >=20 > =46rom a SUIT perspective, I=E2=80=99m still inclined to make sure = that this is tagged as that allows for use-cases that we may not have = considered. Makes sense. Let=E2=80=99s fix the definition of `SUIT-envelope` in the = below. Henk and I created a cleaned up version of the CBOR encoding and = accompanying CDDL. We should check whether this encoding helps us and then integrate it = into the document. https://github.com/ietf-teep/teep-protocol/pull/27 Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 9 06:29:36 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 AACDA3A0B13; Thu, 9 Apr 2020 06:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaX4O47HpZPS; Thu, 9 Apr 2020 06:29:26 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 6997B3A0B10; Thu, 9 Apr 2020 06:29:26 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 039DHerl018074; Thu, 9 Apr 2020 14:29:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=deYz/SgVI6v2Kc5hOjFx1rRr0rVuYDOjKSWZUx15Fh4=; b=In34CGSXsaU1+bavk2PCsfZN3r2nt37/Hasi/qhsBhT/Ur0qbsza5X59fdm6qlCi3VBt C0DJmts1/WGQ6KGcVvqvKnjtQen70+HqSMAq5LL0h0nGiW/NUYRSx/2AToXx8J6+E8fv hee0i8GlWtatSymjDU2X7x1Y0+Sw3dYjhrw9MR2TN9o5Xo5qUXrSo+nrscDUZ3hI7rD6 CbctenfAgaIHkF9sj2NKtg/1YGToaBrfEF4X2ZVD4nT2J4XBI72nUo1XtiOY8X166DjM 09tTrdu0Kl0QI767QE015Oz7VGyVhkd/UpwHCvdNrYjcYgHgNSB5txrnlOl+yhOB9Bo7 Xw== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 309x0cac64-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Apr 2020 14:29:04 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 039DHm05021053; Thu, 9 Apr 2020 06:29:04 -0700 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint5.akamai.com with ESMTP id 3091j9fayr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 09 Apr 2020 06:29:03 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 9 Apr 2020 08:29:02 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Thu, 9 Apr 2020 08:29:02 -0500 From: "Salz, Rich" To: Carsten Bormann , Brendan Moran CC: Akira Tsukamoto , Jim Schaad , Hannes Tschofenig , "suit@ietf.org" , teep Thread-Topic: [Teep] [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged Thread-Index: AQHWDmeRQqj6Rxt5sUGHEvtKTMtPKahxBy+A///SboA= Date: Thu, 9 Apr 2020 13:29:01 +0000 Message-ID: References: <4e6db9fe-c0c7-7ca0-95c7-843ebc164a4c@aist.go.jp> <05ef01d60e21$4bdd1ce0$e39756a0$@augustcellars.com> <799C44A6-515B-40A7-88C5-ACED609BE6A0@tzi.org> <70520B88-66B4-48DD-A3A8-9129B3C14D31@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20040502 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.9] Content-Type: text/plain; charset="utf-8" Content-ID: <170A2ECBBBEE144D95D4C0F850DBBDBA@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-09_04:2020-04-07, 2020-04-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=530 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004090103 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-09_04:2020-04-07, 2020-04-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 bulkscore=0 clxscore=1011 impostorscore=0 suspectscore=0 phishscore=0 mlxscore=0 adultscore=0 lowpriorityscore=0 mlxlogscore=529 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004090103 Archived-At: Subject: Re: [Teep] [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged 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 Apr 2020 13:29:28 -0000 PiAgICBNYWtlcyBzZW5zZS4gIExldOKAmXMgZml4IHRoZSBkZWZpbml0aW9uIG9mIGBTVUlULWVu dmVsb3BlYCBpbiB0aGUgYmVsb3cuDQoNCldlJ3JlIG1pc3NpbmcgdGhlIGNoYW5jZSB0byB1c2Ug Im92ZXJjb2F0IiBvciAiamFja2V0IiAuLi4gOikNCg0K From nobody Thu Apr 9 06:38:53 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 A65793A0B52; Thu, 9 Apr 2020 06:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llC3AL6IU-95; Thu, 9 Apr 2020 06:38:41 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 B37983A0BB1; Thu, 9 Apr 2020 06:38:20 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id j2so193985wrs.9; Thu, 09 Apr 2020 06:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1+GgmWuhKILOYK/2STC9m1k1puNK+pPhLZ1ibFSZAtE=; b=fk2vUsmDFAmCmvze5xKHs9lbGxO8n6BK66oa1sU0MhGrGcyYvACaicbiDC5FhzAZhH UeVQceoO1rAvHq1mhA6g2ktyO2vbMrNeI1LKH1akOWm4cwbkAZsbqGj9xFD4M2pYhniP 7M1+a8dlwZuGbxo25UhGbcyy0xy1CFF9P/BHk3XHNcRpWgK04bCLV4jREl2o7FlENf4/ OpKcdlCp1+gfjUWly/jRp3ySbLm617JEAHRGvDBdAre1DXbyT3ssHJi2/rk/qVwVSpqu HsJ0TbyE4AagNWy6eNV3ZIC4XzBGrPi1W/rtqWaSiUtW+PY71iokJubVFVki4ulNiqdv vkBQ== 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:content-transfer-encoding; bh=1+GgmWuhKILOYK/2STC9m1k1puNK+pPhLZ1ibFSZAtE=; b=bYMNaJ5bORTojggfq4atuPqVpTM+kbPZF05qDk0k1kg9kKGE84nYSCxT9hiitRLoiK uugXvKvC/K2hiuvIDYB8xJlGR1K9J7AITif+e6Mh2khblimXi886stJRZUJABkz499Qa MGhfZJJEHk/8l0MomJQlTEoU45h4n+r4itZm0Oju3F24rTEkBQVJLYt4y6jtwjYgDfbY PUUdvZ6t3CqueR+ewnhj1O4KTzRt43sDlV1hVRELcL4jZopI1aThVigu/Jsfcom/sgPZ Ew588eSNhIy4Hfi/Eyb2AKmXyEJIHh/+fReMcHPi0oqbSMVEcBwvg+5k4G0OL39UWROi Y8WA== X-Gm-Message-State: AGi0Pua7ceKxm9uaMbUykH0C+9KMPtp8MoG+zCn9PYP7w4/UnFziguqC dClinqY1tEHpveLH829mQiH4IsqvDftTRHEMgXs= X-Google-Smtp-Source: APiQypJpWToELRRkVkJh1jbud7842qLB/ieQJgyvmyDd0trcUhKyNhWvsC5pSqEzVS30xQgzNuw0Q/28ehx4hpbRlpg= X-Received: by 2002:adf:aacc:: with SMTP id i12mr15257048wrc.116.1586439498283; Thu, 09 Apr 2020 06:38:18 -0700 (PDT) MIME-Version: 1.0 References: <4e6db9fe-c0c7-7ca0-95c7-843ebc164a4c@aist.go.jp> <05ef01d60e21$4bdd1ce0$e39756a0$@augustcellars.com> <799C44A6-515B-40A7-88C5-ACED609BE6A0@tzi.org> <70520B88-66B4-48DD-A3A8-9129B3C14D31@arm.com> In-Reply-To: From: Akira Tsukamoto Date: Thu, 9 Apr 2020 22:38:07 +0900 Message-ID: To: Carsten Bormann Cc: Brendan Moran , Akira Tsukamoto , Jim Schaad , Hannes Tschofenig , "suit@ietf.org" , teep Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Teep] [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged 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 Apr 2020 13:38:48 -0000 Hi Carsten and Hannes, https://github.com/ietf-teep/teep-protocol/pull/27 The new pull request reflects all the discussion points of converting from map and using minimum major type size for the array member. When I was reading the cddl draft, I was not quite sure how to describe the array with the label name. In your pull request, query-request =3D [ type: TEEP-TYPE-query-request, token: uint, The above cddl description has label name type and token with semicolon. We were trying to avoid having label name inside the array. I thought I have to use =3D> for this purpose. Other discussion we had with the teep is to use the same nonce as the EAT defines. nonce =3D> bytes, to be nonce =3D> bstr .size (8..64) And the size of token we never really agreed about it. How bout token: uint .size 4 The 32bit unsign integer seems to be reasonable for the usage in teep. Best, -Akira On Thu, Apr 9, 2020 at 9:12 PM Carsten Bormann wrote: > > On 2020-04-09, at 14:07, Brendan Moran wrote: > > > > From a SUIT perspective, I=E2=80=99m still inclined to make sure that t= his is tagged as that allows for use-cases that we may not have considered. > > Makes sense. Let=E2=80=99s fix the definition of `SUIT-envelope` in the = below. > > Henk and I created a cleaned up version of the CBOR encoding and accompan= ying CDDL. > We should check whether this encoding helps us and then integrate it into= the document. > > https://github.com/ietf-teep/teep-protocol/pull/27 > > Gr=C3=BC=C3=9Fe, Carsten > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://www.ietf.org/mailman/listinfo/teep From nobody Thu Apr 9 07:13:56 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 B30C43A00E1; Thu, 9 Apr 2020 07:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp7r2GYC4rEJ; Thu, 9 Apr 2020 07:13:49 -0700 (PDT) Received: from mail-edgeKA27.fraunhofer.de (mail-edgeka27.fraunhofer.de [153.96.1.27]) (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 073D13A03F1; Thu, 9 Apr 2020 07:13:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FmAAAjLI9e/xoBYJlmGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFpAwEBAQELAYIobANVLyoKhBKPAoFkCCWUJ4U?= =?us-ascii?q?ngT8yCgoBAQEBAQEBAQEGAQEYCwoCBAEBAoMvgRMCghAkNgcOAhABAQYBAQE?= =?us-ascii?q?BAQUEAgJphVYMgnZdfgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEgINNh43EgE?= =?us-ascii?q?BHgEBAQMBASEPAQU2CxAJAhgCAiYCAicgEAYBCQMBBQIBAYMiAYJ7BQuUOpt?= =?us-ascii?q?5gTKFToNugToGgQ4qAYUihxAPgUw/gREnDAOCWj6CZwEBAgGEdIJeBI1rKoI?= =?us-ascii?q?7O4YrmggHgUp4fQSGd48+I49GBYxLLY8ZiSuTDAIEAgkCFYFZCCuBV00kT4J?= =?us-ascii?q?pUBgNkSsDFxWDO4UUhUNyAoEnjQ8BgQ8BAQ?= X-IPAS-Result: =?us-ascii?q?A2FmAAAjLI9e/xoBYJlmGgEBAQEBAQEBAQMBAQEBEQEBA?= =?us-ascii?q?QICAQEBAYFpAwEBAQELAYIobANVLyoKhBKPAoFkCCWUJ4UngT8yCgoBAQEBA?= =?us-ascii?q?QEBAQEGAQEYCwoCBAEBAoMvgRMCghAkNgcOAhABAQYBAQEBAQUEAgJphVYMg?= =?us-ascii?q?nZdfgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBEgINNh43EgEBHgEBAQMBASEPA?= =?us-ascii?q?QU2CxAJAhgCAiYCAicgEAYBCQMBBQIBAYMiAYJ7BQuUOpt5gTKFToNugToGg?= =?us-ascii?q?Q4qAYUihxAPgUw/gREnDAOCWj6CZwEBAgGEdIJeBI1rKoI7O4YrmggHgUp4f?= =?us-ascii?q?QSGd48+I49GBYxLLY8ZiSuTDAIEAgkCFYFZCCuBV00kT4JpUBgNkSsDFxWDO?= =?us-ascii?q?4UUhUNyAoEnjQ8BgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.72,363,1580770800"; d="scan'208";a="21214743" Received: from mail-mtaka26.fraunhofer.de ([153.96.1.26]) by mail-edgeKA27.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2020 16:13:42 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AADMLI9e/1lIDI1mGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFpAwEBAQELAYIobANNBzAqCoQSjwKBZAgllCe?= =?us-ascii?q?FJ4F7CgEDAQEBAQEGAQEYCwoCBAEBgzGBEwKCDyQ2Bw4CEAEBBQEBAQIBBQR?= =?us-ascii?q?thVYMhXEBAQEDAQEhDwEFNgsQCQIYAgImAgInIBAGAQkDAQUCAQGDIgGDAAu?= =?us-ascii?q?UQJt5gTKFToNygToGgQ4qAYUihxAPgUw/gREnDAOCWj6CZwEBAgGEdIJeBI1?= =?us-ascii?q?rKoI7O4YrmggHgUp4fQSGd48+I49GBYxLLY8ZiSuTDAIEAgkCFYFZCCqBV00?= =?us-ascii?q?kT4JpUBgNkSsDFxWDO4UUhUNBMQKBJ40PAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.72,363,1580770800"; d="scan'208";a="79986779" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaKA26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Apr 2020 16:13:40 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 039EDcah015869 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Thu, 9 Apr 2020 16:13:38 +0200 Received: from [192.168.16.50] (79.234.123.239) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 9 Apr 2020 16:13:32 +0200 To: Akira Tsukamoto , Carsten Bormann CC: "suit@ietf.org" , Brendan Moran , Akira Tsukamoto , Jim Schaad , teep , Hannes Tschofenig References: <4e6db9fe-c0c7-7ca0-95c7-843ebc164a4c@aist.go.jp> <05ef01d60e21$4bdd1ce0$e39756a0$@augustcellars.com> <799C44A6-515B-40A7-88C5-ACED609BE6A0@tzi.org> <70520B88-66B4-48DD-A3A8-9129B3C14D31@arm.com> From: Henk Birkholz Message-ID: <3e608b68-7232-4ca0-f94c-22dc3adc8724@sit.fraunhofer.de> Date: Thu, 9 Apr 2020 16:13:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.234.123.239] Archived-At: Subject: Re: [Teep] [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged 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 Apr 2020 14:13:54 -0000 Hello Akira, in an array context, the name (aka label) is annotation only. It is not transferred over "the wire", so we did not bother to define a corresponding type. In other words, you could simply omit "type: " and "token: " and nothing would change. It is annotation for humans, basically. See https://tools.ietf.org/html/rfc8610#section-2.1 Viele Grüße, Henk On 09.04.20 15:38, Akira Tsukamoto wrote: > Hi Carsten and Hannes, > > https://github.com/ietf-teep/teep-protocol/pull/27 > > The new pull request reflects all the discussion points of converting > from map and using minimum major type size for the array member. > > When I was reading the cddl draft, I was not quite sure how to > describe the array with the label name. > In your pull request, > > query-request = [ > type: TEEP-TYPE-query-request, > token: uint, > > The above cddl description has label name type and token with semicolon. > We were trying to avoid having label name inside the array. > I thought I have to use => for this purpose. > > Other discussion we had with the teep is to use the same nonce as the > EAT defines. > > nonce => bytes, > to be > nonce => bstr .size (8..64) > > And the size of token we never really agreed about it. > How bout > token: uint .size 4 > > The 32bit unsign integer seems to be reasonable for the usage in teep. > > Best, > -Akira > > On Thu, Apr 9, 2020 at 9:12 PM Carsten Bormann wrote: >> >> On 2020-04-09, at 14:07, Brendan Moran wrote: >>> >>> From a SUIT perspective, I’m still inclined to make sure that this is tagged as that allows for use-cases that we may not have considered. >> >> Makes sense. Let’s fix the definition of `SUIT-envelope` in the below. >> >> Henk and I created a cleaned up version of the CBOR encoding and accompanying CDDL. >> We should check whether this encoding helps us and then integrate it into the document. >> >> https://github.com/ietf-teep/teep-protocol/pull/27 >> >> Grüße, Carsten >> >> _______________________________________________ >> TEEP mailing list >> TEEP@ietf.org >> https://www.ietf.org/mailman/listinfo/teep > > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit > From nobody Thu Apr 9 16:43:49 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 6F5C13A13F9; Thu, 9 Apr 2020 16:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=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=aist.go.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCHFDL__9gvY; Thu, 9 Apr 2020 16:43:41 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410040.outbound.protection.outlook.com [40.107.141.40]) (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 6D6C53A13F7; Thu, 9 Apr 2020 16:43:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A9uFaCYQ14JI1su4RIaEJbGG9DQiNZni0XE4+Q3EGJRyE1rCfkgITe3Fznj4O7mu430KHu1GPfcodTzVWmbpSdTKGfuA6IkBuGDiLDc0fQmafTsRMwpq1UKG5iigIjlJYikdqUEXti2Q9nXDhlKSIPNKWgOu9+3+ik3dFRSIcpChDD+JVF+L0AbyjLVyVOTJfvEY7umfvUr7qlLgI48AIU8yndMVGAehktExptqDqU9O+HCDEWkOnvZaRDPXAMcwK1UcrsWqPPPK/b87yvQf+d+DMz2+z0o/HmvnEPbGKA0wBP9sQ5nWSpLAct84kvis87Pjd3Ztzsg4SIg6yxSmqQ== 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=aSOp2KFz3/rhZS0svz698xFK1jS4tyTJNw2Sw3mm14g=; b=k8/jV5m0U1mfnghe59n6godATWfhcBof218jg2YdE6TEevNiItt/8mVaTJnoXNTadDkr0kjmjhF209xZkPMGW4nKuqpSGxjBp6ll3DnHP+AnjByODpk6h5ItzASj+KI251DXQCT5FT9yaTayofCL5sFvgzzMrN4lopAyIAQJ8rXUnQDHifUwdWBUQ/fKvEEhrlyOAGBKEnB+C7uchsOztSVQhVykzODrcVxgyDTbSgkHhYROoF2PVFOucPWjW5oFzhOqfZp8SF1qoqEHYPG98cY6jLaP/yzMq5QyEcq7/zT80xOUpaYEDs8hlAOh0HJ/iN446nOnK1mnTw16RkIY6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aSOp2KFz3/rhZS0svz698xFK1jS4tyTJNw2Sw3mm14g=; b=Y+m6FIs2gW5k5BjadmvS+pzdLp4UnzqGENjOTzCYbET4hv5Z1Pew3j8Xz7ECHTgOBkUVPbkXIjxiQDE8c/5sSDmUJye+m4ndU/uZapgOt8NDvbqP8tihgMPD+dc3kZCIN5oT4F7e1NUn3VdRz4ilQc1J7ZTb1o7GD7ehbJ21y4Q= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akira.tsukamoto@aist.go.jp; Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com (20.178.140.147) by TYAPR01MB4975.jpnprd01.prod.outlook.com (20.179.175.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.17; Thu, 9 Apr 2020 23:43:38 +0000 Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2]) by TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2%7]) with mapi id 15.20.2878.018; Thu, 9 Apr 2020 23:43:38 +0000 To: Henk Birkholz , Akira Tsukamoto , Carsten Bormann Cc: "suit@ietf.org" , Brendan Moran , Jim Schaad , teep , Hannes Tschofenig References: <4e6db9fe-c0c7-7ca0-95c7-843ebc164a4c@aist.go.jp> <05ef01d60e21$4bdd1ce0$e39756a0$@augustcellars.com> <799C44A6-515B-40A7-88C5-ACED609BE6A0@tzi.org> <70520B88-66B4-48DD-A3A8-9129B3C14D31@arm.com> <3e608b68-7232-4ca0-f94c-22dc3adc8724@sit.fraunhofer.de> From: Akira Tsukamoto Message-ID: Date: Fri, 10 Apr 2020 08:43:37 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: <3e608b68-7232-4ca0-f94c-22dc3adc8724@sit.fraunhofer.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYAPR04CA0024.apcprd04.prod.outlook.com (2603:1096:404:15::36) To TYAPR01MB3406.jpnprd01.prod.outlook.com (2603:1096:404:cc::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [150.29.11.3] (150.29.11.3) by TYAPR04CA0024.apcprd04.prod.outlook.com (2603:1096:404:15::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Thu, 9 Apr 2020 23:43:38 +0000 X-Originating-IP: [150.29.11.3] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: a4511df1-bdf3-45f5-2c1f-08d7dcdfd3d8 X-MS-TrafficTypeDiagnostic: TYAPR01MB4975: X-LD-Processed: 18a7fec8-652f-409b-8369-272d9ce80620,ExtAddr X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 0368E78B5B X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3406.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(376002)(396003)(346002)(39860400002)(45080400002)(966005)(8936002)(31686004)(36756003)(110136005)(53546011)(4326008)(81156014)(66476007)(2906002)(66556008)(5660300002)(8676002)(478600001)(316002)(66946007)(81166007)(52116002)(16576012)(54906003)(6706004)(86362001)(6486002)(16526019)(2616005)(956004)(31696002)(186003)(44832011)(26005)(3940600001); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QnboC/x5hXOZAOJhxJ74JZG3wEIXAtuBXl8R9eaRM62xT9JGcl0JfyO13LcoeumbEVBh2gfzm7vqq2EooisF8AY5R86MgBHYsFLT6tqMBaWbi/DfDY33cKfuiuk7Bl3mWAVirXbO+EQH62jBUCdKBPeQ3wFmJvxqly8qoETXDWo36DRQN9SdBQfKLBABvrx45UcNCX/tAiQ3tFlEfGerG9A5wnD7edlBcTifQqw0cfzBwWtndpXRdMyt8KHUXN79EJgHKrT1Hm9T7OV1vJeHaSgVX4KdU5dy3uy3EkcwVMtYvyz4JZf8QRDmSFFmutIZAXuIIzeu1FjxyQxEwISYz/JYZM9kB+vzNHSAPf5Nz4N5IRGDaFiZysgB/BRQSRXcqJvcmwaYH9nlA5F7P+CIYH+RhstZUm81AYMXqTGzVNjjO72/eHTMkhdTNjIF2Go/m/MIufzhWFpvPF7XH1w79+UQevsgZxtHmNUqA35QA27gdsa3FMFYunZdQWz69vx+N60/UQ4gMB8lUxFa7O7DvQqTZbmYIDw4IHRof530w51sw7dsij50PFXnYx8ScVzX X-MS-Exchange-AntiSpam-MessageData: q4r71/LmJANT6zb4zbxzlYKNxohPb4B4/DJHVFjux2gD+MydG9TPqEXFaaCKG0rL75r1EyHiccoKYsQEasyjRmYg0wxzBJquzMBBFbYKwIOuj3Kg4CKZrOFMinVy61ltwWCtkoh72UvCLOXG4TwGOQ== X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: a4511df1-bdf3-45f5-2c1f-08d7dcdfd3d8 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2020 23:43:38.7511 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: PnrRZPo0X4SSZlKxCFmABJGNb5v1eZzA6bG+ZEffzKg7OF5GgmUvhn5N2doDQLkfBYlnF5pN2Ex+pFl2qab6uORdjFd1uQ3xVHYjND4GBYc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4975 Archived-At: Subject: Re: [Teep] [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged 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 Apr 2020 23:43:44 -0000 Hi Henk, Thanks for you comment. I now am perfectly clear about the label name is just annotation for array in cddl. Best, -Akira On 4/9/2020 11:13 PM, Henk Birkholz wrote: > Hello Akira, > > in an array context, the name (aka label) is annotation only. It is not transferred over "the wire", so we did not bother to define a corresponding type. > > In other words, you could simply omit "type: " and "token: " and nothing would change. It is annotation for humans, basically. > > See https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8610%23section-2.1&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C85cf47c432354e5fa73a08d7dc903817%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220384303337245&sdata=%2B%2Bm5aUI2zpFdEXec5dNElG4KNhC%2B60TeUDxMcXjtGqo%3D&reserved=0 > > Viele Grüße, > > Henk > > On 09.04.20 15:38, Akira Tsukamoto wrote: >> Hi Carsten and Hannes, >> >> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fpull%2F27&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C85cf47c432354e5fa73a08d7dc903817%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220384303337245&sdata=ZDVr31cNQdQNR5H2bcvnC%2Bj7m%2BDgVz1kIe4us99%2B%2BsA%3D&reserved=0 >> >> The new pull request reflects all the discussion points of converting >> from map and using minimum major type size for the array member. >> >> When I was reading the cddl draft, I was not quite sure how to >> describe the array with the label name. >> In your pull request, >> >> query-request = [ >>       type: TEEP-TYPE-query-request, >>       token: uint, >> >> The above cddl description has label name type and token with semicolon. >> We were trying to avoid having label name inside the array. >> I thought I have to use => for this purpose. >> >> Other discussion we had with the teep is to use the same nonce as the >> EAT defines. >> >> nonce => bytes, >> to be >> nonce => bstr .size (8..64) >> >> And the size of token we never really agreed about it. >> How bout >>    token: uint .size 4 >> >> The 32bit unsign integer seems to be reasonable for the usage in teep. >> >> Best, >> -Akira >> >> On Thu, Apr 9, 2020 at 9:12 PM Carsten Bormann wrote: >>> >>> On 2020-04-09, at 14:07, Brendan Moran wrote: >>>> >>>>  From a SUIT perspective, I’m still inclined to make sure that this is tagged as that allows for use-cases that we may not have considered. >>> >>> Makes sense.  Let’s fix the definition of `SUIT-envelope` in the below. >>> >>> Henk and I created a cleaned up version of the CBOR encoding and accompanying CDDL. >>> We should check whether this encoding helps us and then integrate it into the document. >>> >>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fpull%2F27&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C85cf47c432354e5fa73a08d7dc903817%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220384303337245&sdata=ZDVr31cNQdQNR5H2bcvnC%2Bj7m%2BDgVz1kIe4us99%2B%2BsA%3D&reserved=0 >>> >>> Grüße, Carsten >>> >>> _______________________________________________ >>> TEEP mailing list >>> TEEP@ietf.org >>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C85cf47c432354e5fa73a08d7dc903817%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220384303337245&sdata=CG21OuaA8t16%2BzyvSFazbG3l2sEpc9sa8trHUmX5TBI%3D&reserved=0 >> >> _______________________________________________ >> Suit mailing list >> Suit@ietf.org >> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C85cf47c432354e5fa73a08d7dc903817%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220384303337245&sdata=Cc9I9ZFT4Ms%2BI198MQw%2B78aJxlDsTlH0EonuB%2B7rKUg%3D&reserved=0 >> From nobody Sun Apr 12 22:46: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 C42213A0F38; Sun, 12 Apr 2020 22:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=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=aist.go.jp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smxUwTce0kBu; Sun, 12 Apr 2020 22:46:02 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400079.outbound.protection.outlook.com [40.107.140.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0793A0F37; Sun, 12 Apr 2020 22:46:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nsdpUUzJXCms1aVDMGwt09lJoO/9VNTiWkSED57thNfeG0pnS5EgSYrsG1Qfvq6EYNeADiQSYMSfoiwBmno5UhsxQVX0GKqQPdlNZMh3XJZoYHf1rAZGzHEw3hr6gc1HFqIY0hywFBaa8EQHK7qcXGXs8k219isJlDMnC2KUqTpF751C+H/eLokLhBWtgjfXpNRIFXdjmjcTINPVsj0g67MOxCcUVn+1jYu5p/m6VeaPJPlC+2CJ7O4+l1GQN9Fiu5gcH1Tpt3LpGj7RrzbZ4OgXzTMmn3E98+M+7QQJ9NPNtYcgQAfu+UYpacgFrRYgM1yK1KNlZEYZ4oxZ+iWoMg== 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=BPSu8CUNsz2SJYb7AZoRUrBm+Wnv6y9wduSVYffjaIE=; b=I/qAIbFeVwlTXZCj2ncIP9Qbzhu0EREKeMegk/O4zTh8XY9LKxDnyTesLdpxrYu3yiCv4B0uhphTN2oMpikzsrHslw2nHOQo6IWDfD/XmMbGeBptlnVnxWRzeeIKKUSEmoF5w5/RZOgaOm1kbb6F872fXWZMpap4s0vYyyE6MrLXm+tVvqiaNH6NfGyyu5vWQBPmL3ypVv8oRMNKHIyOXwdomPVtRhGzwKuJONUlPL4Rfq+7A6eZ+SZ26pkNEwsv+UVh+r6rnsQn+FkYfsNWpmhjNCwxxG+vvQXWR6we44NURVEvbuLE8Xn3N17fonTtxo6cbbcSR50dh88NudnWmg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aist.go.jp; dmarc=pass action=none header.from=aist.go.jp; dkim=pass header.d=aist.go.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BPSu8CUNsz2SJYb7AZoRUrBm+Wnv6y9wduSVYffjaIE=; b=UdXqn2gY7dLSHILwe+w0UGl/pr84wSmWAbmx3DkxD2e3GPyvIFs5F9WwYk5V+z/KIbrU+VJ2caDuO81LR33rL8AM7oJCVVob3OfBQ86/Q1wzY9qQ7IYKsAzHbdo+yfPJzJs0NJQFrVgOwkaNdjnjufaiqpNd8WMOQej/9UtyudI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=akira.tsukamoto@aist.go.jp; Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com (20.178.140.147) by TYAPR01MB5514.jpnprd01.prod.outlook.com (20.180.230.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.19; Mon, 13 Apr 2020 05:45:58 +0000 Received: from TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2]) by TYAPR01MB3406.jpnprd01.prod.outlook.com ([fe80::df1:d999:dc75:cdf2%7]) with mapi id 15.20.2900.015; Mon, 13 Apr 2020 05:45:58 +0000 To: teep , suit@ietf.org From: Akira Tsukamoto Message-ID: <7526678c-9ebc-e265-514c-435dce7595bc@aist.go.jp> Date: Mon, 13 Apr 2020 14:45:58 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: TYCPR01CA0027.jpnprd01.prod.outlook.com (2603:1096:405:1::15) To TYAPR01MB3406.jpnprd01.prod.outlook.com (2603:1096:404:cc::19) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.153] (217.178.18.13) by TYCPR01CA0027.jpnprd01.prod.outlook.com (2603:1096:405:1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Mon, 13 Apr 2020 05:45:58 +0000 X-Originating-IP: [217.178.18.13] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 2fef47d2-6a5a-4eb0-d834-08d7df6df104 X-MS-TrafficTypeDiagnostic: TYAPR01MB5514: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 037291602B X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB3406.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(366004)(39860400002)(136003)(396003)(346002)(450100002)(2906002)(5660300002)(31696002)(26005)(186003)(52116002)(16526019)(86362001)(66556008)(36756003)(81156014)(44832011)(956004)(478600001)(16576012)(6486002)(31686004)(8676002)(8936002)(316002)(966005)(66946007)(2616005)(66476007)(222643001); DIR:OUT; SFP:1101; Received-SPF: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yvLnxo+Bbl8vZVommd6NHqyLSnguxzRgxPTs9SVLt7lAFLEqO5lSzl1oFtWeQRYqASP/lUPm5LQlIuHnWUNbmuubfkERmmz7A7vo9zyhzd/EDXj7o4BnMllIxGYkWcODjfHEq/wekt4uFDJfebc6T9+9CXKBkDTU9tKCaTFh3r+muJYhvXfruZ0bNFc5rWG7pkFyEKkIeSMZbtHNe4pF5D9BwktILl9GtGiUjni98GrPvgLnR1yVAeLtT7fzN+p0Ua+jHnpSpAUuVXDvSFJn8rGsFqEudGSvJuSpjAh4chFEtaeOTI3d2O3DY4i99xrDQGKbjW+L/9/aeqxcO8xnNqMzSZrKlAL12galrZhPaoclbZCiGWXmkQJ/FZeYTiSD1ag54bxkvK6DHUlfVt0HZZpYbH0Y9zXotongWVZuHnou3EIU9Soozf7g8IiA47GcUBxSCT/wnYMgqrUb5rgEtN7SiEI/vRCOPlkds/3+fWjWUuC6XByy1b4Y83eTqiAKvImUxUHTCrw4gUYjuYF6kqb95H0+tVv9MEZc6hmhGpQYTu4g43uFZH7OFpP+kWkD X-MS-Exchange-AntiSpam-MessageData: L54ICQ4grLObfectLX+qBHMkumP5FzzT5uOX3msZUxFaErtLGLL1jpGV2edhSjJXsLKzK8+rKh79nbsXRqmMRZMZpC/MGQMHFygqCVo7ET6e0GA4sG9M76dtBQyaoolXT3MWmepB+EI8PcLcV4CESw== X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 2fef47d2-6a5a-4eb0-d834-08d7df6df104 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2020 05:45:58.5449 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 18a7fec8-652f-409b-8369-272d9ce80620 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 8POw/uxzOhjoCoIYad5fcAVGiPaPSWDWuKL70yNUZpBfm1iBL0m5PVEWUHPsbFnn4sCwzPDz5+Io1TMadKNmCMey7nWVSv2lSTWP9rhKFvg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB5514 Archived-At: Subject: [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryResponse 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 Apr 2020 05:46:06 -0000 Hi all, I would like to restart the discussion of Unique Identifier of TA_ID in TEEP's QueryResponse which was one of the item came up at TEEP interim meeting last week. The discussion started between the Hackathon in Singapore and Berlin. This is the link to the github. https://github.com/ietf-teep/teep-protocol/issues/4 After going though again, I started to have my preference. The usage of TA_ID in TEEP message is to distinguish the required TA in the device by parsing of identification id. The it will be good to be able to match the TA with one bstr for one TA. I started to think hash value might work. Using the hash value from the properties of Parameters in Section 5.4.1 in SUIT CBOR Manifest for each TA. The generating hash from adding all the properties. These are the requited parameters. - Vendor ID. - Class ID. # Could be file name for SGX, uuid for op-tee. uuid is used as file name in op-tee anyway - Image Digest. # This is version of TA It is up to the user who would like to add optional parameters for the seed. We have to consider which hash function to use too, and easiest to come up is probably sha256. The hash value of sha256 is 32 bytes which is still going to be second largest member than NONCE in TEEP message. I prefer smaller bytes to reduce the teep message size but raw parameters of all three above would be larger than 32bytes, so it may be acceptable. The purpose of the hash value here is mainly for prevent colliding between different TAs or different version in the TAM server. -Akira From nobody Tue Apr 14 09:12:51 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 ED1A73A0BAF; Tue, 14 Apr 2020 09:12:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: teep@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.126.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: teep@ietf.org Message-ID: <158688076888.31406.6830376790968300247@ietfa.amsl.com> Date: Tue, 14 Apr 2020 09:12:48 -0700 Archived-At: Subject: [Teep] I-D Action: draft-ietf-teep-protocol-02.txt 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, 14 Apr 2020 16:12:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Trusted Execution Environment Provisioning WG of the IETF. Title : Trusted Execution Environment Provisioning (TEEP) Protocol Authors : Hannes Tschofenig Mingliang Pei David Wheeler Dave Thaler Akira Tsukamoto Filename : draft-ietf-teep-protocol-02.txt Pages : 25 Date : 2020-04-14 Abstract: This document specifies a protocol that installs, updates, and deletes Trusted Applications (TAs) in a device with a Trusted Execution Environment (TEE). This specification defines an interoperable protocol for managing the lifecycle of TAs. The protocol name is pronounced teepee. This conjures an image of a wedge-shaped protective covering for one's belongings, which sort of matches the intent of this protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-teep-protocol-02 https://datatracker.ietf.org/doc/html/draft-ietf-teep-protocol-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-teep-protocol-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 14 09:41:21 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 364B23A0CAB for ; Tue, 14 Apr 2020 09:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=DpIIVgx1; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=DpIIVgx1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Sp6-W6YNALI for ; Tue, 14 Apr 2020 09:41:17 -0700 (PDT) Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120071.outbound.protection.outlook.com [40.107.12.71]) (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 952FA3A0CA1 for ; Tue, 14 Apr 2020 09:41:16 -0700 (PDT) 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=XvKJtOwJ5NetfpnbqpDoFnRU/cKsCzAS9XHO6qqweGU=; b=DpIIVgx1U08044leSQ8oXYe1NbzDCXJU8XL67ITOqbboh4SZ6WSzy3S1pPn47b6nCscUuposObXTgcBNZ5qHBTXUDxN3OjIZMFE1cxaI2G5OEu+XjFED+14poo35hDBOm8U2yAyY1zjpV6MO9IJkdMtmnTrP/0J3Y1MFt76RqqY= Received: from AM5PR0701CA0060.eurprd07.prod.outlook.com (2603:10a6:203:2::22) by PR2PR08MB4732.eurprd08.prod.outlook.com (2603:10a6:101:26::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.26; Tue, 14 Apr 2020 16:41:13 +0000 Received: from VE1EUR03FT050.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:2:cafe::9c) by AM5PR0701CA0060.outlook.office365.com (2603:10a6:203:2::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.15 via Frontend Transport; Tue, 14 Apr 2020 16:41:13 +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 VE1EUR03FT050.mail.protection.outlook.com (10.152.19.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Tue, 14 Apr 2020 16:41:12 +0000 Received: ("Tessian outbound 5345ff401cf8:v50"); Tue, 14 Apr 2020 16:41:12 +0000 X-CR-MTA-TID: 64aa7808 Received: from c168ebe5c7be.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id FBB89CCE-29E8-4CE3-B19B-35B990BFBA8E.1; Tue, 14 Apr 2020 16:41:07 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c168ebe5c7be.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 14 Apr 2020 16:41:07 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sa6NKMLnbTkoAtLC4cNe6YVcnGgAuEBsHt+BKakpIhGsaGy8GEUF6kCXUtl/BcIub3d6cuEXYNDohcEmm3P7SCfz4yWcHdtxTlc/HCB+mLcmurxaqqz5AsFsYwG/oyV5r85mqGTZno/rymtxRvWfKpFGPzBalHo3Vb31ZWOTT3rAWKllSacNNGm4DbgyKTaaEZxeeP/UgbEZB4U5hyjpBVpeBp14hdifdo1Q1GC/KsF75T9PlculZ9+eyy7Gp1kL+934CCAeshBjzncgKWelPEtjRiBiw9ZRTD/5WfNy9gc6vd7KK+iYuu6no04Gqznms/+tzglMfXbRfiZeIJUVtQ== 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=XvKJtOwJ5NetfpnbqpDoFnRU/cKsCzAS9XHO6qqweGU=; b=agJLA3KFg5DSgkt9QQYTnN1uiDoG7XOZNf2qeyUKUSY7pJmNQHf3cJsr/NZRuR/YmBQeCFwaIlAAKPnJWvFP9zpWOAG9NXSWdc/M8+FjlvgpEgB5u+XrhfSaKlOz2KBN5WsVqXNxrhPMCPL++6UDPFa3T/etBJ6WuUJ7P4DvvsDB4mFgPnTtZIxbz7qQdLWglksJXbbnEpMUjzNIVWAnM/ya6VUHPIiNkG2y8N3s8B83VE9TVZyq7Cm+Fr9nT6/+V3LBheY1pVuYVz2cP5zJur33SHV6X8C9L4cvlA6ojg58k0Idt5a1o8MJB4djeI8OLKwBytZOznOcbqL+B+pWkg== 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=XvKJtOwJ5NetfpnbqpDoFnRU/cKsCzAS9XHO6qqweGU=; b=DpIIVgx1U08044leSQ8oXYe1NbzDCXJU8XL67ITOqbboh4SZ6WSzy3S1pPn47b6nCscUuposObXTgcBNZ5qHBTXUDxN3OjIZMFE1cxaI2G5OEu+XjFED+14poo35hDBOm8U2yAyY1zjpV6MO9IJkdMtmnTrP/0J3Y1MFt76RqqY= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3874.eurprd08.prod.outlook.com (2603:10a6:208:108::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.26; Tue, 14 Apr 2020 16:41:06 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2900.028; Tue, 14 Apr 2020 16:41:06 +0000 From: Hannes Tschofenig To: "teep@ietf.org" Thread-Topic: draft-ietf-teep-protocol-02 Thread-Index: AdYSd71jR8K6/i1dRSmjDIznhnr+vQ== Date: Tue, 14 Apr 2020 16:41:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: ea80bba8-61b8-4b58-aa08-185566d040ac.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.116.238] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 454f3b06-43c6-495a-a5b8-08d7e092a496 x-ms-traffictypediagnostic: AM0PR08MB3874:|PR2PR08MB4732: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000; x-forefront-prvs: 0373D94D15 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(366004)(396003)(346002)(376002)(39850400004)(5660300002)(66946007)(76116006)(66556008)(86362001)(478600001)(66446008)(316002)(64756008)(966005)(66476007)(8936002)(9686003)(8676002)(55016002)(81156014)(186003)(6506007)(7696005)(33656002)(6916009)(26005)(2906002)(52536014)(71200400001); DIR:OUT; SFP:1101; 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: ioiuK34O391XiV9oBPueoRZp5AAA8Gzl/fkTTrDafLJZrSRTsbHr4PkKjiguSS2dsDHdit50e1TiQcJCy3o2x3hf0k011sFUdiBgM6Nk9bCA7xjPCFdkKI6rMfp1qIcUMOfjxaWzazBSu164sYlMr+OGan2Jyxxh2q6+/QV8dC5fv0pZ4t7Nb26OdQE8uRzdwful/kC13+/jiUrcVZ+5UYSSERKHasvD87EG+ZtK5Ye0W6H8IH3fsDloDgreD8bIBS+Qor2962K37yeHXTlt4qurfuj0X1fyRczhLdRfA6eJyUDPEqaVV9GDg4472cMmaS708NkC57hZ1YeGyB4plSq17k8KT6OxtmRyuHW7p97OMcaKRKsEbmjST+Wo6euoYjSPYu8XWhMZ5V5r+dT4H/nqFrSuMOmffUzu/x5uU7ZSS3jvLL8H8x0r3R+uZlG50Zj854WTL7YeRUcNkU/+Ptjd626vFGvlThEUN/ZjGRDeEqoxP/OjNQQ8rcuV+3Wa7omPiV7TyO2PaG+0zq2y7w== x-ms-exchange-antispam-messagedata: 9Sj2bYJKpgo585pOXXhkiwbGTBsoudj42WBQjMyv8eLOZF6C4NNGtGHgOWrS86Ze+Eq5UXQ/E70L+3xjPVqAYAmkv6P1alsuuSDjVkDkOuSYm0LtHPA617zxOjGim63GbnxluJ8ZOgXYTbf8fv3/aQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB3716B5F372BA8D979825D563FADA0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3874 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT050.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(136003)(346002)(376002)(39850400004)(46966005)(26005)(966005)(47076004)(2906002)(6916009)(7696005)(186003)(81166007)(356005)(316002)(8676002)(6506007)(336012)(26826003)(9686003)(82740400003)(5660300002)(36906005)(81156014)(70206006)(86362001)(478600001)(55016002)(33656002)(70586007)(8936002)(52536014); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 2f69c48f-91dd-4297-0207-08d7e092a0e4 X-Forefront-PRVS: 0373D94D15 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Ym6DyjK8AFru9snkTAmORjVLQW9adRChHNkw4apqeIs5YU6j14JOHbbJFaipnYmNuzzR92tfbbunZ0FLGb5bomQ1LzXnLGq9XA1SMlufGfxNbcwd6aULJqviNkGbsw0wF6ZfPQyZoXUJ6UuWsiz6YgNkp2oj+E0DOWMmaRY8Ov1JOPOGP/MEuFlD6m8mOoCPxvZdZsKpL7u0kgv/Fpxg80CSf91DlC5MdXwbcB5zPNBoC2E6pmUrQfMSP5XFYHWvUgEeuvKZzMfY8IsineRBQ2fUAKwVUHJzYHRrFheCyRFSvSIdOrO7iA5kqZPDDagKnunr/idVeF70rlnGuDrLvKlWaHuACUbU2iYYiMXuH4c/t5FY5SoJQ/Kohuk1ZAIe4m69LV31rBOBs9HWMwm9cPyEW+UgwRzQ1ChvVMnYdgBh881WF765FUTOG9Zhq5g7RVN2QQ2E4okV318eeAc9/VqqMHHk5Rw1V7sjENFnIuRFbixUG9BIC7UUudepV4stAzyBWs5rIZ9XxSLZqlAW4uV2E7N3pdqOuosvmGvxqYE9qLTeIv0l4oc9yjseChSoqNvY5ww9iH1QcFOLX5S2Jw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2020 16:41:12.6353 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 454f3b06-43c6-495a-a5b8-08d7e092a496 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: PR2PR08MB4732 Archived-At: Subject: [Teep] draft-ietf-teep-protocol-02 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 Apr 2020 16:41:19 -0000 --_000_AM0PR08MB3716B5F372BA8D979825D563FADA0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I have just submitted version -02 of the TEEP protocol draft to have a stab= le snapshot for further discussions and for the prototyping work. The changes focused on the discussions at the last virtual interim meeting = and subsequently on the list/Github. Here are the main changes: * Added Akira as co-author * Added text about creating and verifying TEEP messages * Added Mapping of TEEP Message Parameters to CBOR Labels * Every TEEP message is now signed. * Clarified the use of the nonce and indicated length * Switched to a new message format with mandatory parameters in the arr= ay and the optional parameters in the map. * CDDL fixed (thanks to Carsten & Henk). Added them to the ack section. * Reformatted contributor list * Reformatted text and improved description Here is the link to the doc: https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/ I believe this version is a better foundation for prototyping. Ciao Hannes 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_AM0PR08MB3716B5F372BA8D979825D563FADA0AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have just submitted version -02 of the TEEP protoc= ol draft to have a stable snapshot for further discussions and for the prot= otyping work.

The changes focused on the discussions at the last v= irtual interim meeting and subsequently on the list/Github.

 

Here are the main changes:

 

  • Added Akira as co-author
  • Added text about creati= ng and verifying TEEP messages
  • Added Mapping of TEEP M= essage Parameters to CBOR Labels
  • Every TEEP message is= now signed.
  • Clarified the use of the nonce and indicated length
  • Switched to a new message format with mandatory paramet= ers in the array and the optional parameters in the map.
  • CDDL fixed (thanks to Carsten & Henk). Added them= to the ack section.
  • Reformatted contributor list
  • Reformatted text and improved description<= /li>

 

Here is the link to the doc:

https://datatracker.ietf.org/doc/draft-ietf-teep-protoco= l/

 

I believe this version is a better foundation for pr= ototyping.

 

Ciao

Hannes

 

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_AM0PR08MB3716B5F372BA8D979825D563FADA0AM0PR08MB3716eurp_-- From nobody Fri Apr 17 13:35:08 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 1FC933A1430 for ; Fri, 17 Apr 2020 13:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIfAO0IbHYWx for ; Fri, 17 Apr 2020 13:34:59 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2B03A143A for ; Fri, 17 Apr 2020 13:33:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 29791300B3E for ; Fri, 17 Apr 2020 16:33:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TLpv9Fabz-Yj for ; Fri, 17 Apr 2020 16:33:48 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 270B4300ABE for ; Fri, 17 Apr 2020 16:33:48 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Message-Id: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> Date: Fri, 17 Apr 2020 16:33:49 -0400 To: teep X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: [Teep] Review of draft-ietf-teep-architecture-08 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, 17 Apr 2020 20:35:07 -0000 On the last TEEP call, I agreed to review the TEEP Architecture = document. Here are my comments and questions. 1) Section 1 says: Typically, application components are chosen to execute inside a TEE because those application components perform security sensitive operations or operate on sensitive data. Recognizing that this is the introduction, I was wondering if you could = provide a bit more explanation here. Earlier in the paragraph, the = document offers an example of a banking application. There would be = components of such and application that are trusted, and other = components would be untrusted. This concept is described, but the = coupling to make a complete application could be more explicit to = prepare the reader for the detail that is coming. Within such an = application, it would be good to offer an example of a security = sensitive operations and a separate example of operating on sensitive = data. 2) Section 1 says: To simplify the life of TA developers interacting with TAs in a TEE, an interoperable protocol for managing TAs running in different TEEs of various devices is needed. This feels incomplete to me. Making sure that compatible trusted and = untrusted components of an application are installed on the same device = is vital when they are not bundled. 3) Section 1 offers: - A TA developer wants to remove a confidential TA from a device's TEE if the TA developer is no longer offering such TAs or the TAs are being revoked from a particular user (or device). For example, if a subscription or contract for a particular service has expired, or a payment by the user has not been completed or has been rescinded. This implies that the TA developer has some of the privileges that I = associate with the TAM. Yes, I see the note at the end of the bullets, = but I think this is an indication that the privileges are not quite = right for these roles. Also, if I was writing a TA for a subscription, = I would have the TA perform some form of payment checking, and then = refuse to decrypt the content if the payment checking fails. Perhaps = the REE passes a signed proof of payment. This way, the TA developer = does not need to actually have permission to remove a TA. Further, if = the TA is on a multi-user device, removing the TA would adversely impact = other users. 4) Section 2 says: - Untrusted Application: An application running in a Rich Execution Environment. For alignment with the definition of a TA and te terms used in section = 1, I think this should say: - Untrusted Application: An application component that runs in a REE. It is also useful to indicate that the Untrusted Application may be = dependent on one or more TAs. 5) Section 3.3 talks about the Internet of Things. It does not talk = about the billions of devices being used to mount DDoS attacks. Can it = cover that too? Without putting the network interface inside the TEE, = I'm skeptical there is a solution. 6) Section 3.4 talks about Confidential Cloud Computing. Can something = be said in Section 4.4.1 to make this less abstract? 7) Section 4.1 defines CA incorrectly. A CA is not "Certificate-based = credentials". A CA issues certificates, and the certificates are then = used for authentication and cryptographic key management. This bullet = should begin: "A CA is ..." to follow the pattern of the other bullets. 8) Section 4.3 introduces the term "TA software author" and "TA signer." = I hope we ca pick one. Please add the term that is chosen to Section = 2. 9) Section 4.4 should require support for both confidentiality and = integrity protection. 10) Should GlobalPlatform be added to Section 4.4.1? 11) Section 4.5 uses the term "TA binary signers" and "TA signer". = Please see comment 8 above. 12) Section 5 says: "... encrypted with the TAM public key ...". This = is not correct. The TAM public key is used to establish the key that is = then used for encryption and decryption. Further the wording is aimed = at RSA, which is a key transport algorithm. Please make the wording = accommodate key transport and key agreement approaches. 13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; = however, Section 1 said that a trust anchor could be a raw public key. = Can the TAM use the raw trust anchor key directly? 14) Section 5.2 and Section 5.3 should allow signatures to be directly = by the trust anchor. The current working requires a certification path. 15) Section 5.4 says that "self-signed certificates" are allowed. I = think this is the same as allowing signatures to be directly by the = trust anchor. Please consider this comment in conjunction with comment = 13 above. 16) Section 7 says that there are "different attestation algorithms". = Does this mean different set of claims? Please be more clear here. 17) I think the discussion about "assumptions" would be better written = as things that need to be considered when assessing the degree of = confidence in the claim by the TEE, 18) Section 18: Asymmetric algorithms are also used to manage the = symmetric keys. Symmetric algorithms are also used for data integrity. 19) Section 9.4: Please expand this discussion to cover compromised = trust anchors and compromised intermediate CAs. 20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, = which tells how to make a device certificate that never expires. 21) Please add references for SGX and TrustZone, adding the citations in = the body as appropriate. 22) Nits: Section 3.1: s/trust about the hosting device/trust in the hosting = device/ Section 3.1: s/unlocking the phone/unlocking the device/ Section 4.1: s/certificate/certificate [RFC5280]/ Section 4.2: s/Rich Execution Environment/REE/ (several places) Section 4.5: s/and TA signer verification/and TA signature verification/ Section 4.5: s/nnetwork/network/ Section 5: s/chains up to some CA/chains up to some trust anchor/ Section 5: s/Figure 4: Keys/Figure 4: Signature Keys/ Section 7: s/different standards for/require different degrees of = confidence in/ Section 8, sentence 1: s/algorithm suite/cryptographic algorithm suite/ Section 9.8: s/public key of the TEE that it can use to encrypt/public = key of the TEE to establish a symmetric key for encryption/ From nobody Tue Apr 21 02:33: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 595523A08C6 for ; Tue, 21 Apr 2020 02:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, 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 aag0vb-DU6VE for ; Tue, 21 Apr 2020 02:32:58 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7A23A095F for ; Tue, 21 Apr 2020 02:32:57 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id w20so6961173ljj.0 for ; Tue, 21 Apr 2020 02:32:57 -0700 (PDT) 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=xs5MHONVUxDB0Ck7/8XBvww3fRX+Piguss4O8p02KLg=; b=HqUPU4yr6pgDJTo52yI3XSmwjOMkOLwJScO2QsSnhWJLr9Xj1fOSDLCq10oLGga2pe RdfpgbeTXBROnqzSfQfj/QE4us1UN8eUzPkSEwDwTrq59Xt4p/ImCsUCAOPP3QaLT+q0 1gXdtsG4vqq8cJMoNcLPGh3E9Dxy2TMRM8VcE= 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=xs5MHONVUxDB0Ck7/8XBvww3fRX+Piguss4O8p02KLg=; b=cBCCjcOu1vHkFMX+cEhaYGeg5zIL1qLR4hEq8ZgCeMdKd2NLXVoFuIDBTTPbIHRsyz /TPvP0m5ZL5vy6b195JwqJAaSc5LCBcRCPcCKaEUCCGTG7/10HaD9Do0fNkmXAc0npqX +QtmkLTSPbGWor3g4RQY8dqCLgfFw3iNL5cYEgWCqwj+7PaXyH/T6EC1NLxvt1J3PmLr 3MXfPONsglvuj2GAvVd9zx3kBN7vgZc4yIuaKGL8ZVqG8kmddNzSZV7zKVKHEdsfcn1f qBiz4QRBCCcBez+a4/X5rpM3dlL3fHGriCOhEkXLDkhlDOrJpDnrUXqlL239xGV9MHjl MIsg== X-Gm-Message-State: AGi0PuZWPwU9hp5abMS1ZgdUMRxVzegWQPmsxCswao7vbioIZrfo9h/P SwT4b53Vt1eL+DOm2M0gb4g25eIHIcaWEMnxCsRxRWB9LeI= X-Google-Smtp-Source: APiQypICUIpNWBfREwz6Mq2oCkYqBNiQzqZLLx2mx3YKZqwF81VjZvrKzwkYwqWckm8W3uyWWbC9tSrtSrZDhSzWJU8= X-Received: by 2002:a2e:8e8a:: with SMTP id z10mr5164797ljk.107.1587461575100; Tue, 21 Apr 2020 02:32:55 -0700 (PDT) MIME-Version: 1.0 References: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> In-Reply-To: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> From: Mingliang Pei Date: Tue, 21 Apr 2020 02:32:43 -0700 Message-ID: To: Russ Housley Cc: teep Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000515e4605a3c9b33c" Archived-At: Subject: Re: [Teep] Review of draft-ietf-teep-architecture-08 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, 21 Apr 2020 09:33:02 -0000 --000000000000515e4605a3c9b33c Content-Type: multipart/alternative; boundary="00000000000047faac05a3c9b3ae" --00000000000047faac05a3c9b3ae Content-Type: text/plain; charset="UTF-8" Hi Russ, Thank you very much for your detailed review, suggestions and nits. Please see inline. Best, Ming On Fri, Apr 17, 2020 at 1:37 PM Russ Housley wrote: > On the last TEEP call, I agreed to review the TEEP Architecture document. > Here are my comments and questions. > > 1) Section 1 says: > > Typically, application components are chosen to execute inside a TEE > because those application components perform security sensitive > operations or operate on sensitive data. > > Recognizing that this is the introduction, I was wondering if you could > provide a bit more explanation here. Earlier in the paragraph, the > document offers an example of a banking application. There would be > components of such and application that are trusted, and other components > would be untrusted. This concept is described, but the coupling to make a > complete application could be more explicit to prepare the reader for the > detail that is coming. Within such an application, it would be good to > offer an example of a security sensitive operations and a separate example > of operating on sensitive data. > MP: we will provide two examples as you suggested. We will file this in issue tracker for a fix. > 2) Section 1 says: > > To simplify the life of TA developers interacting with TAs in a TEE, > an interoperable protocol for managing TAs running in different TEEs > of various devices is needed. > > This feels incomplete to me. Making sure that compatible trusted and > untrusted components of an application are installed on the same device is > vital when they are not bundled. > > MP: how about the following? To simplify the life of TA developers interacting with TAs in a TEE, an interoperable protocol for managing TAs running in different TEEs of various devices is needed in order for an untrusted application to use. 3) Section 1 offers: > > - A TA developer wants to remove a confidential TA from a device's > TEE if the TA developer is no longer offering such TAs or the TAs > are being revoked from a particular user (or device). For > example, if a subscription or contract for a particular service > has expired, or a payment by the user has not been completed or > has been rescinded. > > This implies that the TA developer has some of the privileges that I > associate with the TAM. Yes, I see the note at the end of the bullets, but > I think this is an indication that the privileges are not quite right for > these roles. Also, if I was writing a TA for a subscription, I would have > the TA perform some form of payment checking, and then refuse to decrypt > the content if the payment checking fails. Perhaps the REE passes a signed > proof of payment. This way, the TA developer does not need to actually > have permission to remove a TA. Further, if the TA is on a multi-user > device, removing the TA would adversely impact other users. > > MP: the subscription example doesn't fully need TA removal as you said. The first half about a "revoked TA" still calls for the help of TAM. I think we can remove the subscription sentence. A TA could be revoked because it is compromised, or not offered anymore. Regarding the impact on multi-user devices, a TA is shared. A revoked TA use case should apply to all users, which will not have the concern you mentioned. Is this good? 4) Section 2 says: > > - Untrusted Application: An application running in a Rich Execution > Environment. > > For alignment with the definition of a TA and te terms used in section 1, > I think this should say: > > - Untrusted Application: An application component that runs in a > REE. > > It is also useful to indicate that the Untrusted Application may be > dependent on one or more TAs. > > MP: Agree on the additional line. Not sure about changing "application" to "component". An untrusted application intends to mean a regular client application. Trusted application is an independent application; we don't require that the two are strongly tied. Multiple untrusted applications can call the same trusted application. 5) Section 3.3 talks about the Internet of Things. It does not talk about > the billions of devices being used to mount DDoS attacks. Can it cover > that too? Without putting the network interface inside the TEE, I'm > skeptical there is a solution. > > MP: DDoS attack utilized insecure design that was triggered to send queries. If all apps are inside TEE, those apps won't be misused. But not sure the entire IoT can just use TEE that can still provide a network interface as you mentioned. 6) Section 3.4 talks about Confidential Cloud Computing. Can something be > said in Section 4.4.1 to make this less abstract? > > MP: will work with co-authors on some text for review. 7) Section 4.1 defines CA incorrectly. A CA is not "Certificate-based > credentials". A CA issues certificates, and the certificates are then used > for authentication and cryptographic key management. This bullet should > begin: "A CA is ..." to follow the pattern of the other bullets. > > MP: how about the following changes? Certification Authority (CA): Certificate-based credentials used for authenticating a device, a TAM and a TA developer. To Certification Authority (CA): A CA issues certificates that can be used for authenticating a device, a TAM or a TA developer. Different CAs may be used for issuing certificates for a device, a TAM and a TA developer. 8) Section 4.3 introduces the term "TA software author" and "TA signer." I > hope we ca pick one. Please add the term that is chosen to Section 2. > > MP: prefer to pick "TA signer". Will add definition to Section 2. 9) Section 4.4 should require support for both confidentiality and > integrity protection. > > MP: it currently says "Implementations must support encryption of personalization data to preserve the confidentiality of potentially sensitive data contained within it." Agreed. We should add integration protection support too. How about the following? "Implementations must support encryption of personalization data to preserve the confidentiality of potentially sensitive data contained within it and support integrity protection." 10) Should GlobalPlatform be added to Section 4.4.1? > > MP: GP TEE can be referred to in the TrustZone section. How about the following? "A TA is loaded by a trusted OS running in the TEE such as a GlobalPlatform compliant TEE," 11) Section 4.5 uses the term "TA binary signers" and "TA signer". Please > see comment 8 above. > > MP: "TA signer" 12) Section 5 says: "... encrypted with the TAM public key ...". This is > not correct. The TAM public key is used to establish the key that is then > used for encryption and decryption. Further the wording is aimed at RSA, > which is a key transport algorithm. Please make the wording accommodate > key transport and key agreement approaches. > > MP: will revise this, and file it in Github issue tracker for text revision. 13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; > however, Section 1 said that a trust anchor could be a raw public key. Can > the TAM use the raw trust anchor key directly? > > MP: It isn't a common case to use a fixed public key as a trusted anchor instead of a CA certificate. How about allowing a TAM to use a self-signed certificate? It accommodates both. 14) Section 5.2 and Section 5.3 should allow signatures to be directly by > the trust anchor. The current working requires a certification path. > > MP: we assume that signer and the intermediate CAs up to the trust anchor but not include a trust anchor are sent in a signature payload. This can establish a certificate path. Do you mean this about "directly by the trust anchor"? We need to allow intermediate CAs. We can revise the paragraph to elaborate on this if you agree. 15) Section 5.4 says that "self-signed certificates" are allowed. I think > this is the same as allowing signatures to be directly by the trust > anchor. Please consider this comment in conjunction with comment 13 above. > > MP: please see above #13 comment. 16) Section 7 says that there are "different attestation algorithms". Does > this mean different set of claims? Please be more clear here. > > MP: it currently means algorithm agility and algorithms may be different for different devices. Different set of claims from different algorithms from one device is possible but not necessary, I think. A verifier is expected to support all the supported algorithms such that it doesn't have to require different claims to get one working. We will clarify the text. 17) I think the discussion about "assumptions" would be better written as > things that need to be considered when assessing the degree of confidence > in the claim by the TEE, > > MP: will track this as an issue to revise. 18) Section 18: Asymmetric algorithms are also used to manage the symmetric > keys. Symmetric algorithms are also used for data integrity. > > MP: will revise it to reflect both points. Symmetric algorithms are used for encryption of content whereas the asymmetric algorithms are mostly used for signing messages. ==> Symmetric algorithms are used for encryption of content and data integrity whereas the asymmetric algorithms are mostly used for signing messages and managing symmetric keys. 19) Section 9.4: Please expand this discussion to cover compromised trust > anchors and compromised intermediate CAs. > > MP: will file an issue to add this. 20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, > which tells how to make a device certificate that never expires. > > MP: will add a sentence to indicate this possibility. " TEE device certificates are expected to be long lived, longer than the lifetime of a device." ==> "TEE device certificates are expected to be long lived, longer than the lifetime of a device. They can be certificates that never expire as defined in the Section 4.1.2.5 of RFC 5280." 21) Please add references for SGX and TrustZone, adding the citations in > the body as appropriate. > > MP: will add. 22) Nits: > > MP: will fix these below. Thank you very much for these detailed comments, suggestions, and nits. Section 3.1: s/trust about the hosting device/trust in the hosting device/ > > Section 3.1: s/unlocking the phone/unlocking the device/ > > Section 4.1: s/certificate/certificate [RFC5280]/ > > Section 4.2: s/Rich Execution Environment/REE/ (several places) > > Section 4.5: s/and TA signer verification/and TA signature verification/ > > Section 4.5: s/nnetwork/network/ > > Section 5: s/chains up to some CA/chains up to some trust anchor/ > > Section 5: s/Figure 4: Keys/Figure 4: Signature Keys/ > > Section 7: s/different standards for/require different degrees of > confidence in/ > > Section 8, sentence 1: s/algorithm suite/cryptographic algorithm suite/ > > Section 9.8: s/public key of the TEE that it can use to encrypt/public key > of the TEE to establish a symmetric key for encryption/ > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > > https://clicktime.symantec.com/3AXrEd5omjpFtMENR4Ssz2L7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep > --00000000000047faac05a3c9b3ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,

Th= ank you very much for your detailed review, suggestions and nits. Please se= e inline. Best,

Ming


On Fr= i, Apr 17, 2020 at 1:37 PM Russ Housley <housley@vigilsec.com> wrote:
On the last TEEP call, I agreed to review the = TEEP Architecture document.=C2=A0 Here are my comments and questions.

1) Section 1 says:

=C2=A0 =C2=A0Typically, application components are chosen to execute inside= a TEE
=C2=A0 =C2=A0because those application components perform security sensitiv= e
=C2=A0 =C2=A0operations or operate on sensitive data.

Recognizing that this is the introduction, I was wondering if you could pro= vide a bit more explanation here.=C2=A0 Earlier in the paragraph, the docum= ent offers an example of a banking application.=C2=A0 There would be compon= ents of such and application that are trusted, and other components would b= e untrusted. This concept is described, but the coupling to make a complete= application could be more explicit to prepare the reader for the detail th= at is coming.=C2=A0 Within such an application, it would be good to offer a= n example of a security sensitive operations and a separate example of oper= ating on sensitive data.

MP: we will pr= ovide two examples as you suggested. We will file this in issue tracker for= a fix.


2) Section 1 says:

=C2=A0 =C2=A0To simplify the life of TA developers interacting with TAs in = a TEE,
=C2=A0 =C2=A0an interoperable protocol for managing TAs running in differen= t TEEs
=C2=A0 =C2=A0of various devices is needed.

This feels incomplete to me.=C2=A0 Making sure that compatible trusted and = untrusted components of an application are installed on the same device is = vital when they are not bundled.


MP: how about the following?

=C2=A0=C2=A0 To simplify the life of TA developers interact= ing with TAs in a TEE,
=C2=A0 =C2=A0an interoperable protocol for managing TAs running in differen= t TEEs
=C2=A0 =C2=A0of various devices is needed in order for an untrusted applica= tion to use.

3) Section 1 offers:

=C2=A0 =C2=A0-=C2=A0 A TA developer wants to remove a confidential TA from = a device's
=C2=A0 =C2=A0 =C2=A0 TEE if the TA developer is no longer offering such TAs= or the TAs
=C2=A0 =C2=A0 =C2=A0 are being revoked from a particular user (or device).= =C2=A0 For
=C2=A0 =C2=A0 =C2=A0 example, if a subscription or contract for a particula= r service
=C2=A0 =C2=A0 =C2=A0 has expired, or a payment by the user has not been com= pleted or
=C2=A0 =C2=A0 =C2=A0 has been rescinded.

This implies that the TA developer has some of the privileges that I associ= ate with the TAM.=C2=A0 Yes, I see the note at the end of the bullets, but = I think this is an indication that the privileges are not quite right for t= hese roles.=C2=A0 Also, if I was writing a TA for a subscription, I would h= ave the TA perform some form of payment checking, and then refuse to decryp= t the content if the payment checking fails.=C2=A0 Perhaps the REE passes a= signed proof of payment.=C2=A0 This way, the TA developer does not need to= actually have permission to remove a TA. Further, if the TA is on a multi-= user device, removing the TA would adversely impact other users.


MP: the subscription example doesn'= ;t fully need TA removal as you said. The first half about a "revoked = TA" still calls for the help of TAM. I think we can remove the subscri= ption sentence. A TA could be revoked because it is compromised, or not off= ered anymore. Regarding the impact on multi-user devices, a TA is shared. A= revoked TA use case should apply to all users, which will not have the con= cern you mentioned. Is this good?

4) Section 2 says:

=C2=A0 =C2=A0-=C2=A0 Untrusted Application: An application running in a Ric= h Execution
=C2=A0 =C2=A0 =C2=A0 Environment.

For alignment with the definition of a TA and te terms used in section 1, I= think this should say:

=C2=A0 =C2=A0-=C2=A0 Untrusted Application: An application component that r= uns in a
=C2=A0 =C2=A0 =C2=A0 REE.

It is also useful to indicate that the Untrusted Application may be depende= nt on one or more TAs.


MP: Agree on the additional line. Not = sure about changing "application" to "component". An un= trusted application intends to mean a regular client application. Trusted a= pplication is an independent application; we don't require that the two= are strongly tied. Multiple untrusted applications can call the same trust= ed application.

5) Section 3.3 talks about the Internet of Things.=C2=A0 It does not talk a= bout the billions of devices being used to mount DDoS attacks.=C2=A0 Can it= cover that too?=C2=A0 Without putting the network interface inside the TEE= , I'm skeptical there is a solution.


MP: DDoS attack utilized insecure desi= gn that was triggered to send queries. If all apps are inside TEE, those ap= ps won't be misused. But not sure the entire IoT can just use TEE that = can still provide a network interface as you mentioned.

=
6) Section 3.4 talks about Confidential Cloud Computing.=C2=A0 Can somethin= g be said in Section 4.4.1 to make this less abstract?


MP: will work with co-authors on some = text for review.

7) Section 4.1 defines CA incorrectly.=C2=A0 A CA is not "Certificate-= based credentials".=C2=A0 A CA issues certificates, and the certificat= es are then used for authentication and cryptographic key management.=C2=A0= This bullet should begin: "A CA is ..." to follow the pattern of= the other bullets.


MP: how about the following changes?

Certification Authority (CA): Certificate-based credential=
s used
      for authenticating a device, a TAM and a TA developer.

To
<=
br>Certification Authority (CA): A CA issues certificates that can be used
      for authenticating a device, a TAM or a TA developer. Different CAs
      may be used for issuing certificates for a device, a TAM and a TA de=
veloper.


8) Section 4.3 introduces the term "TA software author" and "= ;TA signer."=C2=A0 I hope we ca pick one.=C2=A0 Please add the term th= at is chosen to Section 2.


MP: prefer to pick "TA signer&quo= t;. Will add definition to Section 2.

9) Section 4.4 should require support for both confidentiality and integrit= y protection.


MP: it currently says=C2=A0
= 
   =
"Implementations must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it."

Agreed. We s=
hould add integration protection support too. How about the following?
<=
br>   "Implementations must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it and support integrity pro=
tection."

10) Should GlobalPlatform be added to Section 4.4.1?


MP: GP TEE can be referred to in the T= rustZone section. How about the following?

"A TA= is loaded by a trusted OS running in the TEE such as a GlobalPlatform comp= liant TEE,"

11) Section 4.5 uses the term "TA binary signers" and "TA si= gner".=C2=A0 Please see comment 8 above.


MP: "TA signer"

12) Section 5 says: "... encrypted with the TAM public key ...".= =C2=A0 This is not correct.=C2=A0 The TAM public key is used to establish t= he key that is then used for encryption and decryption.=C2=A0 Further the w= ording is aimed at RSA, which is a key transport algorithm.=C2=A0 Please ma= ke the wording accommodate key transport and key agreement approaches.


MP: will revise this, and file it in G= ithub issue tracker for text revision.

13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA&q= uot;; however, Section 1 said that a trust anchor could be a raw public key= .=C2=A0 Can the TAM use the raw trust anchor key directly?


MP: It isn't a common case to use = a fixed public key as a trusted anchor instead of a CA certificate. How abo= ut allowing a TAM to use a self-signed certificate? It accommodates both.

14) Section 5.2 and Section 5.3 should allow signatures to be directly by t= he trust anchor.=C2=A0 The current working requires a certification path.

MP: we assume that signer and the inte= rmediate CAs up to the trust anchor but not include a trust anchor are sent= in a signature payload. This can establish a certificate path. Do you mean= this about "directly by the trust anchor"? We need to allow inte= rmediate CAs. We can revise the paragraph to elaborate on this if you agree= .

16) Section 7 says that there are "different attestation algorithms&qu= ot;.=C2=A0 Does this mean different set of claims?=C2=A0 Please be more cle= ar here.


MP: it currently means algorithm agili= ty and algorithms may be different for different devices. Different set of = claims from different algorithms from one device is possible but not necess= ary, I think. A verifier is expected to support all the supported algorithm= s such that it doesn't have to require different claims to get one work= ing.

We will clarify the text.

=
17) I think the discussion about "assumptions" would be better wr= itten as things that need to be considered when assessing the degree of con= fidence in the claim by the TEE,


MP: will track this as an issue to rev= ise.

18) Section 18: Asymmetric algorithms are also used to manage the symmetric= keys.=C2=A0 Symmetric algorithms are also used for data integrity.


MP: will revise it to reflect both poi= nts.

Symmetric algorithms are used for encryption
   of content whereas the asymmetric algorithms are mostly used for
   signing messages.

=3D=3D>

Symmetric algorithms are used=
 for encryption
   of content and data integrity whereas the asymmetric algorithms are most=
ly used for
   signing messages and managing symmetric keys.

<= /div>
19) Section 9.4: Please expand this discussion to cover compromised trust a= nchors and compromised intermediate CAs.


MP: will file an issue to add this.

20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, whic= h tells how to make a device certificate that never expires.


MP: will add a sentence to indicate th= is possibility.

"
TEE device certificates are exp=
ected to be long lived, longer than
   the lifetime of a device."

=3D=3D>

"TEE devic=
e certificates are expected to be long lived, longer than
   the lifetime of a device. They can be certificates that never expire    as defined in the Section 4.1.2.5 of RFC 5280."
<= br>
21) Please add references for SGX and TrustZone, adding the citations in th= e body as appropriate.


MP: will add.

22) Nits:


MP: will fix these below. Thank you ve= ry much for these detailed comments, suggestions, and nits.
=
Section 3.1: s/trust about the hosting device/trust in the hosting device/<= br>
Section 3.1: s/unlocking the phone/unlocking the device/

Section 4.1: s/certificate/certificate [RFC5280]/

Section 4.2: s/Rich Execution Environment/REE/ (several places)

Section 4.5: s/and TA signer verification/and TA signature verification/
Section 4.5: s/nnetwork/network/

Section 5: s/chains up to some CA/chains up to some trust anchor/

Section 5: s/Figure 4: Keys/Figure 4: Signature Keys/

Section 7: s/different standards for/require different degrees of confidenc= e in/

Section 8, sentence 1: s/algorithm suite/cryptographic algorithm suite/

Section 9.8: s/public key of the TEE that it can use to encrypt/public key = of the TEE to establish a symmetric key for encryption/

_______________________________________________
TEEP mailing list
TEEP@ietf.org
https://clicktime.symantec.com/3AXrEd5omjpFtMENR4Ssz2L7Vc?u= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
--00000000000047faac05a3c9b3ae-- --000000000000515e4605a3c9b33c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQRQYJKoZIhvcNAQcCoIIQNjCCEDICAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg2aMIIE6DCCA9CgAwIBAgIOSBtqCRO9gCTKXSLwFPMwDQYJKoZIhvcNAQELBQAwTDEgMB4GA1UE CxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMT Ckdsb2JhbFNpZ24wHhcNMTYwNjE1MDAwMDAwWhcNMjQwNjE1MDAwMDAwWjBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tpZok2X9LAHsYqMNVL+Ly6RDkaKar7GD8rVtb9nw6tzPFnvXGeOEA4X5xh9wjx9sScVpGR5wkTg1 fgJIXTlrGESmaqXIdPRd9YQ+Yx9xRIIIPu3Jp/bpbiZBKYDJSbr/2Xago7sb9nnfSyjTSnucUcIP ZVChn6hKneVGBI2DT9yyyD3PmCEJmEzA8Y96qT83JmVH2GaPSSbCw0C+Zj1s/zqtKUbwE5zh8uuZ p4vC019QbaIOb8cGlzgvTqGORwK0gwDYpOO6QQdg5d03WvIHwTunnJdoLrfvqUg2vOlpqJmqR+nH 9lHS+bEstsVJtZieU1Pa+3LzfA/4cT7XA/pnwwIDAQABo4IBtTCCAbEwDgYDVR0PAQH/BAQDAgEG MGoGA1UdJQRjMGEGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwkGCisGAQQBgjcUAgIGCisG AQQBgjcKAwQGCSsGAQQBgjcVBgYKKwYBBAGCNwoDDAYIKwYBBQUHAwcGCCsGAQUFBwMRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFGlygmIxZ5VEhXeRgMQENkmdewthMB8GA1UdIwQYMBaA FI/wS3+oLkUkrk1Q+mOai97i3Ru8MD4GCCsGAQUFBwEBBDIwMDAuBggrBgEFBQcwAYYiaHR0cDov L29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3Js Lmdsb2JhbHNpZ24uY29tL3Jvb3QtcjMuY3JsMGcGA1UdIARgMF4wCwYJKwYBBAGgMgEoMAwGCisG AQQBoDIBKAowQQYJKwYBBAGgMgFfMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNp Z24uY29tL3JlcG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQConc0yzHxn4gtQ16VccKNm4iXv 6rS2UzBuhxI3XDPiwihW45O9RZXzWNgVcUzz5IKJFL7+pcxHvesGVII+5r++9eqI9XnEKCILjHr2 DgvjKq5Jmg6bwifybLYbVUoBthnhaFB0WLwSRRhPrt5eGxMw51UmNICi/hSKBKsHhGFSEaJQALZy 4HL0EWduE6ILYAjX6BSXRDtHFeUPddb46f5Hf5rzITGLsn9BIpoOVrgS878O4JnfUWQi29yBfn75 HajifFvPC+uqn+rcVnvrpLgsLOYG/64kWX/FRH8+mhVe+mcSX3xsUpcxK9q9vLTVtroU/yJUmEC4 OcH5dQsbHBqjMIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNV BAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5BngiFvXAg7aE yiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X17YUhhB5 uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmmKPZpO/bL yCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hpsk+QLjJg 6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7DWzgVGkW qQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBLQNvAUKr+ yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25sbwMpjjM5 RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV3XpYKBov Hd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyrVQ4PkX42 68NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E7gUJTb0o 2HLO02JQZR7rkpeDMdmztcpHWD9fMIIFRzCCBC+gAwIBAgIMJplVpW1Hq+2ySMVcMA0GCSqGSIb3 DQEBCwUAMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMwHhcNMjAwMjIxMTM1 NjQ5WhcNMjMwMjIxMTM1NjQ5WjCBkDELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5hdGFrYTES MBAGA1UEBxMJQmFuZ2Fsb3JlMRYwFAYDVQQKEw1Ccm9hZGNvbSBJbmMuMRYwFAYDVQQDEw1NaW5n bGlhbmcgUGVpMSkwJwYJKoZIhvcNAQkBFhptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALnj+oLejidhAhfIueq2R6kYf0xTddM81r4s9meY /vZiDe5epFRqRGhg8qsgW+LX2vtv5qe0r507+X2VQsqdL1dSQx8M0kMLqddYl9s9fYj12Qz191+J BI196cW/js96aA0aHpvT2jHIZ8n1+L0r9g4uKFt+VV1Z6ZfECZlMC8EZtCv8KXfBfH2dFJ10k+Qg dV+/KUMC2CYgdiIOynoP5Y9FQTcMM0dg8ToVGkdb7gqODxvU8zKuzBF7AY4YdNs03WCZAa5I+84n DiOJCQwyp+y3WJ7BkQq96LxuuJNS6X0YMhujGmUCdlc4BCX9O+8ICz/jTWGhpq+BLGt4hakkdTEC AwEAAaOCAdEwggHNMA4GA1UdDwEB/wQEAwIFoDCBngYIKwYBBQUHAQEEgZEwgY4wTQYIKwYBBQUH MAKGQWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMnNo YTJnM29jc3AuY3J0MD0GCCsGAQUFBzABhjFodHRwOi8vb2NzcDIuZ2xvYmFsc2lnbi5jb20vZ3Nw ZXJzb25hbHNpZ24yc2hhMmczME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIB FiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hh MmczLmNybDAlBgNVHREEHjAcgRptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTATBgNVHSUEDDAK BggrBgEFBQcDBDAfBgNVHSMEGDAWgBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAdBgNVHQ4EFgQUpStv 0AghsERl1TBx5BXhBfzYSicwDQYJKoZIhvcNAQELBQADggEBAFfbbvFJ0WbPYEGcnklrQKfu9s9k KNImqVdomu0FZ6RxOMLGXBmxRTY4Qy0K4rFKkQ+aYT2iWIBBZrHYs6b+xbLAusU8U4WaO+twZeDC IbMNGJ0PCCHe9IYMy1oOK1M7YqufFR3ZGom/ElDbPPBeBt5P6IfZmm+maiU3vOjI15ZIItZKbBlO O6xVaIUhmfNI6jeHo9qRM2JD+PFUDysuPBEI+udCfjCF1jOP+coa/xLFckMJAhHZw8jJGn1Ja1CC p23PR6TUH/Lxkcj5Y+oyx5sGusPp4jW30ONNtGo5+v6UavWPW4/0LMVJGma3LEJ29R18FOu9Fe/s 1NCEczpRDycxggJvMIICawIBATBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0g RzMCDCaZVaVtR6vtskjFXDANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgWAFyMDuT 32hxaizJkaRxEv3bQ3/7hF4bSZWNQB7Amc4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMjAwNDIxMDkzMjU1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG 9w0BAQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAI+33lde4but+ek++1c93Hh0ETMj McqChdPBRl/wRZK+VEl3FKexfxyLYgLXqRpe+0zpL+n7NxSX9bhU7CdWyydn9cwrOsnB6EbkeWZa 0fbW76OivJPvHpMI13F2FMu+5YLtvc+9uGjDQZ1+w+KrqZvODVJuhLNfcJERngjo9cGW+uePWPhd KpkQoJkDYVHyIv056yoofMgHSCP/hQL9nRxb/L5ZuM8LnlS8jqICqcmgO2ss5nnF6M6vwZ3vNbXp yleVKdGX246DDhePksQzvs8MSD1yvNva+PPLvtIbd/ophnAdtLuKQmZCLi5W00bedVkm7UpapJfk WB+xYXthjv0= --000000000000515e4605a3c9b33c-- From nobody Tue Apr 21 07:46:54 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 712923A0415 for ; Tue, 21 Apr 2020 07:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=XtPEOme3; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=XtPEOme3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtptgpKEi4tu for ; Tue, 21 Apr 2020 07:46:47 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on0626.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::626]) (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 34F673A0405 for ; Tue, 21 Apr 2020 07:46:34 -0700 (PDT) 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=Ba9s4Bibv/RpBCuMMiXM0XEHU8L4mhR/1Dsh4Jf9uYU=; b=XtPEOme3JRv8TT6LO/ZnIMiaFP0v3p8WHitQD2upCJwjM9UtZriScedDNTp+pRHYJv755kZcCWJEllBj0ccW9XCiT4ZAoP+eWnjxh6BgrlskMeigIHk4Iw3ZabuOCD9LFtZeRwumPx4/rtxTDyp/6YpQ272LXAwxOzPHP+fEYpY= Received: from AM0PR10CA0027.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:17c::37) by VI1PR0802MB2144.eurprd08.prod.outlook.com (2603:10a6:800:a3::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Tue, 21 Apr 2020 14:45:54 +0000 Received: from AM5EUR03FT007.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:17c:cafe::a2) by AM0PR10CA0027.outlook.office365.com (2603:10a6:208:17c::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Tue, 21 Apr 2020 14:45:54 +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 AM5EUR03FT007.mail.protection.outlook.com (10.152.16.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Tue, 21 Apr 2020 14:45:54 +0000 Received: ("Tessian outbound d63670e9da8f:v53"); Tue, 21 Apr 2020 14:45:54 +0000 X-CR-MTA-TID: 64aa7808 Received: from d0ec7d409e5b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 4462C321-2238-444E-8B3B-64984353BECC.1; Tue, 21 Apr 2020 14:45:48 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d0ec7d409e5b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 21 Apr 2020 14:45:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZZBTrNnWIRGEfqkhxIGIGwegIJiGvYH6j9x2DOoS9tSCidR3Hc5eZADI82XXiaKbS/LHN9B0qvdkpemmgSmkrJ9HySyWIzDzjCFYjpxDTapSrYFeSKUdlHpsQubIVFOw/tyI0gXH4qgnbjfb+stjYacqSOWze46sRiwU+qnrngJFpNJHAwFjdm99dC5qLsWCI4MC2mKHuz+/FcogRPMFpgluflDzZaZkz5eTtZtdaHi537SXofAf19ACL9Uz45fJCZ+rI4tyP0/9lN2UOO8zGpBLzQBnqvd9kVMQsSO7D6H8ITWddFfdJEowqBNI6xgsQMaQvzjVxMMibNH6fVQNlg== 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=Ba9s4Bibv/RpBCuMMiXM0XEHU8L4mhR/1Dsh4Jf9uYU=; b=AItho+AYR78LXwKHwMOZfhtPvVf3yOJpZXXRseWPk940yGfIWGUN/5Xzbh3pLFMy53IUjDPtxkKcIA1cZi9wCxphtFnj39JON4tEtoijuSO3UdOLHLHC7gCby77wJoYeJTsv8E6dzksfcpKf3MmqGv7XOsmJaTnwHewgr96ycgg/pF/zuWsCX7P/Z4r2aTR04xt+M1J6wN7ZfF3j2lS0d5jk+6/CjHO1EmAa9ax9aljEcpIImnZfpBTz1rdpDPcVyBF+WL0DzU5yd5wRf8GTm7A5B2ZBYVuLvj5+GaQMEpSgxphvUHrXz/Lahgrni/n5E7c6csJJiV9cHmE9n/BxAw== 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=Ba9s4Bibv/RpBCuMMiXM0XEHU8L4mhR/1Dsh4Jf9uYU=; b=XtPEOme3JRv8TT6LO/ZnIMiaFP0v3p8WHitQD2upCJwjM9UtZriScedDNTp+pRHYJv755kZcCWJEllBj0ccW9XCiT4ZAoP+eWnjxh6BgrlskMeigIHk4Iw3ZabuOCD9LFtZeRwumPx4/rtxTDyp/6YpQ272LXAwxOzPHP+fEYpY= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4178.eurprd08.prod.outlook.com (2603:10a6:208:133::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Tue, 21 Apr 2020 14:45:47 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee%6]) with mapi id 15.20.2921.030; Tue, 21 Apr 2020 14:45:47 +0000 From: Hannes Tschofenig To: Russ Housley , teep Thread-Topic: [Teep] Review of draft-ietf-teep-architecture-08 Thread-Index: AQHWFPgF+4V7s+hm5EGip0UBtF6t6KiDh6bw Date: Tue, 21 Apr 2020 14:45:47 +0000 Message-ID: References: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> In-Reply-To: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 77a70ade-ba86-4b8e-9afe-9b014bc73aa5.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0231dea8-8232-4adb-9163-08d7e602b1a1 x-ms-traffictypediagnostic: AM0PR08MB4178:|VI1PR0802MB2144: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:1013;OLM:2449; x-forefront-prvs: 038002787A X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(376002)(396003)(39860400002)(366004)(136003)(71200400001)(9686003)(5660300002)(55016002)(86362001)(8676002)(81156014)(8936002)(2906002)(33656002)(66574012)(110136005)(7696005)(64756008)(66476007)(6506007)(53546011)(316002)(26005)(186003)(966005)(478600001)(76116006)(66446008)(52536014)(66556008)(66946007); DIR:OUT; SFP:1101; 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: YvPt/lJSaodYb23ncxDpeP6qrUZvdwnYemTkx2Z/c5oIS8MNDJ+wdQS01CAyyOzfbX8kmdc7N248oJSN5Q9M7h+fZ8Tx5HUN89I1WGYXFylVaCe9mYzp2dULEThUHYr0xA8OjR5jMxfACoXvnMjq0aiJVj0BXzHxevrwlE4KSfTVTzC0cb5V/ZCypa8WI7ATdey2tUz4r5SLy7OkQisD1pEyl3uugAFw88xgHe/5Bftj3xW9qfh0SFw7NSTpRWfQ3gD+BWk7Hrj5BSJpaevGiLN5BQ3N43FeKnnTuDzNo+a37tJQuCRAX+2p2HvVapACUynsUxI8x6DSr3hXH1OPnUxyLt+vhqecRiULa4N1+5C7dnnG/4p636o0WdYl6XiNDIAoTfMtyjX3U2MV1Rmca7AfJSr22ZLotx6owt6r31IZ5NHWHZqUuwK3z4VN8O1r+iy4302/w6xLVVrGebTEJkgyyVj0mDmLVVmLYJmaIkzYTc6MOWWVFIX7Dq+xdObfvCn2OSHFK5dVNMWfpjngyA== x-ms-exchange-antispam-messagedata: SR4Lb1TRvGogd/E4ckq7wnr7XtmKHmlzSDhLItpUSQTVekrOXhV/yyEhzoEnCrcYw2hjLQ6I48V5OV5IHCtLlO7FLuHfdfuOgfYDeu2LUd/Fa+J2mMgay7IxHl43xpIpQuzHTU1N8af+Q0j/VLtWcg== 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: AM0PR08MB4178 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT007.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(396003)(346002)(376002)(46966005)(86362001)(82740400003)(52536014)(33656002)(55016002)(47076004)(9686003)(81166007)(70586007)(70206006)(186003)(336012)(26005)(966005)(8676002)(110136005)(36906005)(316002)(478600001)(81156014)(356005)(8936002)(5660300002)(66574012)(53546011)(6506007)(2906002)(7696005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 6ca8c146-7cb6-4acb-3e6c-08d7e602adbb X-Forefront-PRVS: 038002787A X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tmeqwESOgnQ5SrpYXidY3o58qXxaNuQd9IhjmRJUtQAamNQ3pmdSk0suwSV/fcur4UUOjIDfwCS1IviiLcQN/aBJLl5LWJbFZRBU+3H8lokHVvxhyupnr2jMLU1qgon2TBfHYKR/3LbIJkoNK3vGFQYRyR77XbTLp6kkpYVYm1c5hsZCTcFFLNRJX7Kf90efSH4HbGWhMeGP1jke1mxWMaNS9gBkTXd/Agr13U6Yv12FE7SsUWClPLIs2Meyafuu5fxKfH6p7qzZH2ZwYc1Yizxv8kQaJOd5j27faBFuZPiHq5pUzZzKT22sHLv8CBmOgSsMSEzJKQlDfSVLF6DipTQg5yQl47Bt9Zhq+2QynIH4gePYF3TH/qwdM9rBd14i+3XPi6OIPI/oeX7Ih7i/Wt94OUKB6N0fQCiGLWd3hcm9JDmPg8c0JhxivoYV7FlMNv5ItY3+rthCYR8O5lkUEAIYMeaSiWUAUQSd/JUfrDB1i2kXAEs7JyqfEmc74tmBQwTaojzlZFVGChCBmilAqCQF9BUCQdK49NTTHoNgwjIvx6xNnZalxbPWNFc2o8+YWrwXFhoFl/+HMUXoHyZMeg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2020 14:45:54.0092 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0231dea8-8232-4adb-9163-08d7e602b1a1 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: VI1PR0802MB2144 Archived-At: Subject: Re: [Teep] Review of draft-ietf-teep-architecture-08 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, 21 Apr 2020 14:46:53 -0000 Hi Russ, Thanks for the detailed review. I addressed almost all of it but see my res= ponse below. Ming/DaveW/DaveT - there are also some items for you... -----Original Message----- From: TEEP On Behalf Of Russ Housley Sent: Friday, April 17, 2020 10:34 PM To: teep Subject: [Teep] Review of draft-ietf-teep-architecture-08 On the last TEEP call, I agreed to review the TEEP Architecture document. = Here are my comments and questions. 1) Section 1 says: Typically, application components are chosen to execute inside a TEE because those application components perform security sensitive operations or operate on sensitive data. Recognizing that this is the introduction, I was wondering if you could pro= vide a bit more explanation here. Earlier in the paragraph, the document o= ffers an example of a banking application. There would be components of su= ch and application that are trusted, and other components would be untruste= d. This concept is described, but the coupling to make a complete applicati= on could be more explicit to prepare the reader for the detail that is comi= ng. Within such an application, it would be good to offer an example of a = security sensitive operations and a separate example of operating on sensit= ive data. [Hannes] Here is the PR: https://github.com/ietf-teep/architecture/pull/162 2) Section 1 says: To simplify the life of TA developers interacting with TAs in a TEE, an interoperable protocol for managing TAs running in different TEEs of various devices is needed. This feels incomplete to me. Making sure that compatible trusted and untru= sted components of an application are installed on the same device is vital= when they are not bundled. [Hannes] Fair enough. I created a PR on this topic as well: https://github.com/ietf-teep/architecture/pull/163 3) Section 1 offers: - A TA developer wants to remove a confidential TA from a device's TEE if the TA developer is no longer offering such TAs or the TAs are being revoked from a particular user (or device). For example, if a subscription or contract for a particular service has expired, or a payment by the user has not been completed or has been rescinded. This implies that the TA developer has some of the privileges that I associ= ate with the TAM. Yes, I see the note at the end of the bullets, but I thi= nk this is an indication that the privileges are not quite right for these = roles. Also, if I was writing a TA for a subscription, I would have the TA= perform some form of payment checking, and then refuse to decrypt the cont= ent if the payment checking fails. Perhaps the REE passes a signed proof o= f payment. This way, the TA developer does not need to actually have permi= ssion to remove a TA. Further, if the TA is on a multi-user device, removin= g the TA would adversely impact other users. [Hannes] I agree with you. This sounds a bit strange. I have changed the wo= rding to: - A Device Administrator wants to remove a TA from a device's TEE if the TA developer is no longer maintaining that TA, when the TA has been revoked or is not used for other reasons anymore (e.g. due to an expired subscription). The PR is: https://github.com/ietf-teep/architecture/pull/163 4) Section 2 says: - Untrusted Application: An application running in a Rich Execution Environment. For alignment with the definition of a TA and te terms used in section 1, I= think this should say: - Untrusted Application: An application component that runs in a REE. It is also useful to indicate that the Untrusted Application may be depende= nt on one or more TAs. [Hannes] Sounds useful to me. PR is here: https://github.com/ietf-teep/architecture/pull/164 5) Section 3.3 talks about the Internet of Things. It does not talk about = the billions of devices being used to mount DDoS attacks. Can it cover tha= t too? Without putting the network interface inside the TEE, I'm skeptical= there is a solution. [Hannes] The DDoS attacks you are referring to were caused by default passw= ords on those devices. A TEE cannot help with that directly. You can, of co= urse, put per-device credentials and isolate them better using the TEE. The= problem with the DDoS attacks of these IP-based cameras wasn't the lack of= isolation of software but the fact that all devices used the same credenti= als and that those credentials were public. I am not sure what I could writ= e to talk about these use cases without making too many assumptions. 6) Section 3.4 talks about Confidential Cloud Computing. Can something be = said in Section 4.4.1 to make this less abstract? [Hannes] This is a question for DaveT. Maybe there is some text that could = be copied from the CCC. 7) Section 4.1 defines CA incorrectly. A CA is not "Certificate-based cred= entials". A CA issues certificates, and the certificates are then used for= authentication and cryptographic key management. This bullet should begin= : "A CA is ..." to follow the pattern of the other bullets. [Hannes] Stupid mistake. Here is the PR: https://github.com/ietf-teep/architecture/pull/165 8) Section 4.3 introduces the term "TA software author" and "TA signer." I= hope we ca pick one. Please add the term that is chosen to Section 2. [Hannes] Good catch. I have expanded the text for the TA developer in the i= ntro section and have also removed the terms "TA software author" and "TA s= igner" with the term "TA developer". 9) Section 4.4 should require support for both confidentiality and integrit= y protection. [Hannes] Of course. I correct it. Here is the Pr: https://github.com/ietf-teep/architecture/pull/165 10) Should GlobalPlatform be added to Section 4.4.1? [Hannes] GlobalPlatform defined APIs that simplify the experience of develo= pers when need to pass information between the Untrusted App and the TA (an= d also for the TA to access secure world OS features). I could add text but= I am wondering whether this would go a bit too far. 11) Section 4.5 uses the term "TA binary signers" and "TA signer". Please = see comment 8 above. [Hannes] I hope I removed all occurrences. 12) Section 5 says: "... encrypted with the TAM public key ...". This is n= ot correct. The TAM public key is used to establish the key that is then u= sed for encryption and decryption. Further the wording is aimed at RSA, wh= ich is a key transport algorithm. Please make the wording accommodate key = transport and key agreement approaches. [Hannes] I changed the text in this PR but I wanted to note that we don't w= ant to go into the details on how the encryption works because the details,= as you point out, vary a bit from mechanism to mechanism. PR: https://github.com/ietf-teep/architecture/pull/166 13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; howe= ver, Section 1 said that a trust anchor could be a raw public key. Can the= TAM use the raw trust anchor key directly? [Hannes] I enhanced that sentence. 14) Section 5.2 and Section 5.3 should allow signatures to be directly by t= he trust anchor. The current working requires a certification path. [Hannes] I have updated the text but have a look whether I captured everyth= ing. Here is the PR: https://github.com/ietf-teep/architecture/pull/166 15) Section 5.4 says that "self-signed certificates" are allowed. I think = this is the same as allowing signatures to be directly by the trust anchor.= Please consider this comment in conjunction with comment 13 above. [Hannes] I removed it because I don't think that self-signed certificates r= eally make sense given what we described elsewhere. 16) Section 7 says that there are "different attestation algorithms". Does= this mean different set of claims? Please be more clear here. [Hannes] The idea was to be flexible with regards to attestation schemes, l= ike ECDSA-based attestation, Direct Anonymous Attestation (DAA), Enhanced P= rivacy ID (EPID), a Privacy CA, etc. With our decision to support EAT token= s I believe we pushed the responsibility over to RATS. I still added a few examples: https://github.com/ietf-teep/architecture/pull/167 17) I think the discussion about "assumptions" would be better written as t= hings that need to be considered when assessing the degree of confidence in= the claim by the TEE, [Hannes] @DaveW: Can you take care of this? I believe you wrote that sectio= n. 18) Section 18: Asymmetric algorithms are also used to manage the symmetric= keys. Symmetric algorithms are also used for data integrity. [Hannes] I added a remark on this topic in this PR: https://github.com/ietf-teep/architecture/pull/168 19) Section 9.4: Please expand this discussion to cover compromised trust a= nchors and compromised intermediate CAs. [Hannes] @Ming: Can I push this to you? I believe you wrote that text. 20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, whic= h tells how to make a device certificate that never expires. [Hannes] Good idea. Here is the PR: https://github.com/ietf-teep/architecture/pull/168 21) Please add references for SGX and TrustZone, adding the citations in th= e body as appropriate. [Hannes] DaveT/DaveW: What reference should I use for SGX? 22) Nits: I covered the nits below in the following PR: https://github.com/ietf-teep/architecture/pull/169 Ciao Hannes 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 Tue Apr 21 09:53: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 2BB603A0DAE for ; Tue, 21 Apr 2020 09:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Awej5EjEr0S2 for ; Tue, 21 Apr 2020 09:52:58 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BAE43A1108 for ; Tue, 21 Apr 2020 09:49:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6EE65300B56 for ; Tue, 21 Apr 2020 12:49:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XfFG9dDZgq2C for ; Tue, 21 Apr 2020 12:48:57 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 406BF300AAF; Tue, 21 Apr 2020 12:48:57 -0400 (EDT) From: Russ Housley Message-Id: <0350DFEB-D900-4246-B2AC-A605BA609509@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8CEC22D3-F03C-410F-9F13-7B97ACEB0ACE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Tue, 21 Apr 2020 12:48:58 -0400 In-Reply-To: Cc: teep To: Mingliang Pei References: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Teep] Review of draft-ietf-teep-architecture-08 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, 21 Apr 2020 16:53:03 -0000 --Apple-Mail=_8CEC22D3-F03C-410F-9F13-7B97ACEB0ACE Content-Type: multipart/alternative; boundary="Apple-Mail=_007981EF-0B89-4435-9819-8D1651B7EF9C" --Apple-Mail=_007981EF-0B89-4435-9819-8D1651B7EF9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 21, 2020, at 5:32 AM, Mingliang Pei = wrote: >=20 > Hi Russ, >=20 > Thank you very much for your detailed review, suggestions and nits. = Please see inline. Best, >=20 > Ming >=20 >=20 > On Fri, Apr 17, 2020 at 1:37 PM Russ Housley > wrote: > On the last TEEP call, I agreed to review the TEEP Architecture = document. Here are my comments and questions. >=20 > 1) Section 1 says: >=20 > Typically, application components are chosen to execute inside a = TEE > because those application components perform security sensitive > operations or operate on sensitive data. >=20 > Recognizing that this is the introduction, I was wondering if you = could provide a bit more explanation here. Earlier in the paragraph, = the document offers an example of a banking application. There would be = components of such and application that are trusted, and other = components would be untrusted. This concept is described, but the = coupling to make a complete application could be more explicit to = prepare the reader for the detail that is coming. Within such an = application, it would be good to offer an example of a security = sensitive operations and a separate example of operating on sensitive = data. >=20 > MP: we will provide two examples as you suggested. We will file this = in issue tracker for a fix. >=20 >=20 > 2) Section 1 says: >=20 > To simplify the life of TA developers interacting with TAs in a = TEE, > an interoperable protocol for managing TAs running in different = TEEs > of various devices is needed. >=20 > This feels incomplete to me. Making sure that compatible trusted and = untrusted components of an application are installed on the same device = is vital when they are not bundled. >=20 >=20 > MP: how about the following? >=20 > To simplify the life of TA developers interacting with TAs in a = TEE, > an interoperable protocol for managing TAs running in different = TEEs > of various devices is needed in order for an untrusted application = to use. I think this is a big improvement. >=20 > 3) Section 1 offers: >=20 > - A TA developer wants to remove a confidential TA from a device's > TEE if the TA developer is no longer offering such TAs or the = TAs > are being revoked from a particular user (or device). For > example, if a subscription or contract for a particular service > has expired, or a payment by the user has not been completed or > has been rescinded. >=20 > This implies that the TA developer has some of the privileges that I = associate with the TAM. Yes, I see the note at the end of the bullets, = but I think this is an indication that the privileges are not quite = right for these roles. Also, if I was writing a TA for a subscription, = I would have the TA perform some form of payment checking, and then = refuse to decrypt the content if the payment checking fails. Perhaps = the REE passes a signed proof of payment. This way, the TA developer = does not need to actually have permission to remove a TA. Further, if = the TA is on a multi-user device, removing the TA would adversely impact = other users. >=20 >=20 > MP: the subscription example doesn't fully need TA removal as you = said. The first half about a "revoked TA" still calls for the help of = TAM. I think we can remove the subscription sentence. A TA could be = revoked because it is compromised, or not offered anymore. Regarding the = impact on multi-user devices, a TA is shared. A revoked TA use case = should apply to all users, which will not have the concern you = mentioned. Is this good? I think we need to think about it from the TEE perspective. We should = say what would cause the TEE to delete a TA. >=20 > 4) Section 2 says: >=20 > - Untrusted Application: An application running in a Rich = Execution > Environment. >=20 > For alignment with the definition of a TA and te terms used in section = 1, I think this should say: >=20 > - Untrusted Application: An application component that runs in a > REE. >=20 > It is also useful to indicate that the Untrusted Application may be = dependent on one or more TAs. >=20 >=20 > MP: Agree on the additional line. Not sure about changing = "application" to "component". An untrusted application intends to mean a = regular client application. Trusted application is an independent = application; we don't require that the two are strongly tied. Multiple = untrusted applications can call the same trusted application. A TA is an "application component", so the Untrusted Application is also = an "application component", right? If not pick another term for both = definitions. >=20 > 5) Section 3.3 talks about the Internet of Things. It does not talk = about the billions of devices being used to mount DDoS attacks. Can it = cover that too? Without putting the network interface inside the TEE, = I'm skeptical there is a solution. >=20 >=20 > MP: DDoS attack utilized insecure design that was triggered to send = queries. If all apps are inside TEE, those apps won't be misused. But = not sure the entire IoT can just use TEE that can still provide a = network interface as you mentioned. I'm not sure what you are proposing to say in the document about DDoS. >=20 > 6) Section 3.4 talks about Confidential Cloud Computing. Can = something be said in Section 4.4.1 to make this less abstract? >=20 >=20 > MP: will work with co-authors on some text for review. >=20 > 7) Section 4.1 defines CA incorrectly. A CA is not "Certificate-based = credentials". A CA issues certificates, and the certificates are then = used for authentication and cryptographic key management. This bullet = should begin: "A CA is ..." to follow the pattern of the other bullets. >=20 >=20 > MP: how about the following changes? >=20 > Certification Authority (CA): Certificate-based credentials used > for authenticating a device, a TAM and a TA developer. >=20 > To >=20 > Certification Authority (CA): A CA issues certificates that can be = used > for authenticating a device, a TAM or a TA developer. Different = CAs > may be used for issuing certificates for a device, a TAM and a = TA developer. That seems fine. >=20 >=20 > 8) Section 4.3 introduces the term "TA software author" and "TA = signer." I hope we ca pick one. Please add the term that is chosen to = Section 2. >=20 >=20 > MP: prefer to pick "TA signer". Will add definition to Section 2. Thank you. >=20 > 9) Section 4.4 should require support for both confidentiality and = integrity protection. >=20 >=20 > MP: it currently says >=20 > "Implementations must support > encryption of personalization data to preserve the confidentiality = of > potentially sensitive data contained within it." >=20 > Agreed. We should add integration protection support too. How about = the following? >=20 > "Implementations must support > encryption of personalization data to preserve the confidentiality = of > potentially sensitive data contained within it and support = integrity protection." I'm glad you added integrity protection, not "integration protection" as = you said above! >=20 > 10) Should GlobalPlatform be added to Section 4.4.1? >=20 >=20 > MP: GP TEE can be referred to in the TrustZone section. How about the = following? >=20 > "A TA is loaded by a trusted OS running in the TEE such as a = GlobalPlatform compliant TEE," This section has a paragraph about ARM and Intel TEEs. Elsewhere the = document talks about GlobalPlatform. I think it should get a paragraph = too so that the reader can compare and contrast the three TEEs. >=20 > 11) Section 4.5 uses the term "TA binary signers" and "TA signer". = Please see comment 8 above. >=20 >=20 > MP: "TA signer" >=20 > 12) Section 5 says: "... encrypted with the TAM public key ...". This = is not correct. The TAM public key is used to establish the key that is = then used for encryption and decryption. Further the wording is aimed = at RSA, which is a key transport algorithm. Please make the wording = accommodate key transport and key agreement approaches. >=20 >=20 > MP: will revise this, and file it in Github issue tracker for text = revision. >=20 > 13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; = however, Section 1 said that a trust anchor could be a raw public key.. = Can the TAM use the raw trust anchor key directly? >=20 >=20 > MP: It isn't a common case to use a fixed public key as a trusted = anchor instead of a CA certificate. How about allowing a TAM to use a = self-signed certificate? It accommodates both. That does not align with the discussion of what a trust anchor is in RFC = 5280. I think the raw key needs to be allowed, even it if is not the = most popular choice in current implementations. For example, TLS did = not originally allow raw public keys, but it was added later. Here, all = of the foundational specifications already allow it, so I do not think = it is wise to prohibit raw public keys. >=20 > 14) Section 5.2 and Section 5.3 should allow signatures to be directly = by the trust anchor. The current working requires a certification path. >=20 >=20 > MP: we assume that signer and the intermediate CAs up to the trust = anchor but not include a trust anchor are sent in a signature payload. = This can establish a certificate path. Do you mean this about "directly = by the trust anchor"? We need to allow intermediate CAs. We can revise = the paragraph to elaborate on this if you agree.. No. Please look at RFC 5934. Signatures are verified by the trust = anchor itself or by the public key in a certificate that validates to = the trust anchor. >=20 > 15) Section 5.4 says that "self-signed certificates" are allowed. I = think this is the same as allowing signatures to be directly by the = trust anchor. Please consider this comment in conjunction with comment = 13 above. >=20 >=20 > MP: please see above #13 comment. >=20 > 16) Section 7 says that there are "different attestation algorithms". = Does this mean different set of claims? Please be more clear here. >=20 >=20 > MP: it currently means algorithm agility and algorithms may be = different for different devices. Different set of claims from different = algorithms from one device is possible but not necessary, I think. A = verifier is expected to support all the supported algorithms such that = it doesn't have to require different claims to get one working. >=20 > We will clarify the text. >=20 > 17) I think the discussion about "assumptions" would be better written = as things that need to be considered when assessing the degree of = confidence in the claim by the TEE, >=20 >=20 > MP: will track this as an issue to revise. >=20 > 18) Section 18: Asymmetric algorithms are also used to manage the = symmetric keys. Symmetric algorithms are also used for data integrity. >=20 >=20 > MP: will revise it to reflect both points. >=20 > Symmetric algorithms are used for encryption > of content whereas the asymmetric algorithms are mostly used for > signing messages. >=20 > =3D=3D> >=20 > Symmetric algorithms are used for encryption > of content and data integrity whereas the asymmetric algorithms are = mostly used for > signing messages and managing symmetric keys. Thanks. I think you can drop "mostly". >=20 > 19) Section 9.4: Please expand this discussion to cover compromised = trust anchors and compromised intermediate CAs. >=20 >=20 > MP: will file an issue to add this. >=20 > 20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, = which tells how to make a device certificate that never expires. >=20 >=20 > MP: will add a sentence to indicate this possibility. >=20 > " > TEE device certificates are expected to be long lived, longer than > the lifetime of a device." >=20 > =3D=3D> >=20 > "TEE device certificates are expected to be long lived, longer than > the lifetime of a device. They can be certificates that never = expire > as defined in the Section 4.1.2.5 of RFC 5280." >=20 > 21) Please add references for SGX and TrustZone, adding the citations = in the body as appropriate. >=20 >=20 > MP: will add. Russ --Apple-Mail=_007981EF-0B89-4435-9819-8D1651B7EF9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 21, 2020, at 5:32 AM, Mingliang Pei <mingliang.pei=3D40broadcom.com@dmarc.ietf.org> = wrote:

Hi = Russ,

Thank = you very much for your detailed review, suggestions and nits. Please see = inline. Best,

Ming


On Fri, Apr 17, 2020 at 1:37 PM Russ = Housley <housley@vigilsec.com> wrote:
On the last TEEP call, I agreed to = review the TEEP Architecture document.  Here are my comments and = questions.

1) Section 1 says:

   Typically, application components are chosen to execute = inside a TEE
   because those application components perform security = sensitive
   operations or operate on sensitive data.

Recognizing that this is the introduction, I was wondering if you could = provide a bit more explanation here.  Earlier in the paragraph, the = document offers an example of a banking application.  There would = be components of such and application that are trusted, and other = components would be untrusted. This concept is described, but the = coupling to make a complete application could be more explicit to = prepare the reader for the detail that is coming.  Within such an = application, it would be good to offer an example of a security = sensitive operations and a separate example of operating on sensitive = data.

MP: we will provide two examples as you suggested. We will = file this in issue tracker for a fix.
=

2) Section 1 says:

   To simplify the life of TA developers interacting with TAs = in a TEE,
   an interoperable protocol for managing TAs running in = different TEEs
   of various devices is needed.

This feels incomplete to me.  Making sure that compatible trusted = and untrusted components of an application are installed on the same = device is vital when they are not bundled.


MP: how about the following?

   To simplify the life of TA = developers interacting with TAs in a TEE,
   an interoperable protocol for managing TAs running in = different TEEs
   of various devices is needed in order for an untrusted = application to use.

I think this is a big improvement.


3) Section 1 offers:

   -  A TA developer wants to remove a confidential TA = from a device's
      TEE if the TA developer is no longer offering such = TAs or the TAs
      are being revoked from a particular user (or = device).  For
      example, if a subscription or contract for a = particular service
      has expired, or a payment by the user has not been = completed or
      has been rescinded.

This implies that the TA developer has some of the privileges that I = associate with the TAM.  Yes, I see the note at the end of the = bullets, but I think this is an indication that the privileges are not = quite right for these roles.  Also, if I was writing a TA for a = subscription, I would have the TA perform some form of payment checking, = and then refuse to decrypt the content if the payment checking = fails.  Perhaps the REE passes a signed proof of payment.  = This way, the TA developer does not need to actually have permission to = remove a TA. Further, if the TA is on a multi-user device, removing the = TA would adversely impact other users.


MP: the subscription example doesn't fully need TA removal as = you said. The first half about a "revoked TA" still calls for the help = of TAM. I think we can remove the subscription sentence. A TA could be = revoked because it is compromised, or not offered anymore. Regarding the = impact on multi-user devices, a TA is shared. A revoked TA use case = should apply to all users, which will not have the concern you = mentioned. Is this good?

I think we need to think about it from the TEE = perspective.  We should say what would cause the TEE to delete a = TA.


4) Section 2 says:

   -  Untrusted Application: An application running in a = Rich Execution
      Environment.

For alignment with the definition of a TA and te terms used in section = 1, I think this should say:

   -  Untrusted Application: An application component = that runs in a
      REE.

It is also useful to indicate that the Untrusted Application may be = dependent on one or more TAs.


MP: Agree on the additional line. Not sure about changing = "application" to "component". An untrusted application intends to mean a = regular client application. Trusted application is an independent = application; we don't require that the two are strongly tied. Multiple = untrusted applications can call the same trusted application.

A TA is an "application component", so the Untrusted = Application is also an "application component", right?  If not pick = another term for both definitions.


5) Section 3.3 talks about the Internet of Things.  It does not = talk about the billions of devices being used to mount DDoS = attacks.  Can it cover that too?  Without putting the network = interface inside the TEE, I'm skeptical there is a solution.


MP: DDoS attack utilized insecure design that was triggered = to send queries. If all apps are inside TEE, those apps won't be = misused. But not sure the entire IoT can just use TEE that can still = provide a network interface as you mentioned.

I'm not sure what you are proposing to say in the = document about DDoS.


6) Section 3.4 talks about Confidential Cloud Computing.  Can = something be said in Section 4.4.1 to make this less abstract?


MP: will work with co-authors on some text for review.

7) Section 4.1 defines CA incorrectly.  A CA is not = "Certificate-based credentials".  A CA issues certificates, and the = certificates are then used for authentication and cryptographic key = management.  This bullet should begin: "A CA is ..." to follow the = pattern of the other bullets.


MP: how about the following changes?

Certification Authority (CA): Certificate-based credentials used
      for authenticating a device, a TAM and a TA developer.

To

Certification =
Authority (CA): A CA issues certificates that can be used
      for authenticating a device, a TAM or a TA developer. Different =
CAs
      may be =
used for issuing certificates for a device, a TAM and a TA developer.

That seems fine.



8) Section 4.3 introduces the term "TA software author" and "TA = signer."  I hope we ca pick one.  Please add the term that is = chosen to Section 2.


MP: prefer to pick "TA signer". Will add definition to = Section 2.

Thank you.


9) Section 4.4 should require support for both confidentiality and = integrity protection.


MP: it currently says 

   =
"Implementations must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it."

Agreed. We =
should add integration protection support too. How about the =
following?

   "Implementations must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it and support integrity =
protection."

I'm glad you added integrity protection, not = "integration protection" as you said above!


10) Should GlobalPlatform be added to Section 4.4.1?


MP: GP TEE can be referred to in the TrustZone section. How = about the following?

"A TA is loaded by a trusted OS running in the TEE such as a =
GlobalPlatform compliant =
TEE,"

This section has a paragraph about ARM and Intel TEEs. =  Elsewhere the document talks about GlobalPlatform.  I = think it should get a paragraph too so that the reader can compare and = contrast the three TEEs.


11) Section 4.5 uses the term "TA binary signers" and "TA signer".  = Please see comment 8 above.


MP: "TA signer"

12) Section 5 says: "... encrypted with the TAM public key ...".  = This is not correct.  The TAM public key is used to establish the = key that is then used for encryption and decryption.  Further the = wording is aimed at RSA, which is a key transport algorithm.  = Please make the wording accommodate key transport and key agreement = approaches.


MP: will revise this, and file it in Github issue tracker for = text revision.

13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; = however, Section 1 said that a trust anchor could be a raw public = key..  Can the TAM use the raw trust anchor key directly?


MP: It isn't a common case to use a fixed public key as a = trusted anchor instead of a CA certificate. How about allowing a TAM to = use a self-signed certificate? It accommodates both.

That does not align with the discussion of what a trust = anchor is in RFC 5280.  I think the raw key needs to be allowed, = even it if is not the most popular choice in current implementations. =  For example, TLS did not originally allow raw public keys, but it = was added later.  Here, all of the foundational specifications = already allow it, so I do not think it is wise to prohibit raw public = keys.


14) Section 5.2 and Section 5.3 should allow signatures to be directly = by the trust anchor.  The current working requires a certification = path.


MP: we assume that signer and the intermediate CAs up to the = trust anchor but not include a trust anchor are sent in a signature = payload. This can establish a certificate path. Do you mean this about = "directly by the trust anchor"? We need to allow intermediate CAs. We = can revise the paragraph to elaborate on this if you agree..

No.  Please look at RFC 5934. =  Signatures are verified by the trust anchor itself or by the = public key in a certificate that validates to the trust = anchor.


15) Section 5.4 says that "self-signed certificates" are allowed.  = I think this is the same as allowing signatures to be directly by the = trust anchor.  Please consider this comment in conjunction with = comment 13 above.


MP: please see above #13 comment.

16) Section 7 says that there are "different attestation = algorithms".  Does this mean different set of claims?  Please = be more clear here.


MP: it currently means algorithm agility and algorithms may = be different for different devices. Different set of claims from = different algorithms from one device is possible but not necessary, I = think. A verifier is expected to support all the supported algorithms = such that it doesn't have to require different claims to get one = working.

We = will clarify the text.

17) I think the discussion about "assumptions" would be better written = as things that need to be considered when assessing the degree of = confidence in the claim by the TEE,


MP: will track this as an issue to revise.

18) Section 18: Asymmetric algorithms are also used to manage the = symmetric keys.  Symmetric algorithms are also used for data = integrity.


MP: will revise it to reflect both points.

Symmetric algorithms are used =
for encryption
   of content whereas the asymmetric algorithms are mostly used for
   signing messages.

=3D=3D>

Symmetric algorithms are used for encryption
   of content and data integrity whereas the asymmetric algorithms are =
mostly used for
   signing messages and managing symmetric keys.

Thanks.  I think you can drop = "mostly".


19) Section 9.4: Please expand this discussion to cover compromised = trust anchors and compromised intermediate CAs.


MP: will file an issue to add this.

20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, = which tells how to make a device certificate that never expires.


MP: will add a sentence to indicate this = possibility.

"
TEE device certificates are expected to be long lived, longer than
   the lifetime of a device."

=3D=3D>

"TEE device certificates are expected to be =
long lived, longer than
   the lifetime of a device. They can be certificates that never expire =

   as defined in the Section 4.1.2.5 of RFC =
5280."

21) Please add references for SGX and TrustZone, adding the citations in = the body as appropriate.


MP: will add.

Russ

= --Apple-Mail=_007981EF-0B89-4435-9819-8D1651B7EF9C-- --Apple-Mail=_8CEC22D3-F03C-410F-9F13-7B97ACEB0ACE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXp8j+gAKCRCK5O7Q9ZwR y21cAJ45OFbuCpyhXeHcwJFysZhLIOG8sACg4GAWOCIGMX/leNmJ2/Oo4nYiml4= =kisx -----END PGP SIGNATURE----- --Apple-Mail=_8CEC22D3-F03C-410F-9F13-7B97ACEB0ACE-- From nobody Tue Apr 21 23:12:08 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 B733E3A00D4 for ; Tue, 21 Apr 2020 23:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=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 PyfHacEJngnh for ; Tue, 21 Apr 2020 23:12:02 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB503A00D2 for ; Tue, 21 Apr 2020 23:12:01 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id b2so987971ljp.4 for ; Tue, 21 Apr 2020 23:12:01 -0700 (PDT) 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=L9hb+8BkKjPHO6I1Pe3wQdkI616zsgfff8Fsh67Or9k=; b=Uza94hvCnEEyO6ntnml2UW4SAJsOHy86OdlFGf5DqkR4mB5INa9Jt6Ye14YgGswz7N KqkdPlkd6qiRzY8/zWjSOUW/seU9VCcrPFog9BXrWe51TEyLl9rUg7FS/sYBO3Tb0Vsi nDxWJz0MLtVS/jHE8qyfJPnl8uUjoieWxSc6o= 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=L9hb+8BkKjPHO6I1Pe3wQdkI616zsgfff8Fsh67Or9k=; b=Igx0eu3rC7gxQMDKuXZQj2ofgs9tLDS6weOvJKqtp3XzWMzBzMiV1NXsE7jbwRWXcA MBo8dml7eYEdUDsVQJ6G/mfGVgxaaUPMkOEh1tYiLh0erV1gd0F7eVWbohL4P7skwjn2 tJp8qImQtvMdI5KOT+W8LlVKXQkcZ9aaQuIfRV7rFiDvG9VGbrh5tBea6XpfApLUd0tc MT3Yzo0QFOH1k1qA1dOwd4tXZ3UNfV3it/sesvXoPcU0ThuddlOKh17PAkoHryo3VSk/ 3Z14RczXS/OsjI6blZfPquTP087n6JJZull5NL5uBWtnmOnBP8s05LHb/k030ioz/gZe 9fpw== X-Gm-Message-State: AGi0PuYR+o2ewnT4zKi1fiBmZ/6MW67ttB76bwXq38lx2kkhABSPG2be s4iJ1rWQz5bMb1mo8Ga1KFgfKFOg33Bx+4PQBkKrJDUWwgw= X-Google-Smtp-Source: APiQypJQZLAY7fTAxDZPIdqtPr1KfMB2/QZhDe0ei+9HULp+v3EtZ8dzjhGEJaUpssOx8tneLFW0F/bpzVc4WnsGE3I= X-Received: by 2002:a2e:9b0f:: with SMTP id u15mr808619lji.272.1587535919531; Tue, 21 Apr 2020 23:11:59 -0700 (PDT) MIME-Version: 1.0 References: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> <0350DFEB-D900-4246-B2AC-A605BA609509@vigilsec.com> In-Reply-To: <0350DFEB-D900-4246-B2AC-A605BA609509@vigilsec.com> From: Mingliang Pei Date: Tue, 21 Apr 2020 23:11:48 -0700 Message-ID: To: Russ Housley Cc: teep Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000093291005a3db0278" Archived-At: Subject: Re: [Teep] Review of draft-ietf-teep-architecture-08 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 Apr 2020 06:12:06 -0000 --00000000000093291005a3db0278 Content-Type: multipart/alternative; boundary="0000000000008d90fe05a3db02fd" --0000000000008d90fe05a3db02fd Content-Type: text/plain; charset="UTF-8" Hi Russ, thank you for your replies. Please see inline. BTW, I have filed the agreed ones or ones needing revision in the github issue section. Best, Ming On Tue, Apr 21, 2020 at 9:53 AM Russ Housley wrote: > > > On Apr 21, 2020, at 5:32 AM, Mingliang Pei < > mingliang.pei=40broadcom.com@dmarc.ietf.org> wrote: > > Hi Russ, > > Thank you very much for your detailed review, suggestions and nits. Please > see inline. Best, > > Ming > > > On Fri, Apr 17, 2020 at 1:37 PM Russ Housley wrote: > >> On the last TEEP call, I agreed to review the TEEP Architecture >> document. Here are my comments and questions. >> >> 1) Section 1 says: >> >> Typically, application components are chosen to execute inside a TEE >> because those application components perform security sensitive >> operations or operate on sensitive data. >> >> Recognizing that this is the introduction, I was wondering if you could >> provide a bit more explanation here. Earlier in the paragraph, the >> document offers an example of a banking application. There would be >> components of such and application that are trusted, and other components >> would be untrusted. This concept is described, but the coupling to make a >> complete application could be more explicit to prepare the reader for the >> detail that is coming. Within such an application, it would be good to >> offer an example of a security sensitive operations and a separate example >> of operating on sensitive data. >> > > MP: we will provide two examples as you suggested. We will file this in > issue tracker for a fix. > > >> 2) Section 1 says: >> >> To simplify the life of TA developers interacting with TAs in a TEE, >> an interoperable protocol for managing TAs running in different TEEs >> of various devices is needed. >> >> This feels incomplete to me. Making sure that compatible trusted and >> untrusted components of an application are installed on the same device is >> vital when they are not bundled. >> >> > MP: how about the following? > > To simplify the life of TA developers interacting with TAs in a TEE, > an interoperable protocol for managing TAs running in different TEEs > of various devices is needed in order for an untrusted application to > use. > > > I think this is a big improvement. > > > 3) Section 1 offers: >> >> - A TA developer wants to remove a confidential TA from a device's >> TEE if the TA developer is no longer offering such TAs or the TAs >> are being revoked from a particular user (or device). For >> example, if a subscription or contract for a particular service >> has expired, or a payment by the user has not been completed or >> has been rescinded. >> >> This implies that the TA developer has some of the privileges that I >> associate with the TAM. Yes, I see the note at the end of the bullets, but >> I think this is an indication that the privileges are not quite right for >> these roles. Also, if I was writing a TA for a subscription, I would have >> the TA perform some form of payment checking, and then refuse to decrypt >> the content if the payment checking fails. Perhaps the REE passes a signed >> proof of payment. This way, the TA developer does not need to actually >> have permission to remove a TA. Further, if the TA is on a multi-user >> device, removing the TA would adversely impact other users. >> >> > MP: the subscription example doesn't fully need TA removal as you said. > The first half about a "revoked TA" still calls for the help of TAM. I > think we can remove the subscription sentence. A TA could be revoked > because it is compromised, or not offered anymore. Regarding the impact on > multi-user devices, a TA is shared. A revoked TA use case should apply to > all users, which will not have the concern you mentioned. Is this good? > > > I think we need to think about it from the TEE perspective. We should say > what would cause the TEE to delete a TA. > > MP: it tries to show a use case for the need of TA deletion. From a TEE perspective, it may delete a TA because of a request from a TAM. A TEEP Agent will be carrying out the deletion. I see your point about "privilege" that a developer was assumed to have. How about we revise the use case as the following? - A TA may need to be deleted from a device's TEE if the TA is compromised or the right of use of the TA is revoked from a particular user (or device). There could be cases where additional TAs should be installed that some prior TAs should be deleted to free up spaces. > 4) Section 2 says: >> >> - Untrusted Application: An application running in a Rich Execution >> Environment. >> >> For alignment with the definition of a TA and te terms used in section 1, >> I think this should say: >> >> - Untrusted Application: An application component that runs in a >> REE. >> >> It is also useful to indicate that the Untrusted Application may be >> dependent on one or more TAs. >> >> > MP: Agree on the additional line. Not sure about changing "application" to > "component". An untrusted application intends to mean a regular client > application. Trusted application is an independent application; we don't > require that the two are strongly tied. Multiple untrusted applications can > call the same trusted application. > > > A TA is an "application component", so the Untrusted Application is also > an "application component", right? If not pick another term for both > definitions. > > MP: I filed this as an issue to welcome more comments. If we call "Untrusted Application" as "application component", it looks to me that the word "application" isn't a good fit here. > 5) Section 3.3 talks about the Internet of Things. It does not talk about >> the billions of devices being used to mount DDoS attacks. Can it cover >> that too? Without putting the network interface inside the TEE, I'm >> skeptical there is a solution. >> >> > MP: DDoS attack utilized insecure design that was triggered to send > queries. If all apps are inside TEE, those apps won't be misused. But not > sure the entire IoT can just use TEE that can still provide a network > interface as you mentioned. > > > I'm not sure what you are proposing to say in the document about DDoS. > > MP: I would suggest that we say "This doesn't prevent the devices being used to mount DDoS attacks where network interfaces are mostly hosted in the untrusted REE." Does it work? Thanks. > 6) Section 3.4 talks about Confidential Cloud Computing. Can something be >> said in Section 4.4.1 to make this less abstract? >> >> > MP: will work with co-authors on some text for review. > > 7) Section 4.1 defines CA incorrectly. A CA is not "Certificate-based >> credentials". A CA issues certificates, and the certificates are then used >> for authentication and cryptographic key management. This bullet should >> begin: "A CA is ..." to follow the pattern of the other bullets. >> >> > MP: how about the following changes? > > Certification Authority (CA): Certificate-based credentials used > for authenticating a device, a TAM and a TA developer. > > To > > Certification Authority (CA): A CA issues certificates that can be used > for authenticating a device, a TAM or a TA developer. Different CAs > > may be used for issuing certificates for a device, a TAM and a TA developer. > > > That seems fine. > > Thanks. > > 8) Section 4.3 introduces the term "TA software author" and "TA signer." >> I hope we ca pick one. Please add the term that is chosen to Section 2. >> >> > MP: prefer to pick "TA signer". Will add definition to Section 2. > > > Thank you. > > > 9) Section 4.4 should require support for both confidentiality and >> integrity protection. >> >> > MP: it currently says > > "Implementations must support > encryption of personalization data to preserve the confidentiality of > potentially sensitive data contained within it." > > Agreed. We should add integration protection support too. How about the following? > > "Implementations must support > encryption of personalization data to preserve the confidentiality of > potentially sensitive data contained within it and support integrity protection." > > > I'm glad you added integrity protection, not "integration protection" as > you said above! > > MP: good catch :) > > 10) Should GlobalPlatform be added to Section 4.4.1? >> >> > MP: GP TEE can be referred to in the TrustZone section. How about the > following? > > "A TA is loaded by a trusted OS running in the TEE such as a GlobalPlatform compliant TEE," > > > This section has a paragraph about ARM and Intel TEEs. Elsewhere the > document talks about GlobalPlatform. I think it should get a paragraph too > so that the reader can compare and contrast the three TEEs. > > MP: I will file an issue to fix this per your recommendation. > 11) Section 4.5 uses the term "TA binary signers" and "TA signer". Please >> see comment 8 above. >> >> > MP: "TA signer" > > 12) Section 5 says: "... encrypted with the TAM public key ...". This is >> not correct. The TAM public key is used to establish the key that is then >> used for encryption and decryption. Further the wording is aimed at RSA, >> which is a key transport algorithm. Please make the wording accommodate >> key transport and key agreement approaches. >> >> > MP: will revise this, and file it in Github issue tracker for text > revision. > > 13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; >> however, Section 1 said that a trust anchor could be a raw public key.. >> Can the TAM use the raw trust anchor key directly? >> >> > MP: It isn't a common case to use a fixed public key as a trusted anchor > instead of a CA certificate. How about allowing a TAM to use a self-signed > certificate? It accommodates both. > > > That does not align with the discussion of what a trust anchor is in RFC > 5280. I think the raw key needs to be allowed, even it if is not the most > popular choice in current implementations. For example, TLS did not > originally allow raw public keys, but it was added later. Here, all of the > foundational specifications already allow it, so I do not think it is wise > to prohibit raw public keys. > > MP: appreciate the additional comments. Will revise to allow the use of a raw public key. > 14) Section 5.2 and Section 5.3 should allow signatures to be directly by >> the trust anchor. The current working requires a certification path. >> >> > MP: we assume that signer and the intermediate CAs up to the trust anchor > but not include a trust anchor are sent in a signature payload. This can > establish a certificate path. Do you mean this about "directly by the trust > anchor"? We need to allow intermediate CAs. We can revise the paragraph to > elaborate on this if you agree.. > > > No. Please look at RFC 5934. Signatures are verified by the trust anchor > itself or by the public key in a certificate that validates to the trust > anchor. > > MP: so the trust anchor contains those additional information per my quick reading, right? Will make the revision per your confirmation. > 15) Section 5.4 says that "self-signed certificates" are allowed. I think >> this is the same as allowing signatures to be directly by the trust >> anchor. Please consider this comment in conjunction with comment 13 above. >> >> > MP: please see above #13 comment. > > 16) Section 7 says that there are "different attestation algorithms". >> Does this mean different set of claims? Please be more clear here. >> >> > MP: it currently means algorithm agility and algorithms may be different > for different devices. Different set of claims from different algorithms > from one device is possible but not necessary, I think. A verifier is > expected to support all the supported algorithms such that it doesn't have > to require different claims to get one working. > > We will clarify the text. > > 17) I think the discussion about "assumptions" would be better written as >> things that need to be considered when assessing the degree of confidence >> in the claim by the TEE, >> >> > MP: will track this as an issue to revise. > > 18) Section 18: Asymmetric algorithms are also used to manage the >> symmetric keys. Symmetric algorithms are also used for data integrity. >> >> > MP: will revise it to reflect both points. > > Symmetric algorithms are used for encryption > of content whereas the asymmetric algorithms are mostly used for > signing messages. > > ==> > > Symmetric algorithms are used for encryption > of content and data integrity whereas the asymmetric algorithms are mostly used for > signing messages and managing symmetric keys. > > > Thanks. I think you can drop "mostly". > > MP: thank you. I filed an issue to fix, and dropped "mostly". > > 19) Section 9.4: Please expand this discussion to cover compromised trust >> anchors and compromised intermediate CAs. >> >> > MP: will file an issue to add this. > > 20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, >> which tells how to make a device certificate that never expires. >> >> > MP: will add a sentence to indicate this possibility. > > " > > TEE device certificates are expected to be long lived, longer than > the lifetime of a device." > > ==> > > "TEE device certificates are expected to be long lived, longer than > the lifetime of a device. They can be certificates that never expire > as defined in the Section 4.1.2.5 of RFC 5280." > > > 21) Please add references for SGX and TrustZone, adding the citations in >> the body as appropriate. >> >> > MP: will add. > > > Russ > > --0000000000008d90fe05a3db02fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ, thank you for your replies.= Please see inline. BTW, I have filed the agreed ones or ones needing revis= ion in the github issue section. Best, Ming


On Tue, Apr 21, 2020= at 9:53 AM Russ Housley <housle= y@vigilsec.com> wrote:


On Apr 21, 2020, at 5:32 AM, Mingliang Pei <mingliang.pei=3D40broadcom.com@dmarc.ietf.org> wrote:

=
Hi Russ,

Thank you very much for your detailed review, suggestions and nits. Plea= se see inline. Best,

Ming

=

= On Fri, Apr 17, 2020 at 1:37 PM Russ Housley <housley@vigilsec.com> wrote:
On the last TEEP call, = I agreed to review the TEEP Architecture document.=C2=A0 Here are my commen= ts and questions.

1) Section 1 says:

=C2=A0 =C2=A0Typically, application components are chosen to execute inside= a TEE
=C2=A0 =C2=A0because those application components perform security sensitiv= e
=C2=A0 =C2=A0operations or operate on sensitive data.

Recognizing that this is the introduction, I was wondering if you could pro= vide a bit more explanation here.=C2=A0 Earlier in the paragraph, the docum= ent offers an example of a banking application.=C2=A0 There would be compon= ents of such and application that are trusted, and other components would b= e untrusted. This concept is described, but the coupling to make a complete= application could be more explicit to prepare the reader for the detail th= at is coming.=C2=A0 Within such an application, it would be good to offer a= n example of a security sensitive operations and a separate example of oper= ating on sensitive data.

MP: we will pr= ovide two examples as you suggested. We will file this in issue tracker for= a fix.


2) Section 1 says:

=C2=A0 =C2=A0To simplify the life of TA developers interacting with TAs in = a TEE,
=C2=A0 =C2=A0an interoperable protocol for managing TAs running in differen= t TEEs
=C2=A0 =C2=A0of various devices is needed.

This feels incomplete to me.=C2=A0 Making sure that compatible trusted and = untrusted components of an application are installed on the same device is = vital when they are not bundled.


MP: how about the following?

=C2=A0=C2=A0 To simplify the life of TA developers interact= ing with TAs in a TEE,
=C2=A0 =C2=A0an interoperable protocol for managing TAs running in differen= t TEEs
=C2=A0 =C2=A0of various devices is needed in order for an untrusted applica= tion to use.

I think= this is a big improvement.


3) Section 1 offers:

=C2=A0 =C2=A0-=C2=A0 A TA developer wants to remove a confidential TA from = a device's
=C2=A0 =C2=A0 =C2=A0 TEE if the TA developer is no longer offering such TAs= or the TAs
=C2=A0 =C2=A0 =C2=A0 are being revoked from a particular user (or device).= =C2=A0 For
=C2=A0 =C2=A0 =C2=A0 example, if a subscription or contract for a particula= r service
=C2=A0 =C2=A0 =C2=A0 has expired, or a payment by the user has not been com= pleted or
=C2=A0 =C2=A0 =C2=A0 has been rescinded.

This implies that the TA developer has some of the privileges that I associ= ate with the TAM.=C2=A0 Yes, I see the note at the end of the bullets, but = I think this is an indication that the privileges are not quite right for t= hese roles.=C2=A0 Also, if I was writing a TA for a subscription, I would h= ave the TA perform some form of payment checking, and then refuse to decryp= t the content if the payment checking fails.=C2=A0 Perhaps the REE passes a= signed proof of payment.=C2=A0 This way, the TA developer does not need to= actually have permission to remove a TA. Further, if the TA is on a multi-= user device, removing the TA would adversely impact other users.


MP: the subscription example doesn'= ;t fully need TA removal as you said. The first half about a "revoked = TA" still calls for the help of TAM. I think we can remove the subscri= ption sentence. A TA could be revoked because it is compromised, or not off= ered anymore. Regarding the impact on multi-user devices, a TA is shared. A= revoked TA use case should apply to all users, which will not have the con= cern you mentioned. Is this good?
<= div>
I think we need to think about it from the TEE perspective.= =C2=A0 We should say what would cause the TEE to delete a TA.

MP: it tries to show a use ca= se for the need of TA deletion. From a TEE perspective, it may delete a TA = because of a request from a TAM. A TEEP Agent will be carrying out the dele= tion. I see your point about "privilege" that a developer was ass= umed to have. How about we revise the use case as the following?
=
-=C2=A0 A TA may need to be deleted from a device's TEE = if the TA is compromised or
=C2=A0=C2=A0 the right of use of the = TA is revoked from a particular user (or device). There could
=C2= =A0=C2=A0 be cases where additional TAs should be installed that some prior= TAs should be
=C2=A0 deleted to free up spaces.

<= div class=3D"gmail_quote">

4) Section 2 says:

=C2=A0 =C2=A0-=C2=A0 Untrusted Application: An application running in a Ric= h Execution
=C2=A0 =C2=A0 =C2=A0 Environment.

For alignment with the definition of a TA and te terms used in section 1, I= think this should say:

=C2=A0 =C2=A0-=C2=A0 Untrusted Application: An application component that r= uns in a
=C2=A0 =C2=A0 =C2=A0 REE.

It is also useful to indicate that the Untrusted Application may be depende= nt on one or more TAs.


MP: Agree on the additional line. Not = sure about changing "application" to "component". An un= trusted application intends to mean a regular client application. Trusted a= pplication is an independent application; we don't require that the two= are strongly tied. Multiple untrusted applications can call the same trust= ed application.

A TA= is an "application component", so the Untrusted Application is a= lso an "application component", right?=C2=A0 If not pick another = term for both definitions.


=
MP: I filed this as an issue to welcome more comments. If we cal= l "Untrusted Application" as "application component", i= t looks to me that the word "application" isn't a good fit he= re.


5) Section 3.3 talks about the Internet of Things.=C2=A0 It does not talk a= bout the billions of devices being used to mount DDoS attacks.=C2=A0 Can it= cover that too?=C2=A0 Without putting the network interface inside the TEE= , I'm skeptical there is a solution.


MP: DDoS attack utilized insecure desi= gn that was triggered to send queries. If all apps are inside TEE, those ap= ps won't be misused. But not sure the entire IoT can just use TEE that = can still provide a network interface as you mentioned.

I'm not sure what you are proposing= to say in the document about DDoS.

=

MP: I would suggest that we say

"This doesn't prevent the devices being used to mount DDoS = attacks where network interfaces are mostly hosted in the untrusted REE.&qu= ot;

Does it work? Thanks.

=

6) Section 3.4 talks about Confidential Cloud Computing.=C2=A0 Can somethin= g be said in Section 4.4.1 to make this less abstract?


MP: will work with co-authors on some = text for review.

7) Section 4.1 defines CA incorrectly.=C2=A0 A CA is not "Certificate-= based credentials".=C2=A0 A CA issues certificates, and the certificat= es are then used for authentication and cryptographic key management.=C2=A0= This bullet should begin: "A CA is ..." to follow the pattern of= the other bullets.


MP: how about the following changes?

Certifica=
tion Authority (CA): Certificate-based credentials used
      for authenticating a device, a TAM and a TA developer.

To
<=
br>Certification Authority (CA): A CA issues certificates that can be used
      for authenticating a device, a TAM or a TA developer. Different CAs
      may be used for iss=
uing certificates for a device, a TAM and a TA developer.

That seems fine.

=

Thanks.

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


8) Section 4.3 introduces the term "TA software author" and "= ;TA signer."=C2=A0 I hope we ca pick one.=C2=A0 Please add the term th= at is chosen to Section 2.


MP: prefer to pick "TA signer&quo= t;. Will add definition to Section 2.

Thank you.

<= div dir=3D"ltr">

9) Section 4.4 should require support for both confidentiality and integrit= y protection.


MP: it currently says=C2=A0
= 
   "Implementations must=
 support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it."

Agreed. We should add integration prot=
ection support too. How about the following?

   "Implementation=
s must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it and support integrity pro=
tection."

I'm glad you added integrity protection, not "integration protect= ion" as you said above!

MP: good catch :)

10) Should GlobalPlatform be added to Section 4.4.1?


MP: GP TEE can be referred to in the T= rustZone section. How about the following?

"A TA is loaded by a trusted OS= running in the TEE such as a GlobalPlatform compliant TEE,"

This section has a paragrap= h about ARM and Intel TEEs.=C2=A0 Elsewhere the document talks about=C2=A0G= lobalPlatform.=C2=A0 I think it should get a paragraph too so that the read= er can compare and contrast the three TEEs.


MP: I will file an issue to fix this per your r= ecommendation.


=
11) Section 4.5 uses the term "TA binary signers" and "TA si= gner".=C2=A0 Please see comment 8 above.


MP: "TA signer"

12) Section 5 says: "... encrypted with the TAM public key ...".= =C2=A0 This is not correct.=C2=A0 The TAM public key is used to establish t= he key that is then used for encryption and decryption.=C2=A0 Further the w= ording is aimed at RSA, which is a key transport algorithm.=C2=A0 Please ma= ke the wording accommodate key transport and key agreement approaches.


MP: will revise this, and file it in G= ithub issue tracker for text revision.

13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA&q= uot;; however, Section 1 said that a trust anchor could be a raw public key= ..=C2=A0 Can the TAM use the raw trust anchor key directly?


MP: It isn't a common case to use = a fixed public key as a trusted anchor instead of a CA certificate. How abo= ut allowing a TAM to use a self-signed certificate? It accommodates both.

That does not align w= ith the discussion of what a trust anchor is in RFC 5280.=C2=A0 I think the= raw key needs to be allowed, even it if is not the most popular choice in = current implementations.=C2=A0 For example, TLS did not originally allow ra= w public keys, but it was added later.=C2=A0 Here, all of the foundational = specifications already allow it, so I do not think it is wise to prohibit r= aw public keys.


= MP: appreciate the additional comments. Will revise to allow the use of a r= aw public key.


14) Section 5.2 and Section 5.3 should allow signatures to be directly by t= he trust anchor.=C2=A0 The current working requires a certification path.

MP: we assume that signer and the inte= rmediate CAs up to the trust anchor but not include a trust anchor are sent= in a signature payload. This can establish a certificate path. Do you mean= this about "directly by the trust anchor"? We need to allow inte= rmediate CAs. We can revise the paragraph to elaborate on this if you agree= ..

No.=C2=A0 Please = look at RFC=C2=A05934.=C2=A0 Signatures are verified by the trust anchor it= self or by the public key in a certificate that validates to the trust anch= or.


MP: so the t= rust anchor contains those additional information per my quick reading, rig= ht? Will make the revision per your confirmation.

=

15) Section 5.4 says that "self-signed certificates" are allowed.= =C2=A0 I think this is the same as allowing signatures to be directly by th= e trust anchor.=C2=A0 Please consider this comment in conjunction with comm= ent 13 above.


MP: please see above #13 comment.
<= /div>

16) Section 7 says that there are "different attestation algorithms&qu= ot;.=C2=A0 Does this mean different set of claims?=C2=A0 Please be more cle= ar here.


MP: it currently means algorithm agili= ty and algorithms may be different for different devices. Different set of = claims from different algorithms from one device is possible but not necess= ary, I think. A verifier is expected to support all the supported algorithm= s such that it doesn't have to require different claims to get one work= ing.

We will clarify the text.

=
17) I think the discussion about "assumptions" would be better wr= itten as things that need to be considered when assessing the degree of con= fidence in the claim by the TEE,


MP: will track this as an issue to rev= ise.

18) Section 18: Asymmetric algorithms are also used to manage the symmetric= keys.=C2=A0 Symmetric algorithms are also used for data integrity.


MP: will revise it to reflect both poi= nts.

Sym=
metric algorithms are used for encryption
   of content whereas the asymmetric algorithms are mostly used for
   signing messages.

=3D=3D>

Symmetric algorithms are used=
 for encryption
   of content and data integrity whereas the asymmetric algorithms are most=
ly used for
   signing messages and managing symmetric keys.

Thanks.=C2=A0 I think you can drop "= ;mostly".


M= P: thank you. I filed an issue to fix, and dropped "mostly".
=

19) Section 9.4: Please expand this discussion to cover compromised trust a= nchors and compromised intermediate CAs.


MP: will file an issue to add this.

20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, whic= h tells how to make a device certificate that never expires.


MP: will add a sentence to indicate th= is possibility.

"
TEE device certificates are expected to be long lived, lo=
nger than
   the lifetime of a device."

=3D=3D>

"TEE devic=
e certificates are expected to be long lived, longer than
   the lifetime of a device. They can be certificates that never expire    as defined in the Section 4.1.2.5 of RFC 5280."
<= br>
21) Please add references for SGX and TrustZone, adding the citations in th= e body as appropriate.


MP: will add.
<= /blockquote>

Russ

--0000000000008d90fe05a3db02fd-- --00000000000093291005a3db0278 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQRQYJKoZIhvcNAQcCoIIQNjCCEDICAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg2aMIIE6DCCA9CgAwIBAgIOSBtqCRO9gCTKXSLwFPMwDQYJKoZIhvcNAQELBQAwTDEgMB4GA1UE CxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMT Ckdsb2JhbFNpZ24wHhcNMTYwNjE1MDAwMDAwWhcNMjQwNjE1MDAwMDAwWjBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tpZok2X9LAHsYqMNVL+Ly6RDkaKar7GD8rVtb9nw6tzPFnvXGeOEA4X5xh9wjx9sScVpGR5wkTg1 fgJIXTlrGESmaqXIdPRd9YQ+Yx9xRIIIPu3Jp/bpbiZBKYDJSbr/2Xago7sb9nnfSyjTSnucUcIP ZVChn6hKneVGBI2DT9yyyD3PmCEJmEzA8Y96qT83JmVH2GaPSSbCw0C+Zj1s/zqtKUbwE5zh8uuZ p4vC019QbaIOb8cGlzgvTqGORwK0gwDYpOO6QQdg5d03WvIHwTunnJdoLrfvqUg2vOlpqJmqR+nH 9lHS+bEstsVJtZieU1Pa+3LzfA/4cT7XA/pnwwIDAQABo4IBtTCCAbEwDgYDVR0PAQH/BAQDAgEG MGoGA1UdJQRjMGEGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwkGCisGAQQBgjcUAgIGCisG AQQBgjcKAwQGCSsGAQQBgjcVBgYKKwYBBAGCNwoDDAYIKwYBBQUHAwcGCCsGAQUFBwMRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFGlygmIxZ5VEhXeRgMQENkmdewthMB8GA1UdIwQYMBaA FI/wS3+oLkUkrk1Q+mOai97i3Ru8MD4GCCsGAQUFBwEBBDIwMDAuBggrBgEFBQcwAYYiaHR0cDov L29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3Js Lmdsb2JhbHNpZ24uY29tL3Jvb3QtcjMuY3JsMGcGA1UdIARgMF4wCwYJKwYBBAGgMgEoMAwGCisG AQQBoDIBKAowQQYJKwYBBAGgMgFfMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNp Z24uY29tL3JlcG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQConc0yzHxn4gtQ16VccKNm4iXv 6rS2UzBuhxI3XDPiwihW45O9RZXzWNgVcUzz5IKJFL7+pcxHvesGVII+5r++9eqI9XnEKCILjHr2 DgvjKq5Jmg6bwifybLYbVUoBthnhaFB0WLwSRRhPrt5eGxMw51UmNICi/hSKBKsHhGFSEaJQALZy 4HL0EWduE6ILYAjX6BSXRDtHFeUPddb46f5Hf5rzITGLsn9BIpoOVrgS878O4JnfUWQi29yBfn75 HajifFvPC+uqn+rcVnvrpLgsLOYG/64kWX/FRH8+mhVe+mcSX3xsUpcxK9q9vLTVtroU/yJUmEC4 OcH5dQsbHBqjMIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNV BAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5BngiFvXAg7aE yiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X17YUhhB5 uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmmKPZpO/bL yCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hpsk+QLjJg 6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7DWzgVGkW qQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBLQNvAUKr+ yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25sbwMpjjM5 RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV3XpYKBov Hd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyrVQ4PkX42 68NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E7gUJTb0o 2HLO02JQZR7rkpeDMdmztcpHWD9fMIIFRzCCBC+gAwIBAgIMJplVpW1Hq+2ySMVcMA0GCSqGSIb3 DQEBCwUAMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMwHhcNMjAwMjIxMTM1 NjQ5WhcNMjMwMjIxMTM1NjQ5WjCBkDELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5hdGFrYTES MBAGA1UEBxMJQmFuZ2Fsb3JlMRYwFAYDVQQKEw1Ccm9hZGNvbSBJbmMuMRYwFAYDVQQDEw1NaW5n bGlhbmcgUGVpMSkwJwYJKoZIhvcNAQkBFhptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALnj+oLejidhAhfIueq2R6kYf0xTddM81r4s9meY /vZiDe5epFRqRGhg8qsgW+LX2vtv5qe0r507+X2VQsqdL1dSQx8M0kMLqddYl9s9fYj12Qz191+J BI196cW/js96aA0aHpvT2jHIZ8n1+L0r9g4uKFt+VV1Z6ZfECZlMC8EZtCv8KXfBfH2dFJ10k+Qg dV+/KUMC2CYgdiIOynoP5Y9FQTcMM0dg8ToVGkdb7gqODxvU8zKuzBF7AY4YdNs03WCZAa5I+84n DiOJCQwyp+y3WJ7BkQq96LxuuJNS6X0YMhujGmUCdlc4BCX9O+8ICz/jTWGhpq+BLGt4hakkdTEC AwEAAaOCAdEwggHNMA4GA1UdDwEB/wQEAwIFoDCBngYIKwYBBQUHAQEEgZEwgY4wTQYIKwYBBQUH MAKGQWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMnNo YTJnM29jc3AuY3J0MD0GCCsGAQUFBzABhjFodHRwOi8vb2NzcDIuZ2xvYmFsc2lnbi5jb20vZ3Nw ZXJzb25hbHNpZ24yc2hhMmczME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIB FiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hh MmczLmNybDAlBgNVHREEHjAcgRptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTATBgNVHSUEDDAK BggrBgEFBQcDBDAfBgNVHSMEGDAWgBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAdBgNVHQ4EFgQUpStv 0AghsERl1TBx5BXhBfzYSicwDQYJKoZIhvcNAQELBQADggEBAFfbbvFJ0WbPYEGcnklrQKfu9s9k KNImqVdomu0FZ6RxOMLGXBmxRTY4Qy0K4rFKkQ+aYT2iWIBBZrHYs6b+xbLAusU8U4WaO+twZeDC IbMNGJ0PCCHe9IYMy1oOK1M7YqufFR3ZGom/ElDbPPBeBt5P6IfZmm+maiU3vOjI15ZIItZKbBlO O6xVaIUhmfNI6jeHo9qRM2JD+PFUDysuPBEI+udCfjCF1jOP+coa/xLFckMJAhHZw8jJGn1Ja1CC p23PR6TUH/Lxkcj5Y+oyx5sGusPp4jW30ONNtGo5+v6UavWPW4/0LMVJGma3LEJ29R18FOu9Fe/s 1NCEczpRDycxggJvMIICawIBATBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0g RzMCDCaZVaVtR6vtskjFXDANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgqZV+BgiO F+3m/Jl+B9DOmHVpW89t4dGB04R1r1mqJ08wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMjAwNDIyMDYxMTU5WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG 9w0BAQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAKz8bydS/pVUF8rfasojv69y7kCS jJcvenysRqera2nnhloIFyvgxQsUrDKcM8L+KCFtr0vdqszBbF5DmWCNzU59r+v0JeTBbwdzBD7P xiompDrfFnI/RJySy2mZZ1cr+PE6oaVoJPcl953ETXFEJ5G3pTMZwZ4hwsf+d76GsiEHMZ4GjTSw wWI33Fsxp5yz83JJXzBF/pf8imjP0fuygk9BqK/2DsIugJvEfhA19UW/jvVSyBnKMgntRaAIRviT Hhl9X9dfn/xP/VH8LAHiTnUilTV2X7O3dgqndCaK4+y/MTvTl9GP/6m4NB4hB6BvLUAL14B0tgaJ Q4BQdS2BJ+E= --00000000000093291005a3db0278-- From nobody Tue Apr 21 23:37:16 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 E7E073A0793 for ; Tue, 21 Apr 2020 23:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, 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 4J2wOqUL_cc8 for ; Tue, 21 Apr 2020 23:37:10 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BF13A0795 for ; Tue, 21 Apr 2020 23:37:09 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id w20so1066507ljj.0 for ; Tue, 21 Apr 2020 23:37:09 -0700 (PDT) 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=80HFy0dHhDCxQkD2QIsk47T1RRNop0xH9RN1ucGciNc=; b=c9kCcIUsYvw4Kv76sICvXcZa93tBrDjhgWtByPTMnLcxNxNwy0T9nIRQZVocjvf+5v 3myN2xc9tgVkWzcLY6fBNypu89p9ZkDxUpPuGtNdzhoMakBGDJ8p0hnSDtuXzzJgdSpf EhFKZeKclEy2DlfnXVhLO1wbMiq4xIlkuWQL8= 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=80HFy0dHhDCxQkD2QIsk47T1RRNop0xH9RN1ucGciNc=; b=OwkjB5KXmnGWH65tJCZIosptkvVBzG11UToHaiUuLFwvBZl3F/L8Q82/S5t3Co59Ud I0LE2BOcYX2zmi1b/z3FO6g9yNxfPZYniIC/UavDeCfGNNLSfee5skQ2dYLQSixQBPW4 3qmYo27wW2bmunWnHqulupeymH+b/ebyKW6b20hd88fuUOutDc779u5vCvUufrM0Xw7N 9f5rRj7MzHKKXWkcxw9oh9FUafjV+QkR9kCmghpAJnnhwLzxYxnt0ukxOE7L25KQJSRS n0WIsaQy5Cg3e0Iuv26Ui3rgp3nyFdU0NBZYTOofhghY37CDxj6ceH3pmiVpEodDxe+u 98iA== X-Gm-Message-State: AGi0PuYzJNV5QVlCZbnYFomgWxmli2W7jtYQRYRXZMAGiBX36C8C1rrF WxoPJ7Ud48LpgQDxfGbesRm804vTrgetTWGGmSpXYw== X-Google-Smtp-Source: APiQypJh8xKo5l7EetHJgptBkiIxfGWMUQAleLrRmBh2niitOAmWR0joHvsBTKuvObtEDAOhUHJplztDS+0klfn9gt0= X-Received: by 2002:a2e:8658:: with SMTP id i24mr621700ljj.287.1587537427937; Tue, 21 Apr 2020 23:37:07 -0700 (PDT) MIME-Version: 1.0 References: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> In-Reply-To: From: Mingliang Pei Date: Tue, 21 Apr 2020 23:36:55 -0700 Message-ID: To: Hannes Tschofenig Cc: Russ Housley , teep Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000007aefb205a3db5c50" Archived-At: Subject: Re: [Teep] Review of draft-ietf-teep-architecture-08 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 Apr 2020 06:37:14 -0000 --0000000000007aefb205a3db5c50 Content-Type: multipart/alternative; boundary="0000000000007600c705a3db5c22" --0000000000007600c705a3db5c22 Content-Type: text/plain; charset="UTF-8" Hi Hannes, Thanks for actually making fixes via PRs. My comments included some revisions, and I filed them as issues to track and fix. I will link the issue list with your PRs. >> 19) Section 9.4: Please expand this discussion to cover compromised trust anchors and compromised intermediate CAs. [Hannes] @Ming: Can I push this to you? I believe you wrote that text. Yes. I will create a PR for it. Ming On Tue, Apr 21, 2020 at 7:48 AM Hannes Tschofenig wrote: > Hi Russ, > > Thanks for the detailed review. I addressed almost all of it but see my > response below. Ming/DaveW/DaveT - there are also some items for you... > > -----Original Message----- > From: TEEP On Behalf Of Russ Housley > Sent: Friday, April 17, 2020 10:34 PM > To: teep > Subject: [Teep] Review of draft-ietf-teep-architecture-08 > > On the last TEEP call, I agreed to review the TEEP Architecture document. > Here are my comments and questions. > > 1) Section 1 says: > > Typically, application components are chosen to execute inside a TEE > because those application components perform security sensitive > operations or operate on sensitive data. > > Recognizing that this is the introduction, I was wondering if you could > provide a bit more explanation here. Earlier in the paragraph, the > document offers an example of a banking application. There would be > components of such and application that are trusted, and other components > would be untrusted. This concept is described, but the coupling to make a > complete application could be more explicit to prepare the reader for the > detail that is coming. Within such an application, it would be good to > offer an example of a security sensitive operations and a separate example > of operating on sensitive data. > > [Hannes] Here is the PR: > > https://clicktime.symantec.com/3U9tRcBXS9neAQm3h31kB7c7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F162 > > 2) Section 1 says: > > To simplify the life of TA developers interacting with TAs in a TEE, > an interoperable protocol for managing TAs running in different TEEs > of various devices is needed. > > This feels incomplete to me. Making sure that compatible trusted and > untrusted components of an application are installed on the same device is > vital when they are not bundled. > > [Hannes] Fair enough. I created a PR on this topic as well: > > https://clicktime.symantec.com/3LecjoZBjbLnxFYgDEAkn5G7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F163 > > 3) Section 1 offers: > > - A TA developer wants to remove a confidential TA from a device's > TEE if the TA developer is no longer offering such TAs or the TAs > are being revoked from a particular user (or device). For > example, if a subscription or contract for a particular service > has expired, or a payment by the user has not been completed or > has been rescinded. > > This implies that the TA developer has some of the privileges that I > associate with the TAM. Yes, I see the note at the end of the bullets, but > I think this is an indication that the privileges are not quite right for > these roles. Also, if I was writing a TA for a subscription, I would have > the TA perform some form of payment checking, and then refuse to decrypt > the content if the payment checking fails. Perhaps the REE passes a signed > proof of payment. This way, the TA developer does not need to actually > have permission to remove a TA. Further, if the TA is on a multi-user > device, removing the TA would adversely impact other users. > > [Hannes] I agree with you. This sounds a bit strange. I have changed the > wording to: > > - A Device Administrator wants to remove a TA from a device's TEE if > the TA developer is no longer maintaining that TA, when the TA has > been revoked or is not used for other reasons anymore (e.g. due to an > expired subscription). > > The PR is: > > https://clicktime.symantec.com/3LecjoZBjbLnxFYgDEAkn5G7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F163 > > 4) Section 2 says: > > - Untrusted Application: An application running in a Rich Execution > Environment. > > For alignment with the definition of a TA and te terms used in section 1, > I think this should say: > > - Untrusted Application: An application component that runs in a > REE. > > It is also useful to indicate that the Untrusted Application may be > dependent on one or more TAs. > > [Hannes] Sounds useful to me. PR is here: > > https://clicktime.symantec.com/3BGyEGWFVwCayAKAwStemYY7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F164 > > 5) Section 3.3 talks about the Internet of Things. It does not talk about > the billions of devices being used to mount DDoS attacks. Can it cover > that too? Without putting the network interface inside the TEE, I'm > skeptical there is a solution. > > [Hannes] The DDoS attacks you are referring to were caused by default > passwords on those devices. A TEE cannot help with that directly. You can, > of course, put per-device credentials and isolate them better using the > TEE. The problem with the DDoS attacks of these IP-based cameras wasn't the > lack of isolation of software but the fact that all devices used the same > credentials and that those credentials were public. I am not sure what I > could write to talk about these use cases without making too many > assumptions. > > 6) Section 3.4 talks about Confidential Cloud Computing. Can something be > said in Section 4.4.1 to make this less abstract? > > [Hannes] This is a question for DaveT. Maybe there is some text that could > be copied from the CCC. > > 7) Section 4.1 defines CA incorrectly. A CA is not "Certificate-based > credentials". A CA issues certificates, and the certificates are then used > for authentication and cryptographic key management. This bullet should > begin: "A CA is ..." to follow the pattern of the other bullets. > > [Hannes] Stupid mistake. Here is the PR: > > https://clicktime.symantec.com/3QdbngvsC8Pbwe91EKXejbh7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F165 > > 8) Section 4.3 introduces the term "TA software author" and "TA signer." > I hope we ca pick one. Please add the term that is chosen to Section 2. > > [Hannes] Good catch. I have expanded the text for the TA developer in the > intro section and have also removed the terms "TA software author" and "TA > signer" with the term "TA developer". > > 9) Section 4.4 should require support for both confidentiality and > integrity protection. > > [Hannes] Of course. I correct it. Here is the Pr: > > https://clicktime.symantec.com/3QdbngvsC8Pbwe91EKXejbh7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F165 > > 10) Should GlobalPlatform be added to Section 4.4.1? > > [Hannes] GlobalPlatform defined APIs that simplify the experience of > developers when need to pass information between the Untrusted App and the > TA (and also for the TA to access secure world OS features). I could add > text but I am wondering whether this would go a bit too far. > > 11) Section 4.5 uses the term "TA binary signers" and "TA signer". Please > see comment 8 above. > > [Hannes] I hope I removed all occurrences. > > 12) Section 5 says: "... encrypted with the TAM public key ...". This is > not correct. The TAM public key is used to establish the key that is then > used for encryption and decryption. Further the wording is aimed at RSA, > which is a key transport algorithm. Please make the wording accommodate > key transport and key agreement approaches. > > [Hannes] I changed the text in this PR but I wanted to note that we don't > want to go into the details on how the encryption works because the > details, as you point out, vary a bit from mechanism to mechanism. > > PR: > > https://clicktime.symantec.com/3PnJTUn12pPi5vDzwLbKrXT7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F166 > > 13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; > however, Section 1 said that a trust anchor could be a raw public key. Can > the TAM use the raw trust anchor key directly? > > [Hannes] I enhanced that sentence. > > 14) Section 5.2 and Section 5.3 should allow signatures to be directly by > the trust anchor. The current working requires a certification path. > > [Hannes] I have updated the text but have a look whether I captured > everything. Here is the PR: > > https://clicktime.symantec.com/3PnJTUn12pPi5vDzwLbKrXT7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F166 > > 15) Section 5.4 says that "self-signed certificates" are allowed. I think > this is the same as allowing signatures to be directly by the trust > anchor. Please consider this comment in conjunction with comment 13 above. > > [Hannes] I removed it because I don't think that self-signed certificates > really make sense given what we described elsewhere. > > 16) Section 7 says that there are "different attestation algorithms". > Does this mean different set of claims? Please be more clear here. > > [Hannes] The idea was to be flexible with regards to attestation schemes, > like ECDSA-based attestation, Direct Anonymous Attestation (DAA), Enhanced > Privacy ID (EPID), a Privacy CA, etc. With our decision to support EAT > tokens I believe we pushed the responsibility over to RATS. > > I still added a few examples: > > https://clicktime.symantec.com/3NyQiEpcnNaSDdKAKkVpxHz7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F167 > > 17) I think the discussion about "assumptions" would be better written as > things that need to be considered when assessing the degree of confidence > in the claim by the TEE, > > [Hannes] @DaveW: Can you take care of this? I believe you wrote that > section. > > 18) Section 18: Asymmetric algorithms are also used to manage the > symmetric keys. Symmetric algorithms are also used for data integrity. > > [Hannes] I added a remark on this topic in this PR: > > https://clicktime.symantec.com/3SmGXqTfEyAyyAhffX1HMyF7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F168 > > 19) Section 9.4: Please expand this discussion to cover compromised trust > anchors and compromised intermediate CAs. > > [Hannes] @Ming: Can I push this to you? I believe you wrote that text. > > 20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, > which tells how to make a device certificate that never expires. > > [Hannes] Good idea. Here is the PR: > > https://clicktime.symantec.com/3SmGXqTfEyAyyAhffX1HMyF7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F168 > > 21) Please add references for SGX and TrustZone, adding the citations in > the body as appropriate. > > [Hannes] DaveT/DaveW: What reference should I use for SGX? > > 22) Nits: > > I covered the nits below in the following PR: > > https://clicktime.symantec.com/3UPSKdb8ibLcLv5mnwFRLJV7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F169 > > Ciao > Hannes > > 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 the > information in any medium. Thank you. > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > > https://clicktime.symantec.com/3K8CZpBGrTEYE9VTkz6AaN7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep > --0000000000007600c705a3db5c22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hannes,

= Thanks for actually making fixes via PRs. My comments included some revisio= ns, and I filed them as issues to track and fix. I will link the issue list= with your PRs.

>> 19) Section 9.4: Plea= se expand this discussion to cover compromised trust anchors and compromise= d intermediate CAs.
[Hannes] @Ming: Can I push this to you? I believe you wrote that text.

Yes. I will create a PR for it.

Ming

On Tue, Apr 21, 2020 at 7:48 AM Hannes Tschof= enig <Hannes.Tschofenig@arm= .com> wrote:
Hi Russ,

Thanks for the detailed review. I addressed almost all of it but see my res= ponse below. Ming/DaveW/DaveT - there are also some items for you...

-----Original Message-----
From: TEEP <t= eep-bounces@ietf.org> On Behalf Of Russ Housley
Sent: Friday, April 17, 2020 10:34 PM
To: teep <teep@ietf.o= rg>
Subject: [Teep] Review of draft-ietf-teep-architecture-08

On the last TEEP call, I agreed to review the TEEP Architecture document.= =C2=A0 Here are my comments and questions.

1) Section 1 says:

=C2=A0 =C2=A0Typically, application components are chosen to execute inside= a TEE
=C2=A0 =C2=A0because those application components perform security sensitiv= e
=C2=A0 =C2=A0operations or operate on sensitive data.

Recognizing that this is the introduction, I was wondering if you could pro= vide a bit more explanation here.=C2=A0 Earlier in the paragraph, the docum= ent offers an example of a banking application.=C2=A0 There would be compon= ents of such and application that are trusted, and other components would b= e untrusted. This concept is described, but the coupling to make a complete= application could be more explicit to prepare the reader for the detail th= at is coming.=C2=A0 Within such an application, it would be good to offer a= n example of a security sensitive operations and a separate example of oper= ating on sensitive data.

[Hannes] Here is the PR:
https://clicktime.symantec.com/3U9tRcBXS9neAQm3h3= 1kB7c7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 62

2) Section 1 says:

=C2=A0 =C2=A0To simplify the life of TA developers interacting with TAs in = a TEE,
=C2=A0 =C2=A0an interoperable protocol for managing TAs running in differen= t TEEs
=C2=A0 =C2=A0of various devices is needed.

This feels incomplete to me.=C2=A0 Making sure that compatible trusted and = untrusted components of an application are installed on the same device is = vital when they are not bundled.

[Hannes] Fair enough. I created a PR on this topic as well:
https://clicktime.symantec.com/3LecjoZBjbLnxFYgDE= Akn5G7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 63

3) Section 1 offers:

=C2=A0 =C2=A0-=C2=A0 A TA developer wants to remove a confidential TA from = a device's
=C2=A0 =C2=A0 =C2=A0 TEE if the TA developer is no longer offering such TAs= or the TAs
=C2=A0 =C2=A0 =C2=A0 are being revoked from a particular user (or device).= =C2=A0 For
=C2=A0 =C2=A0 =C2=A0 example, if a subscription or contract for a particula= r service
=C2=A0 =C2=A0 =C2=A0 has expired, or a payment by the user has not been com= pleted or
=C2=A0 =C2=A0 =C2=A0 has been rescinded.

This implies that the TA developer has some of the privileges that I associ= ate with the TAM.=C2=A0 Yes, I see the note at the end of the bullets, but = I think this is an indication that the privileges are not quite right for t= hese roles.=C2=A0 Also, if I was writing a TA for a subscription, I would h= ave the TA perform some form of payment checking, and then refuse to decryp= t the content if the payment checking fails.=C2=A0 Perhaps the REE passes a= signed proof of payment.=C2=A0 This way, the TA developer does not need to= actually have permission to remove a TA. Further, if the TA is on a multi-= user device, removing the TA would adversely impact other users.

[Hannes] I agree with you. This sounds a bit strange. I have changed the wo= rding to:

=C2=A0 - A Device Administrator wants to remove a TA from a device's TE= E if
=C2=A0 =C2=A0 the TA developer is no longer maintaining that TA, when the T= A has
=C2=A0 =C2=A0 been revoked or is not used for other reasons anymore (e.g. d= ue to an
=C2=A0 =C2=A0 expired subscription).

The PR is:
https://clicktime.symantec.com/3LecjoZBjbLnxFYgDE= Akn5G7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 63

4) Section 2 says:

=C2=A0 =C2=A0-=C2=A0 Untrusted Application: An application running in a Ric= h Execution
=C2=A0 =C2=A0 =C2=A0 Environment.

For alignment with the definition of a TA and te terms used in section 1, I= think this should say:

=C2=A0 =C2=A0-=C2=A0 Untrusted Application: An application component that r= uns in a
=C2=A0 =C2=A0 =C2=A0 REE.

It is also useful to indicate that the Untrusted Application may be depende= nt on one or more TAs.

[Hannes] Sounds useful to me. PR is here:
https://clicktime.symantec.com/3BGyEGWFVwCayAKAwS= temYY7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 64

5) Section 3.3 talks about the Internet of Things.=C2=A0 It does not talk a= bout the billions of devices being used to mount DDoS attacks.=C2=A0 Can it= cover that too?=C2=A0 Without putting the network interface inside the TEE= , I'm skeptical there is a solution.

[Hannes] The DDoS attacks you are referring to were caused by default passw= ords on those devices. A TEE cannot help with that directly. You can, of co= urse, put per-device credentials and isolate them better using the TEE. The= problem with the DDoS attacks of these IP-based cameras wasn't the lac= k of isolation of software but the fact that all devices used the same cred= entials and that those credentials were public. I am not sure what I could = write to talk about these use cases without making too many assumptions.
6) Section 3.4 talks about Confidential Cloud Computing.=C2=A0 Can somethin= g be said in Section 4.4.1 to make this less abstract?

[Hannes] This is a question for DaveT. Maybe there is some text that could = be copied from the CCC.

7) Section 4.1 defines CA incorrectly.=C2=A0 A CA is not "Certificate-= based credentials".=C2=A0 A CA issues certificates, and the certificat= es are then used for authentication and cryptographic key management.=C2=A0= This bullet should begin: "A CA is ..." to follow the pattern of= the other bullets.

[Hannes] Stupid mistake. Here is the PR:
https://clicktime.symantec.com/3QdbngvsC8Pbwe91EK= Xejbh7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 65

8) Section 4.3 introduces the term "TA software author" and "= ;TA signer."=C2=A0 I hope we ca pick one.=C2=A0 Please add the term th= at is chosen to Section 2.

[Hannes] Good catch. I have expanded the text for the TA developer in the i= ntro section and have also removed the terms "TA software author"= and "TA signer" with the term "TA developer".

9) Section 4.4 should require support for both confidentiality and integrit= y protection.

[Hannes] Of course. I correct it. Here is the Pr:
https://clicktime.symantec.com/3QdbngvsC8Pbwe91EK= Xejbh7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 65

10) Should GlobalPlatform be added to Section 4.4.1?

[Hannes] GlobalPlatform defined APIs that simplify the experience of develo= pers when need to pass information between the Untrusted App and the TA (an= d also for the TA to access secure world OS features). I could add text but= I am wondering whether this would go a bit too far.

11) Section 4.5 uses the term "TA binary signers" and "TA si= gner".=C2=A0 Please see comment 8 above.

[Hannes] I hope I removed all occurrences.

12) Section 5 says: "... encrypted with the TAM public key ...".= =C2=A0 This is not correct.=C2=A0 The TAM public key is used to establish t= he key that is then used for encryption and decryption.=C2=A0 Further the w= ording is aimed at RSA, which is a key transport algorithm.=C2=A0 Please ma= ke the wording accommodate key transport and key agreement approaches.

[Hannes] I changed the text in this PR but I wanted to note that we don'= ;t want to go into the details on how the encryption works because the deta= ils, as you point out, vary a bit from mechanism to mechanism.

PR:
https://clicktime.symantec.com/3PnJTUn12pPi5vDzwL= bKrXT7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 66

13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA&q= uot;; however, Section 1 said that a trust anchor could be a raw public key= .=C2=A0 Can the TAM use the raw trust anchor key directly?

[Hannes] I enhanced that sentence.

14) Section 5.2 and Section 5.3 should allow signatures to be directly by t= he trust anchor.=C2=A0 The current working requires a certification path.
[Hannes] I have updated the text but have a look whether I captured everyth= ing. Here is the PR:
https://clicktime.symantec.com/3PnJTUn12pPi5vDzwL= bKrXT7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 66

15) Section 5.4 says that "self-signed certificates" are allowed.= =C2=A0 I think this is the same as allowing signatures to be directly by th= e trust anchor.=C2=A0 Please consider this comment in conjunction with comm= ent 13 above.

[Hannes] I removed it because I don't think that self-signed certificat= es really make sense given what we described elsewhere.

16) Section 7 says that there are "different attestation algorithms&qu= ot;.=C2=A0 Does this mean different set of claims?=C2=A0 Please be more cle= ar here.

[Hannes] The idea was to be flexible with regards to attestation schemes, l= ike ECDSA-based attestation, Direct Anonymous Attestation (DAA), Enhanced P= rivacy ID (EPID), a Privacy CA, etc. With our decision to support EAT token= s I believe we pushed the responsibility over to RATS.

I still added a few examples:
https://clicktime.symantec.com/3NyQiEpcnNaSDdKAKk= VpxHz7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 67

17) I think the discussion about "assumptions" would be better wr= itten as things that need to be considered when assessing the degree of con= fidence in the claim by the TEE,

[Hannes] @DaveW: Can you take care of this? I believe you wrote that sectio= n.

18) Section 18: Asymmetric algorithms are also used to manage the symmetric= keys.=C2=A0 Symmetric algorithms are also used for data integrity.

[Hannes] I added a remark on this topic in this PR:
https://clicktime.symantec.com/3SmGXqTfEyAyyAhffX= 1HMyF7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 68

19) Section 9.4: Please expand this discussion to cover compromised trust a= nchors and compromised intermediate CAs.

[Hannes] @Ming: Can I push this to you? I believe you wrote that text.

20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, whic= h tells how to make a device certificate that never expires.

[Hannes] Good idea. Here is the PR:
https://clicktime.symantec.com/3SmGXqTfEyAyyAhffX= 1HMyF7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 68

21) Please add references for SGX and TrustZone, adding the citations in th= e body as appropriate.

[Hannes] DaveT/DaveW: What reference should I use for SGX?

22) Nits:

I covered the nits below in the following PR:
https://clicktime.symantec.com/3UPSKdb8ibLcLv5mnw= FRLJV7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Farchitecture%2Fpull%2F1= 69

Ciao
Hannes

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.

_______________________________________________
TEEP mailing list
TEEP@ietf.org
https://clicktime.symantec.com/3K8CZpBGrTEYE9VTkz6AaN7Vc?u= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
--0000000000007600c705a3db5c22-- --0000000000007aefb205a3db5c50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQRQYJKoZIhvcNAQcCoIIQNjCCEDICAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg2aMIIE6DCCA9CgAwIBAgIOSBtqCRO9gCTKXSLwFPMwDQYJKoZIhvcNAQELBQAwTDEgMB4GA1UE CxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMT Ckdsb2JhbFNpZ24wHhcNMTYwNjE1MDAwMDAwWhcNMjQwNjE1MDAwMDAwWjBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tpZok2X9LAHsYqMNVL+Ly6RDkaKar7GD8rVtb9nw6tzPFnvXGeOEA4X5xh9wjx9sScVpGR5wkTg1 fgJIXTlrGESmaqXIdPRd9YQ+Yx9xRIIIPu3Jp/bpbiZBKYDJSbr/2Xago7sb9nnfSyjTSnucUcIP ZVChn6hKneVGBI2DT9yyyD3PmCEJmEzA8Y96qT83JmVH2GaPSSbCw0C+Zj1s/zqtKUbwE5zh8uuZ p4vC019QbaIOb8cGlzgvTqGORwK0gwDYpOO6QQdg5d03WvIHwTunnJdoLrfvqUg2vOlpqJmqR+nH 9lHS+bEstsVJtZieU1Pa+3LzfA/4cT7XA/pnwwIDAQABo4IBtTCCAbEwDgYDVR0PAQH/BAQDAgEG MGoGA1UdJQRjMGEGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwkGCisGAQQBgjcUAgIGCisG AQQBgjcKAwQGCSsGAQQBgjcVBgYKKwYBBAGCNwoDDAYIKwYBBQUHAwcGCCsGAQUFBwMRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFGlygmIxZ5VEhXeRgMQENkmdewthMB8GA1UdIwQYMBaA FI/wS3+oLkUkrk1Q+mOai97i3Ru8MD4GCCsGAQUFBwEBBDIwMDAuBggrBgEFBQcwAYYiaHR0cDov L29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3Js Lmdsb2JhbHNpZ24uY29tL3Jvb3QtcjMuY3JsMGcGA1UdIARgMF4wCwYJKwYBBAGgMgEoMAwGCisG AQQBoDIBKAowQQYJKwYBBAGgMgFfMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNp Z24uY29tL3JlcG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQConc0yzHxn4gtQ16VccKNm4iXv 6rS2UzBuhxI3XDPiwihW45O9RZXzWNgVcUzz5IKJFL7+pcxHvesGVII+5r++9eqI9XnEKCILjHr2 DgvjKq5Jmg6bwifybLYbVUoBthnhaFB0WLwSRRhPrt5eGxMw51UmNICi/hSKBKsHhGFSEaJQALZy 4HL0EWduE6ILYAjX6BSXRDtHFeUPddb46f5Hf5rzITGLsn9BIpoOVrgS878O4JnfUWQi29yBfn75 HajifFvPC+uqn+rcVnvrpLgsLOYG/64kWX/FRH8+mhVe+mcSX3xsUpcxK9q9vLTVtroU/yJUmEC4 OcH5dQsbHBqjMIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNV BAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5BngiFvXAg7aE yiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X17YUhhB5 uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmmKPZpO/bL yCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hpsk+QLjJg 6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7DWzgVGkW qQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBLQNvAUKr+ yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25sbwMpjjM5 RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV3XpYKBov Hd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyrVQ4PkX42 68NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E7gUJTb0o 2HLO02JQZR7rkpeDMdmztcpHWD9fMIIFRzCCBC+gAwIBAgIMJplVpW1Hq+2ySMVcMA0GCSqGSIb3 DQEBCwUAMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMwHhcNMjAwMjIxMTM1 NjQ5WhcNMjMwMjIxMTM1NjQ5WjCBkDELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5hdGFrYTES MBAGA1UEBxMJQmFuZ2Fsb3JlMRYwFAYDVQQKEw1Ccm9hZGNvbSBJbmMuMRYwFAYDVQQDEw1NaW5n bGlhbmcgUGVpMSkwJwYJKoZIhvcNAQkBFhptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALnj+oLejidhAhfIueq2R6kYf0xTddM81r4s9meY /vZiDe5epFRqRGhg8qsgW+LX2vtv5qe0r507+X2VQsqdL1dSQx8M0kMLqddYl9s9fYj12Qz191+J BI196cW/js96aA0aHpvT2jHIZ8n1+L0r9g4uKFt+VV1Z6ZfECZlMC8EZtCv8KXfBfH2dFJ10k+Qg dV+/KUMC2CYgdiIOynoP5Y9FQTcMM0dg8ToVGkdb7gqODxvU8zKuzBF7AY4YdNs03WCZAa5I+84n DiOJCQwyp+y3WJ7BkQq96LxuuJNS6X0YMhujGmUCdlc4BCX9O+8ICz/jTWGhpq+BLGt4hakkdTEC AwEAAaOCAdEwggHNMA4GA1UdDwEB/wQEAwIFoDCBngYIKwYBBQUHAQEEgZEwgY4wTQYIKwYBBQUH MAKGQWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMnNo YTJnM29jc3AuY3J0MD0GCCsGAQUFBzABhjFodHRwOi8vb2NzcDIuZ2xvYmFsc2lnbi5jb20vZ3Nw ZXJzb25hbHNpZ24yc2hhMmczME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIB FiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hh MmczLmNybDAlBgNVHREEHjAcgRptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTATBgNVHSUEDDAK BggrBgEFBQcDBDAfBgNVHSMEGDAWgBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAdBgNVHQ4EFgQUpStv 0AghsERl1TBx5BXhBfzYSicwDQYJKoZIhvcNAQELBQADggEBAFfbbvFJ0WbPYEGcnklrQKfu9s9k KNImqVdomu0FZ6RxOMLGXBmxRTY4Qy0K4rFKkQ+aYT2iWIBBZrHYs6b+xbLAusU8U4WaO+twZeDC IbMNGJ0PCCHe9IYMy1oOK1M7YqufFR3ZGom/ElDbPPBeBt5P6IfZmm+maiU3vOjI15ZIItZKbBlO O6xVaIUhmfNI6jeHo9qRM2JD+PFUDysuPBEI+udCfjCF1jOP+coa/xLFckMJAhHZw8jJGn1Ja1CC p23PR6TUH/Lxkcj5Y+oyx5sGusPp4jW30ONNtGo5+v6UavWPW4/0LMVJGma3LEJ29R18FOu9Fe/s 1NCEczpRDycxggJvMIICawIBATBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0g RzMCDCaZVaVtR6vtskjFXDANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgw0+wsVBm klavfDwA5pZ7fgmYmBhybrTA0xSDyrIGS7AwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMjAwNDIyMDYzNzA4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG 9w0BAQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAKYIobdxkdVZ6R6Qe81W6HirfRPX njY+U422vRk6TI6lTGOGtIOrAcQH7jLfwgPxbFrvVBf0LgDk4TQF5nsLb7uwXUkwPZSrg1XflgX7 Iv81fCECr5dqa9Hi2H8lEXHFQeA4tTJOQiqItSWIyGPLojF2PCrfzvr7/oUFDG9KXXN5IS+RvVhC 9B/Yv8eP2ZFtzgjopLh9vQ2sjokqDhTy1mNL/bgsmKaAh4v8ejs3zKSGZ7gbWu33cM+VZCINUNqJ 5fzJs48gL2RgamAtf+BcC03MM19iJrcpB3B2MGMiNgQOMavKposAsjEOZXt52hxOjjtgj4LwzuY1 T6rgOcl57R8= --0000000000007aefb205a3db5c50-- From nobody Thu Apr 23 14:32: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 E7E033A1416 for ; Thu, 23 Apr 2020 14:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16UyXDZ-tJ2z for ; Thu, 23 Apr 2020 14:32:06 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDD43A140D for ; Thu, 23 Apr 2020 14:32:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CCA17300B5E for ; Thu, 23 Apr 2020 17:32:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id u-yeNnLeCTaq for ; Thu, 23 Apr 2020 17:31:59 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 3D45F300AB8; Thu, 23 Apr 2020 17:31:59 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FD1F0D73-584D-4BAD-B905-0729DDAFD608"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 23 Apr 2020 17:32:00 -0400 In-Reply-To: Cc: teep To: Mingliang Pei References: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> <0350DFEB-D900-4246-B2AC-A605BA609509@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Teep] Review of draft-ietf-teep-architecture-08 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, 23 Apr 2020 21:32:11 -0000 --Apple-Mail=_FD1F0D73-584D-4BAD-B905-0729DDAFD608 Content-Type: multipart/alternative; boundary="Apple-Mail=_BCAF26BD-D9AC-4B64-886B-E03A46871F79" --Apple-Mail=_BCAF26BD-D9AC-4B64-886B-E03A46871F79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 22, 2020, at 2:11 AM, Mingliang Pei = wrote: >=20 > Hi Russ, thank you for your replies. Please see inline. BTW, I have = filed the agreed ones or ones needing revision in the github issue = section. Best, Ming >=20 >=20 > On Tue, Apr 21, 2020 at 9:53 AM Russ Housley > wrote: >=20 >=20 >> On Apr 21, 2020, at 5:32 AM, Mingliang Pei = > wrote: >>=20 >> Hi Russ, >>=20 >> Thank you very much for your detailed review, suggestions and nits. = Please see inline. Best, >>=20 >> Ming >>=20 >>=20 >> On Fri, Apr 17, 2020 at 1:37 PM Russ Housley > wrote: >> On the last TEEP call, I agreed to review the TEEP Architecture = document. Here are my comments and questions. >>=20 >> 1) Section 1 says: >>=20 >> Typically, application components are chosen to execute inside a = TEE >> because those application components perform security sensitive >> operations or operate on sensitive data. >>=20 >> Recognizing that this is the introduction, I was wondering if you = could provide a bit more explanation here. Earlier in the paragraph, = the document offers an example of a banking application. There would be = components of such and application that are trusted, and other = components would be untrusted. This concept is described, but the = coupling to make a complete application could be more explicit to = prepare the reader for the detail that is coming. Within such an = application, it would be good to offer an example of a security = sensitive operations and a separate example of operating on sensitive = data. >>=20 >> MP: we will provide two examples as you suggested. We will file this = in issue tracker for a fix. >>=20 >>=20 >> 2) Section 1 says: >>=20 >> To simplify the life of TA developers interacting with TAs in a = TEE, >> an interoperable protocol for managing TAs running in different = TEEs >> of various devices is needed. >>=20 >> This feels incomplete to me. Making sure that compatible trusted and = untrusted components of an application are installed on the same device = is vital when they are not bundled. >>=20 >>=20 >> MP: how about the following? >>=20 >> To simplify the life of TA developers interacting with TAs in a = TEE, >> an interoperable protocol for managing TAs running in different = TEEs >> of various devices is needed in order for an untrusted application = to use. >=20 > I think this is a big improvement. >=20 >>=20 >> 3) Section 1 offers: >>=20 >> - A TA developer wants to remove a confidential TA from a = device's >> TEE if the TA developer is no longer offering such TAs or the = TAs >> are being revoked from a particular user (or device). For >> example, if a subscription or contract for a particular service >> has expired, or a payment by the user has not been completed or >> has been rescinded. >>=20 >> This implies that the TA developer has some of the privileges that I = associate with the TAM. Yes, I see the note at the end of the bullets, = but I think this is an indication that the privileges are not quite = right for these roles. Also, if I was writing a TA for a subscription, = I would have the TA perform some form of payment checking, and then = refuse to decrypt the content if the payment checking fails. Perhaps = the REE passes a signed proof of payment. This way, the TA developer = does not need to actually have permission to remove a TA. Further, if = the TA is on a multi-user device, removing the TA would adversely impact = other users. >>=20 >>=20 >> MP: the subscription example doesn't fully need TA removal as you = said. The first half about a "revoked TA" still calls for the help of = TAM. I think we can remove the subscription sentence. A TA could be = revoked because it is compromised, or not offered anymore. Regarding the = impact on multi-user devices, a TA is shared. A revoked TA use case = should apply to all users, which will not have the concern you = mentioned. Is this good? >=20 > I think we need to think about it from the TEE perspective. We should = say what would cause the TEE to delete a TA. >=20 >=20 > MP: it tries to show a use case for the need of TA deletion. =46rom a = TEE perspective, it may delete a TA because of a request from a TAM. A = TEEP Agent will be carrying out the deletion. I see your point about = "privilege" that a developer was assumed to have. How about we revise = the use case as the following? >=20 > - A TA may need to be deleted from a device's TEE if the TA is = compromised or > the right of use of the TA is revoked from a particular user (or = device). There could > be cases where additional TAs should be installed that some prior = TAs should be > deleted to free up spaces. I think this is an improvement. >=20 >>=20 >> 4) Section 2 says: >>=20 >> - Untrusted Application: An application running in a Rich = Execution >> Environment. >>=20 >> For alignment with the definition of a TA and te terms used in = section 1, I think this should say: >>=20 >> - Untrusted Application: An application component that runs in a >> REE. >>=20 >> It is also useful to indicate that the Untrusted Application may be = dependent on one or more TAs. >>=20 >>=20 >> MP: Agree on the additional line. Not sure about changing = "application" to "component". An untrusted application intends to mean a = regular client application. Trusted application is an independent = application; we don't require that the two are strongly tied. Multiple = untrusted applications can call the same trusted application. >=20 > A TA is an "application component", so the Untrusted Application is = also an "application component", right? If not pick another term for = both definitions. >=20 >=20 > MP: I filed this as an issue to welcome more comments. If we call = "Untrusted Application" as "application component", it looks to me that = the word "application" isn't a good fit here. I think you are missing my point. The document currently says: - Trusted Application (TA): An application component that runs in a TEE. and - Untrusted Application: An application running in a Rich Execution Environment. Why is one a component and the other not? >=20 >>=20 >> 5) Section 3.3 talks about the Internet of Things. It does not talk = about the billions of devices being used to mount DDoS attacks. Can it = cover that too? Without putting the network interface inside the TEE, = I'm skeptical there is a solution. >>=20 >>=20 >> MP: DDoS attack utilized insecure design that was triggered to send = queries. If all apps are inside TEE, those apps won't be misused. But = not sure the entire IoT can just use TEE that can still provide a = network interface as you mentioned. >=20 > I'm not sure what you are proposing to say in the document about DDoS. >=20 >=20 > MP: I would suggest that we say >=20 > "This doesn't prevent the devices being used to mount DDoS attacks = where network interfaces are mostly hosted in the untrusted REE." >=20 > Does it work? Thanks. Thanks. That resolves my point. >=20 >>=20 >> 6) Section 3.4 talks about Confidential Cloud Computing. Can = something be said in Section 4.4.1 to make this less abstract? >>=20 >>=20 >> MP: will work with co-authors on some text for review. >>=20 >> 7) Section 4.1 defines CA incorrectly. A CA is not = "Certificate-based credentials". A CA issues certificates, and the = certificates are then used for authentication and cryptographic key = management. This bullet should begin: "A CA is ..." to follow the = pattern of the other bullets. >>=20 >>=20 >> MP: how about the following changes? >>=20 >> Certification Authority (CA): Certificate-based credentials used >> for authenticating a device, a TAM and a TA developer. >>=20 >> To >>=20 >> Certification Authority (CA): A CA issues certificates that can be = used >> for authenticating a device, a TAM or a TA developer. Different = CAs >> may be used for issuing certificates for a device, a TAM and a = TA developer. >=20 > That seems fine. >=20 >=20 > Thanks. >=20 >>=20 >>=20 >> 8) Section 4.3 introduces the term "TA software author" and "TA = signer." I hope we ca pick one. Please add the term that is chosen to = Section 2. >>=20 >>=20 >> MP: prefer to pick "TA signer". Will add definition to Section 2. >=20 > Thank you. >=20 >>=20 >> 9) Section 4.4 should require support for both confidentiality and = integrity protection. >>=20 >>=20 >> MP: it currently says >>=20 >> "Implementations must support >> encryption of personalization data to preserve the confidentiality = of >> potentially sensitive data contained within it." >>=20 >> Agreed. We should add integration protection support too. How about = the following? >>=20 >> "Implementations must support >> encryption of personalization data to preserve the confidentiality = of >> potentially sensitive data contained within it and support = integrity protection." >=20 > I'm glad you added integrity protection, not "integration protection" = as you said above! >=20 >=20 > MP: good catch :) >>=20 >> 10) Should GlobalPlatform be added to Section 4.4.1? >>=20 >>=20 >> MP: GP TEE can be referred to in the TrustZone section. How about the = following? >>=20 >> "A TA is loaded by a trusted OS running in the TEE such as a = GlobalPlatform compliant TEE," >=20 > This section has a paragraph about ARM and Intel TEEs. Elsewhere the = document talks about GlobalPlatform. I think it should get a paragraph = too so that the reader can compare and contrast the three TEEs. >=20 >=20 > MP: I will file an issue to fix this per your recommendation. >=20 >>=20 >> 11) Section 4.5 uses the term "TA binary signers" and "TA signer". = Please see comment 8 above. >>=20 >>=20 >> MP: "TA signer" >>=20 >> 12) Section 5 says: "... encrypted with the TAM public key ...". = This is not correct. The TAM public key is used to establish the key = that is then used for encryption and decryption. Further the wording is = aimed at RSA, which is a key transport algorithm. Please make the = wording accommodate key transport and key agreement approaches. >>=20 >>=20 >> MP: will revise this, and file it in Github issue tracker for text = revision. >>=20 >> 13) Section 5.1 says that a TAM obtains "a TAM certificate from a = CA"; however, Section 1 said that a trust anchor could be a raw public = key... Can the TAM use the raw trust anchor key directly? >>=20 >>=20 >> MP: It isn't a common case to use a fixed public key as a trusted = anchor instead of a CA certificate. How about allowing a TAM to use a = self-signed certificate? It accommodates both. >=20 > That does not align with the discussion of what a trust anchor is in = RFC 5280. I think the raw key needs to be allowed, even it if is not = the most popular choice in current implementations. For example, TLS = did not originally allow raw public keys, but it was added later. Here, = all of the foundational specifications already allow it, so I do not = think it is wise to prohibit raw public keys. >=20 >=20 > MP: appreciate the additional comments. Will revise to allow the use = of a raw public key. Thanks. >=20 >>=20 >> 14) Section 5.2 and Section 5.3 should allow signatures to be = directly by the trust anchor. The current working requires a = certification path. >>=20 >>=20 >> MP: we assume that signer and the intermediate CAs up to the trust = anchor but not include a trust anchor are sent in a signature payload. = This can establish a certificate path. Do you mean this about "directly = by the trust anchor"? We need to allow intermediate CAs. We can revise = the paragraph to elaborate on this if you agree... >=20 > No. Please look at RFC 5934. Signatures are verified by the trust = anchor itself or by the public key in a certificate that validates to = the trust anchor. >=20 >=20 > MP: so the trust anchor contains those additional information per my = quick reading, right? Will make the revision per your confirmation. I think this is resolved by your response to my comment 13. >=20 >>=20 >> 15) Section 5.4 says that "self-signed certificates" are allowed. I = think this is the same as allowing signatures to be directly by the = trust anchor. Please consider this comment in conjunction with comment = 13 above. >>=20 >>=20 >> MP: please see above #13 comment. >>=20 >> 16) Section 7 says that there are "different attestation algorithms". = Does this mean different set of claims? Please be more clear here. >>=20 >>=20 >> MP: it currently means algorithm agility and algorithms may be = different for different devices. Different set of claims from different = algorithms from one device is possible but not necessary, I think. A = verifier is expected to support all the supported algorithms such that = it doesn't have to require different claims to get one working. >>=20 >> We will clarify the text. >>=20 >> 17) I think the discussion about "assumptions" would be better = written as things that need to be considered when assessing the degree = of confidence in the claim by the TEE, >>=20 >>=20 >> MP: will track this as an issue to revise. >>=20 >> 18) Section 18: Asymmetric algorithms are also used to manage the = symmetric keys. Symmetric algorithms are also used for data integrity. >>=20 >>=20 >> MP: will revise it to reflect both points. >>=20 >> Symmetric algorithms are used for encryption >> of content whereas the asymmetric algorithms are mostly used for >> signing messages. >>=20 >> =3D=3D> >>=20 >> Symmetric algorithms are used for encryption >> of content and data integrity whereas the asymmetric algorithms = are mostly used for >> signing messages and managing symmetric keys. >=20 > Thanks. I think you can drop "mostly". >=20 >=20 > MP: thank you. I filed an issue to fix, and dropped "mostly". Thanks. >>=20 >> 19) Section 9.4: Please expand this discussion to cover compromised = trust anchors and compromised intermediate CAs. >>=20 >>=20 >> MP: will file an issue to add this. >>=20 >> 20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC = 5280, which tells how to make a device certificate that never expires. >>=20 >>=20 >> MP: will add a sentence to indicate this possibility. >>=20 >> " >> TEE device certificates are expected to be long lived, longer than >> the lifetime of a device." >>=20 >> =3D=3D> >>=20 >> "TEE device certificates are expected to be long lived, longer than >> the lifetime of a device. They can be certificates that never = expire >> as defined in the Section 4.1.2.5 of RFC 5280." >>=20 >> 21) Please add references for SGX and TrustZone, adding the citations = in the body as appropriate. >>=20 >>=20 >> MP: will add. Russ --Apple-Mail=_BCAF26BD-D9AC-4B64-886B-E03A46871F79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 22, 2020, at 2:11 AM, Mingliang Pei <mingliang.pei=3D40broadcom.com@dmarc.ietf.org> = wrote:

Hi = Russ, thank you for your replies. Please see inline. BTW, I have filed = the agreed ones or ones needing revision in the github issue section. = Best, Ming


On Tue, Apr = 21, 2020 at 9:53 AM Russ Housley <housley@vigilsec.com> wrote:


On Apr = 21, 2020, at 5:32 AM, Mingliang Pei <mingliang.pei=3D40broadcom.com@dmarc.ietf.org> = wrote:

Hi = Russ,

Thank = you very much for your detailed review, suggestions and nits. Please see = inline. Best,

Ming


On Fri, Apr 17, 2020 at 1:37 PM Russ = Housley <housley@vigilsec.com> wrote:
On the last TEEP call, I agreed to = review the TEEP Architecture document.  Here are my comments and = questions.

1) Section 1 says:

   Typically, application components are chosen to execute = inside a TEE
   because those application components perform security = sensitive
   operations or operate on sensitive data.

Recognizing that this is the introduction, I was wondering if you could = provide a bit more explanation here.  Earlier in the paragraph, the = document offers an example of a banking application.  There would = be components of such and application that are trusted, and other = components would be untrusted. This concept is described, but the = coupling to make a complete application could be more explicit to = prepare the reader for the detail that is coming.  Within such an = application, it would be good to offer an example of a security = sensitive operations and a separate example of operating on sensitive = data.

MP: we will provide two examples as you suggested. We will = file this in issue tracker for a fix.
=

2) Section 1 says:

   To simplify the life of TA developers interacting with TAs = in a TEE,
   an interoperable protocol for managing TAs running in = different TEEs
   of various devices is needed.

This feels incomplete to me.  Making sure that compatible trusted = and untrusted components of an application are installed on the same = device is vital when they are not bundled.


MP: how about the following?

   To simplify the life of TA = developers interacting with TAs in a TEE,
   an interoperable protocol for managing TAs running in = different TEEs
   of various devices is needed in order for an untrusted = application to use.

I think this is a big improvement.


3) Section 1 offers:

   -  A TA developer wants to remove a confidential TA = from a device's
      TEE if the TA developer is no longer offering such = TAs or the TAs
      are being revoked from a particular user (or = device).  For
      example, if a subscription or contract for a = particular service
      has expired, or a payment by the user has not been = completed or
      has been rescinded.

This implies that the TA developer has some of the privileges that I = associate with the TAM.  Yes, I see the note at the end of the = bullets, but I think this is an indication that the privileges are not = quite right for these roles.  Also, if I was writing a TA for a = subscription, I would have the TA perform some form of payment checking, = and then refuse to decrypt the content if the payment checking = fails.  Perhaps the REE passes a signed proof of payment.  = This way, the TA developer does not need to actually have permission to = remove a TA. Further, if the TA is on a multi-user device, removing the = TA would adversely impact other users.


MP: the subscription example doesn't fully need TA removal as = you said. The first half about a "revoked TA" still calls for the help = of TAM. I think we can remove the subscription sentence. A TA could be = revoked because it is compromised, or not offered anymore. Regarding the = impact on multi-user devices, a TA is shared. A revoked TA use case = should apply to all users, which will not have the concern you = mentioned. Is this good?

I think we need to think about it from the TEE = perspective.  We should say what would cause the TEE to delete a = TA.


MP: it tries to show a = use case for the need of TA deletion. =46rom a TEE perspective, it may = delete a TA because of a request from a TAM. A TEEP Agent will be = carrying out the deletion. I see your point about "privilege" that a = developer was assumed to have. How about we revise the use case as the = following?

-  A TA may need to be deleted from a device's TEE if = the TA is compromised or
   the right of = use of the TA is revoked from a particular user (or device). There = could
   be cases where additional TAs = should be installed that some prior TAs should be
  deleted to free up = spaces.

I = think this is an improvement.




4) Section 2 says:

   -  Untrusted Application: An application running in a = Rich Execution
      Environment.

For alignment with the definition of a TA and te terms used in section = 1, I think this should say:

   -  Untrusted Application: An application component = that runs in a
      REE.

It is also useful to indicate that the Untrusted Application may be = dependent on one or more TAs.


MP: Agree on the additional line. Not sure about changing = "application" to "component". An untrusted application intends to mean a = regular client application. Trusted application is an independent = application; we don't require that the two are strongly tied. Multiple = untrusted applications can call the same trusted application.

A TA is an "application component", so the Untrusted = Application is also an "application component", right?  If not pick = another term for both definitions.


MP: I filed this as an issue to welcome = more comments. If we call "Untrusted Application" as "application = component", it looks to me that the word "application" isn't a good fit = here.

I think you are missing my point.

The document currently says:

   -  Trusted Application = (TA): An application component that runs in a
    =   TEE.

and

   -  Untrusted Application: = An application running in a Rich Execution
    =   Environment.

Why = is one a component and the other not?



5) Section 3.3 talks about the Internet of Things.  It does not = talk about the billions of devices being used to mount DDoS = attacks.  Can it cover that too?  Without putting the network = interface inside the TEE, I'm skeptical there is a solution.


MP: DDoS attack utilized insecure design that was triggered = to send queries. If all apps are inside TEE, those apps won't be = misused. But not sure the entire IoT can just use TEE that can still = provide a network interface as you mentioned.

I'm not sure what you are proposing to say in the = document about DDoS.


MP: I would suggest that we say

"This doesn't prevent the devices being used to mount DDoS = attacks where network interfaces are mostly hosted in the untrusted = REE."

Does it work? Thanks.

Thanks.  That resolves my point.



6) Section 3.4 talks about Confidential Cloud Computing.  Can = something be said in Section 4.4.1 to make this less abstract?


MP: will work with co-authors on some text for review.

7) Section 4.1 defines CA incorrectly.  A CA is not = "Certificate-based credentials".  A CA issues certificates, and the = certificates are then used for authentication and cryptographic key = management.  This bullet should begin: "A CA is ..." to follow the = pattern of the other bullets.


MP: how about the following changes?

Certification =
Authority (CA): Certificate-based credentials used
      for authenticating a device, a TAM and a TA developer.

To

Certification =
Authority (CA): A CA issues certificates that can be used
      for authenticating a device, a TAM or a TA developer. Different =
CAs
      may be used for =
issuing certificates for a device, a TAM and a TA developer.

That seems fine.


Thanks.



8) Section 4.3 introduces the term "TA software author" and "TA = signer."  I hope we ca pick one.  Please add the term that is = chosen to Section 2.


MP: prefer to pick "TA signer". Will add definition to = Section 2.

Thank you.


9) Section 4.4 should require support for both confidentiality and = integrity protection.


MP: it currently says 

   "Implementations =
must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it."

Agreed. We should add =
integration protection support too. How about the following?

   "Implementations must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it and support integrity =
protection."

I'm glad you added integrity = protection, not "integration protection" as you said above!


MP: good catch :)

10) Should GlobalPlatform be added to Section 4.4.1?


MP: GP TEE can be referred to in the TrustZone section. How = about the following?

"A TA is loaded by a =
trusted OS running in the TEE such as a GlobalPlatform compliant =
TEE,"

This section has a paragraph about ARM and Intel = TEEs.  Elsewhere the document talks = about GlobalPlatform.  I think it should get a paragraph too = so that the reader can compare and contrast the three TEEs.


MP: I will file an issue to fix this = per your recommendation.


11) Section 4.5 uses the term "TA binary signers" and "TA signer".  = Please see comment 8 above.


MP: "TA signer"

12) Section 5 says: "... encrypted with the TAM public key ...".  = This is not correct.  The TAM public key is used to establish the = key that is then used for encryption and decryption.  Further the = wording is aimed at RSA, which is a key transport algorithm.  = Please make the wording accommodate key transport and key agreement = approaches.


MP: will revise this, and file it in Github issue tracker for = text revision.

13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; = however, Section 1 said that a trust anchor could be a raw public = key...  Can the TAM use the raw trust anchor key directly?


MP: It isn't a common case to use a fixed public key as a = trusted anchor instead of a CA certificate. How about allowing a TAM to = use a self-signed certificate? It accommodates both.

That does not align with the discussion of what a trust = anchor is in RFC 5280.  I think the raw key needs to be allowed, = even it if is not the most popular choice in current = implementations.  For example, TLS did not originally allow raw = public keys, but it was added later.  Here, all of the foundational = specifications already allow it, so I do not think it is wise to = prohibit raw public keys.


MP: appreciate the additional comments. = Will revise to allow the use of a raw public key.

Thanks.



14) Section 5.2 and Section 5.3 should allow signatures to be directly = by the trust anchor.  The current working requires a certification = path.


MP: we assume that signer and the intermediate CAs up to the = trust anchor but not include a trust anchor are sent in a signature = payload. This can establish a certificate path. Do you mean this about = "directly by the trust anchor"? We need to allow intermediate CAs. We = can revise the paragraph to elaborate on this if you agree...

No.  Please look at RFC 5934.  = Signatures are verified by the trust anchor itself or by the public key = in a certificate that validates to the trust anchor.


MP: so the trust anchor contains those = additional information per my quick reading, right? Will make the = revision per your confirmation.

I think this is resolved by your response to my comment = 13.



15) Section 5.4 says that "self-signed certificates" are allowed.  = I think this is the same as allowing signatures to be directly by the = trust anchor.  Please consider this comment in conjunction with = comment 13 above.


MP: please see above #13 comment.

16) Section 7 says that there are "different attestation = algorithms".  Does this mean different set of claims?  Please = be more clear here.


MP: it currently means algorithm agility and algorithms may = be different for different devices. Different set of claims from = different algorithms from one device is possible but not necessary, I = think. A verifier is expected to support all the supported algorithms = such that it doesn't have to require different claims to get one = working.

We = will clarify the text.

17) I think the discussion about "assumptions" would be better written = as things that need to be considered when assessing the degree of = confidence in the claim by the TEE,


MP: will track this as an issue to revise.

18) Section 18: Asymmetric algorithms are also used to manage the = symmetric keys.  Symmetric algorithms are also used for data = integrity.


MP: will revise it to reflect both points.

Symmetric algorithms =
are used for encryption
   of content whereas the asymmetric algorithms are mostly used for
   signing messages.

=3D=3D>

Symmetric algorithms are used for encryption
   of content and data integrity whereas the asymmetric algorithms are =
mostly used for
   signing messages and managing symmetric keys.

Thanks.  I think you can drop "mostly".


MP: thank you. I filed an issue to fix, = and dropped "mostly".

Thanks.


19) Section 9.4: Please expand this discussion to cover compromised = trust anchors and compromised intermediate CAs.


MP: will file an issue to add this.

20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, = which tells how to make a device certificate that never expires.


MP: will add a sentence to indicate this = possibility.

"
TEE device =
certificates are expected to be long lived, longer than
   the lifetime of a device."

=3D=3D>

"TEE device certificates are expected to be =
long lived, longer than
   the lifetime of a device. They can be certificates that never expire =

   as defined in the Section 4.1.2.5 of RFC =
5280."

21) Please add references for SGX and TrustZone, adding the citations in = the body as appropriate.


MP: will = add.

Russ

= --Apple-Mail=_BCAF26BD-D9AC-4B64-886B-E03A46871F79-- --Apple-Mail=_FD1F0D73-584D-4BAD-B905-0729DDAFD608 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXqIJUAAKCRCK5O7Q9ZwR y6HpAKC1pOLryv2UYI6czm7Sgur9rSIFywCg1HLFJP3I5bYhQ5AO5j17ERl+4kc= =oKLo -----END PGP SIGNATURE----- --Apple-Mail=_FD1F0D73-584D-4BAD-B905-0729DDAFD608-- From nobody Thu Apr 23 14:55:59 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 E9CE13A144F for ; Thu, 23 Apr 2020 14:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=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 9hbe1lbSx2RO for ; Thu, 23 Apr 2020 14:55:51 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81A03A1451 for ; Thu, 23 Apr 2020 14:55:49 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id f11so3250283ljp.1 for ; Thu, 23 Apr 2020 14:55:49 -0700 (PDT) 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=AtWToH4WRD9ClRaCZn/jUPJuM4LllkLtT3T8hTV0PMA=; b=Lu2YdGKBI/4Wo77S0GjW7Ok4J1acxtkTJ/OWt0BttjsZoD4PaJYchOZ/9J379XcUD4 2DdsJfQ7Py7SqVJb/TwLvSos6kuP7mzAGPUmZg+8AXsgQcnHXRFj4VZ7HEKKmEfMid35 zYRipStZPz1tLZ+fvJJ2tNkYKuvAfb7Lj1Pks= 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=AtWToH4WRD9ClRaCZn/jUPJuM4LllkLtT3T8hTV0PMA=; b=oab7PojtudcW0y9uUBq51QXjFqGj80+vUv1bpsEXbobCPfVUtU5G6BhCni+dsjqmuI 8Hu/EVmPd7hB48uYV6RThm+C1nkVv76A1ciqi3XH5EqVPTjqreUwHulp+P5Jt5ZFpo8l UaPKKuauMek5CuW551VH9V0piqBytV0ail+2gE4N8n1oTpC4va7xZB/9Aws6NZZNmAmg fSSLCnwdO4HYacHE+ZxrAhiv+0oJgMLen+iUxvV1mZ9F7wtjkSbDBC6lHCoTNXSsyKis 4sOSAe3CSOrP0mf38at7DJej8jcsxh/D2dRVuaThsAVdCra3KrTN1wGIJ0i13Pyli2yP 4B/w== X-Gm-Message-State: AGi0PuZ0MOvtXyfBap783iOOq+hyCyJbpfgZ167KlDSMJ6NRNRZ/N3ha 7U1/v77o0NO/VMcbORtmrBjHg8I7PBjwaf8eY387ut8eh5A= X-Google-Smtp-Source: APiQypJc+AEzLO1BOswAr8jgMo0OHeTMZlgmagok43JTe77eSQhI7qyGQQEfM59Gj+JdV+PxjRWvrzyHSzCTDJ6Whxw= X-Received: by 2002:a2e:8e8a:: with SMTP id z10mr3507056ljk.107.1587678947143; Thu, 23 Apr 2020 14:55:47 -0700 (PDT) MIME-Version: 1.0 References: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> <0350DFEB-D900-4246-B2AC-A605BA609509@vigilsec.com> In-Reply-To: From: Mingliang Pei Date: Thu, 23 Apr 2020 14:55:35 -0700 Message-ID: To: Russ Housley Cc: teep Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000af512505a3fc4fa0" Archived-At: Subject: Re: [Teep] Review of draft-ietf-teep-architecture-08 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, 23 Apr 2020 21:55:56 -0000 --000000000000af512505a3fc4fa0 Content-Type: multipart/alternative; boundary="000000000000a9dacf05a3fc4f37" --000000000000a9dacf05a3fc4f37 Content-Type: text/plain; charset="UTF-8" Hi Russ, please see inline about the "application component". I understood that you want consistency. My argument is that I would rather choose to say "application" in both cases without the word "component" instead of calling both "application component". The document currently says: - Trusted Application (TA): An application component that runs in a TEE. and - Untrusted Application: An application running in a Rich Execution Environment. ==> The document currently says: - Trusted Application (TA): An application that runs in a TEE. and - Untrusted Application: An application that runs in a Rich Execution Environment. Does this work? Thanks, Ming On Thu, Apr 23, 2020 at 2:32 PM Russ Housley wrote: > > > On Apr 22, 2020, at 2:11 AM, Mingliang Pei < > mingliang.pei=40broadcom.com@dmarc.ietf.org> wrote: > > Hi Russ, thank you for your replies. Please see inline. BTW, I have filed > the agreed ones or ones needing revision in the github issue section. Best, > Ming > > > On Tue, Apr 21, 2020 at 9:53 AM Russ Housley wrote: > >> >> >> On Apr 21, 2020, at 5:32 AM, Mingliang Pei < >> mingliang.pei=40broadcom.com@dmarc.ietf.org> wrote: >> >> Hi Russ, >> >> Thank you very much for your detailed review, suggestions and nits. >> Please see inline. Best, >> >> Ming >> >> >> On Fri, Apr 17, 2020 at 1:37 PM Russ Housley >> wrote: >> >>> On the last TEEP call, I agreed to review the TEEP Architecture >>> document. Here are my comments and questions. >>> >>> 1) Section 1 says: >>> >>> Typically, application components are chosen to execute inside a TEE >>> because those application components perform security sensitive >>> operations or operate on sensitive data. >>> >>> Recognizing that this is the introduction, I was wondering if you could >>> provide a bit more explanation here. Earlier in the paragraph, the >>> document offers an example of a banking application. There would be >>> components of such and application that are trusted, and other components >>> would be untrusted. This concept is described, but the coupling to make a >>> complete application could be more explicit to prepare the reader for the >>> detail that is coming. Within such an application, it would be good to >>> offer an example of a security sensitive operations and a separate example >>> of operating on sensitive data. >>> >> >> MP: we will provide two examples as you suggested. We will file this in >> issue tracker for a fix. >> >> >>> 2) Section 1 says: >>> >>> To simplify the life of TA developers interacting with TAs in a TEE, >>> an interoperable protocol for managing TAs running in different TEEs >>> of various devices is needed. >>> >>> This feels incomplete to me. Making sure that compatible trusted and >>> untrusted components of an application are installed on the same device is >>> vital when they are not bundled. >>> >>> >> MP: how about the following? >> >> To simplify the life of TA developers interacting with TAs in a TEE, >> an interoperable protocol for managing TAs running in different TEEs >> of various devices is needed in order for an untrusted application to >> use. >> >> >> I think this is a big improvement. >> >> >> 3) Section 1 offers: >>> >>> - A TA developer wants to remove a confidential TA from a device's >>> TEE if the TA developer is no longer offering such TAs or the TAs >>> are being revoked from a particular user (or device). For >>> example, if a subscription or contract for a particular service >>> has expired, or a payment by the user has not been completed or >>> has been rescinded. >>> >>> This implies that the TA developer has some of the privileges that I >>> associate with the TAM. Yes, I see the note at the end of the bullets, but >>> I think this is an indication that the privileges are not quite right for >>> these roles. Also, if I was writing a TA for a subscription, I would have >>> the TA perform some form of payment checking, and then refuse to decrypt >>> the content if the payment checking fails. Perhaps the REE passes a signed >>> proof of payment. This way, the TA developer does not need to actually >>> have permission to remove a TA. Further, if the TA is on a multi-user >>> device, removing the TA would adversely impact other users. >>> >>> >> MP: the subscription example doesn't fully need TA removal as you said. >> The first half about a "revoked TA" still calls for the help of TAM. I >> think we can remove the subscription sentence. A TA could be revoked >> because it is compromised, or not offered anymore. Regarding the impact on >> multi-user devices, a TA is shared. A revoked TA use case should apply to >> all users, which will not have the concern you mentioned. Is this good? >> >> >> I think we need to think about it from the TEE perspective. We should >> say what would cause the TEE to delete a TA. >> >> > MP: it tries to show a use case for the need of TA deletion. From a TEE > perspective, it may delete a TA because of a request from a TAM. A TEEP > Agent will be carrying out the deletion. I see your point about "privilege" > that a developer was assumed to have. How about we revise the use case as > the following? > > - A TA may need to be deleted from a device's TEE if the TA is > compromised or > the right of use of the TA is revoked from a particular user (or > device). There could > be cases where additional TAs should be installed that some prior TAs > should be > deleted to free up spaces. > > > I think this is an improvement. > > > > >> 4) Section 2 says: >>> >>> - Untrusted Application: An application running in a Rich Execution >>> Environment. >>> >>> For alignment with the definition of a TA and te terms used in section >>> 1, I think this should say: >>> >>> - Untrusted Application: An application component that runs in a >>> REE. >>> >>> It is also useful to indicate that the Untrusted Application may be >>> dependent on one or more TAs. >>> >>> >> MP: Agree on the additional line. Not sure about changing "application" >> to "component". An untrusted application intends to mean a regular client >> application. Trusted application is an independent application; we don't >> require that the two are strongly tied. Multiple untrusted applications can >> call the same trusted application. >> >> >> A TA is an "application component", so the Untrusted Application is also >> an "application component", right? If not pick another term for both >> definitions. >> >> > MP: I filed this as an issue to welcome more comments. If we call > "Untrusted Application" as "application component", it looks to me that the > word "application" isn't a good fit here. > > > I think you are missing my point. > > The document currently says: > > - Trusted Application (TA): An application component that runs in a > TEE. > > and > > - Untrusted Application: An application running in a Rich Execution > Environment. > > Why is one a component and the other not? > > > >> 5) Section 3.3 talks about the Internet of Things. It does not talk >>> about the billions of devices being used to mount DDoS attacks. Can it >>> cover that too? Without putting the network interface inside the TEE, I'm >>> skeptical there is a solution. >>> >>> >> MP: DDoS attack utilized insecure design that was triggered to send >> queries. If all apps are inside TEE, those apps won't be misused. But not >> sure the entire IoT can just use TEE that can still provide a network >> interface as you mentioned. >> >> >> I'm not sure what you are proposing to say in the document about DDoS. >> >> > MP: I would suggest that we say > > "This doesn't prevent the devices being used to mount DDoS attacks where > network interfaces are mostly hosted in the untrusted REE." > > Does it work? Thanks. > > > Thanks. That resolves my point. > > > >> 6) Section 3.4 talks about Confidential Cloud Computing. Can something >>> be said in Section 4.4.1 to make this less abstract? >>> >>> >> MP: will work with co-authors on some text for review. >> >> 7) Section 4.1 defines CA incorrectly. A CA is not "Certificate-based >>> credentials". A CA issues certificates, and the certificates are then used >>> for authentication and cryptographic key management. This bullet should >>> begin: "A CA is ..." to follow the pattern of the other bullets. >>> >>> >> MP: how about the following changes? >> >> Certification Authority (CA): Certificate-based credentials used >> for authenticating a device, a TAM and a TA developer. >> >> To >> >> Certification Authority (CA): A CA issues certificates that can be used >> for authenticating a device, a TAM or a TA developer. Different CAs >> >> may be used for issuing certificates for a device, a TAM and a TA developer. >> >> >> That seems fine. >> >> > Thanks. > > >> >> 8) Section 4.3 introduces the term "TA software author" and "TA signer." >>> I hope we ca pick one. Please add the term that is chosen to Section 2. >>> >>> >> MP: prefer to pick "TA signer". Will add definition to Section 2. >> >> >> Thank you. >> >> >> 9) Section 4.4 should require support for both confidentiality and >>> integrity protection. >>> >>> >> MP: it currently says >> >> "Implementations must support >> encryption of personalization data to preserve the confidentiality of >> potentially sensitive data contained within it." >> >> Agreed. We should add integration protection support too. How about the following? >> >> "Implementations must support >> encryption of personalization data to preserve the confidentiality of >> potentially sensitive data contained within it and support integrity protection." >> >> >> I'm glad you added integrity protection, not "integration protection" as >> you said above! >> >> > MP: good catch :) > >> >> 10) Should GlobalPlatform be added to Section 4.4.1? >>> >>> >> MP: GP TEE can be referred to in the TrustZone section. How about the >> following? >> >> "A TA is loaded by a trusted OS running in the TEE such as a GlobalPlatform compliant TEE," >> >> >> This section has a paragraph about ARM and Intel TEEs. Elsewhere the >> document talks about GlobalPlatform. I think it should get a paragraph too >> so that the reader can compare and contrast the three TEEs. >> >> > MP: I will file an issue to fix this per your recommendation. > > >> 11) Section 4.5 uses the term "TA binary signers" and "TA signer". >>> Please see comment 8 above. >>> >>> >> MP: "TA signer" >> >> 12) Section 5 says: "... encrypted with the TAM public key ...". This is >>> not correct. The TAM public key is used to establish the key that is then >>> used for encryption and decryption. Further the wording is aimed at RSA, >>> which is a key transport algorithm. Please make the wording accommodate >>> key transport and key agreement approaches. >>> >>> >> MP: will revise this, and file it in Github issue tracker for text >> revision. >> >> 13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; >>> however, Section 1 said that a trust anchor could be a raw public key... >>> Can the TAM use the raw trust anchor key directly? >>> >>> >> MP: It isn't a common case to use a fixed public key as a trusted anchor >> instead of a CA certificate. How about allowing a TAM to use a self-signed >> certificate? It accommodates both. >> >> >> That does not align with the discussion of what a trust anchor is in RFC >> 5280. I think the raw key needs to be allowed, even it if is not the most >> popular choice in current implementations. For example, TLS did not >> originally allow raw public keys, but it was added later. Here, all of the >> foundational specifications already allow it, so I do not think it is wise >> to prohibit raw public keys. >> >> > MP: appreciate the additional comments. Will revise to allow the use of a > raw public key. > > > Thanks. > > > >> 14) Section 5.2 and Section 5.3 should allow signatures to be directly by >>> the trust anchor. The current working requires a certification path. >>> >>> >> MP: we assume that signer and the intermediate CAs up to the trust anchor >> but not include a trust anchor are sent in a signature payload. This can >> establish a certificate path. Do you mean this about "directly by the trust >> anchor"? We need to allow intermediate CAs. We can revise the paragraph to >> elaborate on this if you agree... >> >> >> No. Please look at RFC 5934. Signatures are verified by the trust >> anchor itself or by the public key in a certificate that validates to the >> trust anchor. >> >> > MP: so the trust anchor contains those additional information per my quick > reading, right? Will make the revision per your confirmation. > > > I think this is resolved by your response to my comment 13. > > > >> 15) Section 5.4 says that "self-signed certificates" are allowed. I >>> think this is the same as allowing signatures to be directly by the trust >>> anchor. Please consider this comment in conjunction with comment 13 above. >>> >>> >> MP: please see above #13 comment. >> >> 16) Section 7 says that there are "different attestation algorithms". >>> Does this mean different set of claims? Please be more clear here. >>> >>> >> MP: it currently means algorithm agility and algorithms may be different >> for different devices. Different set of claims from different algorithms >> from one device is possible but not necessary, I think. A verifier is >> expected to support all the supported algorithms such that it doesn't have >> to require different claims to get one working. >> >> We will clarify the text. >> >> 17) I think the discussion about "assumptions" would be better written as >>> things that need to be considered when assessing the degree of confidence >>> in the claim by the TEE, >>> >>> >> MP: will track this as an issue to revise. >> >> 18) Section 18: Asymmetric algorithms are also used to manage the >>> symmetric keys. Symmetric algorithms are also used for data integrity. >>> >>> >> MP: will revise it to reflect both points. >> >> Symmetric algorithms are used for encryption >> of content whereas the asymmetric algorithms are mostly used for >> signing messages. >> >> ==> >> >> Symmetric algorithms are used for encryption >> of content and data integrity whereas the asymmetric algorithms are mostly used for >> signing messages and managing symmetric keys. >> >> >> Thanks. I think you can drop "mostly". >> >> > MP: thank you. I filed an issue to fix, and dropped "mostly". > > > Thanks. > > >> 19) Section 9.4: Please expand this discussion to cover compromised trust >>> anchors and compromised intermediate CAs. >>> >>> >> MP: will file an issue to add this. >> >> 20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, >>> which tells how to make a device certificate that never expires. >>> >>> >> MP: will add a sentence to indicate this possibility. >> >> " >> >> TEE device certificates are expected to be long lived, longer than >> the lifetime of a device." >> >> ==> >> >> "TEE device certificates are expected to be long lived, longer than >> the lifetime of a device. They can be certificates that never expire >> as defined in the Section 4.1.2.5 of RFC 5280." >> >> >> 21) Please add references for SGX and TrustZone, adding the citations in >>> the body as appropriate. >>> >>> >> MP: will add. >> >> > Russ > > --000000000000a9dacf05a3fc4f37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ, please see inline about the &quo= t;application component". I understood that you want consistency. My a= rgument is that I would rather choose to say "application" in bot= h cases without the word "component" instead of calling both &quo= t;application component".

The document currently says:

= =C2=A0 =C2=A0- =C2=A0Trusted Application (TA): An application component tha= t runs in a
=C2=A0 =C2=A0 =C2=A0 TEE.

an= d

=C2=A0 =C2=A0- =C2=A0Untrusted Application:= An application running in a Rich Execution
=C2=A0 =C2=A0 =C2=A0 = Environment.

=3D=3D>

<= div>The document currently says:

=C2=A0 =C2= =A0- =C2=A0Trusted Application (TA): An application that runs in a
=C2=A0 =C2=A0 =C2=A0 TEE.

and

=C2=A0 =C2=A0- =C2=A0Untrusted Application: An application that= runs in a Rich Execution
=C2=A0 =C2=A0 =C2=A0 Environment.
=

Does this work?

<= /div>
Thanks,

Ming
=

= On Thu, Apr 23, 2020 at 2:32 PM Russ Housley <housley@vigilsec.com> wrote:


On Apr 22, 2020, at 2:11 AM, M= ingliang Pei <mingliang.pei=3D40broadcom.com@dmarc.ietf.org&= gt; wrote:

Hi Russ, th= ank you for your replies. Please see inline. BTW, I have filed the agreed o= nes or ones needing revision in the github issue section. Best, Ming
<= br>

On Tue, Apr 21, 2020 at 9:53 AM Russ Housley <housley@vigilsec.com> wrote:
<= /div>


On Apr 21, 2020, at 5:32 AM, Mingliang Pei <= ;mingliang.pei=3D40broadcom.com@dmarc.ietf.org> wrote:
=
Hi Russ,

Thank you very much for your detailed review, suggestions and nits. = Please see inline. Best,

Ming


On Fri, Apr 17, 2020 at 1:37 PM Russ Housley <housley@vigilsec.com> wrote:
=
On the last TEEP ca= ll, I agreed to review the TEEP Architecture document.=C2=A0 Here are my co= mments and questions.

1) Section 1 says:

=C2=A0 =C2=A0Typically, application components are chosen to execute inside= a TEE
=C2=A0 =C2=A0because those application components perform security sensitiv= e
=C2=A0 =C2=A0operations or operate on sensitive data.

Recognizing that this is the introduction, I was wondering if you could pro= vide a bit more explanation here.=C2=A0 Earlier in the paragraph, the docum= ent offers an example of a banking application.=C2=A0 There would be compon= ents of such and application that are trusted, and other components would b= e untrusted. This concept is described, but the coupling to make a complete= application could be more explicit to prepare the reader for the detail th= at is coming.=C2=A0 Within such an application, it would be good to offer a= n example of a security sensitive operations and a separate example of oper= ating on sensitive data.

MP: we will pr= ovide two examples as you suggested. We will file this in issue tracker for= a fix.


2) Section 1 says:

=C2=A0 =C2=A0To simplify the life of TA developers interacting with TAs in = a TEE,
=C2=A0 =C2=A0an interoperable protocol for managing TAs running in differen= t TEEs
=C2=A0 =C2=A0of various devices is needed.

This feels incomplete to me.=C2=A0 Making sure that compatible trusted and = untrusted components of an application are installed on the same device is = vital when they are not bundled.


MP: how about the following?

=C2=A0=C2=A0 To simplify the life of TA developers interact= ing with TAs in a TEE,
=C2=A0 =C2=A0an interoperable protocol for managing TAs running in differen= t TEEs
=C2=A0 =C2=A0of various devices is needed in order for an untrusted applica= tion to use.

I think= this is a big improvement.


3) Section 1 offers:

=C2=A0 =C2=A0-=C2=A0 A TA developer wants to remove a confidential TA from = a device's
=C2=A0 =C2=A0 =C2=A0 TEE if the TA developer is no longer offering such TAs= or the TAs
=C2=A0 =C2=A0 =C2=A0 are being revoked from a particular user (or device).= =C2=A0 For
=C2=A0 =C2=A0 =C2=A0 example, if a subscription or contract for a particula= r service
=C2=A0 =C2=A0 =C2=A0 has expired, or a payment by the user has not been com= pleted or
=C2=A0 =C2=A0 =C2=A0 has been rescinded.

This implies that the TA developer has some of the privileges that I associ= ate with the TAM.=C2=A0 Yes, I see the note at the end of the bullets, but = I think this is an indication that the privileges are not quite right for t= hese roles.=C2=A0 Also, if I was writing a TA for a subscription, I would h= ave the TA perform some form of payment checking, and then refuse to decryp= t the content if the payment checking fails.=C2=A0 Perhaps the REE passes a= signed proof of payment.=C2=A0 This way, the TA developer does not need to= actually have permission to remove a TA. Further, if the TA is on a multi-= user device, removing the TA would adversely impact other users.


MP: the subscription example doesn'= ;t fully need TA removal as you said. The first half about a "revoked = TA" still calls for the help of TAM. I think we can remove the subscri= ption sentence. A TA could be revoked because it is compromised, or not off= ered anymore. Regarding the impact on multi-user devices, a TA is shared. A= revoked TA use case should apply to all users, which will not have the con= cern you mentioned. Is this good?
<= div>
I think we need to think about it from the TEE perspective.= =C2=A0 We should say what would cause the TEE to delete a TA.

MP: it tries to show a use ca= se for the need of TA deletion. From a TEE perspective, it may delete a TA = because of a request from a TAM. A TEEP Agent will be carrying out the dele= tion. I see your point about "privilege" that a developer was ass= umed to have. How about we revise the use case as the following?
=
-=C2=A0 A TA may need to be deleted from a device's TEE = if the TA is compromised or
=C2=A0=C2=A0 the right of use of the = TA is revoked from a particular user (or device). There could
=C2= =A0=C2=A0 be cases where additional TAs should be installed that some prior= TAs should be
=C2=A0 deleted to free up spaces.

I think this is an improvement.



4) Section 2 says:

=C2=A0 =C2=A0-=C2=A0 Untrusted Application: An application running in a Ric= h Execution
=C2=A0 =C2=A0 =C2=A0 Environment.

For alignment with the definition of a TA and te terms used in section 1, I= think this should say:

=C2=A0 =C2=A0-=C2=A0 Untrusted Application: An application component that r= uns in a
=C2=A0 =C2=A0 =C2=A0 REE.

It is also useful to indicate that the Untrusted Application may be depende= nt on one or more TAs.


MP: Agree on the additional line. Not = sure about changing "application" to "component". An un= trusted application intends to mean a regular client application. Trusted a= pplication is an independent application; we don't require that the two= are strongly tied. Multiple untrusted applications can call the same trust= ed application.

A TA= is an "application component", so the Untrusted Application is a= lso an "application component", right?=C2=A0 If not pick another = term for both definitions.


=
MP: I filed this as an issue to welcome more comments. If we cal= l "Untrusted Application" as "application component", i= t looks to me that the word "application" isn't a good fit he= re.

I think you are = missing my point.

The document currently says:

=C2=A0 =C2=A0- =C2=A0Trusted Application (TA): A= n application component that runs in a
=C2=A0 =C2=A0 =C2=A0 TEE.<= /div>

and

=C2=A0 =C2=A0- = =C2=A0Untrusted Application: An application running in a Rich Execution
=C2=A0 =C2=A0 =C2=A0 Environment.

Why is one a component and the other not?


=

5) Section 3.3 talks about the Internet of Things.=C2=A0 It does not talk a= bout the billions of devices being used to mount DDoS attacks.=C2=A0 Can it= cover that too?=C2=A0 Without putting the network interface inside the TEE= , I'm skeptical there is a solution.


MP: DDoS attack utilized insecure desi= gn that was triggered to send queries. If all apps are inside TEE, those ap= ps won't be misused. But not sure the entire IoT can just use TEE that = can still provide a network interface as you mentioned.

I'm not sure what you are proposing= to say in the document about DDoS.

=

MP: I would suggest that we say

"This doesn't prevent the devices being used to mount DDoS = attacks where network interfaces are mostly hosted in the untrusted REE.&qu= ot;

Does it work? Thanks.

Thanks.=C2=A0 That resolves my point.



6) Section 3.4 talks about Confidential Cloud Computing.=C2=A0 Can somethin= g be said in Section 4.4.1 to make this less abstract?


MP: will work with co-authors on some = text for review.

7) Section 4.1 defines CA incorrectly.=C2=A0 A CA is not "Certificate-= based credentials".=C2=A0 A CA issues certificates, and the certificat= es are then used for authentication and cryptographic key management.=C2=A0= This bullet should begin: "A CA is ..." to follow the pattern of= the other bullets.


MP: how about the following changes?

Certifica=
tion Authority (CA): Certificate-based credentials used
      for authenticating a device, a TAM and a TA developer.

To
<=
br>Certification Authority (CA): A CA issues certificates that can be used
      for authenticating a device, a TAM or a TA developer. Different CAs
      may be used for iss=
uing certificates for a device, a TAM and a TA developer.

That seems fine.

=

Thanks.

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


8) Section 4.3 introduces the term "TA software author" and "= ;TA signer."=C2=A0 I hope we ca pick one.=C2=A0 Please add the term th= at is chosen to Section 2.


MP: prefer to pick "TA signer&quo= t;. Will add definition to Section 2.

Thank you.

<= div dir=3D"ltr">

9) Section 4.4 should require support for both confidentiality and integrit= y protection.


MP: it currently says=C2=A0
= 
   "Implementations must=
 support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it."

Agreed. We should add integration prot=
ection support too. How about the following?

   "Implementation=
s must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it and support integrity pro=
tection."

I'm glad you added integrity protection, not "integration protect= ion" as you said above!

MP: good catch :)
<= div class=3D"gmail_quote">

10) Should GlobalPlatform be added to Section 4.4.1?


MP: GP TEE can be referred to in the T= rustZone section. How about the following?

"A TA is loaded by a trusted OS= running in the TEE such as a GlobalPlatform compliant TEE,"

This section has a paragrap= h about ARM and Intel TEEs.=C2=A0 Elsewhere the document talks about=C2=A0G= lobalPlatform.=C2=A0 I think it should get a paragraph too so that the read= er can compare and contrast the three TEEs.


MP: I will file an issue to fix this per your r= ecommendation.


11) Section 4.5 uses the term "TA binary signers" and "TA si= gner".=C2=A0 Please see comment 8 above.


MP: "TA signer"

12) Section 5 says: "... encrypted with the TAM public key ...".= =C2=A0 This is not correct.=C2=A0 The TAM public key is used to establish t= he key that is then used for encryption and decryption.=C2=A0 Further the w= ording is aimed at RSA, which is a key transport algorithm.=C2=A0 Please ma= ke the wording accommodate key transport and key agreement approaches.


MP: will revise this, and file it in G= ithub issue tracker for text revision.

13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA&q= uot;; however, Section 1 said that a trust anchor could be a raw public key= ...=C2=A0 Can the TAM use the raw trust anchor key directly?


MP: It isn't a common case to use = a fixed public key as a trusted anchor instead of a CA certificate. How abo= ut allowing a TAM to use a self-signed certificate? It accommodates both.

That does not align w= ith the discussion of what a trust anchor is in RFC 5280.=C2=A0 I think the= raw key needs to be allowed, even it if is not the most popular choice in = current implementations.=C2=A0 For example, TLS did not originally allow ra= w public keys, but it was added later.=C2=A0 Here, all of the foundational = specifications already allow it, so I do not think it is wise to prohibit r= aw public keys.


= MP: appreciate the additional comments. Will revise to allow the use of a r= aw public key.

Thank= s.



14) Section 5.2 and Section 5.3 should allow signatures to be directly by t= he trust anchor.=C2=A0 The current working requires a certification path.

MP: we assume that signer and the inte= rmediate CAs up to the trust anchor but not include a trust anchor are sent= in a signature payload. This can establish a certificate path. Do you mean= this about "directly by the trust anchor"? We need to allow inte= rmediate CAs. We can revise the paragraph to elaborate on this if you agree= ...

No.=C2=A0 Please= look at RFC=C2=A05934.=C2=A0 Signatures are verified by the trust anchor i= tself or by the public key in a certificate that validates to the trust anc= hor.


MP: so the = trust anchor contains those additional information per my quick reading, ri= ght? Will make the revision per your confirmation.

I think this is resolved by your response to= my comment 13.



15) Section 5.4 says that "self-signed certificates" are allowed.= =C2=A0 I think this is the same as allowing signatures to be directly by th= e trust anchor.=C2=A0 Please consider this comment in conjunction with comm= ent 13 above.


MP: please see above #13 comment.
<= /div>

16) Section 7 says that there are "different attestation algorithms&qu= ot;.=C2=A0 Does this mean different set of claims?=C2=A0 Please be more cle= ar here.


MP: it currently means algorithm agili= ty and algorithms may be different for different devices. Different set of = claims from different algorithms from one device is possible but not necess= ary, I think. A verifier is expected to support all the supported algorithm= s such that it doesn't have to require different claims to get one work= ing.

We will clarify the text.

=
17) I think the discussion about "assumptions" would be better wr= itten as things that need to be considered when assessing the degree of con= fidence in the claim by the TEE,


MP: will track this as an issue to rev= ise.

18) Section 18: Asymmetric algorithms are also used to manage the symmetric= keys.=C2=A0 Symmetric algorithms are also used for data integrity.


MP: will revise it to reflect both poi= nts.

Sym=
metric algorithms are used for encryption
   of content whereas the asymmetric algorithms are mostly used for
   signing messages.

=3D=3D>

Symmetric algorithms are used=
 for encryption
   of content and data integrity whereas the asymmetric algorithms are most=
ly used for
   signing messages and managing symmetric keys.

Thanks.=C2=A0 I think you can drop "= ;mostly".


M= P: thank you. I filed an issue to fix, and dropped "mostly".
=

Thanks.

<= blockquote type=3D"cite">
<= 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">
=
19) Section 9.4: Please expand this discussion to cover compromised trust a= nchors and compromised intermediate CAs.


MP: will file an issue to add this.

20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, whic= h tells how to make a device certificate that never expires.


MP: will add a sentence to indicate th= is possibility.

"
TEE device certificates are expected to be long lived, lo=
nger than
   the lifetime of a device."

=3D=3D>

"TEE devic=
e certificates are expected to be long lived, longer than
   the lifetime of a device. They can be certificates that never expire    as defined in the Section 4.1.2.5 of RFC 5280."
<= br>
21) Please add references for SGX and TrustZone, adding the citations in th= e body as appropriate.


MP: will add.
<= /blockquote>
Russ

--000000000000a9dacf05a3fc4f37-- --000000000000af512505a3fc4fa0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQRQYJKoZIhvcNAQcCoIIQNjCCEDICAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg2aMIIE6DCCA9CgAwIBAgIOSBtqCRO9gCTKXSLwFPMwDQYJKoZIhvcNAQELBQAwTDEgMB4GA1UE CxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMT Ckdsb2JhbFNpZ24wHhcNMTYwNjE1MDAwMDAwWhcNMjQwNjE1MDAwMDAwWjBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tpZok2X9LAHsYqMNVL+Ly6RDkaKar7GD8rVtb9nw6tzPFnvXGeOEA4X5xh9wjx9sScVpGR5wkTg1 fgJIXTlrGESmaqXIdPRd9YQ+Yx9xRIIIPu3Jp/bpbiZBKYDJSbr/2Xago7sb9nnfSyjTSnucUcIP ZVChn6hKneVGBI2DT9yyyD3PmCEJmEzA8Y96qT83JmVH2GaPSSbCw0C+Zj1s/zqtKUbwE5zh8uuZ p4vC019QbaIOb8cGlzgvTqGORwK0gwDYpOO6QQdg5d03WvIHwTunnJdoLrfvqUg2vOlpqJmqR+nH 9lHS+bEstsVJtZieU1Pa+3LzfA/4cT7XA/pnwwIDAQABo4IBtTCCAbEwDgYDVR0PAQH/BAQDAgEG MGoGA1UdJQRjMGEGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwkGCisGAQQBgjcUAgIGCisG AQQBgjcKAwQGCSsGAQQBgjcVBgYKKwYBBAGCNwoDDAYIKwYBBQUHAwcGCCsGAQUFBwMRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFGlygmIxZ5VEhXeRgMQENkmdewthMB8GA1UdIwQYMBaA FI/wS3+oLkUkrk1Q+mOai97i3Ru8MD4GCCsGAQUFBwEBBDIwMDAuBggrBgEFBQcwAYYiaHR0cDov L29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3Js Lmdsb2JhbHNpZ24uY29tL3Jvb3QtcjMuY3JsMGcGA1UdIARgMF4wCwYJKwYBBAGgMgEoMAwGCisG AQQBoDIBKAowQQYJKwYBBAGgMgFfMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNp Z24uY29tL3JlcG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQConc0yzHxn4gtQ16VccKNm4iXv 6rS2UzBuhxI3XDPiwihW45O9RZXzWNgVcUzz5IKJFL7+pcxHvesGVII+5r++9eqI9XnEKCILjHr2 DgvjKq5Jmg6bwifybLYbVUoBthnhaFB0WLwSRRhPrt5eGxMw51UmNICi/hSKBKsHhGFSEaJQALZy 4HL0EWduE6ILYAjX6BSXRDtHFeUPddb46f5Hf5rzITGLsn9BIpoOVrgS878O4JnfUWQi29yBfn75 HajifFvPC+uqn+rcVnvrpLgsLOYG/64kWX/FRH8+mhVe+mcSX3xsUpcxK9q9vLTVtroU/yJUmEC4 OcH5dQsbHBqjMIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNV BAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5BngiFvXAg7aE yiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X17YUhhB5 uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmmKPZpO/bL yCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hpsk+QLjJg 6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7DWzgVGkW qQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBLQNvAUKr+ yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25sbwMpjjM5 RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV3XpYKBov Hd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyrVQ4PkX42 68NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E7gUJTb0o 2HLO02JQZR7rkpeDMdmztcpHWD9fMIIFRzCCBC+gAwIBAgIMJplVpW1Hq+2ySMVcMA0GCSqGSIb3 DQEBCwUAMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMwHhcNMjAwMjIxMTM1 NjQ5WhcNMjMwMjIxMTM1NjQ5WjCBkDELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5hdGFrYTES MBAGA1UEBxMJQmFuZ2Fsb3JlMRYwFAYDVQQKEw1Ccm9hZGNvbSBJbmMuMRYwFAYDVQQDEw1NaW5n bGlhbmcgUGVpMSkwJwYJKoZIhvcNAQkBFhptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALnj+oLejidhAhfIueq2R6kYf0xTddM81r4s9meY /vZiDe5epFRqRGhg8qsgW+LX2vtv5qe0r507+X2VQsqdL1dSQx8M0kMLqddYl9s9fYj12Qz191+J BI196cW/js96aA0aHpvT2jHIZ8n1+L0r9g4uKFt+VV1Z6ZfECZlMC8EZtCv8KXfBfH2dFJ10k+Qg dV+/KUMC2CYgdiIOynoP5Y9FQTcMM0dg8ToVGkdb7gqODxvU8zKuzBF7AY4YdNs03WCZAa5I+84n DiOJCQwyp+y3WJ7BkQq96LxuuJNS6X0YMhujGmUCdlc4BCX9O+8ICz/jTWGhpq+BLGt4hakkdTEC AwEAAaOCAdEwggHNMA4GA1UdDwEB/wQEAwIFoDCBngYIKwYBBQUHAQEEgZEwgY4wTQYIKwYBBQUH MAKGQWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMnNo YTJnM29jc3AuY3J0MD0GCCsGAQUFBzABhjFodHRwOi8vb2NzcDIuZ2xvYmFsc2lnbi5jb20vZ3Nw ZXJzb25hbHNpZ24yc2hhMmczME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIB FiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hh MmczLmNybDAlBgNVHREEHjAcgRptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTATBgNVHSUEDDAK BggrBgEFBQcDBDAfBgNVHSMEGDAWgBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAdBgNVHQ4EFgQUpStv 0AghsERl1TBx5BXhBfzYSicwDQYJKoZIhvcNAQELBQADggEBAFfbbvFJ0WbPYEGcnklrQKfu9s9k KNImqVdomu0FZ6RxOMLGXBmxRTY4Qy0K4rFKkQ+aYT2iWIBBZrHYs6b+xbLAusU8U4WaO+twZeDC IbMNGJ0PCCHe9IYMy1oOK1M7YqufFR3ZGom/ElDbPPBeBt5P6IfZmm+maiU3vOjI15ZIItZKbBlO O6xVaIUhmfNI6jeHo9qRM2JD+PFUDysuPBEI+udCfjCF1jOP+coa/xLFckMJAhHZw8jJGn1Ja1CC p23PR6TUH/Lxkcj5Y+oyx5sGusPp4jW30ONNtGo5+v6UavWPW4/0LMVJGma3LEJ29R18FOu9Fe/s 1NCEczpRDycxggJvMIICawIBATBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0g RzMCDCaZVaVtR6vtskjFXDANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg4xZ61COh U0hLC4qgtCg5C9AcVHJ6CGqqRDE8sf/Tr+kwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMjAwNDIzMjE1NTQ3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG 9w0BAQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAIuroJ2yyeQBTXfhMLg3V2jOaW9C pWlgKl8lPEXLwh6Vmuv/Kp/TOz0ivKgZ8W1VlsLX1wJQzz3OorQTEdvDTghxfNqj75ckxVUnqRV7 hZxni+aw7YwYtlmjH2tvvauMBQLlCwDThvhVLY3R0OHU0aWa9+v+SF4s/Dj4qBQWmPqs7vDTH/PU l/IXLsofPe57VrLPq8eIfcD61PvLzL+j+kxDRcMyLuCQc1J4SOEyC1zEu7ViRwDu41ozxayp8LH0 I49vk579iy/rDnrN/3MZ267SsWPrUY8W7f0H4ITOlpWxYqMqX4PZORVG6ymnTDtElKMhM8vQQ9ow 6d3ve4iz79w= --000000000000af512505a3fc4fa0-- From nobody Thu Apr 23 14:58:49 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 69B6A3A1541 for ; Thu, 23 Apr 2020 14:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDPXeY2-Xyf3 for ; Thu, 23 Apr 2020 14:58:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0597F3A14F2 for ; Thu, 23 Apr 2020 14:58:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 76E6B300B50 for ; Thu, 23 Apr 2020 17:58:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RMsWWy8xz541 for ; Thu, 23 Apr 2020 17:58:07 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 87394300AB8; Thu, 23 Apr 2020 17:58:07 -0400 (EDT) From: Russ Housley Message-Id: <72D6C460-7C53-4286-A71C-EC19F057D7CB@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0C1158E8-B179-41DB-9C66-DEBAB5356253"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Thu, 23 Apr 2020 17:58:08 -0400 In-Reply-To: Cc: teep To: Mingliang Pei References: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> <0350DFEB-D900-4246-B2AC-A605BA609509@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [Teep] Review of draft-ietf-teep-architecture-08 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, 23 Apr 2020 21:58:38 -0000 --Apple-Mail=_0C1158E8-B179-41DB-9C66-DEBAB5356253 Content-Type: multipart/alternative; boundary="Apple-Mail=_6F3DBE4C-F208-4DDD-A60F-4E8D80BBF343" --Apple-Mail=_6F3DBE4C-F208-4DDD-A60F-4E8D80BBF343 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 23, 2020, at 5:55 PM, Mingliang Pei = wrote: >=20 > Hi Russ, please see inline about the "application component". I = understood that you want consistency. My argument is that I would rather = choose to say "application" in both cases without the word "component" = instead of calling both "application component". >=20 > The document currently says: >=20 > - Trusted Application (TA): An application component that runs in = a > TEE. >=20 > and >=20 > - Untrusted Application: An application running in a Rich = Execution > Environment. >=20 > =3D=3D> >=20 > The document currently says: >=20 > - Trusted Application (TA): An application that runs in a > TEE. >=20 > and >=20 > - Untrusted Application: An application that runs in a Rich = Execution > Environment. >=20 > Does this work? That works fine. The inconsistency was the only issue. Russ >=20 > Thanks, >=20 > Ming >=20 > On Thu, Apr 23, 2020 at 2:32 PM Russ Housley > wrote: >=20 >=20 >> On Apr 22, 2020, at 2:11 AM, Mingliang Pei = > wrote: >>=20 >> Hi Russ, thank you for your replies. Please see inline. BTW, I have = filed the agreed ones or ones needing revision in the github issue = section. Best, Ming >>=20 >>=20 >> On Tue, Apr 21, 2020 at 9:53 AM Russ Housley > wrote: >>=20 >>=20 >>> On Apr 21, 2020, at 5:32 AM, Mingliang Pei = > wrote: >>>=20 >>> Hi Russ, >>>=20 >>> Thank you very much for your detailed review, suggestions and nits. = Please see inline. Best, >>>=20 >>> Ming >>>=20 >>>=20 >>> On Fri, Apr 17, 2020 at 1:37 PM Russ Housley > wrote: >>> On the last TEEP call, I agreed to review the TEEP Architecture = document. Here are my comments and questions. >>>=20 >>> 1) Section 1 says: >>>=20 >>> Typically, application components are chosen to execute inside a = TEE >>> because those application components perform security sensitive >>> operations or operate on sensitive data. >>>=20 >>> Recognizing that this is the introduction, I was wondering if you = could provide a bit more explanation here. Earlier in the paragraph, = the document offers an example of a banking application. There would be = components of such and application that are trusted, and other = components would be untrusted. This concept is described, but the = coupling to make a complete application could be more explicit to = prepare the reader for the detail that is coming. Within such an = application, it would be good to offer an example of a security = sensitive operations and a separate example of operating on sensitive = data. >>>=20 >>> MP: we will provide two examples as you suggested. We will file this = in issue tracker for a fix. >>>=20 >>>=20 >>> 2) Section 1 says: >>>=20 >>> To simplify the life of TA developers interacting with TAs in a = TEE, >>> an interoperable protocol for managing TAs running in different = TEEs >>> of various devices is needed. >>>=20 >>> This feels incomplete to me. Making sure that compatible trusted = and untrusted components of an application are installed on the same = device is vital when they are not bundled. >>>=20 >>>=20 >>> MP: how about the following? >>>=20 >>> To simplify the life of TA developers interacting with TAs in a = TEE, >>> an interoperable protocol for managing TAs running in different = TEEs >>> of various devices is needed in order for an untrusted = application to use. >>=20 >> I think this is a big improvement. >>=20 >>>=20 >>> 3) Section 1 offers: >>>=20 >>> - A TA developer wants to remove a confidential TA from a = device's >>> TEE if the TA developer is no longer offering such TAs or the = TAs >>> are being revoked from a particular user (or device). For >>> example, if a subscription or contract for a particular = service >>> has expired, or a payment by the user has not been completed = or >>> has been rescinded. >>>=20 >>> This implies that the TA developer has some of the privileges that I = associate with the TAM. Yes, I see the note at the end of the bullets, = but I think this is an indication that the privileges are not quite = right for these roles. Also, if I was writing a TA for a subscription, = I would have the TA perform some form of payment checking, and then = refuse to decrypt the content if the payment checking fails. Perhaps = the REE passes a signed proof of payment. This way, the TA developer = does not need to actually have permission to remove a TA. Further, if = the TA is on a multi-user device, removing the TA would adversely impact = other users. >>>=20 >>>=20 >>> MP: the subscription example doesn't fully need TA removal as you = said. The first half about a "revoked TA" still calls for the help of = TAM. I think we can remove the subscription sentence. A TA could be = revoked because it is compromised, or not offered anymore. Regarding the = impact on multi-user devices, a TA is shared. A revoked TA use case = should apply to all users, which will not have the concern you = mentioned. Is this good? >>=20 >> I think we need to think about it from the TEE perspective. We = should say what would cause the TEE to delete a TA. >>=20 >>=20 >> MP: it tries to show a use case for the need of TA deletion. =46rom a = TEE perspective, it may delete a TA because of a request from a TAM. A = TEEP Agent will be carrying out the deletion. I see your point about = "privilege" that a developer was assumed to have. How about we revise = the use case as the following? >>=20 >> - A TA may need to be deleted from a device's TEE if the TA is = compromised or >> the right of use of the TA is revoked from a particular user (or = device). There could >> be cases where additional TAs should be installed that some prior = TAs should be >> deleted to free up spaces. >=20 > I think this is an improvement. >=20 >=20 >>=20 >>>=20 >>> 4) Section 2 says: >>>=20 >>> - Untrusted Application: An application running in a Rich = Execution >>> Environment. >>>=20 >>> For alignment with the definition of a TA and te terms used in = section 1, I think this should say: >>>=20 >>> - Untrusted Application: An application component that runs in a >>> REE. >>>=20 >>> It is also useful to indicate that the Untrusted Application may be = dependent on one or more TAs. >>>=20 >>>=20 >>> MP: Agree on the additional line. Not sure about changing = "application" to "component". An untrusted application intends to mean a = regular client application. Trusted application is an independent = application; we don't require that the two are strongly tied. Multiple = untrusted applications can call the same trusted application. >>=20 >> A TA is an "application component", so the Untrusted Application is = also an "application component", right? If not pick another term for = both definitions. >>=20 >>=20 >> MP: I filed this as an issue to welcome more comments. If we call = "Untrusted Application" as "application component", it looks to me that = the word "application" isn't a good fit here. >=20 > I think you are missing my point. >=20 > The document currently says: >=20 > - Trusted Application (TA): An application component that runs in = a > TEE. >=20 > and >=20 > - Untrusted Application: An application running in a Rich = Execution > Environment. >=20 > Why is one a component and the other not? >=20 >>=20 >>>=20 >>> 5) Section 3.3 talks about the Internet of Things. It does not talk = about the billions of devices being used to mount DDoS attacks. Can it = cover that too? Without putting the network interface inside the TEE, = I'm skeptical there is a solution. >>>=20 >>>=20 >>> MP: DDoS attack utilized insecure design that was triggered to send = queries. If all apps are inside TEE, those apps won't be misused. But = not sure the entire IoT can just use TEE that can still provide a = network interface as you mentioned. >>=20 >> I'm not sure what you are proposing to say in the document about = DDoS. >>=20 >>=20 >> MP: I would suggest that we say >>=20 >> "This doesn't prevent the devices being used to mount DDoS attacks = where network interfaces are mostly hosted in the untrusted REE." >>=20 >> Does it work? Thanks. >=20 > Thanks. That resolves my point. >=20 >>=20 >>>=20 >>> 6) Section 3.4 talks about Confidential Cloud Computing. Can = something be said in Section 4.4.1 to make this less abstract? >>>=20 >>>=20 >>> MP: will work with co-authors on some text for review. >>>=20 >>> 7) Section 4.1 defines CA incorrectly. A CA is not = "Certificate-based credentials". A CA issues certificates, and the = certificates are then used for authentication and cryptographic key = management. This bullet should begin: "A CA is ..." to follow the = pattern of the other bullets. >>>=20 >>>=20 >>> MP: how about the following changes? >>>=20 >>> Certification Authority (CA): Certificate-based credentials used >>> for authenticating a device, a TAM and a TA developer. >>>=20 >>> To >>>=20 >>> Certification Authority (CA): A CA issues certificates that can be = used >>> for authenticating a device, a TAM or a TA developer. = Different CAs >>> may be used for issuing certificates for a device, a TAM and a = TA developer. >>=20 >> That seems fine. >>=20 >>=20 >> Thanks. >>=20 >>>=20 >>>=20 >>> 8) Section 4.3 introduces the term "TA software author" and "TA = signer." I hope we ca pick one. Please add the term that is chosen to = Section 2. >>>=20 >>>=20 >>> MP: prefer to pick "TA signer". Will add definition to Section 2. >>=20 >> Thank you. >>=20 >>>=20 >>> 9) Section 4.4 should require support for both confidentiality and = integrity protection. >>>=20 >>>=20 >>> MP: it currently says >>>=20 >>> "Implementations must support >>> encryption of personalization data to preserve the = confidentiality of >>> potentially sensitive data contained within it." >>>=20 >>> Agreed. We should add integration protection support too. How about = the following? >>>=20 >>> "Implementations must support >>> encryption of personalization data to preserve the = confidentiality of >>> potentially sensitive data contained within it and support = integrity protection." >>=20 >> I'm glad you added integrity protection, not "integration protection" = as you said above! >>=20 >>=20 >> MP: good catch :) >>>=20 >>> 10) Should GlobalPlatform be added to Section 4.4.1? >>>=20 >>>=20 >>> MP: GP TEE can be referred to in the TrustZone section. How about = the following? >>>=20 >>> "A TA is loaded by a trusted OS running in the TEE such as a = GlobalPlatform compliant TEE," >>=20 >> This section has a paragraph about ARM and Intel TEEs. Elsewhere the = document talks about GlobalPlatform. I think it should get a paragraph = too so that the reader can compare and contrast the three TEEs. >>=20 >>=20 >> MP: I will file an issue to fix this per your recommendation. >>=20 >>>=20 >>> 11) Section 4.5 uses the term "TA binary signers" and "TA signer". = Please see comment 8 above. >>>=20 >>>=20 >>> MP: "TA signer" >>>=20 >>> 12) Section 5 says: "... encrypted with the TAM public key ...". = This is not correct. The TAM public key is used to establish the key = that is then used for encryption and decryption. Further the wording is = aimed at RSA, which is a key transport algorithm. Please make the = wording accommodate key transport and key agreement approaches. >>>=20 >>>=20 >>> MP: will revise this, and file it in Github issue tracker for text = revision. >>>=20 >>> 13) Section 5.1 says that a TAM obtains "a TAM certificate from a = CA"; however, Section 1 said that a trust anchor could be a raw public = key... Can the TAM use the raw trust anchor key directly? >>>=20 >>>=20 >>> MP: It isn't a common case to use a fixed public key as a trusted = anchor instead of a CA certificate. How about allowing a TAM to use a = self-signed certificate? It accommodates both. >>=20 >> That does not align with the discussion of what a trust anchor is in = RFC 5280. I think the raw key needs to be allowed, even it if is not = the most popular choice in current implementations. For example, TLS = did not originally allow raw public keys, but it was added later. Here, = all of the foundational specifications already allow it, so I do not = think it is wise to prohibit raw public keys. >>=20 >>=20 >> MP: appreciate the additional comments. Will revise to allow the use = of a raw public key. >=20 > Thanks. >=20 >>=20 >>>=20 >>> 14) Section 5.2 and Section 5.3 should allow signatures to be = directly by the trust anchor. The current working requires a = certification path. >>>=20 >>>=20 >>> MP: we assume that signer and the intermediate CAs up to the trust = anchor but not include a trust anchor are sent in a signature payload. = This can establish a certificate path. Do you mean this about "directly = by the trust anchor"? We need to allow intermediate CAs. We can revise = the paragraph to elaborate on this if you agree... >>=20 >> No. Please look at RFC 5934. Signatures are verified by the trust = anchor itself or by the public key in a certificate that validates to = the trust anchor. >>=20 >>=20 >> MP: so the trust anchor contains those additional information per my = quick reading, right? Will make the revision per your confirmation. >=20 > I think this is resolved by your response to my comment 13. >=20 >>=20 >>>=20 >>> 15) Section 5.4 says that "self-signed certificates" are allowed. I = think this is the same as allowing signatures to be directly by the = trust anchor. Please consider this comment in conjunction with comment = 13 above. >>>=20 >>>=20 >>> MP: please see above #13 comment. >>>=20 >>> 16) Section 7 says that there are "different attestation = algorithms". Does this mean different set of claims? Please be more = clear here. >>>=20 >>>=20 >>> MP: it currently means algorithm agility and algorithms may be = different for different devices. Different set of claims from different = algorithms from one device is possible but not necessary, I think. A = verifier is expected to support all the supported algorithms such that = it doesn't have to require different claims to get one working. >>>=20 >>> We will clarify the text. >>>=20 >>> 17) I think the discussion about "assumptions" would be better = written as things that need to be considered when assessing the degree = of confidence in the claim by the TEE, >>>=20 >>>=20 >>> MP: will track this as an issue to revise. >>>=20 >>> 18) Section 18: Asymmetric algorithms are also used to manage the = symmetric keys. Symmetric algorithms are also used for data integrity. >>>=20 >>>=20 >>> MP: will revise it to reflect both points. >>>=20 >>> Symmetric algorithms are used for encryption >>> of content whereas the asymmetric algorithms are mostly used for >>> signing messages. >>>=20 >>> =3D=3D> >>>=20 >>> Symmetric algorithms are used for encryption >>> of content and data integrity whereas the asymmetric algorithms = are mostly used for >>> signing messages and managing symmetric keys. >>=20 >> Thanks. I think you can drop "mostly". >>=20 >>=20 >> MP: thank you. I filed an issue to fix, and dropped "mostly". >=20 > Thanks. >=20 >>>=20 >>> 19) Section 9.4: Please expand this discussion to cover compromised = trust anchors and compromised intermediate CAs. >>>=20 >>>=20 >>> MP: will file an issue to add this. >>>=20 >>> 20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC = 5280, which tells how to make a device certificate that never expires. >>>=20 >>>=20 >>> MP: will add a sentence to indicate this possibility. >>>=20 >>> " >>> TEE device certificates are expected to be long lived, longer than >>> the lifetime of a device." >>>=20 >>> =3D=3D> >>>=20 >>> "TEE device certificates are expected to be long lived, longer than >>> the lifetime of a device. They can be certificates that never = expire >>> as defined in the Section 4.1.2.5 of RFC 5280." >>>=20 >>> 21) Please add references for SGX and TrustZone, adding the = citations in the body as appropriate. >>>=20 >>>=20 >>> MP: will add. >=20 > Russ >=20 --Apple-Mail=_6F3DBE4C-F208-4DDD-A60F-4E8D80BBF343 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 23, 2020, at 5:55 PM, Mingliang Pei <mingliang.pei@broadcom.com> wrote:

Hi Russ, please see inline about = the "application component". I understood that you want consistency. My = argument is that I would rather choose to say "application" in both = cases without the word "component" instead of calling both "application = component".

The = document currently says:

   -  Trusted Application = (TA): An application component that runs in a
  =     TEE.

and

   -  Untrusted Application: = An application running in a Rich Execution
  =     Environment.

=3D=3D>

The document currently says:

  =  -  Trusted Application (TA): An application that runs in = a
      TEE.

and

   - =  Untrusted Application: An application that runs in a Rich = Execution
      = Environment.

Does this = work?

That works fine.  The inconsistency was the = only issue.

Russ



Thanks,

Ming

On Thu, Apr = 23, 2020 at 2:32 PM Russ Housley <housley@vigilsec.com> wrote:


On Apr = 22, 2020, at 2:11 AM, Mingliang Pei <mingliang.pei=3D40broadcom.com@dmarc.ietf.org> = wrote:

Hi Russ, thank = you for your replies. Please see inline. BTW, I have filed the agreed = ones or ones needing revision in the github issue section. Best, = Ming


On Tue, Apr = 21, 2020 at 9:53 AM Russ Housley <housley@vigilsec.com> wrote:


On Apr 21, 2020, at 5:32 AM, Mingliang Pei <mingliang.pei=3D40broadcom.com@dmarc.ietf.org> = wrote:

Hi = Russ,

Thank = you very much for your detailed review, suggestions and nits. Please see = inline. Best,

Ming


On Fri, Apr 17, 2020 at 1:37 PM Russ = Housley <housley@vigilsec.com> wrote:
On the last TEEP call, I agreed to = review the TEEP Architecture document.  Here are my comments and = questions.

1) Section 1 says:

   Typically, application components are chosen to execute = inside a TEE
   because those application components perform security = sensitive
   operations or operate on sensitive data.

Recognizing that this is the introduction, I was wondering if you could = provide a bit more explanation here.  Earlier in the paragraph, the = document offers an example of a banking application.  There would = be components of such and application that are trusted, and other = components would be untrusted. This concept is described, but the = coupling to make a complete application could be more explicit to = prepare the reader for the detail that is coming.  Within such an = application, it would be good to offer an example of a security = sensitive operations and a separate example of operating on sensitive = data.

MP: we will provide two examples as you suggested. We will = file this in issue tracker for a fix.
=

2) Section 1 says:

   To simplify the life of TA developers interacting with TAs = in a TEE,
   an interoperable protocol for managing TAs running in = different TEEs
   of various devices is needed.

This feels incomplete to me.  Making sure that compatible trusted = and untrusted components of an application are installed on the same = device is vital when they are not bundled.


MP: how about the following?

   To simplify the life of TA = developers interacting with TAs in a TEE,
   an interoperable protocol for managing TAs running in = different TEEs
   of various devices is needed in order for an untrusted = application to use.

I think this is a big improvement.


3) Section 1 offers:

   -  A TA developer wants to remove a confidential TA = from a device's
      TEE if the TA developer is no longer offering such = TAs or the TAs
      are being revoked from a particular user (or = device).  For
      example, if a subscription or contract for a = particular service
      has expired, or a payment by the user has not been = completed or
      has been rescinded.

This implies that the TA developer has some of the privileges that I = associate with the TAM.  Yes, I see the note at the end of the = bullets, but I think this is an indication that the privileges are not = quite right for these roles.  Also, if I was writing a TA for a = subscription, I would have the TA perform some form of payment checking, = and then refuse to decrypt the content if the payment checking = fails.  Perhaps the REE passes a signed proof of payment.  = This way, the TA developer does not need to actually have permission to = remove a TA. Further, if the TA is on a multi-user device, removing the = TA would adversely impact other users.


MP: the subscription example doesn't fully need TA removal as = you said. The first half about a "revoked TA" still calls for the help = of TAM. I think we can remove the subscription sentence. A TA could be = revoked because it is compromised, or not offered anymore. Regarding the = impact on multi-user devices, a TA is shared. A revoked TA use case = should apply to all users, which will not have the concern you = mentioned. Is this good?

I think we need to think about it from the TEE = perspective.  We should say what would cause the TEE to delete a = TA.


MP: it tries to show a = use case for the need of TA deletion. =46rom a TEE perspective, it may = delete a TA because of a request from a TAM. A TEEP Agent will be = carrying out the deletion. I see your point about "privilege" that a = developer was assumed to have. How about we revise the use case as the = following?

-  A TA may need to be deleted from a device's TEE if = the TA is compromised or
   the right of = use of the TA is revoked from a particular user (or device). There = could
   be cases where additional TAs = should be installed that some prior TAs should be
  deleted to free up = spaces.

I think this is an improvement.




4) Section 2 says:

   -  Untrusted Application: An application running in a = Rich Execution
      Environment.

For alignment with the definition of a TA and te terms used in section = 1, I think this should say:

   -  Untrusted Application: An application component = that runs in a
      REE.

It is also useful to indicate that the Untrusted Application may be = dependent on one or more TAs.


MP: Agree on the additional line. Not sure about changing = "application" to "component". An untrusted application intends to mean a = regular client application. Trusted application is an independent = application; we don't require that the two are strongly tied. Multiple = untrusted applications can call the same trusted application.

A TA is an "application component", so the Untrusted = Application is also an "application component", right?  If not pick = another term for both definitions.


MP: I filed this as an issue to welcome = more comments. If we call "Untrusted Application" as "application = component", it looks to me that the word "application" isn't a good fit = here.

I think you are missing my = point.

The = document currently says:

   -  Trusted Application = (TA): An application component that runs in a
  =     TEE.

and

   -  Untrusted Application: = An application running in a Rich Execution
  =     Environment.

Why is one a component and the other = not?



5) Section 3.3 talks about the Internet of Things.  It does not = talk about the billions of devices being used to mount DDoS = attacks.  Can it cover that too?  Without putting the network = interface inside the TEE, I'm skeptical there is a solution.


MP: DDoS attack utilized insecure design that was triggered = to send queries. If all apps are inside TEE, those apps won't be = misused. But not sure the entire IoT can just use TEE that can still = provide a network interface as you mentioned.

I'm not sure what you are proposing to say in the = document about DDoS.


MP: I would suggest that we say

"This doesn't prevent the devices being used to mount DDoS = attacks where network interfaces are mostly hosted in the untrusted = REE."

Does it work? Thanks.

Thanks.  That resolves my point.



6) Section 3.4 talks about Confidential Cloud Computing.  Can = something be said in Section 4.4.1 to make this less abstract?


MP: will work with co-authors on some text for review.

7) Section 4.1 defines CA incorrectly.  A CA is not = "Certificate-based credentials".  A CA issues certificates, and the = certificates are then used for authentication and cryptographic key = management.  This bullet should begin: "A CA is ..." to follow the = pattern of the other bullets.


MP: how about the following changes?

Certification =
Authority (CA): Certificate-based credentials used
      for authenticating a device, a TAM and a TA developer.

To

Certification =
Authority (CA): A CA issues certificates that can be used
      for authenticating a device, a TAM or a TA developer. Different =
CAs
      may be used for =
issuing certificates for a device, a TAM and a TA developer.

That seems fine.


Thanks.



8) Section 4.3 introduces the term "TA software author" and "TA = signer."  I hope we ca pick one.  Please add the term that is = chosen to Section 2.


MP: prefer to pick "TA signer". Will add definition to = Section 2.

Thank you.


9) Section 4.4 should require support for both confidentiality and = integrity protection.


MP: it currently says 

   "Implementations =
must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it."

Agreed. We should add =
integration protection support too. How about the following?

   "Implementations must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it and support integrity =
protection."

I'm glad you added integrity = protection, not "integration protection" as you said above!


MP: good catch :)

10) Should GlobalPlatform be added to Section 4.4.1?


MP: GP TEE can be referred to in the TrustZone section. How = about the following?

"A TA is loaded by a =
trusted OS running in the TEE such as a GlobalPlatform compliant =
TEE,"

This section has a paragraph about ARM and Intel = TEEs.  Elsewhere the document talks = about GlobalPlatform.  I think it should get a paragraph too = so that the reader can compare and contrast the three TEEs.


MP: I will file an issue to fix this = per your recommendation.


11) Section 4.5 uses the term "TA binary signers" and "TA signer".  = Please see comment 8 above.


MP: "TA signer"

12) Section 5 says: "... encrypted with the TAM public key ...".  = This is not correct.  The TAM public key is used to establish the = key that is then used for encryption and decryption.  Further the = wording is aimed at RSA, which is a key transport algorithm.  = Please make the wording accommodate key transport and key agreement = approaches.


MP: will revise this, and file it in Github issue tracker for = text revision.

13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; = however, Section 1 said that a trust anchor could be a raw public = key...  Can the TAM use the raw trust anchor key directly?


MP: It isn't a common case to use a fixed public key as a = trusted anchor instead of a CA certificate. How about allowing a TAM to = use a self-signed certificate? It accommodates both.

That does not align with the discussion of what a trust = anchor is in RFC 5280.  I think the raw key needs to be allowed, = even it if is not the most popular choice in current = implementations.  For example, TLS did not originally allow raw = public keys, but it was added later.  Here, all of the foundational = specifications already allow it, so I do not think it is wise to = prohibit raw public keys.


MP: appreciate the additional comments. = Will revise to allow the use of a raw public key.

Thanks.



14) Section 5.2 and Section 5.3 should allow signatures to be directly = by the trust anchor.  The current working requires a certification = path.


MP: we assume that signer and the intermediate CAs up to the = trust anchor but not include a trust anchor are sent in a signature = payload. This can establish a certificate path. Do you mean this about = "directly by the trust anchor"? We need to allow intermediate CAs. We = can revise the paragraph to elaborate on this if you agree...

No.  Please look at RFC 5934.  = Signatures are verified by the trust anchor itself or by the public key = in a certificate that validates to the trust anchor.


MP: so the trust anchor contains those = additional information per my quick reading, right? Will make the = revision per your confirmation.

I think this is resolved by your response to my comment = 13.



15) Section 5.4 says that "self-signed certificates" are allowed.  = I think this is the same as allowing signatures to be directly by the = trust anchor.  Please consider this comment in conjunction with = comment 13 above.


MP: please see above #13 comment.

16) Section 7 says that there are "different attestation = algorithms".  Does this mean different set of claims?  Please = be more clear here.


MP: it currently means algorithm agility and algorithms may = be different for different devices. Different set of claims from = different algorithms from one device is possible but not necessary, I = think. A verifier is expected to support all the supported algorithms = such that it doesn't have to require different claims to get one = working.

We = will clarify the text.

17) I think the discussion about "assumptions" would be better written = as things that need to be considered when assessing the degree of = confidence in the claim by the TEE,


MP: will track this as an issue to revise.

18) Section 18: Asymmetric algorithms are also used to manage the = symmetric keys.  Symmetric algorithms are also used for data = integrity.


MP: will revise it to reflect both points.

Symmetric algorithms =
are used for encryption
   of content whereas the asymmetric algorithms are mostly used for
   signing messages.

=3D=3D>

Symmetric algorithms are used for encryption
   of content and data integrity whereas the asymmetric algorithms are =
mostly used for
   signing messages and managing symmetric keys.

Thanks.  I think you can drop "mostly".


MP: thank you. I filed an issue to fix, = and dropped "mostly".

Thanks.


19) Section 9.4: Please expand this discussion to cover compromised = trust anchors and compromised intermediate CAs.


MP: will file an issue to add this.

20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, = which tells how to make a device certificate that never expires.


MP: will add a sentence to indicate this = possibility.

"
TEE device =
certificates are expected to be long lived, longer than
   the lifetime of a device."

=3D=3D>

"TEE device certificates are expected to be =
long lived, longer than
   the lifetime of a device. They can be certificates that never expire =

   as defined in the Section 4.1.2.5 of RFC =
5280."

21) Please add references for SGX and TrustZone, adding the citations in = the body as appropriate.


MP: will = add.

Russ

= --Apple-Mail=_6F3DBE4C-F208-4DDD-A60F-4E8D80BBF343-- --Apple-Mail=_0C1158E8-B179-41DB-9C66-DEBAB5356253 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRJuTEKFXbtfFQz5huK5O7Q9ZwRywUCXqIPcAAKCRCK5O7Q9ZwR y1EkAJ0RNccZ3Eq8qKh2YvUUaN/oo0kCBgCg6ZeNH9BaqSKVLA/rUr426WLh9ZE= =zS9Y -----END PGP SIGNATURE----- --Apple-Mail=_0C1158E8-B179-41DB-9C66-DEBAB5356253-- From nobody Thu Apr 23 15:01:33 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 75D773A1462 for ; Thu, 23 Apr 2020 15:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=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 Chty7lpRTEc4 for ; Thu, 23 Apr 2020 15:01:25 -0700 (PDT) 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 379CF3A1461 for ; Thu, 23 Apr 2020 15:01:25 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id n6so7838320ljg.12 for ; Thu, 23 Apr 2020 15:01:25 -0700 (PDT) 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=sGSu9+046Sld4pbi45ZeObJIoStg7QjrgyVThUWdI+Q=; b=DTf7mLjd5tpldYBaTr/aFe/ZFJYRO2kmcIlG49/dl4H1Nayjm2l/zdjfp8H7iF1kQm y6X2PBGs4m/GIp81RHnowJLSd3nkZ5cqHCgzhiyODl8JsFeFg3cjugvSmkQYJp0MaqlG HI1DNOBdVRS4FWgyQTosOCdwr9tfwZjb7aWok= 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=sGSu9+046Sld4pbi45ZeObJIoStg7QjrgyVThUWdI+Q=; b=DQjYbG2NvTGsxgvyhb2hWIJbuz3SYiMvj+YPUNQ81+QX5IU+55KPQ93fhnkbCRC1Gb 4uBeIsqx6EQhbfUiZNuBkdgJB8ueLEdnewikQ7tMGMYdHiJ2cgWWEO3r2PRPxARMvs+K mUkIP9E+RLpgtg6h1OAZI8gwg/OECqNYtpvOvh9duxdF/IF4sJ5PhC0P70lQayYl4kw9 X8u9j6lxldCZ9a4XMBPyqi4LH9I98qoylfaSRC3eOHoeZKjHLySv+/xBf8BDw0/1FB3T M6Mq3vhSd8Vt+JugwU2z/VHf5rkApIsRDEw7gp/Z5GP7L6N5mMjy3xmCRt/qE6VR2krQ nSxg== X-Gm-Message-State: AGi0PuZMMC5X+438wQgJjP63aIOtojdbNTdPBdzlB97hLHT5vkyXkl/H Sr6YxNhJl0HaWAvMT0l2ZspARQnal+jrazkj2tSjNg== X-Google-Smtp-Source: APiQypL5+fL7/OpTHG9kQ9GZYBecGtP7OcGOycle+LmNw6X1NUMF8nQn1UoqYWJWPY6IoQrhuIXqZZaeDLJFIVVNiJ8= X-Received: by 2002:a2e:8e8a:: with SMTP id z10mr3519123ljk.107.1587679283018; Thu, 23 Apr 2020 15:01:23 -0700 (PDT) MIME-Version: 1.0 References: <218509BB-AD51-4F29-8904-2BD5D4AF663D@vigilsec.com> <0350DFEB-D900-4246-B2AC-A605BA609509@vigilsec.com> <72D6C460-7C53-4286-A71C-EC19F057D7CB@vigilsec.com> In-Reply-To: <72D6C460-7C53-4286-A71C-EC19F057D7CB@vigilsec.com> From: Mingliang Pei Date: Thu, 23 Apr 2020 15:01:11 -0700 Message-ID: To: Russ Housley Cc: teep Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b6bb8105a3fc639a" Archived-At: Subject: Re: [Teep] Review of draft-ietf-teep-architecture-08 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, 23 Apr 2020 22:01:31 -0000 --000000000000b6bb8105a3fc639a Content-Type: multipart/alternative; boundary="000000000000aeceff05a3fc635c" --000000000000aeceff05a3fc635c Content-Type: text/plain; charset="UTF-8" Thanks Russ. Will update to reflect this, Ming On Thu, Apr 23, 2020 at 2:58 PM Russ Housley wrote: > > > On Apr 23, 2020, at 5:55 PM, Mingliang Pei > wrote: > > Hi Russ, please see inline about the "application component". I understood > that you want consistency. My argument is that I would rather choose to say > "application" in both cases without the word "component" instead of calling > both "application component". > > The document currently says: > > - Trusted Application (TA): An application component that runs in a > TEE. > > and > > - Untrusted Application: An application running in a Rich Execution > Environment. > > ==> > > The document currently says: > > - Trusted Application (TA): An application that runs in a > TEE. > > and > > - Untrusted Application: An application that runs in a Rich Execution > Environment. > > Does this work? > > > That works fine. The inconsistency was the only issue. > > Russ > > > > Thanks, > > Ming > > On Thu, Apr 23, 2020 at 2:32 PM Russ Housley wrote: > >> >> >> On Apr 22, 2020, at 2:11 AM, Mingliang Pei < >> mingliang.pei=40broadcom.com@dmarc.ietf.org> wrote: >> >> Hi Russ, thank you for your replies. Please see inline. BTW, I have filed >> the agreed ones or ones needing revision in the github issue section. Best, >> Ming >> >> >> On Tue, Apr 21, 2020 at 9:53 AM Russ Housley >> wrote: >> >>> >>> >>> On Apr 21, 2020, at 5:32 AM, Mingliang Pei < >>> mingliang.pei=40broadcom.com@dmarc.ietf.org> wrote: >>> >>> Hi Russ, >>> >>> Thank you very much for your detailed review, suggestions and nits. >>> Please see inline. Best, >>> >>> Ming >>> >>> >>> On Fri, Apr 17, 2020 at 1:37 PM Russ Housley >>> wrote: >>> >>>> On the last TEEP call, I agreed to review the TEEP Architecture >>>> document. Here are my comments and questions. >>>> >>>> 1) Section 1 says: >>>> >>>> Typically, application components are chosen to execute inside a TEE >>>> because those application components perform security sensitive >>>> operations or operate on sensitive data. >>>> >>>> Recognizing that this is the introduction, I was wondering if you could >>>> provide a bit more explanation here. Earlier in the paragraph, the >>>> document offers an example of a banking application. There would be >>>> components of such and application that are trusted, and other components >>>> would be untrusted. This concept is described, but the coupling to make a >>>> complete application could be more explicit to prepare the reader for the >>>> detail that is coming. Within such an application, it would be good to >>>> offer an example of a security sensitive operations and a separate example >>>> of operating on sensitive data. >>>> >>> >>> MP: we will provide two examples as you suggested. We will file this in >>> issue tracker for a fix. >>> >>> >>>> 2) Section 1 says: >>>> >>>> To simplify the life of TA developers interacting with TAs in a TEE, >>>> an interoperable protocol for managing TAs running in different TEEs >>>> of various devices is needed. >>>> >>>> This feels incomplete to me. Making sure that compatible trusted and >>>> untrusted components of an application are installed on the same device is >>>> vital when they are not bundled. >>>> >>>> >>> MP: how about the following? >>> >>> To simplify the life of TA developers interacting with TAs in a TEE, >>> an interoperable protocol for managing TAs running in different TEEs >>> of various devices is needed in order for an untrusted application to >>> use. >>> >>> >>> I think this is a big improvement. >>> >>> >>> 3) Section 1 offers: >>>> >>>> - A TA developer wants to remove a confidential TA from a device's >>>> TEE if the TA developer is no longer offering such TAs or the TAs >>>> are being revoked from a particular user (or device). For >>>> example, if a subscription or contract for a particular service >>>> has expired, or a payment by the user has not been completed or >>>> has been rescinded. >>>> >>>> This implies that the TA developer has some of the privileges that I >>>> associate with the TAM. Yes, I see the note at the end of the bullets, but >>>> I think this is an indication that the privileges are not quite right for >>>> these roles. Also, if I was writing a TA for a subscription, I would have >>>> the TA perform some form of payment checking, and then refuse to decrypt >>>> the content if the payment checking fails. Perhaps the REE passes a signed >>>> proof of payment. This way, the TA developer does not need to actually >>>> have permission to remove a TA. Further, if the TA is on a multi-user >>>> device, removing the TA would adversely impact other users. >>>> >>>> >>> MP: the subscription example doesn't fully need TA removal as you said. >>> The first half about a "revoked TA" still calls for the help of TAM. I >>> think we can remove the subscription sentence. A TA could be revoked >>> because it is compromised, or not offered anymore. Regarding the impact on >>> multi-user devices, a TA is shared. A revoked TA use case should apply to >>> all users, which will not have the concern you mentioned. Is this good? >>> >>> >>> I think we need to think about it from the TEE perspective. We should >>> say what would cause the TEE to delete a TA. >>> >>> >> MP: it tries to show a use case for the need of TA deletion. From a TEE >> perspective, it may delete a TA because of a request from a TAM. A TEEP >> Agent will be carrying out the deletion. I see your point about "privilege" >> that a developer was assumed to have. How about we revise the use case as >> the following? >> >> - A TA may need to be deleted from a device's TEE if the TA is >> compromised or >> the right of use of the TA is revoked from a particular user (or >> device). There could >> be cases where additional TAs should be installed that some prior TAs >> should be >> deleted to free up spaces. >> >> >> I think this is an improvement. >> >> >> >> >>> 4) Section 2 says: >>>> >>>> - Untrusted Application: An application running in a Rich Execution >>>> Environment. >>>> >>>> For alignment with the definition of a TA and te terms used in section >>>> 1, I think this should say: >>>> >>>> - Untrusted Application: An application component that runs in a >>>> REE. >>>> >>>> It is also useful to indicate that the Untrusted Application may be >>>> dependent on one or more TAs. >>>> >>>> >>> MP: Agree on the additional line. Not sure about changing "application" >>> to "component". An untrusted application intends to mean a regular client >>> application. Trusted application is an independent application; we don't >>> require that the two are strongly tied. Multiple untrusted applications can >>> call the same trusted application. >>> >>> >>> A TA is an "application component", so the Untrusted Application is also >>> an "application component", right? If not pick another term for both >>> definitions. >>> >>> >> MP: I filed this as an issue to welcome more comments. If we call >> "Untrusted Application" as "application component", it looks to me that the >> word "application" isn't a good fit here. >> >> >> I think you are missing my point. >> >> The document currently says: >> >> - Trusted Application (TA): An application component that runs in a >> TEE. >> >> and >> >> - Untrusted Application: An application running in a Rich Execution >> Environment. >> >> Why is one a component and the other not? >> >> >> >>> 5) Section 3.3 talks about the Internet of Things. It does not talk >>>> about the billions of devices being used to mount DDoS attacks. Can it >>>> cover that too? Without putting the network interface inside the TEE, I'm >>>> skeptical there is a solution. >>>> >>>> >>> MP: DDoS attack utilized insecure design that was triggered to send >>> queries. If all apps are inside TEE, those apps won't be misused. But not >>> sure the entire IoT can just use TEE that can still provide a network >>> interface as you mentioned. >>> >>> >>> I'm not sure what you are proposing to say in the document about DDoS. >>> >>> >> MP: I would suggest that we say >> >> "This doesn't prevent the devices being used to mount DDoS attacks where >> network interfaces are mostly hosted in the untrusted REE." >> >> Does it work? Thanks. >> >> >> Thanks. That resolves my point. >> >> >> >>> 6) Section 3.4 talks about Confidential Cloud Computing. Can something >>>> be said in Section 4.4.1 to make this less abstract? >>>> >>>> >>> MP: will work with co-authors on some text for review. >>> >>> 7) Section 4.1 defines CA incorrectly. A CA is not "Certificate-based >>>> credentials". A CA issues certificates, and the certificates are then used >>>> for authentication and cryptographic key management. This bullet should >>>> begin: "A CA is ..." to follow the pattern of the other bullets. >>>> >>>> >>> MP: how about the following changes? >>> >>> Certification Authority (CA): Certificate-based credentials used >>> for authenticating a device, a TAM and a TA developer. >>> >>> To >>> >>> Certification Authority (CA): A CA issues certificates that can be used >>> for authenticating a device, a TAM or a TA developer. Different CAs >>> >>> may be used for issuing certificates for a device, a TAM and a TA developer. >>> >>> >>> That seems fine. >>> >>> >> Thanks. >> >> >>> >>> 8) Section 4.3 introduces the term "TA software author" and "TA >>>> signer." I hope we ca pick one. Please add the term that is chosen to >>>> Section 2. >>>> >>>> >>> MP: prefer to pick "TA signer". Will add definition to Section 2. >>> >>> >>> Thank you. >>> >>> >>> 9) Section 4.4 should require support for both confidentiality and >>>> integrity protection. >>>> >>>> >>> MP: it currently says >>> >>> "Implementations must support >>> encryption of personalization data to preserve the confidentiality of >>> potentially sensitive data contained within it." >>> >>> Agreed. We should add integration protection support too. How about the following? >>> >>> "Implementations must support >>> encryption of personalization data to preserve the confidentiality of >>> potentially sensitive data contained within it and support integrity protection." >>> >>> >>> I'm glad you added integrity protection, not "integration protection" as >>> you said above! >>> >>> >> MP: good catch :) >> >>> >>> 10) Should GlobalPlatform be added to Section 4.4.1? >>>> >>>> >>> MP: GP TEE can be referred to in the TrustZone section. How about the >>> following? >>> >>> "A TA is loaded by a trusted OS running in the TEE such as a GlobalPlatform compliant TEE," >>> >>> >>> This section has a paragraph about ARM and Intel TEEs. Elsewhere the >>> document talks about GlobalPlatform. I think it should get a paragraph too >>> so that the reader can compare and contrast the three TEEs. >>> >>> >> MP: I will file an issue to fix this per your recommendation. >> >> >>> 11) Section 4.5 uses the term "TA binary signers" and "TA signer". >>>> Please see comment 8 above. >>>> >>>> >>> MP: "TA signer" >>> >>> 12) Section 5 says: "... encrypted with the TAM public key ...". This >>>> is not correct. The TAM public key is used to establish the key that is >>>> then used for encryption and decryption. Further the wording is aimed at >>>> RSA, which is a key transport algorithm. Please make the wording >>>> accommodate key transport and key agreement approaches. >>>> >>>> >>> MP: will revise this, and file it in Github issue tracker for text >>> revision. >>> >>> 13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA"; >>>> however, Section 1 said that a trust anchor could be a raw public key... >>>> Can the TAM use the raw trust anchor key directly? >>>> >>>> >>> MP: It isn't a common case to use a fixed public key as a trusted anchor >>> instead of a CA certificate. How about allowing a TAM to use a self-signed >>> certificate? It accommodates both. >>> >>> >>> That does not align with the discussion of what a trust anchor is in RFC >>> 5280. I think the raw key needs to be allowed, even it if is not the most >>> popular choice in current implementations. For example, TLS did not >>> originally allow raw public keys, but it was added later. Here, all of the >>> foundational specifications already allow it, so I do not think it is wise >>> to prohibit raw public keys. >>> >>> >> MP: appreciate the additional comments. Will revise to allow the use of a >> raw public key. >> >> >> Thanks. >> >> >> >>> 14) Section 5.2 and Section 5.3 should allow signatures to be directly >>>> by the trust anchor. The current working requires a certification path. >>>> >>>> >>> MP: we assume that signer and the intermediate CAs up to the trust >>> anchor but not include a trust anchor are sent in a signature payload. This >>> can establish a certificate path. Do you mean this about "directly by the >>> trust anchor"? We need to allow intermediate CAs. We can revise the >>> paragraph to elaborate on this if you agree... >>> >>> >>> No. Please look at RFC 5934. Signatures are verified by the trust >>> anchor itself or by the public key in a certificate that validates to the >>> trust anchor. >>> >>> >> MP: so the trust anchor contains those additional information per my >> quick reading, right? Will make the revision per your confirmation. >> >> >> I think this is resolved by your response to my comment 13. >> >> >> >>> 15) Section 5.4 says that "self-signed certificates" are allowed. I >>>> think this is the same as allowing signatures to be directly by the trust >>>> anchor. Please consider this comment in conjunction with comment 13 above. >>>> >>>> >>> MP: please see above #13 comment. >>> >>> 16) Section 7 says that there are "different attestation algorithms". >>>> Does this mean different set of claims? Please be more clear here. >>>> >>>> >>> MP: it currently means algorithm agility and algorithms may be different >>> for different devices. Different set of claims from different algorithms >>> from one device is possible but not necessary, I think. A verifier is >>> expected to support all the supported algorithms such that it doesn't have >>> to require different claims to get one working. >>> >>> We will clarify the text. >>> >>> 17) I think the discussion about "assumptions" would be better written >>>> as things that need to be considered when assessing the degree of >>>> confidence in the claim by the TEE, >>>> >>>> >>> MP: will track this as an issue to revise. >>> >>> 18) Section 18: Asymmetric algorithms are also used to manage the >>>> symmetric keys. Symmetric algorithms are also used for data integrity. >>>> >>>> >>> MP: will revise it to reflect both points. >>> >>> Symmetric algorithms are used for encryption >>> of content whereas the asymmetric algorithms are mostly used for >>> signing messages. >>> >>> ==> >>> >>> Symmetric algorithms are used for encryption >>> of content and data integrity whereas the asymmetric algorithms are mostly used for >>> signing messages and managing symmetric keys. >>> >>> >>> Thanks. I think you can drop "mostly". >>> >>> >> MP: thank you. I filed an issue to fix, and dropped "mostly". >> >> >> Thanks. >> >> >>> 19) Section 9.4: Please expand this discussion to cover compromised >>>> trust anchors and compromised intermediate CAs. >>>> >>>> >>> MP: will file an issue to add this. >>> >>> 20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, >>>> which tells how to make a device certificate that never expires. >>>> >>>> >>> MP: will add a sentence to indicate this possibility. >>> >>> " >>> >>> TEE device certificates are expected to be long lived, longer than >>> the lifetime of a device." >>> >>> ==> >>> >>> "TEE device certificates are expected to be long lived, longer than >>> the lifetime of a device. They can be certificates that never expire >>> as defined in the Section 4.1.2.5 of RFC 5280." >>> >>> >>> 21) Please add references for SGX and TrustZone, adding the citations in >>>> the body as appropriate. >>>> >>>> >>> MP: will add. >>> >>> >> Russ >> >> > --000000000000aeceff05a3fc635c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Russ. Will update to reflect this, Ming
On Thu, = Apr 23, 2020 at 2:58 PM Russ Housley <housley@vigilsec.com> wrote:


On Apr 23, 2020, at 5:55 PM, Mingliang= Pei <mi= ngliang.pei@broadcom.com> wrote:

Hi Russ, please see inline about the "application compone= nt". I understood that you want consistency. My argument is that I wou= ld rather choose to say "application" in both cases without the w= ord "component" instead of calling both "application compone= nt".

The do= cument currently says:

=C2=A0 =C2=A0- =C2=A0T= rusted Application (TA): An application component that runs in a
= =C2=A0 =C2=A0 =C2=A0 TEE.

and

=
=C2=A0 =C2=A0- =C2=A0Untrusted Application: An application runnin= g in a Rich Execution
=C2=A0 =C2=A0 =C2=A0 Environment.

=3D=3D>

The document curre= ntly says:

=C2=A0 =C2=A0- =C2=A0Trusted Appli= cation (TA): An application that runs in a
=C2=A0 =C2=A0 =C2=A0 T= EE.

and

=C2=A0 =C2= =A0- =C2=A0Untrusted Application: An application that runs in a Rich Execut= ion
=C2=A0 =C2=A0 =C2=A0 Environment.

Do= es this work?

That works fine.=C2=A0 The inconsistency was the only i= ssue.

Russ


=

Thanks,
<= div>
Ming

On Thu, Apr 23, 2020 at 2:32 PM Russ= Housley <hous= ley@vigilsec.com> wrote:


On Apr 22,= 2020, at 2:11 AM, Mingliang Pei <mingliang.pei=3D40broadcom.com= @dmarc.ietf.org> wrote:

Hi Russ, thank you for your replies. Please see inline. BTW, I hav= e filed the agreed ones or ones needing revision in the github issue sectio= n. Best, Ming


On Tue, Apr 21, 2020 at 9:53 AM Russ Housley <housley@vigilsec.com= > wrote:
=


On Apr 21, 2020, at 5:32 A= M, Mingliang Pei <mingliang.pei=3D40broadcom.com@dmarc.ietf.org<= /a>> wrote:

Hi Russ= ,

Thank you very much for your detailed review, su= ggestions and nits. Please see inline. Best,

M= ing


On Fri, Apr 17, 2020 at 1:37 PM Russ Housley <housley@vigilsec.co= m> wrote:
On the last TEEP call, I agreed to review the TEEP Architecture document.= =C2=A0 Here are my comments and questions.

1) Section 1 says:

=C2=A0 =C2=A0Typically, application components are chosen to execute inside= a TEE
=C2=A0 =C2=A0because those application components perform security sensitiv= e
=C2=A0 =C2=A0operations or operate on sensitive data.

Recognizing that this is the introduction, I was wondering if you could pro= vide a bit more explanation here.=C2=A0 Earlier in the paragraph, the docum= ent offers an example of a banking application.=C2=A0 There would be compon= ents of such and application that are trusted, and other components would b= e untrusted. This concept is described, but the coupling to make a complete= application could be more explicit to prepare the reader for the detail th= at is coming.=C2=A0 Within such an application, it would be good to offer a= n example of a security sensitive operations and a separate example of oper= ating on sensitive data.

MP: we will pr= ovide two examples as you suggested. We will file this in issue tracker for= a fix.


2) Section 1 says:

=C2=A0 =C2=A0To simplify the life of TA developers interacting with TAs in = a TEE,
=C2=A0 =C2=A0an interoperable protocol for managing TAs running in differen= t TEEs
=C2=A0 =C2=A0of various devices is needed.

This feels incomplete to me.=C2=A0 Making sure that compatible trusted and = untrusted components of an application are installed on the same device is = vital when they are not bundled.


MP: how about the following?

=C2=A0=C2=A0 To simplify the life of TA developers interact= ing with TAs in a TEE,
=C2=A0 =C2=A0an interoperable protocol for managing TAs running in differen= t TEEs
=C2=A0 =C2=A0of various devices is needed in order for an untrusted applica= tion to use.

I think= this is a big improvement.


3) Section 1 offers:

=C2=A0 =C2=A0-=C2=A0 A TA developer wants to remove a confidential TA from = a device's
=C2=A0 =C2=A0 =C2=A0 TEE if the TA developer is no longer offering such TAs= or the TAs
=C2=A0 =C2=A0 =C2=A0 are being revoked from a particular user (or device).= =C2=A0 For
=C2=A0 =C2=A0 =C2=A0 example, if a subscription or contract for a particula= r service
=C2=A0 =C2=A0 =C2=A0 has expired, or a payment by the user has not been com= pleted or
=C2=A0 =C2=A0 =C2=A0 has been rescinded.

This implies that the TA developer has some of the privileges that I associ= ate with the TAM.=C2=A0 Yes, I see the note at the end of the bullets, but = I think this is an indication that the privileges are not quite right for t= hese roles.=C2=A0 Also, if I was writing a TA for a subscription, I would h= ave the TA perform some form of payment checking, and then refuse to decryp= t the content if the payment checking fails.=C2=A0 Perhaps the REE passes a= signed proof of payment.=C2=A0 This way, the TA developer does not need to= actually have permission to remove a TA. Further, if the TA is on a multi-= user device, removing the TA would adversely impact other users.


MP: the subscription example doesn'= ;t fully need TA removal as you said. The first half about a "revoked = TA" still calls for the help of TAM. I think we can remove the subscri= ption sentence. A TA could be revoked because it is compromised, or not off= ered anymore. Regarding the impact on multi-user devices, a TA is shared. A= revoked TA use case should apply to all users, which will not have the con= cern you mentioned. Is this good?
<= div>
I think we need to think about it from the TEE perspective.= =C2=A0 We should say what would cause the TEE to delete a TA.

MP: it tries to show a use ca= se for the need of TA deletion. From a TEE perspective, it may delete a TA = because of a request from a TAM. A TEEP Agent will be carrying out the dele= tion. I see your point about "privilege" that a developer was ass= umed to have. How about we revise the use case as the following?
=
-=C2=A0 A TA may need to be deleted from a device's TEE = if the TA is compromised or
=C2=A0=C2=A0 the right of use of the = TA is revoked from a particular user (or device). There could
=C2= =A0=C2=A0 be cases where additional TAs should be installed that some prior= TAs should be
=C2=A0 deleted to free up spaces.

I think this is an improvement.



4) Section 2 says:

=C2=A0 =C2=A0-=C2=A0 Untrusted Application: An application running in a Ric= h Execution
=C2=A0 =C2=A0 =C2=A0 Environment.

For alignment with the definition of a TA and te terms used in section 1, I= think this should say:

=C2=A0 =C2=A0-=C2=A0 Untrusted Application: An application component that r= uns in a
=C2=A0 =C2=A0 =C2=A0 REE.

It is also useful to indicate that the Untrusted Application may be depende= nt on one or more TAs.


MP: Agree on the additional line. Not = sure about changing "application" to "component". An un= trusted application intends to mean a regular client application. Trusted a= pplication is an independent application; we don't require that the two= are strongly tied. Multiple untrusted applications can call the same trust= ed application.

A TA= is an "application component", so the Untrusted Application is a= lso an "application component", right?=C2=A0 If not pick another = term for both definitions.


=
MP: I filed this as an issue to welcome more comments. If we cal= l "Untrusted Application" as "application component", i= t looks to me that the word "application" isn't a good fit he= re.

I think you are = missing my point.

The document currently says:

=C2=A0 =C2=A0- =C2=A0Trusted Application (TA): A= n application component that runs in a
=C2=A0 =C2=A0 =C2=A0 TEE.<= /div>

and

=C2=A0 =C2=A0- = =C2=A0Untrusted Application: An application running in a Rich Execution
=C2=A0 =C2=A0 =C2=A0 Environment.

Why is one a component and the other not?


=

5) Section 3.3 talks about the Internet of Things.=C2=A0 It does not talk a= bout the billions of devices being used to mount DDoS attacks.=C2=A0 Can it= cover that too?=C2=A0 Without putting the network interface inside the TEE= , I'm skeptical there is a solution.


MP: DDoS attack utilized insecure desi= gn that was triggered to send queries. If all apps are inside TEE, those ap= ps won't be misused. But not sure the entire IoT can just use TEE that = can still provide a network interface as you mentioned.

I'm not sure what you are proposing= to say in the document about DDoS.

=

MP: I would suggest that we say

"This doesn't prevent the devices being used to mount DDoS = attacks where network interfaces are mostly hosted in the untrusted REE.&qu= ot;

Does it work? Thanks.

Thanks.=C2=A0 That resolves my point.



6) Section 3.4 talks about Confidential Cloud Computing.=C2=A0 Can somethin= g be said in Section 4.4.1 to make this less abstract?


MP: will work with co-authors on some = text for review.

7) Section 4.1 defines CA incorrectly.=C2=A0 A CA is not "Certificate-= based credentials".=C2=A0 A CA issues certificates, and the certificat= es are then used for authentication and cryptographic key management.=C2=A0= This bullet should begin: "A CA is ..." to follow the pattern of= the other bullets.


MP: how about the following changes?

Certifica=
tion Authority (CA): Certificate-based credentials used
      for authenticating a device, a TAM and a TA developer.

To
<=
br>Certification Authority (CA): A CA issues certificates that can be used
      for authenticating a device, a TAM or a TA developer. Different CAs
      may be used for iss=
uing certificates for a device, a TAM and a TA developer.

That seems fine.

=

Thanks.

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


8) Section 4.3 introduces the term "TA software author" and "= ;TA signer."=C2=A0 I hope we ca pick one.=C2=A0 Please add the term th= at is chosen to Section 2.


MP: prefer to pick "TA signer&quo= t;. Will add definition to Section 2.

Thank you.

<= div dir=3D"ltr">

9) Section 4.4 should require support for both confidentiality and integrit= y protection.


MP: it currently says=C2=A0
= 
   "Implementations must=
 support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it."

Agreed. We should add integration prot=
ection support too. How about the following?

   "Implementation=
s must support
   encryption of personalization data to preserve the confidentiality of
   potentially sensitive data contained within it and support integrity pro=
tection."

I'm glad you added integrity protection, not "integration protect= ion" as you said above!

MP: good catch :)
<= div class=3D"gmail_quote">

10) Should GlobalPlatform be added to Section 4.4.1?


MP: GP TEE can be referred to in the T= rustZone section. How about the following?

"A TA is loaded by a trusted OS= running in the TEE such as a GlobalPlatform compliant TEE,"

This section has a paragrap= h about ARM and Intel TEEs.=C2=A0 Elsewhere the document talks about=C2=A0G= lobalPlatform.=C2=A0 I think it should get a paragraph too so that the read= er can compare and contrast the three TEEs.


MP: I will file an issue to fix this per your r= ecommendation.


11) Section 4.5 uses the term "TA binary signers" and "TA si= gner".=C2=A0 Please see comment 8 above.


MP: "TA signer"

12) Section 5 says: "... encrypted with the TAM public key ...".= =C2=A0 This is not correct.=C2=A0 The TAM public key is used to establish t= he key that is then used for encryption and decryption.=C2=A0 Further the w= ording is aimed at RSA, which is a key transport algorithm.=C2=A0 Please ma= ke the wording accommodate key transport and key agreement approaches.


MP: will revise this, and file it in G= ithub issue tracker for text revision.

13) Section 5.1 says that a TAM obtains "a TAM certificate from a CA&q= uot;; however, Section 1 said that a trust anchor could be a raw public key= ...=C2=A0 Can the TAM use the raw trust anchor key directly?


MP: It isn't a common case to use = a fixed public key as a trusted anchor instead of a CA certificate. How abo= ut allowing a TAM to use a self-signed certificate? It accommodates both.

That does not align w= ith the discussion of what a trust anchor is in RFC 5280.=C2=A0 I think the= raw key needs to be allowed, even it if is not the most popular choice in = current implementations.=C2=A0 For example, TLS did not originally allow ra= w public keys, but it was added later.=C2=A0 Here, all of the foundational = specifications already allow it, so I do not think it is wise to prohibit r= aw public keys.


= MP: appreciate the additional comments. Will revise to allow the use of a r= aw public key.

Thank= s.



14) Section 5.2 and Section 5.3 should allow signatures to be directly by t= he trust anchor.=C2=A0 The current working requires a certification path.

MP: we assume that signer and the inte= rmediate CAs up to the trust anchor but not include a trust anchor are sent= in a signature payload. This can establish a certificate path. Do you mean= this about "directly by the trust anchor"? We need to allow inte= rmediate CAs. We can revise the paragraph to elaborate on this if you agree= ...

No.=C2=A0 Please= look at RFC=C2=A05934.=C2=A0 Signatures are verified by the trust anchor i= tself or by the public key in a certificate that validates to the trust anc= hor.


MP: so the = trust anchor contains those additional information per my quick reading, ri= ght? Will make the revision per your confirmation.

I think this is resolved by your response to= my comment 13.



15) Section 5.4 says that "self-signed certificates" are allowed.= =C2=A0 I think this is the same as allowing signatures to be directly by th= e trust anchor.=C2=A0 Please consider this comment in conjunction with comm= ent 13 above.


MP: please see above #13 comment.
<= /div>

16) Section 7 says that there are "different attestation algorithms&qu= ot;.=C2=A0 Does this mean different set of claims?=C2=A0 Please be more cle= ar here.


MP: it currently means algorithm agili= ty and algorithms may be different for different devices. Different set of = claims from different algorithms from one device is possible but not necess= ary, I think. A verifier is expected to support all the supported algorithm= s such that it doesn't have to require different claims to get one work= ing.

We will clarify the text.

=
17) I think the discussion about "assumptions" would be better wr= itten as things that need to be considered when assessing the degree of con= fidence in the claim by the TEE,


MP: will track this as an issue to rev= ise.

18) Section 18: Asymmetric algorithms are also used to manage the symmetric= keys.=C2=A0 Symmetric algorithms are also used for data integrity.


MP: will revise it to reflect both poi= nts.

Sym=
metric algorithms are used for encryption
   of content whereas the asymmetric algorithms are mostly used for
   signing messages.

=3D=3D>

Symmetric algorithms are used=
 for encryption
   of content and data integrity whereas the asymmetric algorithms are most=
ly used for
   signing messages and managing symmetric keys.

Thanks.=C2=A0 I think you can drop "= ;mostly".


M= P: thank you. I filed an issue to fix, and dropped "mostly".
=

Thanks.

<= blockquote type=3D"cite">
<= 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">
=
19) Section 9.4: Please expand this discussion to cover compromised trust a= nchors and compromised intermediate CAs.


MP: will file an issue to add this.

20) Section 9.7: You may want to point to Section 4.1.2.5 of RFC 5280, whic= h tells how to make a device certificate that never expires.


MP: will add a sentence to indicate th= is possibility.

"
TEE device certificates are expected to be long lived, lo=
nger than
   the lifetime of a device."

=3D=3D>

"TEE devic=
e certificates are expected to be long lived, longer than
   the lifetime of a device. They can be certificates that never expire    as defined in the Section 4.1.2.5 of RFC 5280."
<= br>
21) Please add references for SGX and TrustZone, adding the citations in th= e body as appropriate.


MP: will add.
<= /blockquote>
Russ


--000000000000aeceff05a3fc635c-- --000000000000b6bb8105a3fc639a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQRQYJKoZIhvcNAQcCoIIQNjCCEDICAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg2aMIIE6DCCA9CgAwIBAgIOSBtqCRO9gCTKXSLwFPMwDQYJKoZIhvcNAQELBQAwTDEgMB4GA1UE CxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMT Ckdsb2JhbFNpZ24wHhcNMTYwNjE1MDAwMDAwWhcNMjQwNjE1MDAwMDAwWjBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tpZok2X9LAHsYqMNVL+Ly6RDkaKar7GD8rVtb9nw6tzPFnvXGeOEA4X5xh9wjx9sScVpGR5wkTg1 fgJIXTlrGESmaqXIdPRd9YQ+Yx9xRIIIPu3Jp/bpbiZBKYDJSbr/2Xago7sb9nnfSyjTSnucUcIP ZVChn6hKneVGBI2DT9yyyD3PmCEJmEzA8Y96qT83JmVH2GaPSSbCw0C+Zj1s/zqtKUbwE5zh8uuZ p4vC019QbaIOb8cGlzgvTqGORwK0gwDYpOO6QQdg5d03WvIHwTunnJdoLrfvqUg2vOlpqJmqR+nH 9lHS+bEstsVJtZieU1Pa+3LzfA/4cT7XA/pnwwIDAQABo4IBtTCCAbEwDgYDVR0PAQH/BAQDAgEG MGoGA1UdJQRjMGEGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwkGCisGAQQBgjcUAgIGCisG AQQBgjcKAwQGCSsGAQQBgjcVBgYKKwYBBAGCNwoDDAYIKwYBBQUHAwcGCCsGAQUFBwMRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFGlygmIxZ5VEhXeRgMQENkmdewthMB8GA1UdIwQYMBaA FI/wS3+oLkUkrk1Q+mOai97i3Ru8MD4GCCsGAQUFBwEBBDIwMDAuBggrBgEFBQcwAYYiaHR0cDov L29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3Js Lmdsb2JhbHNpZ24uY29tL3Jvb3QtcjMuY3JsMGcGA1UdIARgMF4wCwYJKwYBBAGgMgEoMAwGCisG AQQBoDIBKAowQQYJKwYBBAGgMgFfMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNp Z24uY29tL3JlcG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQConc0yzHxn4gtQ16VccKNm4iXv 6rS2UzBuhxI3XDPiwihW45O9RZXzWNgVcUzz5IKJFL7+pcxHvesGVII+5r++9eqI9XnEKCILjHr2 DgvjKq5Jmg6bwifybLYbVUoBthnhaFB0WLwSRRhPrt5eGxMw51UmNICi/hSKBKsHhGFSEaJQALZy 4HL0EWduE6ILYAjX6BSXRDtHFeUPddb46f5Hf5rzITGLsn9BIpoOVrgS878O4JnfUWQi29yBfn75 HajifFvPC+uqn+rcVnvrpLgsLOYG/64kWX/FRH8+mhVe+mcSX3xsUpcxK9q9vLTVtroU/yJUmEC4 OcH5dQsbHBqjMIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNV BAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5BngiFvXAg7aE yiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X17YUhhB5 uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmmKPZpO/bL yCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hpsk+QLjJg 6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7DWzgVGkW qQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBLQNvAUKr+ yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25sbwMpjjM5 RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV3XpYKBov Hd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyrVQ4PkX42 68NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E7gUJTb0o 2HLO02JQZR7rkpeDMdmztcpHWD9fMIIFRzCCBC+gAwIBAgIMJplVpW1Hq+2ySMVcMA0GCSqGSIb3 DQEBCwUAMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMwHhcNMjAwMjIxMTM1 NjQ5WhcNMjMwMjIxMTM1NjQ5WjCBkDELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5hdGFrYTES MBAGA1UEBxMJQmFuZ2Fsb3JlMRYwFAYDVQQKEw1Ccm9hZGNvbSBJbmMuMRYwFAYDVQQDEw1NaW5n bGlhbmcgUGVpMSkwJwYJKoZIhvcNAQkBFhptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALnj+oLejidhAhfIueq2R6kYf0xTddM81r4s9meY /vZiDe5epFRqRGhg8qsgW+LX2vtv5qe0r507+X2VQsqdL1dSQx8M0kMLqddYl9s9fYj12Qz191+J BI196cW/js96aA0aHpvT2jHIZ8n1+L0r9g4uKFt+VV1Z6ZfECZlMC8EZtCv8KXfBfH2dFJ10k+Qg dV+/KUMC2CYgdiIOynoP5Y9FQTcMM0dg8ToVGkdb7gqODxvU8zKuzBF7AY4YdNs03WCZAa5I+84n DiOJCQwyp+y3WJ7BkQq96LxuuJNS6X0YMhujGmUCdlc4BCX9O+8ICz/jTWGhpq+BLGt4hakkdTEC AwEAAaOCAdEwggHNMA4GA1UdDwEB/wQEAwIFoDCBngYIKwYBBQUHAQEEgZEwgY4wTQYIKwYBBQUH MAKGQWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMnNo YTJnM29jc3AuY3J0MD0GCCsGAQUFBzABhjFodHRwOi8vb2NzcDIuZ2xvYmFsc2lnbi5jb20vZ3Nw ZXJzb25hbHNpZ24yc2hhMmczME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIB FiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hh MmczLmNybDAlBgNVHREEHjAcgRptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTATBgNVHSUEDDAK BggrBgEFBQcDBDAfBgNVHSMEGDAWgBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAdBgNVHQ4EFgQUpStv 0AghsERl1TBx5BXhBfzYSicwDQYJKoZIhvcNAQELBQADggEBAFfbbvFJ0WbPYEGcnklrQKfu9s9k KNImqVdomu0FZ6RxOMLGXBmxRTY4Qy0K4rFKkQ+aYT2iWIBBZrHYs6b+xbLAusU8U4WaO+twZeDC IbMNGJ0PCCHe9IYMy1oOK1M7YqufFR3ZGom/ElDbPPBeBt5P6IfZmm+maiU3vOjI15ZIItZKbBlO O6xVaIUhmfNI6jeHo9qRM2JD+PFUDysuPBEI+udCfjCF1jOP+coa/xLFckMJAhHZw8jJGn1Ja1CC p23PR6TUH/Lxkcj5Y+oyx5sGusPp4jW30ONNtGo5+v6UavWPW4/0LMVJGma3LEJ29R18FOu9Fe/s 1NCEczpRDycxggJvMIICawIBATBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0g RzMCDCaZVaVtR6vtskjFXDANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg1JZ0XFGz ehd8S3UyIdS8pvS2EshctHV6IKsL3Lyn0kUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMjAwNDIzMjIwMTIzWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG 9w0BAQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAAVuOFxPbRasUrAS1ciKhPUbDb3W WUdk3/0WvD787CX7UZkuEmgsQ7X9sf2+I+GybZIobmcSxtAiNQsknCwLPnOsWPPNXEwQxAIS2pdj O4DPj3sBDRAuGuHrm1cdLrqLN3ZNu8UB5rZ+tgDxo8lz1iz26/avCjLH4dBr9bBqcnFRaFfELawn +/d5n0WD+IrM4XHEoAabRQx7+dk3bMyKgErVkSjzxd5SIDNraK9semhIqVRKBwfo7J+Kp5hlYJv7 urjOHlwqrN0ulMEy18SYMOrVWGEZgdg2Lg9B79ubSRJ+M8+CUkuzgiuYW4jjqi+lEbWjnwN9G7OA O09kVT6ionM= --000000000000b6bb8105a3fc639a-- From nobody Thu Apr 23 22:13:37 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 72E203A0B8A for ; Thu, 23 Apr 2020 22:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=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 KU98wL2uHV6k for ; Thu, 23 Apr 2020 22:13:33 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 C290E3A0AC9 for ; Thu, 23 Apr 2020 22:13:28 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id j14so6624850lfg.9 for ; Thu, 23 Apr 2020 22:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=XpIcpAEps14LLiq/Ln+b3+1CHetaEOwwP89SNAjlFqc=; b=YM6k3SdL3pgveK/2A5pgFUtIIm65O2I4NHoPUhGQccKe+drKsCNl9KfV8iB60eEIpI zm6jSDhi3wfOtKUWz5W6nqLOBbaAOojeQJ6ypchG8Bhp0oZ4R8hQHTfmHEAvGWxQc/Lm raCISq6Uk2+RbrUOvQ8CeA03AkONvBmx9EwgQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XpIcpAEps14LLiq/Ln+b3+1CHetaEOwwP89SNAjlFqc=; b=HHp4w1I6Pi/y+1uWYqo899c1MG16iuHlLCUB1OXUCQjUp/whU6gxuCN9eo6RtjlZaH jbfvQo22DJXsWs83FTxEWgYfVWGaPPW9lAfdCo6nehv2jy++8ClwxoITOTn3j6t5OBxN L0nay5BLa0IIrkQZvgHhzpAsLAr6ud08tjjmnUHkJLgzWCHlJjIA98l3WUZuBS3CeeIs enyqXaFRK9TedNzfeSOrRdbkQn1t7E2GDFxvdUAJ+tyNQ5YKERWOd8hgnv7dpLtkg3+g JhaLWl2sF2MzFBeWAhL/y5Cpqcrntfi6GHROVCkKgH0WZXZz3dvOyYuGVszWHIc7RqJf DfOw== X-Gm-Message-State: AGi0Pua2s1w+StlfAiiWBb4zkEL/T3F/yml+vorR41m0ncip9kHkeKSv gHOiw6ETgzS2mdCE1VNBftqz9i9atLkLPnHe958EwIUIi1o= X-Google-Smtp-Source: APiQypJjwFv2p9nHmHJ0sL8Gt82gXmj4EjOG9bskmPHdx/v6fOUGdRlkIGKXTwY9sZ2VYrT2mW7zmx7YNLYCgdTZ9ss= X-Received: by 2002:a19:f611:: with SMTP id x17mr5014595lfe.51.1587705206289; Thu, 23 Apr 2020 22:13:26 -0700 (PDT) MIME-Version: 1.0 From: Mingliang Pei Date: Thu, 23 Apr 2020 22:13:15 -0700 Message-ID: To: teep Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d97a8605a4026caf" Archived-At: Subject: [Teep] Review of draft https://tools.ietf.org/html/draft-ietf-teep-otrp-over-http-06 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, 24 Apr 2020 05:13:36 -0000 --000000000000d97a8605a4026caf Content-Type: multipart/alternative; boundary="000000000000d4711805a4026c3b" --000000000000d4711805a4026c3b Content-Type: text/plain; charset="UTF-8" On the last TEEP call, I agreed to review the TEEP HTTP transport draft. Here are my comments and questions. 1) Abstract section says "is used to manage code and configuration data" Should it just say manage "Trusted Applications" as this can assume the context defined in TEEP architecture and TEEP protocol document. 2) It also says "a Trusted Application Manager (TAM) service is used to manage TEEs in devices that can initiate communication to the TAM." A TAM doesn't manage TEEs. Suggest change it to "manage Trusted Applications". TEEs don't initiate communication to the TAM. Suggest change it to "TEEP Agent". 3) Section 1 says "a "Trusted Application Manager(TAM)" on the server side) must themselves run inside a TEE." This specification shouldn't set this as a requirement. A TAM in a secure data center that passes certain security requirements could be acceptable to some devices. 4) Section 2 says "and TEEP Broker, and Rich Execution Environment (REE)" The first "and" could be removed? 5) Section 3: The hyperlink of "Section 6" doesn't point to the TEEP architecture document. 6) Section 5.1: "The TEEP/HTTP Client then informs the TEEP implementation" and "The TEEP implementation will either (a) pass no data back,..." Should this TEEP implementation mean the "TEEP Agent" inside the TEE? 7) Section 5.4 says "An implementation MUST provide a way to periodically check for TEEP policy changes." TEEP policy hasn't been defined so far yet. Good to provide some examples of this, and where they are defined and who defines them. Will it mean TEEP client policy or TEEP server policy? The TA revocation status check in B) may not mean a policy; the time frequency to check TA revocation would be a policy. 8) Section 7 says "The TEEP/HTTP Client calls the TEEP implementation's "RequestTA" API, passing TA Needed = X." Should it be calling "TEEP Agent"? So far, we assume that all communications to TEEP in TEE will go through TEEP Agent. In step 3 below, it indicates that "The TEEP Agent passes the TAM URI..." 9) Step 8 says "Back on the TEEP Agent side" Does it mean "TEEP Broker side"? 10) Step 9: shouldn't the TEEP Agent be involved in this communication? 11) Step 11 says "passes the payload up to the TAM implementation." To be consistent with step 5 above, "TAM implementation" changes to "TEEP implementation" or "TAM TEEP Implementation". Nits: Section 4: s/upon a following such a redirect/upon following such a redirect Section 5.1: s/the TEEP/HTTP Client attempts to create session state/the TEEP/HTTP Client attempts to create a session state Ming --000000000000d4711805a4026c3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On the last TEEP call, I agreed to review the TEEP HT= TP transport draft. Here are my comments and questions.

<= /div>
1) Abstract section says "is used to manage code and configu= ration data"

Should it just say manage "Trusted Applicatio= ns" as this can
assume the context defined in TEEP architecture and= TEEP protocol
document.

2) It also says "a Trusted Applicat= ion Manager (TAM) service
=C2=A0 =C2=A0is used to manage TEEs in devices= that can initiate communication to
=C2=A0 =C2=A0the TAM."

A= TAM doesn't manage TEEs. Suggest change it to "manage Trusted App= lications".
TEEs don't initiate communication to th= e TAM. Suggest change it to "TEEP Agent".

3) Section 1 say= s "a "Trusted Application Manager(TAM)" on the server side) = must
themselves run inside a TEE."

This specification should= n't set this as a requirement. A TAM in a secure data
center that pa= sses certain security requirements could be acceptable to some devices.
=
4) Section 2 says "and TEEP Broker, and Rich Execution Environment= (REE)"

The first "and" could be removed?

5) S= ection 3: The hyperlink of "Section 6" doesn't point to the T= EEP architecture document.

6) Section 5.1: "The TEEP/HTTP Clien= t then informs the TEEP implementation" and
"The TEEP implemen= tation will either (a) pass no data back,..."

Should this TEEP = implementation mean the "TEEP Agent" inside the TEE?

7) Se= ction 5.4 says "An implementation MUST provide a way to periodically c= heck for TEEP
=C2=A0 =C2=A0policy changes."

TEEP policy hasn= 't been defined so far yet. Good to provide some examples of this,
a= nd where they are defined and who defines them. Will it mean TEEP client po= licy
or TEEP server policy? The TA revocation status check in B) may not= mean a policy; the
time frequency to check TA revocation would be a pol= icy.

8) Section 7 says "The TEEP/HTTP Client calls the TEEP imp= lementation's "RequestTA"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 API,= passing TA Needed =3D X."

Should it be calling "TEEP Agen= t"? So far, we assume that all communications to
TEEP in TEE will g= o through TEEP Agent. In step 3 below, it indicates that
"The TEEP = Agent passes the TAM URI..."

9) Step 8 says "Back on the T= EEP Agent side"

Does it mean "TEEP Broker side"?
<= br>10) Step 9: shouldn't the TEEP Agent be involved in this communicati= on?

11) Step 11 says "passes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the= payload up to the TAM implementation."

To be consistent with s= tep 5 above, "TAM implementation" changes to "TEEP implement= ation"
or "TAM TEEP Implementation".

Nits:

= Section 4: s/upon a following such a redirect/upon following such a redirec= t
Section 5.1: s/the TEEP/HTTP Client attempts to create session state/t= he TEEP/HTTP Client attempts to create a session state

=
Ming

--000000000000d4711805a4026c3b-- --000000000000d97a8605a4026caf Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQRQYJKoZIhvcNAQcCoIIQNjCCEDICAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg2aMIIE6DCCA9CgAwIBAgIOSBtqCRO9gCTKXSLwFPMwDQYJKoZIhvcNAQELBQAwTDEgMB4GA1UE CxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMT Ckdsb2JhbFNpZ24wHhcNMTYwNjE1MDAwMDAwWhcNMjQwNjE1MDAwMDAwWjBdMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEzMDEGA1UEAxMqR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIFNIQTI1NiAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA tpZok2X9LAHsYqMNVL+Ly6RDkaKar7GD8rVtb9nw6tzPFnvXGeOEA4X5xh9wjx9sScVpGR5wkTg1 fgJIXTlrGESmaqXIdPRd9YQ+Yx9xRIIIPu3Jp/bpbiZBKYDJSbr/2Xago7sb9nnfSyjTSnucUcIP ZVChn6hKneVGBI2DT9yyyD3PmCEJmEzA8Y96qT83JmVH2GaPSSbCw0C+Zj1s/zqtKUbwE5zh8uuZ p4vC019QbaIOb8cGlzgvTqGORwK0gwDYpOO6QQdg5d03WvIHwTunnJdoLrfvqUg2vOlpqJmqR+nH 9lHS+bEstsVJtZieU1Pa+3LzfA/4cT7XA/pnwwIDAQABo4IBtTCCAbEwDgYDVR0PAQH/BAQDAgEG MGoGA1UdJQRjMGEGCCsGAQUFBwMCBggrBgEFBQcDBAYIKwYBBQUHAwkGCisGAQQBgjcUAgIGCisG AQQBgjcKAwQGCSsGAQQBgjcVBgYKKwYBBAGCNwoDDAYIKwYBBQUHAwcGCCsGAQUFBwMRMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFGlygmIxZ5VEhXeRgMQENkmdewthMB8GA1UdIwQYMBaA FI/wS3+oLkUkrk1Q+mOai97i3Ru8MD4GCCsGAQUFBwEBBDIwMDAuBggrBgEFBQcwAYYiaHR0cDov L29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3RyMzA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3Js Lmdsb2JhbHNpZ24uY29tL3Jvb3QtcjMuY3JsMGcGA1UdIARgMF4wCwYJKwYBBAGgMgEoMAwGCisG AQQBoDIBKAowQQYJKwYBBAGgMgFfMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNp Z24uY29tL3JlcG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUAA4IBAQConc0yzHxn4gtQ16VccKNm4iXv 6rS2UzBuhxI3XDPiwihW45O9RZXzWNgVcUzz5IKJFL7+pcxHvesGVII+5r++9eqI9XnEKCILjHr2 DgvjKq5Jmg6bwifybLYbVUoBthnhaFB0WLwSRRhPrt5eGxMw51UmNICi/hSKBKsHhGFSEaJQALZy 4HL0EWduE6ILYAjX6BSXRDtHFeUPddb46f5Hf5rzITGLsn9BIpoOVrgS878O4JnfUWQi29yBfn75 HajifFvPC+uqn+rcVnvrpLgsLOYG/64kWX/FRH8+mhVe+mcSX3xsUpcxK9q9vLTVtroU/yJUmEC4 OcH5dQsbHBqjMIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNV BAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5BngiFvXAg7aE yiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X17YUhhB5 uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmmKPZpO/bL yCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hpsk+QLjJg 6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7DWzgVGkW qQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBLQNvAUKr+ yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25sbwMpjjM5 RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV3XpYKBov Hd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyrVQ4PkX42 68NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E7gUJTb0o 2HLO02JQZR7rkpeDMdmztcpHWD9fMIIFRzCCBC+gAwIBAgIMJplVpW1Hq+2ySMVcMA0GCSqGSIb3 DQEBCwUAMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTMwMQYDVQQD EypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0gRzMwHhcNMjAwMjIxMTM1 NjQ5WhcNMjMwMjIxMTM1NjQ5WjCBkDELMAkGA1UEBhMCSU4xEjAQBgNVBAgTCUthcm5hdGFrYTES MBAGA1UEBxMJQmFuZ2Fsb3JlMRYwFAYDVQQKEw1Ccm9hZGNvbSBJbmMuMRYwFAYDVQQDEw1NaW5n bGlhbmcgUGVpMSkwJwYJKoZIhvcNAQkBFhptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALnj+oLejidhAhfIueq2R6kYf0xTddM81r4s9meY /vZiDe5epFRqRGhg8qsgW+LX2vtv5qe0r507+X2VQsqdL1dSQx8M0kMLqddYl9s9fYj12Qz191+J BI196cW/js96aA0aHpvT2jHIZ8n1+L0r9g4uKFt+VV1Z6ZfECZlMC8EZtCv8KXfBfH2dFJ10k+Qg dV+/KUMC2CYgdiIOynoP5Y9FQTcMM0dg8ToVGkdb7gqODxvU8zKuzBF7AY4YdNs03WCZAa5I+84n DiOJCQwyp+y3WJ7BkQq96LxuuJNS6X0YMhujGmUCdlc4BCX9O+8ICz/jTWGhpq+BLGt4hakkdTEC AwEAAaOCAdEwggHNMA4GA1UdDwEB/wQEAwIFoDCBngYIKwYBBQUHAQEEgZEwgY4wTQYIKwYBBQUH MAKGQWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWduMnNo YTJnM29jc3AuY3J0MD0GCCsGAQUFBzABhjFodHRwOi8vb2NzcDIuZ2xvYmFsc2lnbi5jb20vZ3Nw ZXJzb25hbHNpZ24yc2hhMmczME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIB FiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3NwZXJzb25hbHNpZ24yc2hh MmczLmNybDAlBgNVHREEHjAcgRptaW5nbGlhbmcucGVpQGJyb2FkY29tLmNvbTATBgNVHSUEDDAK BggrBgEFBQcDBDAfBgNVHSMEGDAWgBRpcoJiMWeVRIV3kYDEBDZJnXsLYTAdBgNVHQ4EFgQUpStv 0AghsERl1TBx5BXhBfzYSicwDQYJKoZIhvcNAQELBQADggEBAFfbbvFJ0WbPYEGcnklrQKfu9s9k KNImqVdomu0FZ6RxOMLGXBmxRTY4Qy0K4rFKkQ+aYT2iWIBBZrHYs6b+xbLAusU8U4WaO+twZeDC IbMNGJ0PCCHe9IYMy1oOK1M7YqufFR3ZGom/ElDbPPBeBt5P6IfZmm+maiU3vOjI15ZIItZKbBlO O6xVaIUhmfNI6jeHo9qRM2JD+PFUDysuPBEI+udCfjCF1jOP+coa/xLFckMJAhHZw8jJGn1Ja1CC p23PR6TUH/Lxkcj5Y+oyx5sGusPp4jW30ONNtGo5+v6UavWPW4/0LMVJGma3LEJ29R18FOu9Fe/s 1NCEczpRDycxggJvMIICawIBATBtMF0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMTMwMQYDVQQDEypHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gU0hBMjU2IC0g RzMCDCaZVaVtR6vtskjFXDANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgjE3MbyKp bMhggM4XVZ+sto1sI9VjIxoRU86Z2/AQEPcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMjAwNDI0MDUxMzI2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG 9w0BAQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAI1lewphZlvwHM6zdrR5rta/fA4R EzdElj3eenUWOP5p7qEU92qQtFocd+73lqx03h/vQX0235e3+A0k+M8e51Nciswz/ZGBbbRT8krK FuIFiWZ39L574ZFpTAWvtINvm3qvUR2Mqt0B28M3zZnHlwLcoKx+Ulq8oTjaCIrSHzVlu82LaPzL rrTB0XO0BMGHYFElev3g1hetK+PrueHIaVZYSf1QDZClCHH09mFSo4kNSlACQ4ZV2O+AKQdizL++ 1fB5CliAYtU3aIqTPAd6tojUpbbuxkUkImZn8pPbuBj/qEcdbh+cClrTnTEWqgo/yjnGYbnaE2p7 M74vrGlixsc= --000000000000d97a8605a4026caf-- From nobody Mon Apr 27 19:01: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 E5C2D3A0BE5 for ; Mon, 27 Apr 2020 19:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 5SuxlmaJgzTi for ; Mon, 27 Apr 2020 19:01:33 -0700 (PDT) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 CE6E73A0BE1 for ; Mon, 27 Apr 2020 19:01:32 -0700 (PDT) Received: by mail-vk1-xa29.google.com with SMTP id p5so3044172vke.1 for ; Mon, 27 Apr 2020 19:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=82/qIxfWrZ0uh7YjcrAb4O0rvW11+jatuMZLRfDomsE=; b=a7BRr6BpbcDaosl6ZCTg9xuaZ5ee9akb0JQ1yfwdi0MBOFTtLTjFNqPxEsI/jGz7Kj mBTwUaQTrXbqPgfuyRpTM4/bvTRxZo8tiFEP3lhmoFWKW9i6CclNi7VVAdvuhB9L7TW1 YF73B0cTj7n4vaB85EyoERt/pfLU0lhKuTfWL9/279+ByT5Cwg6u//KsRdX5yVdacbrT ceeuTiH5uKiDVRSR4fK3+tYotmbz0C4r6OUTHZtK30W2367KiS916Po72PVAyL7C9dra 8E46ao5JxN1FDhRaDiRKPQwNCypb/arZ8vh/8WjP0vf2n+04dncVJnnJ/jLpcc05/2+U oxjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=82/qIxfWrZ0uh7YjcrAb4O0rvW11+jatuMZLRfDomsE=; b=L7j0QM+OtBeVXb37Fp4ZUhQUuHle97oofkQYHgKIzOZl2YGVtdWoPaIe5of/xnRfo8 xPD2yMrE+V377W7VvmWLzVsQkFKEmIIfkoUsRV3WazqAv+4XMbh8XqAfCEDKc1IP1LiU kgoB2G+6ydqtsDeOiskeZxIC2ZY4pIBW6sYr06nPMgF8Hr6GUtxwXNnAH73UvqOzgtOl Zy8j6wYm3pJvZ2uOtpzJPDeX4G6j27VyBD1jw8qmZgwfRNNBfsMCz/9cMLnx7pfS+Evv M+4VNiNA69aVA3ShRL6kecip6geIhcE2d9HSOHpPsiN/601yFbLyimoj5UbmZoTJhuHf xkFQ== X-Gm-Message-State: AGi0PuZY8EAdAegSYSF7SGsPHJNvvy7n2uwjzMAnPtU+qnl9aA+kbUHN 3Fuz6t2dXmFStkFKT+jcHlgAPqb6z8H69u1bHqrTR5JK X-Google-Smtp-Source: APiQypJwyfm2IVlZobQUB862u+UQ/nHocfsQOYBxLCMsGWz7Rv6DYaHUNCa2WH+r9JomPtcdxLUW64PF6iMkNxneWCw= X-Received: by 2002:a1f:7cc7:: with SMTP id x190mr8792032vkc.39.1588039290755; Mon, 27 Apr 2020 19:01:30 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Mon, 27 Apr 2020 22:01:19 -0400 Message-ID: To: teep@ietf.org Content-Type: multipart/alternative; boundary="000000000000d09eb805a45035f1" Archived-At: Subject: [Teep] review on draft-ietf-teep-architecture-08 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, 28 Apr 2020 02:01:37 -0000 --000000000000d09eb805a45035f1 Content-Type: text/plain; charset="UTF-8" Hi, I reviewed the draft-ietf-teep-architecture-08 and please find my comments below. Yours, Daniel Trusted Execution Environment Provisioning (TEEP) Architecture draft-ietf-teep-architecture-08 The Trusted Execution Environment Provisioning (TEEP) protocol addresses the following problems: - An installer of an Untrusted Application that depends on a given TA wants to request installation of that TA in the device's TEE so that the Untrusted Application can complete, but the TEE needs to verify whether such a TA is actually authorized to run in the TEE and consume potentially scarce TEE resources. - A TA developer providing a TA whose code itself is considered confidential wants to determine security-relevant information of a device before allowing their TA to be provisioned to the TEE within the device. An example is the verification of the type of TEE included in a device and that it is capable of providing the security protections required. - A TEE in a device wants to determine whether an entity that wants to manage a TA in the device is authorized to manage TAs in the TEE, and what TAs the entity is permitted to manage. - A TAM (e.g., operated by a device administrator) wants to determine if a TA exists (is installed) on a device (in the TEE), and if not, install the TA in the TEE. - A TAM wants to check whether a TA in a device's TEE is the most up-to-date version, and if not, update the TA in the TEE. - A TA developer wants to remove a confidential TA from a device's TEE if the TA developer is no longer offering such TAs or the TAs are being revoked from a particular user (or device). For example, if a subscription or contract for a particular service has expired, or a payment by the user has not been completed or has been rescinded. - A TA developer wants to define the relationship between cooperating TAs under the TA developer's control, and specify whether the TAs can communicate, share data, and/or share key material. I believe that the intent of these example was to provide a high level description of the goals of the architecture. I think it is necessary to introduce TA and untrusted Application, but I do not think TAM needs to be mentioned. Note: The TA developer requires the help of a TAM to provision the Trusted Applications to remote devices and the TEEP protocol exchanges messages between a TAM and a TEEP Agent via a TEEP Broker. I am incline to think that such clarification comes too early and mostly because TAM has been introduced. 2. Terminology The following terms are used: - Device: A physical piece of hardware that hosts one or more TEEs, often along with a Rich Execution Environment. A device contains a default list of Trust Anchors that identify entities (e.g., TAMs) that are trusted by the device. This list is normally set by the device manufacturer, and may be governed by the device's network carrier when it is a mobile device. The list of Trust Anchors is normally modifiable by the device's owner or Device Administrator. However the device manufacturer or network carrier (in the mobile device case) may restrict some modifications, for example, by not allowing the manufacturer or carrier's Trust Anchor to be removed or disabled. >From the definition it is unclear to me where the Trust Anchors are stored. I think the definition should specify the trust anchors are stored in the TEEP Agent explicitly. - Trusted Application (TA) Developer: An entity that wishes to provide functionality on devices that requires the use of one or more Trusted Applications. It is not clear why we have something more complex than an entity that publishes, implements TAs. The way I read the text is that functionalities are using TAs which might be closer to an untrusted application. 3. Use Cases 3.1. Payment A payment application in a mobile device requires high security and trust about the hosting device. Payments initiated from a mobile device can use a Trusted Application to provide strong identification and proof of transaction. For a mobile payment application, some biometric identification information could also be stored in a TEE. The mobile payment application can use such information for unlocking the phone and for local identification of the user. A trusted user interface (UI) may be used in a mobile device to prevent malicious software from stealing sensitive user input data. Such an implementation often relies on a TEE for providing access to peripherals, such as PIN input. It is unclear to me whether this is a single use case or many use cases related to the payment. It believe it would be clarifying to describe a little bit more what the TA does as well as the interactions with the untrusted applications. Typically it seems that the UI is part of the TA, which guarantee trusted inputs. I am wondering what mechanism or trust is necessary to actually trust the output of the TA. In other words why the "True" from the TA should be more trusted than the PIN values. It seems important to consider that anything coming out to the untrusted world can be tampered or replayed - even the output of the TA. Given the example, it seems to me hard to understand how TA are used. 3.2. Authentication For better security of authentication, a device may store its keys and cryptographic libraries inside a TEE limiting access to cryptographic functions via a well-defined interface and thereby reducing access to keying material. Though I am biaised, draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 are example of this. 3.3. Internet of Things The Internet of Things (IoT) has been posing threats to critical infrastructure because of weak security in devices. It is desirable that IoT devices can prevent malware from manipulating actuators (e.g., unlocking a door), or stealing or modifying sensitive data, such as authentication credentials in the device. A TEE can be the best way to implement such IoT security functions. quite broad... but ok.;-) Pei, et al. Expires October 6, 2020 [Page 7] Internet-Draft TEEP Architecture April 2020 3.4. Confidential Cloud Computing A tenant can store sensitive data in a TEE in a cloud computing server such that only the tenant can access the data, preventing the cloud hosting provider from accessing the data. A tenant can run TAs inside a server TEE for secure operation and enhanced data security. This provides benefits not only to tenants with better data security but also to cloud hosting providers for reduced liability and increased cloud adoption. This use case is useful as the document is heavily focused on devices. This use case introduces the notion of tenants that do share the resource of the device - or server. The Device Administrator ( cloud provider) will authorize a tenants' TAM and provision a specific TEE with Trusted Anchors for the tenants. I am also wondering how two concurrent TEEs from different tenants can remain isolated. Isolation is probably something that should be described in the security considerations. 4. Architecture 4.1. System Components Figure 1 shows the main components in a typical device with an REE. Full descriptions of components not previously defined are provided below. Interactions of all components are further explained in the following paragraphs. +-------------------------------------------+ | Device | | +--------+ | TA Developer | +-------------+ | |-----------+ | | | TEE-1 | | TEEP |---------+ | | | | +--------+ | +----| Broker | | | | +--------+ | | | | TEEP | | | | |<---+ | | +->| |<-+ | | | Agent |<----+ | | | | | +-| TAM-1 | | | +--------+ | | |<-+ | | +->| | |<-+ | | | +--------+ | | | | +--------+ | | | +---+ +---+ | | | | | TAM-2 | | | +-->|TA1| |TA2| | +-------+ | | | +--------+ | | | | | | | |<---------| App-2 |--+ | | | | | | +---+ +---+ | +-------+ | | | Device Administrator | | +-------------+ | App-1 | | | | | | | | | | | | +--------------------| |---+ | | | | |--------+ | | +-------+ | +-------------------------------------------+ Figure 1: Notional Architecture of TEEP - TA developers and Device Administrators utilize the services of a TAM to manage TAs on devices. TA developers do not directly interact with devices. Device Administators may elect to use a TAM for remote administration of TAs instead of managing each device directly. I think before going in to the details of each boxes the architecture should describe the high level goals of the architecture that is enabling the management of an TA developed by a TA Developer on a Device. The messages are exchanged between the TAM and the TEEP Agent. What is not so clear to me is whether a TEEP Agent can validate a TA from a TA developer that is using a different key than the TAM. I am unsure everything is based on session security. Suppose I would like a TEE only running TA from Vendor X independently from the TAM. If such validation occurs it is also unclear to me the validation occurs in the TEE or is performed by the TEEP agent. It also clarifies to explicitly mention that Brokers are not expected to terminate the session between the TAM and the TEEP Agent, but are mostly here to implement networking services in REE that may not be provided by the TEE, i.e. by the TEEP Agent. What I was missing in my first reading was the terminating points of the sessions. In particular, in some cases a broker could be a MiM, so it is better to clarify that it is not the case here. Of course if my understanding is correct. Pei, et al. Expires October 6, 2020 [Page 8] Internet-Draft TEEP Architecture April 2020 - Trusted Application Manager (TAM): A TAM is responsible for performing lifecycle management activity on TAs on behalf of TA developers and Device Administrators. This includes creation and provisioning might more accurate, but that is just a suggestion. deletion of TAs, and may include, for example, over-the-air updates to keep TAs up-to-date and clean up when a version should be removed. TAMs may provide services that make it easier for TA developers or Device Administators to use the TAM's service to manage multiple devices, although that is not required of a TAM. The TAM performs its management of TAs on the device through interactions with a device's TEEP Broker, which relays messages between a TAM and a TEEP Agent running inside the TEE. Unless specified before I would suggest to specify the meaning of "relay" and in particular that authentication of the messages are not performed by the broker but by the Agent. A TA developer or Device Administrator chooses a particular TAM based on whether the TAM is trusted by a device or set of devices. The TAM is trusted by a device if the TAM's public key is, or chains up to, an authorized Trust Anchor in the device. A TA developer or Device Administrator may run their own TAM, but the devices they wish to manage must include this TAM's public key/ certificate, or a certificate it chains up to, in the Trust Anchor list. I have the impression that Trust Anchor Store is the term used in the Terminology. I also think it helps clarifying the trust anchors are part of the Agent... so in a TEE. - TEEP Broker: A TEEP Broker is an application component running in a Rich Execution Environment (REE) that enables the message protocol exchange between a TAM and a TEE in a device. A TEEP Broker does not process messages on behalf of a TEE, but merely is responsible for relaying messages from the TAM to the TEE, and for returning the TEE's responses to the TAM. Same here "relay" here does not involve some kind of authentication. - Certification Authority (CA): Certificate-based credentials used for authenticating a device, a TAM and a TA developer. A device embeds a list of root certificates (Trust Anchors), from trusted CAs that a TAM will be validated against. A TAM will remotely attest a device by checking whether a device comes with a certificate from a CA that the TAM trusts. The CAs do not need to be the same; different CAs can be chosen by each TAM, and different device CAs can be used by different device manufacturers. I have the impression that Trust Anchor has been the terminology used. 4.2. Multiple TEEs in a Device Brokers on a particular platform. In addition, since TEEs may be physically separated, with wholly different resources, there may be no need for TEEP Brokers to share information on installed TAs or resource usage. I am wondering how multiple TEE could be used as a way to isolate different tenants. As the broker is part of the REE it seems that it does not necessarily need to be set by the Device Administrator, but eventually by the tenant. Would it be possible ? 4.3. Multiple TAMs and Relationship to TAs When a TEEP Broker receives a request Is such a request a TEEP request or something more abstract ? 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. """The trusted TAM provisioned on the device""" seems to indicates that a common Trust Anchor Store is shared by all TEEs. I suppose that is provisioned on a per agent base. My understanding is that the Agent may implement the HTTP transport but will not treat networking aspects. These will be instead handled by the Broker. If that is correct, this could maybe clarified. 4.4. Untrusted Apps, Trusted Apps, and Personalization Data 1. The Untrusted Application, TA(s), and personalization data are all bundled together in a single package by a TA developer and provided to the TEEP Broker through the TAM. Does this scenario corresponds to a push from the TAM ? 2. The Untrusted Application and the TA(s) are bundled together in a single package, which a TAM or a publicly accessible app store maintains, and the personalization data is separately provided by the TA developer's TAM. The first TAM seems to me related to a push while the app store corresponds to a pull scenario. I also understand the second TAM is requested by the Agent. If that is correct it would be clarifying to specify the initiator of the request. 3. All components are independent. The Untrusted Application is installed through some independent or device-specific mechanism, and the TAM provides the TA and personalization data from the TA developer. Delivery of the TA and personalization data may be combined or separate. 4.5. Entity Relations (App Developers) (App Store) (TAM) (Device with TEE) (CAs) | | | | | | | | (Embedded TEE cert) <--| | | | | | | <--- Get an app cert -----------------------------------| | | | | | | | | <-- Get a TAM cert ---------| | | | | | 1. Build two apps: | | | | | | | | (a) Untrusted | | | | App - 2a. Supply --> | --- 3. Install ------> | | | | | | (b) TA -- 2b. Supply ----------> | 4. Messaging-->| | | | | | Figure 3: Developer Experience Note that Figure 3 shows the TA developer as a TA signer. The TA signer is either the same as the TA developer, or is a related entity trusted to sign the developer's TAs. Figure 3 shows an example where the same developer builds two applications: 1) an Untrusted Application; 2) a TA that provides some security functions to be run inside a TEE. isn't it a and b in the figure. At step 2, the TA developer uploads the Untrusted Application (2a) to an Application Store. The Untrusted Application may optionally bundle the TA binary. Meanwhile, the TA developer may provide its TA to a TAM that will be managing the TA in various devices. At step 3, a user will go to an Application Store to download the Untrusted Application. Since the Untrusted Application depends on the TA, installing the Untrusted Application will trigger TA installation by initiating communication with a TAM. This is step 4. Since the broker requests the TAM I would have expected the arrow in the other way. I also have the impression some text is missing around the cert related arrows. It should be noted that network communication capability is generally not available in TAs in today's TEE-powered devices. Consequently, Trusted Applications generally rely on broker in the REE to provide access to nnetwork functionality in the REE. A broker does not need to know the actual content of messages to facilitate such access. nnetwork Similarly, since the TEEP Agent runs inside a TEE, the TEEP Agent generally relies on a TEEP Broker in the REE to provide network access, and relay TAM requests to the TEEP Agent and relay the responses back to the TAM. 9.6. Malicious TA Removal It is possible that a rogue developer distributes a malicious Untrusted Application and intends to get a malicious TA installed. It's the responsibility of the TAM to not install malicious trusted apps in the first place. The TEEP architecture allows a TEEP Agent to decide which TAMs it trusts via Trust Anchors, and delegates the TA authenticity check to the TAMs it trusts. It may happen that a TA was previously considered trustworthy but is later found to be buggy or compromised. In this case, the TAM can initiate the removal of the TA by notifying devices to remove the TA (and potentially the REE or device owner to remove any Untrusted Application that depend on the TA). If the TAM does not currently Pei, et al. Expires October 6, 2020 [Page 26] Internet-Draft TEEP Architecture April 2020 have a connection to the TEEP Agent on a device, such a notification would occur the next time connectivity does exist. That is, to recover, the TEEP Agent must be able to reach out to the TAM, for example whenever the RequestPolicyCheck API (Section 6.2.1) is invoked by a timer or other event. Given the security assumption of a TEE a rogue TA will not be able to steal data of the other TA - which is not the case for applications running in a REE. I also believe that some additional considerations are needed regarding tenants sharing a given device ( or server). -- Daniel Migault Ericsson --000000000000d09eb805a45035f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I reviewed the draft-ietf-te= ep-architecture-08 and please find my comments below.=C2=A0=C2=A0

Yours,=C2=A0
Daniel



=C2=A0 =C2=A0 =C2=A0Trusted Execution Environment Provision= ing (TEEP) Architecture
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 draft-ietf-teep-architecture-08

=C2=A0 =C2=A0T= he Trusted Execution Environment Provisioning (TEEP) protocol
=C2=A0 =C2= =A0addresses the following problems:

=C2=A0 =C2=A0- =C2=A0An install= er of an Untrusted Application that depends on a given
=C2=A0 =C2=A0 =C2= =A0 TA wants to request installation of that TA in the device's TEE so<= br>=C2=A0 =C2=A0 =C2=A0 that the Untrusted Application can complete, but th= e TEE needs to
=C2=A0 =C2=A0 =C2=A0 verify whether such a TA is actually= authorized to run in the TEE
=C2=A0 =C2=A0 =C2=A0 and consume potential= ly scarce TEE resources.

=C2=A0 =C2=A0- =C2=A0A TA developer providi= ng a TA whose code itself is considered
=C2=A0 =C2=A0 =C2=A0 confidentia= l wants to determine security-relevant information of a
=C2=A0 =C2=A0 = =C2=A0 device before allowing their TA to be provisioned to the TEE
=C2= =A0 =C2=A0 =C2=A0 within the device.=C2=A0 An example is the verification o= f the type of
=C2=A0 =C2=A0 =C2=A0 TEE included in a device and that it = is capable of providing the
=C2=A0 =C2=A0 =C2=A0 security protections re= quired.

=C2=A0 =C2=A0- =C2=A0A TEE in a device wants to determine wh= ether an entity that wants
=C2=A0 =C2=A0 =C2=A0 to manage a TA in the de= vice is authorized to manage TAs in the
=C2=A0 =C2=A0 =C2=A0 TEE, and wh= at TAs the entity is permitted to manage.

=C2=A0 =C2=A0- =C2=A0A TAM= (e.g., operated by a device administrator) wants to
=C2=A0 =C2=A0 =C2= =A0 determine if a TA exists (is installed) on a device (in the TEE),
= =C2=A0 =C2=A0 =C2=A0 and if not, install the TA in the TEE.

=C2=A0 = =C2=A0- =C2=A0A TAM wants to check whether a TA in a device's TEE is th= e most
=C2=A0 =C2=A0 =C2=A0 up-to-date version, and if not, update the T= A in the TEE.

=C2=A0 =C2=A0- =C2=A0A TA developer wants to remove a = confidential TA from a device's
=C2=A0 =C2=A0 =C2=A0 TEE if the TA d= eveloper is no longer offering such TAs or the TAs

=C2=A0 =C2=A0 =C2= =A0 are being revoked from a particular user (or device).=C2=A0 For
=C2= =A0 =C2=A0 =C2=A0 example, if a subscription or contract for a particular s= ervice
=C2=A0 =C2=A0 =C2=A0 has expired, or a payment by the user has no= t been completed or
=C2=A0 =C2=A0 =C2=A0 has been rescinded.

=C2= =A0 =C2=A0- =C2=A0A TA developer wants to define the relationship between=C2=A0 =C2=A0 =C2=A0 cooperating TAs under the TA developer's control= , and specify
=C2=A0 =C2=A0 =C2=A0 whether the TAs can communicate, shar= e data, and/or share key
=C2=A0 =C2=A0 =C2=A0 material.

<mglt&= gt;

I believe that the intent of these example was to
provide a h= igh level description of the goals of
the architecture. I think it is ne= cessary to
introduce TA and untrusted Application, but I do
not think= TAM needs to be mentioned.

</mglt>

=C2=A0 =C2=A0Note:= The TA developer requires the help of a TAM to provision the
=C2=A0 =C2= =A0Trusted Applications to remote devices and the TEEP protocol
=C2=A0 = =C2=A0exchanges messages between a TAM and a TEEP Agent via a TEEP Broker.<= br>
<mglt>

I am incline to think that such clarificationcomes too early and mostly because TAM has been
introduced.

<= ;/mglt>

2.=C2=A0 Terminology

=C2=A0 =C2=A0The following te= rms are used:

=C2=A0 =C2=A0- =C2=A0Device: A physical piece of hardw= are that hosts one or more TEEs,
=C2=A0 =C2=A0 =C2=A0 often along with a= Rich Execution Environment.=C2=A0 A device contains
=C2=A0 =C2=A0 =C2= =A0 a default list of Trust Anchors that identify entities (e.g.,
=C2=A0= =C2=A0 =C2=A0 TAMs) that are trusted by the device.=C2=A0 This list is nor= mally set
=C2=A0 =C2=A0 =C2=A0 by the device manufacturer, and may be go= verned by the device's
=C2=A0 =C2=A0 =C2=A0 network carrier when it = is a mobile device.=C2=A0 The list of Trust
=C2=A0 =C2=A0 =C2=A0 Anchors= is normally modifiable by the device's owner or Device
=C2=A0 =C2= =A0 =C2=A0 Administrator.=C2=A0 However the device manufacturer or network = carrier
=C2=A0 =C2=A0 =C2=A0 (in the mobile device case) may restrict so= me modifications, for
=C2=A0 =C2=A0 =C2=A0 example, by not allowing the = manufacturer or carrier's Trust
=C2=A0 =C2=A0 =C2=A0 Anchor to be re= moved or disabled.

<mglt>

From the definition it is un= clear to me where the
Trust Anchors are stored. I think the definitionshould specify the trust anchors are stored in the
TEEP Agent explicit= ly.

</mglt>

=C2=A0 =C2=A0- =C2=A0Trusted Application (= TA) Developer: An entity that wishes to
=C2=A0 =C2=A0 =C2=A0 provide fun= ctionality on devices that requires the use of one or
=C2=A0 =C2=A0 =C2= =A0 more Trusted Applications.

<mglt>
It is not clear why = we have something more complex
than an entity that publishes, implements= TAs. The
way I read the text is that functionalities are
using TAs w= hich might be closer to an untrusted
application. =C2=A0

<mglt= >


3.=C2=A0 Use Cases

3.1.=C2=A0 Payment

=C2=A0 = =C2=A0A payment application in a mobile device requires high security and=C2=A0 =C2=A0trust about the hosting device.=C2=A0 Payments initiated fro= m a mobile
=C2=A0 =C2=A0device can use a Trusted Application to provide = strong identification
=C2=A0 =C2=A0and proof of transaction.

=C2= =A0 =C2=A0For a mobile payment application, some biometric identification=C2=A0 =C2=A0information could also be stored in a TEE.=C2=A0 The mobile = payment
=C2=A0 =C2=A0application can use such information for unlocking = the phone and for
=C2=A0 =C2=A0local identification of the user.

= =C2=A0 =C2=A0A trusted user interface (UI) may be used in a mobile device t= o
=C2=A0 =C2=A0prevent malicious software from stealing sensitive user i= nput data.
=C2=A0 =C2=A0Such an implementation often relies on a TEE for= providing access to
=C2=A0 =C2=A0peripherals, such as PIN input.
<mglt>

It is unclear to me whether this is a single use
ca= se or many use cases related to the payment. It
believe it would be clar= ifying to describe a
little bit more what the TA does as well as the
= interactions with the untrusted applications.
Typically it seems that th= e UI is part of the TA,
which guarantee trusted inputs. I am wonderingwhat mechanism or trust is necessary to actually
trust the output of t= he TA. In other words why the
"True" from the TA should be mor= e trusted than the
PIN values.=C2=A0 It seems important to consider that=
anything coming out to the untrusted world can be
tampered or replay= ed - even the output of the TA.
Given the example, it seems to me hard t= o
understand how TA are used. =C2=A0 =C2=A0

</mglt>

= 3.2.=C2=A0 Authentication

=C2=A0 =C2=A0For better security of authen= tication, a device may store its keys
=C2=A0 =C2=A0and cryptographic lib= raries inside a TEE limiting access to
=C2=A0 =C2=A0cryptographic functi= ons via a well-defined interface and thereby
=C2=A0 =C2=A0reducing acces= s to keying material.

<mglt>

Though I am biaised, draft= -mglt-lurk-tls12 and
draft-mglt-lurk-tls13 are example of this.
</= mglt>

3.3.=C2=A0 Internet of Things

=C2=A0 =C2=A0The Inter= net of Things (IoT) has been posing threats to critical
=C2=A0 =C2=A0inf= rastructure because of weak security in devices.=C2=A0 It is desirable
= =C2=A0 =C2=A0that IoT devices can prevent malware from manipulating actuato= rs
=C2=A0 =C2=A0(e.g., unlocking a door), or stealing or modifying sensi= tive data,
=C2=A0 =C2=A0such as authentication credentials in the device= .=C2=A0 A TEE can be the
=C2=A0 =C2=A0best way to implement such IoT sec= urity functions.


<mglt> quite broad... but ok.;-) </mgl= t>




Pei, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Expires October 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0[Page 7]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0TEEP Architecture =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 April 2020


3.4.=C2=A0 Confidential Cloud Co= mputing

=C2=A0 =C2=A0A tenant can store sensitive data in a TEE in a= cloud computing
=C2=A0 =C2=A0server such that only the tenant can acces= s the data, preventing the
=C2=A0 =C2=A0cloud hosting provider from acce= ssing the data.=C2=A0 A tenant can run TAs
=C2=A0 =C2=A0inside a server = TEE for secure operation and enhanced data security.
=C2=A0 =C2=A0This p= rovides benefits not only to tenants with better data security
=C2=A0 = =C2=A0but also to cloud hosting providers for reduced liability and
=C2= =A0 =C2=A0increased cloud adoption.

<mglt>

This use ca= se is useful as the document is heavily
focused on devices. This use cas= e introduces the
notion of tenants that do share the resource of
the = device - or server. The Device Administrator (
cloud provider) will auth= orize a tenants' TAM
and provision a specific TEE with Trusted Ancho= rs
for the tenants.=C2=A0 I am also wondering how two
concurrent TEEs= from different tenants can remain
isolated. Isolation is probably somet= hing that
should be described in the security
considerations. =C2=A0 =

</mglt>

4.=C2=A0 Architecture

4.1.=C2=A0 System= Components

=C2=A0 =C2=A0Figure 1 shows the main components in a typ= ical device with an REE.
=C2=A0 =C2=A0Full descriptions of components no= t previously defined are provided
=C2=A0 =C2=A0below.=C2=A0 Interactions= of all components are further explained in the
=C2=A0 =C2=A0following p= aragraphs.

=C2=A0 =C2=A0+-------------------------------------------= +
=C2=A0 =C2=A0| Device =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------+ =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0TA Developer
=C2=A0 =C2=A0| =C2=A0 =C2=A0+------= -------+ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0|-----------+ = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0| =C2=A0 = =C2=A0| TEE-1 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | TEEP =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+----| Broker | =C2=A0 =C2=A0 = =C2=A0 | | | =C2=A0+--------+ =C2=A0|
=C2=A0 =C2=A0| =C2=A0 =C2=A0| | TE= EP =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| | Agent =C2=A0|<----+ =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0| =C2=A0| | =C2=A0+-| =C2=A0TAM-1 |
=C2=A0 =C2= =A0| =C2=A0 =C2=A0| +--------+ =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0= =C2=A0 =C2=A0|<-+ | =C2=A0| +->| | =C2=A0 =C2=A0 =C2=A0 =C2=A0|<-= +
=C2=A0 =C2=A0| =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 +--------+ =C2=A0| | =C2=A0| =C2=A0 =C2=A0| +---= -----+ =C2=A0|
=C2=A0 =C2=A0| =C2=A0 =C2=A0| +---+ +---+ | =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | | =C2=A0| =C2=A0 =C2=A0= | TAM-2 =C2=A0| =C2=A0 =C2=A0|
=C2=A0 =C2=A0| =C2=A0+-->|TA1| |TA2| |= =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 |<--= -------| App-2 |--+ | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0| =C2=A0| | +---+ +---+ | =C2=A0 =C2=A0+= -------+ =C2=A0 | =C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0Device Administrator<= br>=C2=A0 =C2=A0| =C2=A0| +-------------+ =C2=A0 =C2=A0| App-1 | =C2=A0 | = =C2=A0 =C2=A0| =C2=A0|
=C2=A0 =C2=A0| =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 | =C2=A0 =C2=A0| =C2=A0|
=C2=A0 =C2=A0| =C2=A0+--------------------|= =C2=A0 =C2=A0 =C2=A0 |---+ =C2=A0 =C2=A0| =C2=A0|
=C2=A0 =C2=A0| =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 |--------+ =C2=A0|
=C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------+ =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+------------------------= -------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Figure 1: Notional Architecture of TEEP

=C2=A0 =C2= =A0- =C2=A0TA developers and Device Administrators utilize the services of = a
=C2=A0 =C2=A0 =C2=A0 TAM to manage TAs on devices.=C2=A0 TA developers= do not directly
=C2=A0 =C2=A0 =C2=A0 interact with devices.=C2=A0 Devic= e Administators may elect to use a
=C2=A0 =C2=A0 =C2=A0 TAM for remote a= dministration of TAs instead of managing each
=C2=A0 =C2=A0 =C2=A0 devic= e directly.

<mglt>
I think before going in to the details o= f each
boxes the architecture should describe the high
level goals of= the architecture that is enabling
the management of an TA developed by = a TA
Developer on a Device. The messages are exchanged
between the TA= M and the TEEP Agent.

What is not so clear to me is whether a TEEP = Agent
can validate a TA from a TA developer that is
using a different= key than the TAM. I am unsure
everything is based on session security. = Suppose I
would like a TEE only running TA from Vendor X
independentl= y from the TAM. If such validation
occurs it is also unclear to me the v= alidation
occurs in the TEE or is performed by the TEEP
agent. =C2=A0=

It also clarifies to explicitly mention that
Brokers are not exp= ected to terminate the session
between the TAM and the TEEP Agent, but a= re mostly
here to implement networking services in REE that
may not b= e provided by the TEE, i.e. by the TEEP
Agent.

What I was missin= g in my first reading was the
terminating points of the sessions. In par= ticular,
in some cases a broker could be a MiM, so it is
better to cl= arify that it is not the case here. Of
course if my understanding is cor= rect.

<mglt>




Pei, et al. =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Expires October 6, 2020 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Page 8]
=0C
Internet-Draft =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0TEEP Architecture =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 April 2020


=C2=A0 =C2= =A0- =C2=A0Trusted Application Manager (TAM): A TAM is responsible for
= =C2=A0 =C2=A0 =C2=A0 performing lifecycle management activity on TAs on beh= alf of TA
=C2=A0 =C2=A0 =C2=A0 developers and Device Administrators.=C2= =A0 This includes creation and
<mglt>
provisioning might more a= ccurate, but that is just
a suggestion. =C2=A0
</mglt>
=C2= =A0 =C2=A0 =C2=A0 deletion of TAs, and may include, for example, over-the-a= ir
=C2=A0 =C2=A0 =C2=A0 updates to keep TAs up-to-date and clean up when= a version should
=C2=A0 =C2=A0 =C2=A0 be removed.=C2=A0 TAMs may provid= e services that make it easier for TA
=C2=A0 =C2=A0 =C2=A0 developers or= Device Administators to use the TAM's service to
=C2=A0 =C2=A0 =C2= =A0 manage multiple devices, although that is not required of a TAM.
=C2=A0 =C2=A0 =C2=A0 The TAM performs its management of TAs on the device = through
=C2=A0 =C2=A0 =C2=A0 interactions with a device's TEEP Broke= r, which relays messages
=C2=A0 =C2=A0 =C2=A0 between a TAM and a TEEP A= gent running inside the TEE. =C2=A0

<mglt>

Unless speci= fied before I would suggest to
specify the meaning of "relay" = and in particular
that authentication of the messages are not
perform= ed by the broker but by the Agent.

</mglt>


=C2=A0 = =C2=A0 =C2=A0 A TA developer or Device Administrator chooses a particular T= AM
=C2=A0 =C2=A0 =C2=A0 based on whether the TAM is trusted by a device = or set of devices.
=C2=A0 =C2=A0 =C2=A0 The TAM is trusted by a device i= f the TAM's public key is, or
=C2=A0 =C2=A0 =C2=A0 chains up to, an = authorized Trust Anchor in the device.=C2=A0 A TA
=C2=A0 =C2=A0 =C2=A0 d= eveloper or Device Administrator may run their own TAM, but the
=C2=A0 = =C2=A0 =C2=A0 devices they wish to manage must include this TAM's publi= c key/
=C2=A0 =C2=A0 =C2=A0 certificate, or a certificate it chains up t= o, in the Trust Anchor
=C2=A0 =C2=A0 =C2=A0 list.

<mglt>I have the impression that Trust Anchor Store is
the term used in the T= erminology. I also think it
helps clarifying the trust anchors are part = of the
Agent... so in a TEE.

</mglt>


=C2=A0 =C2= =A0- =C2=A0TEEP Broker: A TEEP Broker is an application component running i= n
=C2=A0 =C2=A0 =C2=A0 a Rich Execution Environment (REE) that enables t= he message
=C2=A0 =C2=A0 =C2=A0 protocol exchange between a TAM and a TE= E in a device.=C2=A0 A TEEP
=C2=A0 =C2=A0 =C2=A0 Broker does not process= messages on behalf of a TEE, but merely is
=C2=A0 =C2=A0 =C2=A0 respons= ible for relaying messages from the TAM to the TEE, and for
=C2=A0 =C2= =A0 =C2=A0 returning the TEE's responses to the TAM.

<mglt>= ;
Same here "relay" here does not involve some kind
of auth= entication.

</mglt>

=C2=A0 =C2=A0- =C2=A0Certification= Authority (CA): Certificate-based credentials used
=C2=A0 =C2=A0 =C2=A0= for authenticating a device, a TAM and a TA developer.=C2=A0 A device
= =C2=A0 =C2=A0 =C2=A0 embeds a list of root certificates (Trust Anchors), fr= om trusted
=C2=A0 =C2=A0 =C2=A0 CAs that a TAM will be validated against= .=C2=A0 A TAM will remotely
=C2=A0 =C2=A0 =C2=A0 attest a device by chec= king whether a device comes with a
=C2=A0 =C2=A0 =C2=A0 certificate from= a CA that the TAM trusts.=C2=A0 The CAs do not need to
=C2=A0 =C2=A0 = =C2=A0 be the same; different CAs can be chosen by each TAM, and
=C2=A0 = =C2=A0 =C2=A0 different device CAs can be used by different device
=C2= =A0 =C2=A0 =C2=A0 manufacturers.

<mglt>
I have the impressi= on that Trust Anchor has been
the terminology used.

</mgtl>= ;

4.2.=C2=A0 Multiple TEEs in a Device



=C2=A0 =C2=A0B= rokers on a particular platform.=C2=A0 In addition, since TEEs may be
= =C2=A0 =C2=A0physically separated, with wholly different resources, there m= ay be
=C2=A0 =C2=A0no need for TEEP Brokers to share information on inst= alled TAs or
=C2=A0 =C2=A0resource usage.

<mglt>

I a= m wondering how multiple TEE could be used as a
way to isolate different= tenants. As the broker is
part of the REE it seems that it does not
= necessarily need to be set by the Device
Administrator, but eventually b= y the tenant. Would
it be possible ?

</mglt>

4.3.= =C2=A0 Multiple TAMs and Relationship to TAs


=C2=A0 =C2=A0When a= TEEP Broker receives a request
<mglt>

Is such a request = a TEEP request or
something more abstract ?

</mglt>

= from an Untrusted Application
=C2=A0 =C2=A0to install a TA, a list of TA= M URIs may be provided for that TA, and
=C2=A0 =C2=A0the request is pass= ed to the TEEP Agent.=C2=A0 If the TEEP Agent decides
=C2=A0 =C2=A0that = the TA needs to be installed, the TEEP Agent selects a single
=C2=A0 =C2= =A0TAM URI that is consistent with the list of trusted TAMs provisioned
= =C2=A0 =C2=A0on the device, invokes the HTTP transport for TEEP to connect = to the
=C2=A0 =C2=A0TAM URI, and begins a TEEP protocol exchange.
<mglt>
"""The trusted TAM provisioned on the devi= ce"""
seems to indicates that a common Trust Anchor
St= ore is shared by all TEEs. I suppose that is
provisioned on a per agent = base. =C2=A0

My understanding is that the Agent may implement
the= HTTP transport but will not treat networking
aspects. These will be ins= tead handled by the
Broker. If that is correct, this could maybe
clar= ified. =C2=A0

</mglt>

4.4.=C2=A0 Untrusted Apps, Truste= d Apps, and Personalization Data


=C2=A0 =C2=A01.=C2=A0 The Untru= sted Application, TA(s), and personalization data are
=C2=A0 =C2=A0 =C2= =A0 =C2=A0all bundled together in a single package by a TA developer and=C2=A0 =C2=A0 =C2=A0 =C2=A0provided to the TEEP Broker through the TAM.
<mglt>
Does this scenario corresponds to a push from the
T= AM ?
</mglt>


=C2=A0 =C2=A02.=C2=A0 The Untrusted Applic= ation and the TA(s) are bundled together in a
=C2=A0 =C2=A0 =C2=A0 =C2= =A0single package, which a TAM or a publicly accessible app store
=C2=A0= =C2=A0 =C2=A0 =C2=A0maintains, and the personalization data is separately = provided by
=C2=A0 =C2=A0 =C2=A0 =C2=A0the TA developer's TAM.
&l= t;mglt>
The first TAM seems to me related to a push while
the app = store corresponds to a pull scenario. I
also understand the second TAM i= s requested by the
Agent. If that is correct it would be clarifying
t= o specify the initiator of the request.

</mglt>

=C2=A0= =C2=A03.=C2=A0 All components are independent.=C2=A0 The Untrusted Applica= tion is
=C2=A0 =C2=A0 =C2=A0 =C2=A0installed through some independent or= device-specific mechanism,
=C2=A0 =C2=A0 =C2=A0 =C2=A0and the TAM provi= des the TA and personalization data from the TA
=C2=A0 =C2=A0 =C2=A0 =C2= =A0developer.=C2=A0 Delivery of the TA and personalization data may be
= =C2=A0 =C2=A0 =C2=A0 =C2=A0combined or separate.

4.5.=C2=A0 Entity R= elations

=C2=A0 =C2=A0 (App Developers) =C2=A0 (App Store) =C2=A0 (T= AM) =C2=A0 =C2=A0 =C2=A0(Device with TEE) =C2=A0(CAs)
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0(Embe= dded TEE cert) <--|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| <--- Get an app cert -----------------------------------|
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | <-- Get = a TAM cert ---------|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A01. Build two apps: =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 (a) Untrusted =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 App - 2a. Supply --> | --- 3.= Install ------> | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0 =C2=A0 (b) TA -- 2b. Supply ----------> | 4. Me= ssaging-->| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Figure 3: Developer Experience

=C2=A0 =C2=A0Note that Fig= ure 3 shows the TA developer as a TA signer.=C2=A0 The TA
=C2=A0 =C2=A0s= igner is either the same as the TA developer, or is a related entity
=C2= =A0 =C2=A0trusted to sign the developer's TAs.

=C2=A0 =C2=A0Figu= re 3 shows an example where the same developer builds two
=C2=A0 =C2=A0a= pplications: 1) an Untrusted Application; 2) a TA that provides some
=C2= =A0 =C2=A0security functions to be run inside a TEE.
<mglt>
is= n't it a and b in the figure.

</mglt>
At step 2, the T= A
=C2=A0 =C2=A0developer uploads the Untrusted Application (2a) to an Ap= plication
=C2=A0 =C2=A0Store.=C2=A0 The Untrusted Application may option= ally bundle the TA
=C2=A0 =C2=A0binary.=C2=A0 Meanwhile, the TA develope= r may provide its TA to a TAM that
=C2=A0 =C2=A0will be managing the TA = in various devices.=C2=A0 At step 3, a user will
=C2=A0 =C2=A0go to an A= pplication Store to download the Untrusted Application.
=C2=A0 =C2=A0Sin= ce the Untrusted Application depends on the TA, installing the
=C2=A0 = =C2=A0Untrusted Application will trigger TA installation by initiating
= =C2=A0 =C2=A0communication with a TAM.=C2=A0 This is step 4.

<mg= lt>
Since the broker requests the TAM I would have
expected the ar= row in the other way.

I also have the impression some text is missi= ng
around the cert related arrows.

</mglt>

=C2=A0 = =C2=A0It should be noted that network communication capability is generally=
=C2=A0 =C2=A0not available in TAs in today's TEE-powered devices.= =C2=A0 Consequently,
=C2=A0 =C2=A0Trusted Applications generally rely on= broker in the REE to provide
=C2=A0 =C2=A0access to nnetwork functional= ity in the REE.=C2=A0 A broker does not need
=C2=A0 =C2=A0to know the ac= tual content of messages to facilitate such access.

<mglt>
= nnetwork
</mglt>

=C2=A0 =C2=A0Similarly, since the TEEP Age= nt runs inside a TEE, the TEEP Agent
=C2=A0 =C2=A0generally relies on a = TEEP Broker in the REE to provide network
=C2=A0 =C2=A0access, and relay= TAM requests to the TEEP Agent and relay the
=C2=A0 =C2=A0responses bac= k to the TAM.



9.6.=C2=A0 Malicious TA Removal

=C2=A0 = =C2=A0It is possible that a rogue developer distributes a malicious
=C2= =A0 =C2=A0Untrusted Application and intends to get a malicious TA installed= .
=C2=A0 =C2=A0It's the responsibility of the TAM to not install mal= icious trusted
=C2=A0 =C2=A0apps in the first place.=C2=A0 The TEEP arch= itecture allows a TEEP Agent
=C2=A0 =C2=A0to decide which TAMs it trusts= via Trust Anchors, and delegates the
=C2=A0 =C2=A0TA authenticity check= to the TAMs it trusts.

=C2=A0 =C2=A0It may happen that a TA was pre= viously considered trustworthy but is
=C2=A0 =C2=A0later found to be bug= gy or compromised.=C2=A0 In this case, the TAM can
=C2=A0 =C2=A0initiate= the removal of the TA by notifying devices to remove the TA
=C2=A0 =C2= =A0(and potentially the REE or device owner to remove any Untrusted
=C2= =A0 =C2=A0Application that depend on the TA).=C2=A0 If the TAM does not cur= rently



Pei, et al. =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Expires October 6, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [Page 26]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0TEEP Architecture =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 April 2020


=C2=A0 =C2=A0have a connection to t= he TEEP Agent on a device, such a notification
=C2=A0 =C2=A0would occur = the next time connectivity does exist.=C2=A0 That is, to
=C2=A0 =C2=A0re= cover, the TEEP Agent must be able to reach out to the TAM, for
=C2=A0 = =C2=A0example whenever the RequestPolicyCheck API (Section 6.2.1) is
=C2= =A0 =C2=A0invoked by a timer or other event.

<mglt>

Giv= en the security assumption of a TEE a rogue TA
will not be able to steal= data of the other TA -
which is not the case for applications running i= n
a REE.

I also believe that some additional considerations
a= re needed regarding tenants sharing a given
device ( or server).
</mglt>
--
Daniel Migault
<= /div>
Ericsson
--000000000000d09eb805a45035f1--