From nobody Tue May 12 02:14: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 053773A0D06; Tue, 12 May 2020 02:13:53 -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=tJd4HGDC; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=tJd4HGDC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idCZJFfruSZN; Tue, 12 May 2020 02:13:51 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60040.outbound.protection.outlook.com [40.107.6.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 614C93A0D00; Tue, 12 May 2020 02:13:50 -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=zqumsYCa7b0dekCyXOmdmvrN4ZGhdACJ4xfRY9PGg2Q=; b=tJd4HGDCC25LkU2rYA1FW1pjzZEcg6s5bilRkDr2jWUqKc6zBtEHP4hsCk+UnYbroy1mhvbQSrxS349nAzd9WgBCYLjitwDQ4WUQC+dDwIjGgEoeD/ECm0srTdmBR6zSp0H3jLUWJpc8JsET19mMJ9+33XkvzNjmpbYf34m3/ck= Received: from DB7PR05CA0051.eurprd05.prod.outlook.com (2603:10a6:10:2e::28) by HE1PR08MB2684.eurprd08.prod.outlook.com (2603:10a6:7:2c::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.33; Tue, 12 May 2020 09:13:07 +0000 Received: from DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:2e:cafe::f5) by DB7PR05CA0051.outlook.office365.com (2603:10a6:10:2e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28 via Frontend Transport; Tue, 12 May 2020 09:13:07 +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 DB5EUR03FT052.mail.protection.outlook.com (10.152.21.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Tue, 12 May 2020 09:13:07 +0000 Received: ("Tessian outbound fb9de21a7e90:v54"); Tue, 12 May 2020 09:13:07 +0000 X-CR-MTA-TID: 64aa7808 Received: from 0666189ff1e5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id AFC4EC06-FF25-4ECD-B6DE-27E6961438A7.1; Tue, 12 May 2020 09:13:02 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 0666189ff1e5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 12 May 2020 09:13:02 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I86fRQ/ur5W1wIpDno5VbdzTT3+qb82G23Exric91cZIsf+T6sD4Y7XVZWtB35HgpBds3mn7GR54DHVC6rY/CLNuPbTwFRubeme28t56KATXkevLdestxaivGFZZo6wHBToiAFsztNK3g+QVBAbkUpQc2ddiT2TQml2GHR3dhks6Zc2aMjubDmvJMmcpkd+eiBTvDXZox0Or5SdTeTggOcT3FJoyWjgLWzd7JXXwfi7+JnIWZWa8ct/90iRiNSAS8BhZquOWCdP9Zw08QT8Csy/WfEfvCMBj4PNIKMYW/DmvurlgnW/BS7v84AqGSwjcerl6oy9Lt6p6fSG1L9qIJw== 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=zqumsYCa7b0dekCyXOmdmvrN4ZGhdACJ4xfRY9PGg2Q=; b=nDwWtrWfl5igNKCUoXucpBrp+jkPgbF5DROTTBXKYp9Az3xGAFnBiG25efuBtQw/EhbuvWATDbt8ppgDO+Wr/emmr3f8O2TA99bGuU/Mx/5CX0X7DMt30ouDF0ICnc54f/B6l8s8vgJn6Xvi47gHo2DHY208TaElRaC4fXKjxhhWV45T0fPn5JKUL6/Giv3osXa2Q9dS0DCAh+g1kWyYZB0HEPDrEOvB9HC6RlHJvbnZEhKBAyNxDjCZZ0FpK3ANWty/81eFeLRCIpki+dzHf9FIdj4M9oWCeeS+kAKh9Om5DrofYhLJfE6G0/M58EkU838TGeHuRFRdKp4YrwYu1g== 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=zqumsYCa7b0dekCyXOmdmvrN4ZGhdACJ4xfRY9PGg2Q=; b=tJd4HGDCC25LkU2rYA1FW1pjzZEcg6s5bilRkDr2jWUqKc6zBtEHP4hsCk+UnYbroy1mhvbQSrxS349nAzd9WgBCYLjitwDQ4WUQC+dDwIjGgEoeD/ECm0srTdmBR6zSp0H3jLUWJpc8JsET19mMJ9+33XkvzNjmpbYf34m3/ck= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB5235.eurprd08.prod.outlook.com (2603:10a6:208:163::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28; Tue, 12 May 2020 09:13:01 +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.2979.033; Tue, 12 May 2020 09:13:01 +0000 From: Hannes Tschofenig To: Akira Tsukamoto , teep , "suit@ietf.org" Thread-Topic: [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryResponse Thread-Index: AQHWEVbXFgYm+cwGsUmvssVwMd+QFqikRL8A Date: Tue, 12 May 2020 09:13:01 +0000 Message-ID: References: <7526678c-9ebc-e265-514c-435dce7595bc@aist.go.jp> In-Reply-To: <7526678c-9ebc-e265-514c-435dce7595bc@aist.go.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: f1494f5d-ef7e-4f35-9593-8a428c3690c0.0 x-checkrecipientchecked: true Authentication-Results-Original: aist.go.jp; dkim=none (message not signed) header.d=none;aist.go.jp; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.122.242] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: ffd21ac8-36db-4ad6-9f99-08d7f654af53 x-ms-traffictypediagnostic: AM0PR08MB5235:|HE1PR08MB2684: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 0401647B7F X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: iYr+ki+zJRSGfntojQCj9rzoGjRfQguy1dmyMc/sE+sNJeR4QHSUWuJGllhnqNKAYuRou6TXLxFBSy5wrBNZzcTvw8Om/YZ46inZKsa1Izm2Sj61DuDk65Z8/5mM1sIF5Qr4jobmTM8nG3rVC4hCASIPwhBJXktQK4riusaYt3j87nuCbpWfQ/jZ/eMQ1E3tNtz4wEplh6VeQzP0BmCoetQAAyF27Y9vIibBR7Ux7q1BHe/148w9Irnz4gBpkiSipfEOAR9tXuV9eux685iEvqY6brXZEoLHigAjI28zP1H5ehSOtDyH6xGXU33Ru2JNVGgVNxi5XV6mAJG1gMIyGXOdw0X9dVFF43jE//6Y0k6uX5bgI110o78sLkRO+pRXN35uTiTcNVKtGgw0v128xZHpi4kaXxZeAfpd1iuHOZLMdTHd16fqZSOwqAozlSiQplZhSY6Ns0oYYSGmYa+NC1JG7dXM4EMBEYwnXHTTnq2o8WVOBtSnUlLru56XIOyLSNHWHPxx+MY64YTvVCYkdAUMPXpHRh2Pxi28sIMrQX7UhD7gIOqI85Q6+ftC5wPAKtYwkjoOM47OZuKP5Q/1RVhSLnqwihv5RBxi0Ioa0MVWYcOafghy+1MYWQxU2tXc 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:(4636009)(396003)(366004)(136003)(376002)(346002)(39860400002)(33430700001)(9686003)(7696005)(55016002)(33656002)(76116006)(66556008)(66946007)(86362001)(64756008)(66476007)(2906002)(66446008)(52536014)(966005)(26005)(8936002)(8676002)(6506007)(478600001)(186003)(71200400001)(5660300002)(33440700001)(53546011)(316002)(110136005)(222643001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2WxFC6TYz8K8uQkvt78N0tc6GhU/uvGZQzqpJl5gL3Ee+DqrcqWFxcjpxgQIeWDxy4Ujo9f4HeThisiTPfcGISziCLPlBTE152KtS0aLBnrHnwikB/17+ZqfmbpmRQ5UtE9VioStycAcilJtSdmTqSWYwhIHxqnz8DYEkM1assJWsajmxfZZ5Pn6d6/U7GBLrxqiYn6IvXwsm6JWcZQ9mqbuyLq8FD8gqNsGZDEm1WBqNeBgDsMctady3cRbo2jSMD9ZZacs0TUQ1gLnPpZ86n2n85T3i22cJhXGu03GR5pW7h4ueTyLynlp8sflr4DXjbQHbx93D+wKRhXdu88o0iVLGn1tzln5T2ROxaiECHC9XU7QX0b04l71WXnW6+bpvoUhTvy06D1xi+Y3z0FCSmOPn8FS05I/RVGadIahpXbZYJVVB6lVQ0aCDcbKvn19I5Xv6k7GR0k0XmnEuH+XHFOXEuAuH3+mzG4filKyhZQlhyunVIEHdc6xYoS9zb8q 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: AM0PR08MB5235 Original-Authentication-Results: aist.go.jp; dkim=none (message not signed) header.d=none;aist.go.jp; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT052.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)(136003)(39860400002)(396003)(376002)(346002)(46966005)(33430700001)(70586007)(52536014)(8676002)(5660300002)(478600001)(82310400002)(8936002)(33440700001)(356005)(316002)(2906002)(70206006)(9686003)(86362001)(110136005)(33656002)(81166007)(7696005)(55016002)(966005)(26005)(53546011)(47076004)(336012)(6506007)(186003)(82740400003)(450100002)(222643001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: b10cf131-dc47-41bf-5070-08d7f654ab98 X-Forefront-PRVS: 0401647B7F X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HFMwNOZGvYDqBVzt+BM+XFmZv3c/TsuHWp7IJPnWycsYkfVUGAzp02t58DqKcv4hjgEtCbXfodbodnTS2AO0xdzyy6E0SSVYicJJABxL48QskbFh2pPpWVWLb7bHGr/ddT6vefNDJx/8URdEWlCkqygWpbeXXRPDEH6zn2arg+c3D/BgqGUDp+gmDzA8LnztiVcFOyfiaB83pibutCmPJdWzehil1m66CL6+hlQcfOCnAg1nLVouDFMAcjvT74YA8ofQNrMCKwv8KPNLKonL4pRT265Ca4iJt9QQHoTSfYZjTHw7NscWyGs7uCRoLWnShxwsLiaEVQ+x911hEFAQRDQCGsWEjA5cW6mQBX/ww6+r4deqVEqA/sHSWiIkYium3KqqQdey2wZbuCeeinbguYIkNwUUQe+hZl1Gb8KZPDDb0wzeUf5LZv0OKt8p9BM+2HqC1sMSZg4yv8TNGjpzGRbHvHRNIs/2WnRZ4EqSTdziau8NKaqRe4H6u5xUdX0mAqUYKeDBvhCsPrdK9nDHWx3BgSDSSM3KPyZxEMi1AmmZxfiSfjVJnJnAmmhGXULWrn3apSKgI7JXIPthi/6oU9CyvdtIzTzTztVEKH3GECY+XP+6krqbSAL3KbNnY+P5JssewQJ3cPSXwGxtgjqm1q+iSkr1u4fYPRUXbXYD6tzs24Y0iJZ/USyd/BJWrpoO X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2020 09:13:07.5293 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ffd21ac8-36db-4ad6-9f99-08d7f654af53 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: HE1PR08MB2684 Archived-At: Subject: Re: [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: Tue, 12 May 2020 09:13:53 -0000 Hi Akira, I had a chat with Brendan about this topic. In the SUIT model there is a manifest somewhere and it provides a pointer t= o where the binary, and other data is. That pointer is a URI. This is used to fetch the information from some repo= sitory. The vendor id and class id are identifiers used by the device to determine = whether it is looking at a manifest that can be applied to itself. A device= must not install software/firmware it is not supposed to because otherwise= you can quickly DoS the device. For me, the question is what information should the device report when it i= s asked what software it runs. Brendan suggested to use the Component ID an= d we would make recommendations regarding the construction and the uniquene= ss we would like to have. For example, we could say that the component id f= or a TA should be a UUID and the same TA binary would have the same UUID. N= ote that this component ID could subsequently also be used as a filename bu= t we could also keep it separate. What do you think? Ciao Hannes -----Original Message----- From: TEEP On Behalf Of Akira Tsukamoto Sent: Monday, April 13, 2020 7:46 AM To: teep ; suit@ietf.org Subject: [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryRespons= e Hi all, I would like to restart the discussion of Unique Identifier of TA_ID in TEE= P'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 use= d 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 larg= est member than NONCE in TEEP message. I prefer smaller bytes to reduce the teep message size but raw parameters o= f 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 _______________________________________________ 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 Tue May 12 03:49: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 13D6C3A0D74; Tue, 12 May 2020 03:49:23 -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 WzTZmF6_OeU2; Tue, 12 May 2020 03:49:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46EC3A0D79; Tue, 12 May 2020 03:49:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1B7FE389A6; Tue, 12 May 2020 06:47:13 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nEStQxhAN5R4; Tue, 12 May 2020 06:47:12 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DB4C6389A4; Tue, 12 May 2020 06:47:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E04715E; Tue, 12 May 2020 06:49:15 -0400 (EDT) From: Michael Richardson To: teep , "suit\@ietf.org" CC: sacm@ietf.org, Henk Birkholz In-Reply-To: References: <7526678c-9ebc-e265-514c-435dce7595bc@aist.go.jp> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Teep] [Suit] 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: Tue, 12 May 2020 10:49:23 -0000 --=-=-= Content-Type: text/plain Hannes Tschofenig wrote: > For me, the question is what information should the device report when > it is asked what software it runs. Brendan suggested to use the > Component ID and we would make recommendations regarding the > construction and the uniqueness we would like to have. For example, we > could say that the component id for a TA should be a UUID and the same > TA binary would have the same UUID. Note that this component ID could > subsequently also be used as a filename but we could also keep it > separate. > What do you think? That seems correct to me. It seems to wander into some SUIT/TEEP/CoSWID considerations. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl66fysACgkQgItw+93Q 3WX7Egf+Kd2SVowfVdSzCzutvSFuRiN+oTeVa6X4VoS9QAE1prXdzzuyZ9Hemrll VfjE3tjBXdulvyaMFIkS3I19LqhcyZSGjnjO0mJMs/gNgZkwzktZU6Z2z4thWxTQ Rsrjtb53xEaotK8h6jkLElN3Sl4exu6Poor1y09uOkXFBKCkznPYaV4O80J2YpKA mGcT3EY90Ca/ey3RqjsgW/BxDRlogTUiJ4/cdBg63OMxS1e9lTFIXTiU8I+D8GTe txcy8UB6sy5AHw3cis2LZ5C1GkVbNmb4sNtxDm6RtV7WSWXaDHR6uKBB5wD7NIlr XZ0ZTCyocCw2WzIoRKZIrizWLTK75g== =J84t -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 12 23:00:48 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 2EFF73A0822 for ; Tue, 12 May 2020 23:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, 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 CXa2u3abouHA for ; Tue, 12 May 2020 23:00:44 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F2A3A0DBE for ; Tue, 12 May 2020 23:00:43 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id d22so6522799lfm.11 for ; Tue, 12 May 2020 23:00:43 -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=ywt8t4IAd5yune8XSVscIxabr1ir5NBWLn6GCH28+bM=; b=Y9+W+O+TOz1O16wM0tZV9DNS7oDaH9haS1niOUDFtMSH5HGUOjQka+dlfdJXUq/wlb NGbql60AHisJFvfh7ZDVnJchdTBxGeUfeH1dsfm5G6JuPjBzlITJhmwOHlr3znfAPf8D VZPQwcJ4Y47GVFF3u0qmJ7HcngklY8hc1Asy0= 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=ywt8t4IAd5yune8XSVscIxabr1ir5NBWLn6GCH28+bM=; b=JI0Iwaxi2WgheVdTCIcPDxAx7Dtj3B/xETyWSJKohQWJlQsgQUNK5B1Jcv+pidtw6w saYlgzMPm/G8+I6bpwcjkkX1SxtNa1ebL7VpA8Mo+lZs/77eDGdcpClWAMT+sgxsWkIJ YUtYSNx8FKEW1RxMZO0fJrf8ad2Cj/kpxSnDr8SlfDxyoYK4gd/L4ebXpgw6xedUEFjs ESce+6ZMVyY0ixkFoZtiJZNdet2YBdxkw9H1KU45Oxwh3FEWEzHWvi6GVBOJ0EJ+dtWj Uj6cH6BUrxlDZk37LkyxNWajEJyaWiAstruPkMupZ0+W1wNG4v0t0zcjESYzAoEqrciT 0VXw== X-Gm-Message-State: AOAM532cunIELN2VSmmlHSVwsa2KWlOb9MvCUP/p4iauw/yHvVuqk6Wh tGRPdDdO0ZXHbQxTb+u1SoLSeDZs1RUOiWKipa5oYg== X-Google-Smtp-Source: ABdhPJzAHaKGfPG4z5HEDUCmHqJU2datHoRp6rNGNB0vPdF+Xe45Lr/JHngE/9Tbrb97Wt1DSW5G4VV99+5A4AX20BA= X-Received: by 2002:a19:7004:: with SMTP id h4mr15815781lfc.148.1589349641682; Tue, 12 May 2020 23:00:41 -0700 (PDT) MIME-Version: 1.0 References: <7526678c-9ebc-e265-514c-435dce7595bc@aist.go.jp> In-Reply-To: From: Mingliang Pei Date: Tue, 12 May 2020 23:00:30 -0700 Message-ID: To: Hannes Tschofenig Cc: Akira Tsukamoto , teep , "suit@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d87df705a5814c81" Archived-At: Subject: Re: [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: Wed, 13 May 2020 06:00:46 -0000 --000000000000d87df705a5814c81 Content-Type: multipart/alternative; boundary="000000000000d196d505a5814cc1" --000000000000d196d505a5814cc1 Content-Type: text/plain; charset="UTF-8" One of the questions is: who creates or assigns an ID as the TA_ID to a TA? A TAM is responsible to install, upgrade, or delete a TA. It may give it an identifier to track it. Different versions of TAs may use the same TA ID but add a version convention. This allows a TAM to identify a TA for upgrade. To ensure uniqueness, a UUID is a good choice for a TA ID where a TAM may create to be unique. Should the TA developer create and provide TA ID to the downstream systems? It can but I think a TAM may override it if it needs to do so. The TA developer should define a friendly display name for the TA. When a TAM manages many TAs, a TAM operator will like to see friendly display names rather than the opaque TA IDs that are created for machine consumption. A TAM may locally maintain a mapping between TA names and TA IDs. With SUIT compatibility, a UUID Component ID for TA ID can work. Is there a place holder in SUIT for a TA friendly name? A TA name doesn't need to be passed to the TEEs for management; it may help debugging logging but may not be worthy of the bandwidth and size cost. Thanks, Ming On Tue, May 12, 2020 at 2:14 AM Hannes Tschofenig wrote: > Hi Akira, > > I had a chat with Brendan about this topic. > > In the SUIT model there is a manifest somewhere and it provides a pointer > to where the binary, and other data is. > That pointer is a URI. This is used to fetch the information from some > repository. > > The vendor id and class id are identifiers used by the device to determine > whether it is looking at a manifest that can be applied to itself. A device > must not install software/firmware it is not supposed to because otherwise > you can quickly DoS the device. > > For me, the question is what information should the device report when it > is asked what software it runs. Brendan suggested to use the Component ID > and we would make recommendations regarding the construction and the > uniqueness we would like to have. For example, we could say that the > component id for a TA should be a UUID and the same TA binary would have > the same UUID. Note that this component ID could subsequently also be used > as a filename but we could also keep it separate. > > What do you think? > > Ciao > Hannes > > -----Original Message----- > From: TEEP On Behalf Of Akira Tsukamoto > Sent: Monday, April 13, 2020 7:46 AM > To: teep ; suit@ietf.org > Subject: [Teep] Unique Identifier of TA_ID in TA_LIST for > TEEP_QueryResponse > > 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://clicktime.symantec.com/38kWqaWA3sW14euWCDuBdWf7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues%2F4 > > 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 > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > > https://clicktime.symantec.com/3bbx7gUqzexL4igHH5sBig7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep > 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/3bbx7gUqzexL4igHH5sBig7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep > --000000000000d196d505a5814cc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One of the questions is: who creates or assigns an ID= as the TA_ID to a TA?

A TAM is responsible to ins= tall, upgrade, or delete a TA. It may give it an identifier to track it. Di= fferent versions of TAs may use the same TA ID but add a version convention= . This allows a TAM to identify a TA for upgrade.

= To ensure uniqueness, a UUID is a good choice for a TA ID where a TAM may c= reate to be unique.

Should the TA developer create= and provide TA ID to the downstream systems? It can but I think a TAM may = override it if it needs to do so. The TA developer should define a friendly= display name for the TA. When a TAM manages many TAs, a TAM operator will = like to see friendly display names rather than the opaque TA IDs that are c= reated for machine consumption. A TAM may locally maintain a mapping betwee= n TA names and TA IDs.

With SUIT compatibility= , a UUID Component ID for TA ID can work. Is there a place holder in SUIT f= or a TA friendly name? A TA name doesn't need to be passed to the TEEs = for management; it may help debugging logging but may not be worthy of the = bandwidth and size cost.

Thanks,
Ming


<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 12, 2020 at 2:14 AM Hannes= Tschofenig <Hannes.Tschofe= nig@arm.com> wrote:
Hi Akira,

I had a chat with Brendan about this topic.

In the SUIT model there is a manifest somewhere and it provides a pointer t= o where the binary, and other data is.
That pointer is a URI. This is used to fetch the information from some repo= sitory.

The vendor id and class id are identifiers used by the device to determine = whether it is looking at a manifest that can be applied to itself. A device= must not install software/firmware it is not supposed to because otherwise= you can quickly DoS the device.

For me, the question is what information should the device report when it i= s asked what software it runs. Brendan suggested to use the Component ID an= d we would make recommendations regarding the construction and the uniquene= ss we would like to have. For example, we could say that the component id f= or a TA should be a UUID and the same TA binary would have the same UUID. N= ote that this component ID could subsequently also be used as a filename bu= t we could also keep it separate.

What do you think?

Ciao
Hannes

-----Original Message-----
From: TEEP <t= eep-bounces@ietf.org> On Behalf Of Akira Tsukamoto
Sent: Monday, April 13, 2020 7:46 AM
To: teep <teep@ietf.o= rg>; suit@ietf.or= g
Subject: [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryRespons= e

Hi all,

I would like to restart the discussion of Unique Identifier of TA_ID in TEE= P's QueryResponse which was one of the item came up at TEEP interim mee= ting last week.

The discussion started between the Hackathon in Singapore and Berlin.

This is the link to the github.
https://clicktime.symantec.com/38kWqaWA3sW14euWC= DuBdWf7Vc?u=3Dhttps%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues= %2F4

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.
=C2=A0 =C2=A0 -=C2=A0 Vendor ID.
=C2=A0 =C2=A0 -=C2=A0 Class ID. # Could be file name for SGX, uuid for op-t= ee. uuid is used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as fil= e name in op-tee anyway
=C2=A0 =C2=A0 -=C2=A0 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 larg= est member than NONCE in TEEP message.
I prefer smaller bytes to reduce the teep message size but raw parameters o= f 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

_______________________________________________
TEEP mailing list
TEEP@ietf.org
https://clicktime.symantec.com/3bbx7gUqzexL4igHH5sBig7Vc?u= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
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/3bbx7gUqzexL4igHH5sBig7Vc?u= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
--000000000000d196d505a5814cc1-- --000000000000d87df705a5814c81 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 RzMCDCaZVaVtR6vtskjFXDANBglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgcQALs2LV 9KW0yU6Q0JeEuKMgwx0IxkDXJLGPwEQ0zpgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMjAwNTEzMDYwMDQyWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG 9w0BAQcwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAJhgiS/VUkq4wj6xwIIGmgJ9K0qz EQsSAlSKRGYqT9CsXdHJ1auNb0FqbdGJk2lZSFTz4AAI3vjTK1e3eYMiR+DVT+jmO01aTcJh2qJj u9R/E4uDw7diQyjhsAGSqsVU0UCkaPo+CPxe4kA4m+eH4BnoU11PphvKIBgTEbo1vnEuCxtq9XGq Ifz+jn9gqaXhTK9TS7/ASZB34F+Z3IMbTDYpBMSQiPdpHMvVgwgzyeixSy5Eg7Wtuxz8zyMI6sEa 8rAOyYuSI9bajdQoSgN5M/PLg135rPQC0WvG3xtFGcSFuARz+rUyYAuAX3WyyV5sk+PNEq/XfHnj ZbTsuJh5/W8= --000000000000d87df705a5814c81-- From nobody Wed May 13 03:45:35 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 CD7B93A0984 for ; Wed, 13 May 2020 03:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=VzZlY2QF; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=VzZlY2QF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUfAc9aIvsOU for ; Wed, 13 May 2020 03:45:31 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130051.outbound.protection.outlook.com [40.107.13.51]) (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 6D5EE3A0982 for ; Wed, 13 May 2020 03:45:30 -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=QAU+LJqt80L9wVOHIh80i5+RJBHmDaRqDjNzTBAke44=; b=VzZlY2QFmk3ppxr59p1XxDMGgvZ2oyq8c4K9k5VgmnQQi7d+8VpS3U+CB/cmTltANL0imHAH6LLcYf8FniOkuaFzmTsdErkqBcuYNO1YMkN9YH6jvYOki5qM4k42HSuCUDrS+m6V9foguBVN+i1Rv7p2ogT8VaHXiD/i38/DdYw= Received: from MR2P264CA0097.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:33::13) by VI1PR08MB3181.eurprd08.prod.outlook.com (2603:10a6:803:3f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.33; Wed, 13 May 2020 10:45:27 +0000 Received: from VE1EUR03FT022.eop-EUR03.prod.protection.outlook.com (2603:10a6:500:33:cafe::54) by MR2P264CA0097.outlook.office365.com (2603:10a6:500:33::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20 via Frontend Transport; Wed, 13 May 2020 10:45:26 +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 VE1EUR03FT022.mail.protection.outlook.com (10.152.18.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.19 via Frontend Transport; Wed, 13 May 2020 10:45:26 +0000 Received: ("Tessian outbound 4cdf5642225a:v54"); Wed, 13 May 2020 10:45:26 +0000 X-CR-MTA-TID: 64aa7808 Received: from e6a1247f941d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id DFC1ADCB-3078-46EB-894C-D5C7DAE765D1.1; Wed, 13 May 2020 10:45:21 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e6a1247f941d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 13 May 2020 10:45:21 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VmT9hvN8i74p/qJwDbZcGhkX+eWPMKoM0EXU6ssgGbYvrbYMsARHGeq1j10/+OoYxtRLEiwo59VQD/BwrFUxkFGPC8Y2BWkBVxjYt6ltCXx0RHgykWPmknJfJYDmm0ZSqGY79dFDATXQlSVXzVwlpc2h3G0RggUCFgfjvx78NSqyw5gmo5wWnGT862zgOdh1gzKyFj/NSNfprH5sOsXpTQBTPenzC3RUZp3vx9fNSb8QQrZSPyWwQEcL0uU0fh3kmmFkXhteWTKeCGaEK8Z8B3kB/wd5bNdpPyzWOvJ7bIrxsWz2zf4jn4kT6XpuwBwRKAV05TbPpNDc8NWV/8T5ww== 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=QAU+LJqt80L9wVOHIh80i5+RJBHmDaRqDjNzTBAke44=; b=oOsrx6psKOqxOY3oz5fDciNveY/Tq9ois0HhXQ7s8afPyOZudfVWthZcVx6tGWWjOve7Uee73qLDnJeoV5zsbo3RZ4Ocx7jGK0VtJJZPr4KU3yzsTenCSy3VdB7ynA/BWPicDkpG7kkKML68Yrs5/fExAPXDRI8oeCO1fhMjg4foNYg4B9EIMHzIUs7R2KlcwNPcFa28zjeL93y0LjbFFNxZRazN28urlp1/CkZIfRTwGE3JANOhz+fCwQMNPdCQsJGYzybiVKxAcEQs7lhiprimkOw4XW9haCzkAzAIgBRVurYYRjPcfsGBkedd3YD0VOa2gSUW6aZLqTNukuuBgg== 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=QAU+LJqt80L9wVOHIh80i5+RJBHmDaRqDjNzTBAke44=; b=VzZlY2QFmk3ppxr59p1XxDMGgvZ2oyq8c4K9k5VgmnQQi7d+8VpS3U+CB/cmTltANL0imHAH6LLcYf8FniOkuaFzmTsdErkqBcuYNO1YMkN9YH6jvYOki5qM4k42HSuCUDrS+m6V9foguBVN+i1Rv7p2ogT8VaHXiD/i38/DdYw= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0SPR01MB0031.eurprd08.prod.outlook.com (2603:10a6:208:7b::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.33; Wed, 13 May 2020 10:45:19 +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.2979.033; Wed, 13 May 2020 10:45:19 +0000 From: Hannes Tschofenig To: teep Thread-Topic: draft-ietf-teep-otrp-over-http-06 Thread-Index: AdYoT0JwuJyj7L3ISgW6R9hoPfO8nA== Date: Wed, 13 May 2020 10:45:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 453bf7b3-3499-4c9d-ae29-09a73230db20.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.122.242] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: e41e0f62-eb29-4013-238e-08d7f72abf33 x-ms-traffictypediagnostic: AM0SPR01MB0031:|VI1PR08MB3181: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0402872DA1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: Dha2CZCgS/68sRD+VI6//Dz9Zo/pjmQ8Ex6Z+6XrXFsGGlAV6uEfqZXVQXGnWIj63tVM5Qg6QlTN2/4CqXMiiGY7yChPdnUDvhtBOKJmThAllzdLCMsHDtUyXdOtaRWRftagXX1xPHvMzqXa5vSHGAWQZ3ONz4fERsX0XkxTdkjZfTAC5zFP44XgGj6VPyHF7f37zGse0ZF0xQaqPS5uHoanGUxrmnGSkodH0YUlTmL+Bg1EyxGi8PUOA1LS58Cq36Xy1bCwQI3S74a9HFnrb2bqcqe3FFW4PdrKkUqPnq0bsAmHsQevNNEctixuq2DoYhnDQyblgXqL4mg67svYDh3g9PMCEolHdplgrutMQR0Cak8U9PgyHN/md6W3nxGOiR6Ot5Cxj3RODcfVEk/yPz5p13c9XEUQwnJsgzjNvRgiN0w0Lj/dw0RTpjJSFlb2lDVnWzxyNWKnXaw3qXPgqWoe6mKAjdT0RsmV7Q5QRWPB2k0R9czizIHzCk3dTKwWTmHKxjR4t792l9O7s/m7Bwy1/zVTwTo1CWaOg3pmVrkVkFAKLhqUTfa1WhZG3sPMDYGqBPP4MAnravk6UGp8hNtS81ztbn2BccT/bJlDSDE= 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:(4636009)(396003)(39860400002)(136003)(376002)(346002)(366004)(33430700001)(64756008)(66946007)(76116006)(8936002)(33656002)(33440700001)(186003)(478600001)(5660300002)(166002)(86362001)(966005)(6506007)(26005)(7696005)(66446008)(316002)(66476007)(66556008)(9686003)(2906002)(8676002)(71200400001)(55016002)(52536014)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qsQuPmj0RCAgr9QThC3963R51mhueMkWxPM9EGwdXJ4pCi9DE+EA459hAYG+fJshaGVeaU9thIURp0ekCCBX8aB9dC78wE5UaT4FUxv3ivoEkSq/u+0R1kD7MY+fV84lmYfWzrclOo5p7bG3BKPhLIdbi45xRJLbC60vaHXHnTgZNXReoO1ZSebE8fQs7nckA7btV8A8NhvbGDTKltZSv/0c4pzlp7OtH+M2Rvuhrz46JLA/FLhrxpy0jQCv3eaEM88U0MNRgs+WowWX77jmARA98QFUjAiYkW4hduP/dS6zX5B0wI6YTcVaOSUbfPcvkHfGs8jd+3nJFXpvZwRD52R4UNMZ1w3rR+CaMSgtFGnhJNp2yHqUTOgNwTaHtVnOixrSFiN8T5WqDZ2LOmCuGLIpdoBgy9ZunlnAUyt6dagoi5TSTSBbeR74ptMbwISki6n14stoY67o80Lf1+V4IEG/eWjIfFk6Orzlz75qvh1a2V3Oe3e4bbUMtj9y6mS9 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37168A2CC099C7FE52EFBBACFABF0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0SPR01MB0031 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT022.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)(376002)(136003)(396003)(346002)(39850400004)(46966005)(33430700001)(82310400002)(26005)(186003)(8676002)(9686003)(70206006)(47076004)(33656002)(55016002)(316002)(6916009)(8936002)(36906005)(70586007)(166002)(2906002)(6506007)(81166007)(33440700001)(82740400003)(356005)(478600001)(336012)(86362001)(7696005)(966005)(52536014)(5660300002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 3136f63d-4b9c-4bd9-045e-08d7f72abb2f X-Forefront-PRVS: 0402872DA1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: fx9QMXIQJzHmsbrmpbvOQMhZaDCqHLm/N6O3UlMjzO/Y+OiGA2ZsvdRKhaBIPQr2zV8VdGcLX7uMdwCay6YYFOHiceDo9gm+P6S4qCIYtCsqvwvIkjfBQiPqQe9/zN5AVw+gtijVsqXgCM4kT3PsWwj6p+sdgjs9CQ0UlR+9FRA6b4hkIVZBauS5a4aGb9z8v99XrCc0TLJ1S6P0fCk20qNTe4LMARimHH1/CpUfy4dfefJEo6MYpR+dzwmKu747wV1Qqj1cNs/6Y73TR58DwIotpGcagrZf/fJAzzgaN6FA6mgQLRwAs9G5x+O/uizyU7JZOBsmIJ3F5Ax3yWHZ6ZJE6S4VztgPWJpPQSYlczAeAeGRjz99lADnb1ugv6GZWwohbiLmb4YxsiJ9/h+UzoSuIWK0k99gor3xHT5v0IzEYQoxNjASScfaZ+o8VUMp0UT2dflBaCZOahVmjILehRs6Fm9c/tsQoVs4WwmwgpI87rWxIPzWD4VQ+f6vEUupFzYEi8LFdWi5cZArbISop3+p8Cg4p7r2PnXxD3cfysWv1GPuhtlJeLS5P+TgKFCBaB4BLs+eVSylUHfZbt0ZczipoAYDRlDtQj1WRAiAhv/gowmeW6HTcmPicHfMnug4vJJ8dK98LBp533HEFT9ZJw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2020 10:45:26.3272 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e41e0f62-eb29-4013-238e-08d7f72abf33 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: VI1PR08MB3181 Archived-At: Subject: [Teep] 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: Wed, 13 May 2020 10:45:34 -0000 --_000_AM0PR08MB37168A2CC099C7FE52EFBBACFABF0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, Hi all, I read through https://tools.ietf.org/html/draft-ietf-teep-otrp-over-http-0= 6 and have a few high level comments. I wonder whether there is room for simplification in these two figures belo= w. IMHO the middle layer is not needed in this figure. We have two layers, nam= ely the TEEP protocol layer and the HTTP transport. +------------------+ TEEP +------------------+ | TEEP Agent | <----------------------> | TAM | +------------------+ +------------------+ | | +------------------+ TEEP-over-HTTP +------------------+ | TEEP/HTTP Client | <----------------------> | TEEP/HTTP Server | +------------------+ +------------------+ | | +------------------+ HTTP +------------------+ | HTTP Client | <----------------------> | HTTP Server | +------------------+ +------------------+ Figure 1: Agent-to-TAM Communication The same is true for the next figure in the document. I would remove the TE= EP/HTTP implementation part and the figure is already substantially simpler= to understand. Furthermore, I am wondering whether Section 3 shouldn't go to the architect= ure draft because this is not really about the HTTP transport. Replace HTTP= with CoAP, MQTT, etc. and the design aspect would still be the same. Furth= ermore, we have decided in the architecture that we want to provide applica= tion layer security independent of the transport and hence the question abo= ut where various pieces should go is less about security anymore. We could = have made the design differently but we followed the OTrP approach. Model: A B C ... TEE TEE TEE +----------------+ | | | | TEEP | Agent | | | Agent | implementation | | | | +----------------+ v | | | | | +----------------+ ^ | | | TEEP/HTTP | Broker | | | | implementation | | | | +----------------+ | v | | | | +----------------+ | ^ | | HTTP | | | | | implementation | | | | +----------------+ | | v | | | +----------------+ | | ^ | TCP or QUIC | | | | Broker | implementation | | | | +----------------+ | | | REE REE REE Figure 2: TEEP Broker Models Minor aspects: The content type has to change. Currently it talks about JSON. Reference https://tools.ietf.org/html/rfc6125 Instead of RFC 2818. In terms of HTTP transport aspects I believe the important aspects are * Does it use the HTTP ports (80/443)? (Yes, in our case) * Does it use the HTTP URI scheme? (Yes, in our case) * What HTTP messages are being used? (POST only in our case) * What URIs are we sending the requests to? (I don't think we talk abou= t this but we should.) * What header fields does the client and the server use? (*) * Are we using Cookies? (I would say that we don't. Currently not discu= ssed.) * The use of status codes ** * Server Push*** * HTTP authentication **** * Redirect handling ***** *) The text says that the client uses the Accept header but I don't see any= normative language there. The headers the server uses are listed but my understanding of those is tha= t they are only relevant for co-existence with web browsing. Clearly, the c= ommunication we are describing isn't useful for web browsing scenarios. IMHO the following statement should be enough: " The "Cache-control" header SHOULD be set to disable caching of any TEEP = protocol messages by HTTP intermediaries. Otherwise, there is the risk of stale TEEP messages. " To me, the following three headers shown in the draft are an overkill: X-Content-Type-Options: nosniff Content-Security-Policy: default-src 'none' Referrer-Policy: no-referrer I would also add the following sentence: " If the TAM does not receive the appropriate Content-Type and Accept head= er fields, the TAM SHOULD fail the request, returning a 406 (not acceptable) response. TAM responses MUST include a Content-Length header. " **) The example gives me the impression that the protocol end indication is= the 204 No Content. While I never saw it that way we should describe it mo= re clearly if that's indeed the case. (FWIW the note that the TEEP Agent ca= n start with a QueryResponse if it has the TAM public key is IMHO incorrect= .) ***) I don't see any use for it. ****) I don't see a need to use HTTP-based client authentication *****) The text is currently very fuzzy. It says "Redirects MAY be automati= cally followed." Based on what decision should a developer decide whether i= t wants to follow the redirect? 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_AM0PR08MB37168A2CC099C7FE52EFBBACFABF0AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave, Hi all,

 

I read through https://tools.ietf.org/html/draft-= ietf-teep-otrp-over-http-06 and have a few high level comments.

 

I wonder whether there is room for simplification= in these two figures below.  

 

IMHO the middle layer is not needed in this figur= e. We have two layers, namely the TEEP protocol layer and the HTTP transpor= t.

 

      +------------------+  &= nbsp;        TEEP    = ;       +------------------+

      |    TEEP Agent  = ;  | <----------------------> |     &nb= sp;  TAM       |

      +------------------+  &= nbsp;           &nbs= p;           +-------= -----------+

            =    |          &= nbsp;           &nbs= p;            &= nbsp;          |

      +------------------+  &= nbsp;   TEEP-over-HTTP      +-------= -----------+

      | TEEP/HTTP Client | <----------------= ------> | TEEP/HTTP Server |

      +------------------+  &= nbsp;           &nbs= p;           +-------= -----------+

            =    |          &= nbsp;           &nbs= p;            &= nbsp;          |

      +------------------+  &= nbsp;        HTTP    = ;       +------------------+

      |    HTTP Client &nbs= p; | <----------------------> |    HTTP Server &n= bsp; |

      +------------------+  &= nbsp;           &nbs= p;           +-------= -----------+

 

            =        Figure 1: Agent-to-TAM Communication

 

The same is true for the next figure in the docum= ent. I would remove the TEEP/HTTP implementation part and the figure is alr= eady substantially simpler to understand.

Furthermore, I am wondering whether Section 3 sho= uldn’t go to the architecture draft because this is not really about = the HTTP transport. Replace HTTP with CoAP, MQTT, etc. and the design aspec= t would still be the same. Furthermore, we have decided in the architecture that we want to provide application la= yer security independent of the transport and hence the question about wher= e various pieces should go is less about security anymore. We could have ma= de the design differently but we followed the OTrP approach.

 

       &nbs= p;            &= nbsp;      Model:    A  &= nbsp;   B      C    = ...

 

       &nbs= p;            &= nbsp;           &nbs= p;   TEE    TEE    TEE

        = 3;----------------+        &nbs= p;  |      |      |<= o:p>

        |&n= bsp;     TEEP      | &nbs= p;   Agent |      |   &nb= sp;  | Agent

        | i= mplementation |          = |      |      |

        = 3;----------------+        &nbs= p;  v      |      |<= o:p>

       &nbs= p;         |    = ;            &n= bsp;         |   &nb= sp;  |

        = 3;----------------+        &nbs= p;  ^      |      |<= o:p>

        |&n= bsp;   TEEP/HTTP   |    Broker | &n= bsp;    |      |<= /p>

        | i= mplementation |          = |      |      |

        = 3;----------------+        &nbs= p;  |      v      |<= o:p>

       &nbs= p;         |    = ;            &n= bsp;  |          &nb= sp;  |

        = 3;----------------+        &nbs= p;  |      ^      |<= o:p>

        |&n= bsp;     HTTP      | &nbs= p;         |    = ;  |      |

        | i= mplementation |          = |      |      |

        = 3;----------------+        &nbs= p;  |      |      v<= o:p>

       &nbs= p;         |    = ;            &n= bsp;  |      |

        = 3;----------------+        &nbs= p;  |      |      ^<= o:p>

        |&n= bsp;  TCP or QUIC  |       &nb= sp;   |      |    &n= bsp; | Broker

        | i= mplementation |          = |      |      |

        = 3;----------------+        &nbs= p;  |      |      |<= o:p>

       &nbs= p;            &= nbsp;           &nbs= p;   REE    REE    REE

 

       &nbs= p;            &= nbsp;  Figure 2: TEEP Broker Models

 

Minor aspects:

 

The content type has to change. Currently it talk= s about JSON.

 

Reference https://tools.ietf.org/html/rfc6125 Instead of RFC 2818.

 

In terms of HTTP transport aspects I believe the = important aspects are

 

  • Does it use th= e HTTP ports (80/443)?  (Yes, in our case)
  • Does it use the HTTP URI s= cheme? (Yes, in our case)
  • What HTTP messages are being used? (POST only = in our case)
  • What URIs are we sending the requests to? (I don’t thin= k we talk about this but we should.)
  • What header fields does the client an= d the server use? (*)
  • Are we using Cookies? (I would say that we don’= ;t. Currently not discussed.)
  • The use of status codes **
    • Server Push***
  • = HTTP authentication ****
  • Redirect handling *****

 

*) The text says that the client uses the Accept = header but I don’t see any normative language there.

The headers the server uses are listed but my und= erstanding of those is that they are only relevant for co-existence with we= b browsing. Clearly, the communication we are describing isn’t useful= for web browsing scenarios.

 

IMHO the following statement should be enough: =

“

   The "Cache-control" head= er SHOULD be set to disable caching of any TEEP protocol

   messages by HTTP intermediaries.  = Otherwise, there

   is the risk of stale TEEP messages.

“

To me, the following three headers shown in the d= raft are an overkill:

 

       X-Content-Type-= Options: nosniff

       Content-Securit= y-Policy: default-src 'none'

       Referrer-Policy= : no-referrer

 

I would also add the following sentence:

“

   If the TAM does not receive the appropr= iate Content-Type and Accept header fields, the

   TAM SHOULD fail the request, returning = a 406 (not acceptable)

   response.  TAM responses MUST incl= ude a Content-Length header.

“

 

**) The example gives me the impression that the = protocol end indication is the 204 No Content. While I never saw it that wa= y we should describe it more clearly if that’s indeed the case. (FWIW= the note that the TEEP Agent can start with a QueryResponse if it has the TAM public key is IMHO incorrect.)=

 

***) I don’t see any use for it.

 

****) I don’t see a need to use HTTP-based = client authentication

 

*****) The text is currently very fuzzy. It says = “Redirects MAY be automatically followed.” Based on what decisi= on should a developer decide whether it wants to follow the redirect?

 

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_AM0PR08MB37168A2CC099C7FE52EFBBACFABF0AM0PR08MB3716eurp_-- From nobody Wed May 13 04:19:55 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 6830B3A1063; Wed, 13 May 2020 04:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=2.497, 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, RCVD_IN_MSPIKE_H2=-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=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 r5v5AdTmLgNU; Wed, 13 May 2020 04:19:46 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410045.outbound.protection.outlook.com [40.107.141.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FA23A09A2; Wed, 13 May 2020 04:19:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aNNzfnRApsT/rfQrWK+dnOhgpYj74a91eqx/vciMooAYdpxBKshMfolHaKf0YcREm51Tt+Q+2a2oI/y5yx+lEXsfa6gHCKrZ00srNGhBU74esrCcLmUWNVDNSJIpy7ZPcEY1eypM7OpxjbS5TY0YkKxxOStx4Iz4b1nO0I64xlhe73eeddEGSuvBHDh3igDak8EyYGBYLzpBBvMD0VENyryGbd23xQKI5Ac7z2MndxxEqJdog3Tn4Z3jJWbDiy6dYnxvYiuy1ANhRyZMElbcafKkPgdP0X2CZAP8L/MwHarQu4ukcK/NfF0eS5YH5pZsoMsuIE3jLOBjDoRsQTjigg== 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=QYGeASVcr2FtgzyD1bidI7NTsZBy5DXapA+JV37+0h8=; b=jF1kfbnFuwAiLvjaKzo3xuCibG9s8k8G0FZX8cDTt4Es9Uu/JSdyS0THw3/3q1NRJQI5ymgDS7ukfdZ2oIwrl3/tY/5duC622xWUO/a7QOC/M71BAAR2fdHe51P7h1IMpdkRyGKQA6AAsKKUXoRpye75S/pVuqTnuT48QKRqUnyFgl3KL2Ku2rDqhHQBipSe/MCoUwlfq46dGFd88BrHVslYi4gXTc+2wEYHk7GuWW8m7768HbWdKDs4iXO5Box2OSXBssXQbY1y5DzbQLsPjHOQC7OJWINNc7d+kFK2FIH2YdcPByi3P1mpS1ajBS3Bdgm2h6MKq7uNCDEzsliUNA== 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=QYGeASVcr2FtgzyD1bidI7NTsZBy5DXapA+JV37+0h8=; b=IQ+cJ77TglC7EB6ydati3rvbUCsn9nXleJTN3XstYaZvll9UaOUAFcPhxsAOrn/44IRBYSO/UfaqPp4DxukHsZRUDMBJicJXl9XsQgUlHVYBOplk5ryHcJaI58CAW2JMH2DevGgbjWnhFBIp+rhdM9wSiODfZMbjtuII1Krq4qY= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=aist.go.jp; Received: from TYBPR01MB5328.jpnprd01.prod.outlook.com (20.180.224.205) by TYBPR01MB5471.jpnprd01.prod.outlook.com (20.180.225.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29; Wed, 13 May 2020 11:19:44 +0000 Received: from TYBPR01MB5328.jpnprd01.prod.outlook.com ([fe80::dc2:dddc:31e4:65dc]) by TYBPR01MB5328.jpnprd01.prod.outlook.com ([fe80::dc2:dddc:31e4:65dc%7]) with mapi id 15.20.2979.033; Wed, 13 May 2020 11:19:44 +0000 To: Mingliang Pei , Hannes Tschofenig Cc: teep , "suit@ietf.org" References: <7526678c-9ebc-e265-514c-435dce7595bc@aist.go.jp> From: Akira Tsukamoto Message-ID: <00515b62-b2ae-405e-2c44-c533c6857873@aist.go.jp> Date: Wed, 13 May 2020 20:17:39 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TY2PR02CA0023.apcprd02.prod.outlook.com (2603:1096:404:56::35) To TYBPR01MB5328.jpnprd01.prod.outlook.com (2603:1096:404:801f::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.153] (103.2.250.188) by TY2PR02CA0023.apcprd02.prod.outlook.com (2603:1096:404:56::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.30 via Frontend Transport; Wed, 13 May 2020 11:19:44 +0000 X-Originating-IP: [103.2.250.188] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: ff1fad1e-f4c9-4e07-7eb4-08d7f72f89b6 X-MS-TrafficTypeDiagnostic: TYBPR01MB5471: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0402872DA1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mlID6aLyJg63KsTrnejvYV6ONK41J+X+qA8G3eFN9uwb65QBLfBUuWwIKlxwQ7rrFmEgh7c5nyTOVL5DXR/FUn2Wg4ULQqoQd7lwYPYj3f1qMsZmcSeCVzhoarziQPArZsrRSzTkLhCTiTto1fkVybRbhSNhWtoelNo6wYRxNq+soFS/64NCC6gpl1Ea55zDB6N/u52FKT6dKPno501cvIx8mLW9H8DPPxDovgkbWrVonapf6lKbPt2gaiKKDhXYWXpoIQCZvbayVKNJKElRSIIme8OePVJmthwzK1zDWrhwGyo06I2l+zLqdI4QDPW5e+A2CdYnoSLaB+eAbpQbjlIPTddgZ44CdQSCvyVNfaxcfhYiGvhck7MemnGUdlCq6mHqDazBB5l37ZNPKMTlLhYr54jAt+rRoi/iS19TP7OG31KNRIWTe2IgiCu+tf1FDtWS+0xRglDREKqvnyBsAlXI7/VNvhSRL/erfYEMMGcSBJ0LRQ+G/wg2zA0JMQs4V0L5r9+74aFBvQkeksUqtFozpH+64eZ1sAOfK9RVorvbFmi6E7v3eM8HniPkuHNMWOsrVsfjKpPKMeKOGM3q60e1oN3Wja9MOKTx8ou8brfAm+Nu/O6xntjs4X12DEfgw3W8Qm/zJpXELiTQdJm3A2/lVKOd0pEVcazcFwMNfnM= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYBPR01MB5328.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(396003)(376002)(366004)(136003)(33430700001)(31686004)(478600001)(44832011)(31696002)(26005)(16526019)(16576012)(966005)(186003)(54906003)(52116002)(316002)(110136005)(6486002)(36756003)(8936002)(66476007)(66946007)(53546011)(66556008)(2906002)(86362001)(33440700001)(5660300002)(6666004)(2616005)(956004)(4326008)(8676002)(222643001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Jcf48QrXlPMoR1Ze7ATYMpRCc/XDCsXAVaVDytiXvOnLf//Ypq4/JiWYDq9yR5YLg8dFZHj9lMSf8MCgotgJ9tKDkdBJ4NTwxsWS9Oq4pDyrgkssL8nA6ANmEmmikW4HA8nlIdBd94V06EvH+WARxPdZPX19jk1qDH6Bv/bsfRqVlukUtUzXqjv7hG+YhZf0IlYRr52bx5ZEm8ZGNyTrRJd0wNInV8SCUyvxXJZdQgNx/wPsOK6GYjfriN8kYAUMQ0AULttxjjwemSERv3lj7LsH3etFLyjE4PNRGDHvxwQnAldZf98W4LL0Q5A7BuKsyOifrhWRLUxP75N4sZAIQuKThEtp8u816MR2Zu9S6koESxRkxlb6PuASL2ud6Vzr0JpRI9HjpZoFHw6po6fMR48WKCCeZJi7fK2EUPda/aQVE5TIwDgPDEowFCfIBBdE6Mke4Ge3ICsy+sjdUMLg27CKHgKQMLItUrQkAU8Dk1g= X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-Network-Message-Id: ff1fad1e-f4c9-4e07-7eb4-08d7f72f89b6 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2020 11:19:44.3948 (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: 4IpCFZzGtsYcgCGbpkxE5KWrCI0bE5TIy7H31GaNF/3L7a0qm7Qrq4w2g7yZW7/Vo7QHqtaZq+W3L2iXEp6hgdtfaeEM/7WIz3BJqFEmsFI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYBPR01MB5471 Archived-At: Subject: Re: [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: Wed, 13 May 2020 11:19:49 -0000 Hi What I was thinking of images similar to the pseudocode bellow. typedef struct { uint16_t vender_id; /* RFC4112, type5, 128 bit, 16 byte */ uint16_t class_id; /* RFC4112, type5, 128 bit, 16 byte */ uint16_t device_id; /* device unique-ID, 128 bit, 16 byte */ } teep_uid_t; digest[MDSIZE]; teep_uid_t uid; sha256_ctx_t ctx; uint32_t hash_uid; /* 256 bit */ memset(digest, 0, sizeof(digest)); memset(&uid, 0, sizeof(uid)); sha256_init(&ctx, MDSIZE); sha256_update(&ctx, &uid.vender_id, sizeof(uid.vender_id)); sha256_update(&ctx, &uid.class_id, sizeof(uid.class_id)); sha256_update(&ctx, &uid.device_id, sizeof(uid.device_id)); sha256_final(digest, &ctx); convert_d_uid(digest, hash_uid); Then use the hash_uid as TA_ID in the teep message. This way the TAM do not have to separately store the TAs with vender_id and/or class_id. And good definition of vender_id, class_id and device_id are in the suit manifest draft, therefor, we do not have to mention the details in teep drafts. We have to specify which sha256 or anything else to use. -Akira On 5/13/20 15:00, Mingliang Pei wrote: > One of the questions is: who creates or assigns an ID as the TA_ID to a TA? > > A TAM is responsible to install, upgrade, or delete a TA. It may give it an identifier to track it. Different versions of TAs may use the same TA ID but add a version convention. This allows a TAM to identify a TA for upgrade. > > To ensure uniqueness, a UUID is a good choice for a TA ID where a TAM may create to be unique. > > Should the TA developer create and provide TA ID to the downstream systems? It can but I think a TAM may override it if it needs to do so. The TA developer should define a friendly display name for the TA. When a TAM manages many TAs, a TAM operator will like to see friendly display names rather than the opaque TA IDs that are created for machine consumption. A TAM may locally maintain a mapping between TA names and TA IDs. > > With SUIT compatibility, a UUID Component ID for TA ID can work. Is there a place holder in SUIT for a TA friendly name? A TA name doesn't need to be passed to the TEEs for management; it may help debugging logging but may not be worthy of the bandwidth and size cost. > > Thanks, > > Ming > > > On Tue, May 12, 2020 at 2:14 AM Hannes Tschofenig > wrote: > > Hi Akira, > > I had a chat with Brendan about this topic. > > In the SUIT model there is a manifest somewhere and it provides a pointer to where the binary, and other data is. > That pointer is a URI. This is used to fetch the information from some repository. > > The vendor id and class id are identifiers used by the device to determine whether it is looking at a manifest that can be applied to itself. A device must not install software/firmware it is not supposed to because otherwise you can quickly DoS the device. > > For me, the question is what information should the device report when it is asked what software it runs. Brendan suggested to use the Component ID and we would make recommendations regarding the construction and the uniqueness we would like to have. For example, we could say that the component id for a TA should be a UUID and the same TA binary would have the same UUID. Note that this component ID could subsequently also be used as a filename but we could also keep it separate. > > What do you think? > > Ciao > Hannes > > -----Original Message----- > From: TEEP > On Behalf Of Akira Tsukamoto > Sent: Monday, April 13, 2020 7:46 AM > To: teep >; suit@ietf.org > Subject: [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryResponse > > 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://clicktime.symantec.com/38kWqaWA3sW14euWCDuBdWf7Vc?u=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fissues%2F4 > > 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 > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://clicktime.symantec.com/3bbx7gUqzexL4igHH5sBig7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep > 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/3bbx7gUqzexL4igHH5sBig7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep > From nobody Fri May 15 17:09:38 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 EF9613A0762 for ; Fri, 15 May 2020 17:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=O+YpNNph; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=W3EV2i18 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9G1RfiVg-oR for ; Fri, 15 May 2020 17:09:35 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080CF3A073E for ; Fri, 15 May 2020 17:09:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2254; q=dns/txt; s=iport; t=1589587775; x=1590797375; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=E3V8bdokz++0opkjG3zhoRe1mr3cGEj9rfq0Vx2ObTY=; b=O+YpNNphHihY1gmUR60sbnhqFNBoG0QJBU6ZJDdPsiL9hrOyCn3obFXI 0/y41uKqFUuQMsNfSMm8WG/hZxQwPhqvezZX1RqSa6y97s221TOSm8cS8 OVMUHm8RgUg1zEl6TI1ih6XEq0ZJA7P+n1tIVWk5qe3P7GSJpT6Z0U6jM A=; X-IPAS-Result: =?us-ascii?q?A0ABDQA6Lr9e/5NdJa1mHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UeBVFEHb1gvLAqEG4NGA4sxgWyYYIJSA1QLAQEBDAEBGA0IAgQBAYREAheCA?= =?us-ascii?q?SQ4EwIDAQEBAwIDAQEBAQUBAQECAQUEbYVWAQuFcgIBAQIBARAGCxEMAQEsB?= =?us-ascii?q?QcPAgEIGgImAgICJQsVBgEGAwIEExQOgwQBgksDLgEOphECgTmIYXaBMoMBA?= =?us-ascii?q?QEFgUZBQoJ1GIIOAwaBDiqCY4lfGoIAgREnDBCCTT6BBIFjAQEBhHgzgi2OP?= =?us-ascii?q?oMeoS8Kgk6DX5RjHYJdjXGNApA8mU+DewIEAgQFAg4BAQWBaSKBVnAVOyoBg?= =?us-ascii?q?j5QGA2QQBiDWoUUhUJ0AjUCBgEHAQEDCXyNJwGBDwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AJEACdh1VpULns/AIsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGv6dsgUPHG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK6PFRbXsHkaA6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.73,397,1583193600"; d="scan'208";a="466478768" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 May 2020 00:09:34 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 04G09XH2005047 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 16 May 2020 00:09:34 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 15 May 2020 19:09:33 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 15 May 2020 20:09:32 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 15 May 2020 19:09:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oS4MfxdCeFi9bm3OXfxXQbjpc7CLfiVgPnjk/jW6Q2pu/npMI9keZEDLrbhSErXauo/Y0hOlS72oboqv8YN6DC+2EZvy6s/vq3giNjV5I8cJPZqS48VWbZ90yD5L1acKhTRAdtO5/RMl50d4cADIVbA9wGs3WqN69UKtE3nlpyIvTzN7Gv+IMaYDjOCuVRemhxcCOCD8IJNSa0pp4QGTRTfYd+f64y20iiiOHdn6KZjRkUapUwuXexq/+ORfmgEMYnS1lLZqzK7wsEVmoyO+lJ1o5r8JijcfFGQHoytp6mndSnPJVBwAoDoe/kmBEZSm1/rENT3RVR2UFyp/gAJdFg== 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=E3V8bdokz++0opkjG3zhoRe1mr3cGEj9rfq0Vx2ObTY=; b=TjL8y2ez6b3GEAVL/3ml/oNyzxC5bbCAtgn//bJN11mXiHqZEyfHYt5982nDbOSJ9pz/UhuJseHJY9hbHqjfyLzbeou6c7jbucHCrZ2QxJuD/5z6Bo488w/53Pp4gIo4iPW6ZOK1tdsS+lkEOBlSwQ4j+CWJHKO3U+22g+RKzZBY8FfvK0rJCilH0abzc+4II8xzPa6egLkA/ECBPhv2hh7JwdGC77z2a530ybk0/tE5+2PakhoiuPZJqTxi/WvdARMjN/cmdJJZAiXLymw/ECcP1rZXaLbn/n7g4sZI1oa4YyHaOTqNLKLl5wjv7+mEbvXTGWEIMxzbO4Bl49nEDA== 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=E3V8bdokz++0opkjG3zhoRe1mr3cGEj9rfq0Vx2ObTY=; b=W3EV2i18O/f7CfS0llELpst+5AbByuQ+HYIq9NjwVhJMh8vQ3fKl1vncS4bhnOGLpgngleG9/9ZYYVa63JbFF8ZMUEgKhT2kY4jdSvmmgpSF6yV8KgKXbvPWFv1SSkCT6GG0KH0rnbRVM9nWFqqod8TN4cZ7BsNyg9siWs67Mu0= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB4289.namprd11.prod.outlook.com (2603:10b6:a03:1ce::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.24; Sat, 16 May 2020 00:09:31 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::101e:db5b:b661:949%6]) with mapi id 15.20.2979.033; Sat, 16 May 2020 00:09:31 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "teep@ietf.org" Thread-Topic: IETF 108 will be an online meeting Thread-Index: AQHWKjPhNrTFxf1imku9hCLCO+c0gKipYskA Date: Sat, 16 May 2020 00:09:31 +0000 Message-ID: <552BFC46-8E6D-4691-B50B-BC4DDFCC21F5@cisco.com> References: <83D4CBCE-E464-4CCC-8679-592531EF7448@ietf.org> In-Reply-To: <83D4CBCE-E464-4CCC-8679-592531EF7448@ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.15.200413 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 650d6ecb-579b-481c-283f-08d7f92d686a x-ms-traffictypediagnostic: BY5PR11MB4289: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 040513D301 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7tQZQWhdoSV9nsZ8AW4TW0wEsHPIIG+Z26dGPQvXVA1B4Fe+NJ97EhGNBS0xxbnoMR/1USvwrv9BXUo5WbkGHkk98QqVPRkdMtE3j1bvSF21xq3FOBZrVFwz97pF4BRZjsrSMqkwXvwc11LRGRPhvCliEKsXOoZbplChvqC8gqEYfLqOMy/LQA0A2YNkYCYpYzUTgyfS6mQp0zZp3owksglD14FCucn++NOFjkq4xodnVPQfavKKlW9zPDKkHIns4tCM8Q5zMF4uVZ9cskosT2DBbQc7x6gHpIipsAin2jAakBpw/Cn/hLxslaZn3+5wRPY179gAkMWSAXTRd7HaE6sfEjaskV71fTJVPqW+Md7QOsvzXjqM5HxNFxKElL8jgCbYDMFUgyeyXApodMs/bdHGSg720Zkx2Aq26nc/g6qel5FNgAxcfmSDQELpSVuLDhhm/wQzx/TPNG+4I55Dvqq43slArzgkYkd0Tva4VT+G4RxVekNDsqZ219GChDcFCBNVBlrVF3dfBiQtNC8hUA== 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:(4636009)(396003)(366004)(346002)(136003)(39860400002)(376002)(8936002)(2906002)(316002)(5660300002)(36756003)(26005)(8676002)(6506007)(186003)(66574014)(966005)(66556008)(76116006)(6486002)(6512007)(66446008)(66946007)(86362001)(478600001)(64756008)(71200400001)(6916009)(66476007)(33656002)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: jfhIhicQPG8rYM/un2MUA/VbLTx1ibEneQGAAACbB8b9V5uskxnz3v2+12K79DKAz8vzbpWOhDD9D3AMqGK3jjIM9HwjBOwRGI9a6CwvPi21ceDBCKiGz+F4W6Fab9EKiREpp9LrKnFBqH5G6skkoacItbuxSKYv8jdwmtOVzsf/6ZzW2HldYt80zFaVEQNPGPtX7MOd1BU+1VnrCGb0119HtQ/a0ShkqSLAKS9hxpIQrymFgbQHNEQYlIUhLk6PpsNww1hMX/12DQrPLvA1T/eB9pchU740d5cRB1Ms41v4AHGCDs5y8/FL2I5KdQ7BAyQBHiDZeV8KH0MPNLYtYTMVsk35jitfwIIcHL9g6seELTcX4Mp98I3NHQbmUzZTIVopUJPSySWezNxE6sypHJVM/dFHXYKLaJ8meypUiaLZhBwyCdk8EpuDAb3QHN7XFvTNCmOCvh7yCqqeX40s/x05Qov/X0WQTpXU5fWTAIfTPy18+j4byfP3/QTRgtge x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2A587A4FD82669448DC73B045B877F7D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 650d6ecb-579b-481c-283f-08d7f92d686a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2020 00:09:31.5507 (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: VpzR5f8nJAxIE8Igg8cKdcUlGQoYuq9dYHMwyHDSsxhNFEbZqp9M+w7g+dSr7x5fcqAeXNCiPVTi4q3FrAn66A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4289 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: [Teep] FW: IETF 108 will be an online meeting 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, 16 May 2020 00:09:37 -0000 SW4gY2FzZSB5b3UgZG9uJ3QgcmVhZCB0aGUgSUVURiBBbm5vdW5jZSBsaXN0Og0KDQrvu79PbiA1 LzE0LzIwLCAyOjA4IFBNLCAiSUVURi1Bbm5vdW5jZSBvbiBiZWhhbGYgb2YgSUVURiBDaGFpciIg PGlldGYtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2hhaXJAaWV0Zi5v cmc+IHdyb3RlOg0KDQogICAgVGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFN0ZWVyaW5nIEdyb3Vw IChJRVNHKSwgdGhlIElFVEYgTExDIEJvYXJkIG9mIERpcmVjdG9ycywgYW5kIHRoZSBJbnRlcm5l dCBSZXNlYXJjaCBUYXNrIEZvcmNlIChJUlRGKSBDaGFpciBoYXZlIGRlY2lkZWQgdG8gcmVwbGFj ZSB0aGUgaW4tcGVyc29uIElFVEYgMTA4IE1hZHJpZCBtZWV0aW5nIHdpdGggYW4gb25saW5lIG1l ZXRpbmcuIFRoaXMgZGVjaXNpb24gaXMgYmFzZWQgb24gdGhlIElFVEYgRXhlY3V0aXZlIERpcmVj dG9y4oCZcyByZWNvbW1lbmRhdGlvbiwgd2hpY2ggd2FzIG1hZGUgYWZ0ZXIgY29uZHVjdGluZyBh biBhc3Nlc3NtZW50IG9mIGxvY2FsIGNvbmRpdGlvbnMgdXNpbmcgdGhlIGNyaXRlcmlhIHNldCBv dXQgaW4gdGhlIGFzc2Vzc21lbnQgZnJhbWV3b3JrIFsxXSBkZXZlbG9wZWQgd2l0aCBjb21tdW5p dHkgaW5wdXQuDQogICAgDQogICAgVGhlIHJlY29tbWVuZGF0aW9uIGFuZCBmdWxsIGFzc2Vzc21l bnQgYXJlIGF2YWlsYWJsZSBhdDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWVkaWEvZG9jdW1lbnRz L0lFVEZfMTA4X01hZHJpZF9nb19uby1nb19hc3Nlc3NtZW50LnBkZg0KICAgIA0KICAgIFRoZSBv bmxpbmUgSUVURiAxMDggbWVldGluZyB3aWxsIHRha2UgcGxhY2UgMjctMzEgSnVseSBmcm9tIDEx OjAwIHRvIDE2OjAwIFVUQyBlYWNoIGRheS4gVGhlIGVuZCB0aW1lIG9mIDE2OjAwIFVUQyBpcyBh cHByb3hpbWF0ZTsgc29tZSBkYXlzIG1heSBiZSBzaG9ydGVyIGRlcGVuZGluZyBvbiBzY2hlZHVs aW5nLiBUaGVzZSB0aW1lIGJsb2NrcyB3ZXJlIGNob3NlbiBiYXNlZCBvbiB0aGUgc3VydmV5IGZl ZWRiYWNrIFsyXSB3ZSByZWNlaXZlZC4NCiAgICANCiAgICBGdXJ0aGVyIGRldGFpbHMgYWJvdXQg dGhlIG9ubGluZSBtZWV0aW5nIHdpbGwgYmUgc2hhcmVkIGFzIHRoZXkgYmVjb21lIGF2YWlsYWJs ZS4NCiAgICANCiAgICBTaW5jZXJlbHksDQogICAgQWxpc3NhIENvb3BlciwgSUVURiBDaGFpcg0K ICAgIENvbGluIFBlcmtpbnMsIElSVEYgQ2hhaXINCiAgICBKYXNvbiBMaXZpbmdvb2QsIElFVEYg TExDIEJvYXJkIENoYWlyDQogICAgDQogICAgWzFdIGh0dHBzOi8vd3d3LmlldGYub3JnL2Jsb2cv YXNzZXNzbWVudC1jcml0ZXJpYS1kZWNpc2lvbi1wZXJzb252aXJ0dWFsLWlldGYtMTA4Lz8NCiAg ICBbMl0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWVkaWEvZG9jdW1lbnRzL3N1cnZleS1wbGFubmlu Zy1wb3NzaWJsZS1vbmxpbmUtbWVldGluZ3MtcmVzcG9uc2VzLnBkZg0KICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgSUVURi1Bbm5vdW5jZSBt YWlsaW5nIGxpc3QNCiAgICBJRVRGLUFubm91bmNlQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQogICAgDQoNCg== From nobody Sun May 17 23:19: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 341BA3A086A; Sun, 17 May 2020 23:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1QoSFdl4Olp; Sun, 17 May 2020 23:19:50 -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 D5E383A085B; Sun, 17 May 2020 23:19:49 -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 04I6JbWM006749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 May 2020 02:19:39 -0400 Date: Sun, 17 May 2020 23:19:37 -0700 From: Benjamin Kaduk To: Akira Tsukamoto Cc: Mingliang Pei , Hannes Tschofenig , teep , "suit@ietf.org" Message-ID: <20200518061937.GH58497@kduck.mit.edu> References: <7526678c-9ebc-e265-514c-435dce7595bc@aist.go.jp> <00515b62-b2ae-405e-2c44-c533c6857873@aist.go.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00515b62-b2ae-405e-2c44-c533c6857873@aist.go.jp> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Teep] [Suit] 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, 18 May 2020 06:19:51 -0000 On Wed, May 13, 2020 at 08:17:39PM +0900, Akira Tsukamoto wrote: > > We have to specify which sha256 or anything else to use. Note that BCP 201 says you have to be able to support multiple algorithms. -Ben From nobody Mon May 18 03:20: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 830F93A09F1; Mon, 18 May 2020 03:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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=bbJrsJ2F; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=bbJrsJ2F Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO8N32f9mpdS; Mon, 18 May 2020 03:20:31 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20053.outbound.protection.outlook.com [40.107.2.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056D13A0A73; Mon, 18 May 2020 03:20:30 -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=8UfBsZN+U7Me1YtvQRigcA8We7kJCk2+F5jswwcbbJU=; b=bbJrsJ2F9g9MQj97eCGZ9I2T3hp61yS+jojiOPVxMFl/iAGlb5gWHoIfjGmKWsehE/XQZx/s3ZdalgxRnbNooII5PMq+FkrjDQXMjW4at0QlV0ctCWCbOjfx8Qmm0I0qV7vWKuDS7oMnSrOsf+GcjiKd5czfST/c6FE6SgchScg= Received: from AM6PR0502CA0042.eurprd05.prod.outlook.com (2603:10a6:20b:56::19) by VI1PR0802MB2333.eurprd08.prod.outlook.com (2603:10a6:800:9f::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20; Mon, 18 May 2020 10:20:27 +0000 Received: from AM5EUR03FT030.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:56:cafe::f6) by AM6PR0502CA0042.outlook.office365.com (2603:10a6:20b:56::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.24 via Frontend Transport; Mon, 18 May 2020 10:20:27 +0000 X-MS-Exchange-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.3000.19 via Frontend Transport; Mon, 18 May 2020 10:20:27 +0000 Received: ("Tessian outbound 567b75aed2b9:v54"); Mon, 18 May 2020 10:20:27 +0000 X-CR-MTA-TID: 64aa7808 Received: from 61bfa4b74cbd.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B2146AF8-A7AE-4773-BC27-7E4226575959.1; Mon, 18 May 2020 10:20:22 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 61bfa4b74cbd.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 18 May 2020 10:20:22 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m/q+rRS3RLSz/vJQAqNVNXmdZscjafssl68b8UznKWr93YJ9gYN+1Y3HjDhzFwdQq330zFpDx8jkiQpPx5MQmhf7M90qIMMT8kE5pzuekHg64qloZXC3DTWf4md57FWOCgXAWKF3BVSrOVXfM1k3Km8ogvTR/Ese2x5q9DVfiX8kND6ipDQ0eDp1MO9q/bZWo7hHb1UOMehIo1gKOwsrym5zowphN43+Xpp8G/RHFMVGYTd9RLPAXTAVm2ZGp/FeQ1HffemRhXpBfJtg+udbjDbH7ASSL9Vl9AIwM6BAaQop7ztt6Zg3+n3u9iPgCunikvUEkUYj7ab6BR5M3EQUpA== 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=8UfBsZN+U7Me1YtvQRigcA8We7kJCk2+F5jswwcbbJU=; b=nKjO+5xxLigkFvLAmmD+0wKT51qTj5PkEuiUCIVf4XV7RvEVs7K4xL1M7cmYWSWALIVWGmUJ7a0iiPDmR8WurVMSBxy71IE9IQEd0sl074kXsKxp7EZu91eC277IKtCjZPOxdxYtdeLnY1tNExN6traDoJTF1draOq6rTXSeWrb0QBlEcwlSxP0oR9ERkuojvA454UVhSebLObXDHzaWrxRDab0P5E0Tzught0sRou+TDmZWDIp+i6XLeuMZPjcsAk6xxEN4wOZUMaDJ8ikoD9Jl4XFtYwytEAWwxSbieikdi88cn+qBFGg77PMnNvRSiRrRY0M06+URDPVHE9p6qg== 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=8UfBsZN+U7Me1YtvQRigcA8We7kJCk2+F5jswwcbbJU=; b=bbJrsJ2F9g9MQj97eCGZ9I2T3hp61yS+jojiOPVxMFl/iAGlb5gWHoIfjGmKWsehE/XQZx/s3ZdalgxRnbNooII5PMq+FkrjDQXMjW4at0QlV0ctCWCbOjfx8Qmm0I0qV7vWKuDS7oMnSrOsf+GcjiKd5czfST/c6FE6SgchScg= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4003.eurprd08.prod.outlook.com (2603:10a6:208:12d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.27; Mon, 18 May 2020 10:20:21 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3000.034; Mon, 18 May 2020 10:20:21 +0000 From: Hannes Tschofenig To: Benjamin Kaduk , Akira Tsukamoto CC: Mingliang Pei , teep , "suit@ietf.org" Thread-Topic: [Suit] [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_QueryResponse Thread-Index: AQHWEVbXFgYm+cwGsUmvssVwMd+QFqikRL8AgAFwMACAAFicgIAHiGOAgABC9mA= Date: Mon, 18 May 2020 10:20:20 +0000 Message-ID: References: <7526678c-9ebc-e265-514c-435dce7595bc@aist.go.jp> <00515b62-b2ae-405e-2c44-c533c6857873@aist.go.jp> <20200518061937.GH58497@kduck.mit.edu> In-Reply-To: <20200518061937.GH58497@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 61d7393b-bcee-4f4d-8fd6-4f42ee740bea.1 x-checkrecipientchecked: true Authentication-Results-Original: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.122.242] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 4cee6280-6200-4b51-b40c-08d7fb1515a0 x-ms-traffictypediagnostic: AM0PR08MB4003:|VI1PR0802MB2333: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:4941;OLM:8882; x-forefront-prvs: 04073E895A X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: uWTf0SSbP7C3WgkKKp/HGIRwEvJkojUqR1NYc5O6Q3Z2R1zQpbznVgxRJDNFAMMlLBwgeSx92Vm9s2gwUgxRjxZHsD+MCmz4DLwPJwAtl54EST2mIT3t8sxYQzUdqjmKMjffJXzstcp0S3gcG5Nq2sFhJbLvXz4McrqWjBUabPWTod9I6sKfFjGDurqrdu97mmXglO7tMWQ/j3AfqtqGZJXNQs7KZvzRZ5q4coV+Eu8zXZUuyWM5ELkQSDD2Y/SwuuS4imOM7BD/82D1kjNLMTIJwEGtfBCwsY/laqjeaXnmVWAXaUV1WnHNf4p/ieo1u1dbeiBPBstLQ+VpVDinTqgVEabLWgMKYoQOTsMk55NY6twc5XE9mAzE1f+S9Gz2ETViux3xDW7mwvhxL/goOPn7uP9R8//dwh2zY0cAssrDQ5QHPFoKWef8IoyaZXlW+P5Nd2HYNTvXcXCQOwNJwl1tQ9R7/Qck/knIxE1iSaa7j1rwigzd/BvaO/94KThS 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:(4636009)(376002)(346002)(396003)(366004)(136003)(39860400002)(66946007)(110136005)(54906003)(33656002)(316002)(55016002)(9686003)(4326008)(2906002)(478600001)(52536014)(186003)(26005)(66556008)(76116006)(64756008)(66446008)(71200400001)(66476007)(7696005)(6506007)(53546011)(8676002)(8936002)(86362001)(5660300002)(4744005)(222643001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: tNTHdShQBTKWq3v/vwXoHRKGv9AmtpikIPD0TmwMw4/hruqsyXSCapVm3H8pYx6F2OzCuZkTv3VLY2Z2kUS/gLrcApS8vvsbIgaI/i9U5MwnYUi8gNPubisnqNDr5E8273YjALAnL8Rj9cMO3htmUPN7+55/wtWJlKqJdGJPWMHWbI3TE0jlJo8saoOPqLGHI60xDpCusIdSp3hHKDoS5S7hIn7DvUlnfJKBdx2PRPj69bUppilCGKGvdhxq/ER+X1ebV8fmbi8/kzpo1WVoPjzeXPU2e9jh8NUnRs6UVE29hRdiHCw1lY93LK9c9aM5fqtS67d1ISzydiRlQxJWY5vJsvVw6QOlGIhu+nEJrlUVB188wEWZcHYqz5Xgv9HGU/d2dtPFl+qYWqHq+tMm8FrMWpPnfZgZkKJmHLa4Ua4qjQscB1cqRaUuVqaizUp58AOdVGbrzhGu/7AtM9R8Xul3km1FjfjYMaM6mYQWWzQ= 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: AM0PR08MB4003 Original-Authentication-Results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=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:(4636009)(39860400002)(346002)(136003)(396003)(376002)(46966005)(53546011)(81166007)(5660300002)(450100002)(356005)(52536014)(316002)(47076004)(36906005)(55016002)(7696005)(9686003)(6506007)(4326008)(8676002)(110136005)(478600001)(54906003)(82310400002)(8936002)(186003)(26005)(336012)(2906002)(86362001)(33656002)(70206006)(70586007)(82740400003)(222643001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: bfe28f06-8ac3-45ad-38b0-08d7fb1511f4 X-Forefront-PRVS: 04073E895A X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Fh3xIXUijAqXqW7TB9wBMXTrWnPH/MYxIxzpkvL10EByk0zyglKzlbn5zme5oGfHToHb2KH7G7YHzQ3scjvb87wQCSmWCqdOXemuuFM2sgVWpkLbV/azoU2uCNt9favi4Lm2kDgfmR4Q6POgwwUxKxlZ6ASp3zXCibATQ/AgoMKs6hDwtpK1oZBnbStKp7EME4Sh8/ygcRcSYaCNrk5UPcjRtS1Dh4GTrf7fVuQTGhS/CXEuzHZeiCTJ6Z2WpQoLll0WeQrYFW3u/EWPB+w1k8nQLd7yDM8EjIBJKIrlIdmTRktSc9oNt/eiAtTfyWe6MBQ7F6h1QpVzZ4OGvj3u1H56Uwt16oWtI781o/xFXn4V0DVGtgp+pXwTXPByxV5EC9UQ9yGfeLJ8etFti6jr+QDMJj0csjD7zPvUCvhg40+YAVUgLNugPpvD1Ro2YjBoCv48NElxNpVUGxEwpE6FH51KbsC+ReKYO8kx/wXNx6p2hExP5mk3pM3i4LrSCyiSEV1uAuPfNeeoFa1Du4XLVfIkwwwW1eZDuIUd5bh77sE= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2020 10:20:27.1203 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4cee6280-6200-4b51-b40c-08d7fb1515a0 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: VI1PR0802MB2333 Archived-At: Subject: Re: [Teep] [Suit] 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, 18 May 2020 10:20:34 -0000 Hi Ben, BCP 201 does not apply here because we are not using the algorithm for use = with cryptography but rather to shorten the identifier while still reducing= name collisions. Ciao Hannes -----Original Message----- From: Benjamin Kaduk Sent: Monday, May 18, 2020 8:20 AM To: Akira Tsukamoto Cc: Mingliang Pei ; Hannes Tschofenig ; teep ; suit@ietf.org Subject: Re: [Suit] [Teep] Unique Identifier of TA_ID in TA_LIST for TEEP_Q= ueryResponse On Wed, May 13, 2020 at 08:17:39PM +0900, Akira Tsukamoto wrote: > > We have to specify which sha256 or anything else to use. Note that BCP 201 says you have to be able to support multiple algorithms. -Ben 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 Thu May 28 08:09:17 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 1203E3A0F4E; Thu, 28 May 2020 08:09:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: teep@ietf.org, ncamwing@cisco.com, kaduk@mit.edu, teep-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159067855598.24651.9565948575881084963@ietfa.amsl.com> Date: Thu, 28 May 2020 08:09:16 -0700 Archived-At: Subject: [Teep] teep - New Meeting Session Request for IETF 108 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: Thu, 28 May 2020 15:09:16 -0000 A new meeting session request has just been submitted by Nancy Cam-Winget, a Chair of the teep working group. --------------------------------------------------------- Working Group Name: Trusted Execution Environment Provisioning Area Name: Security Area Session Requester: Nancy Cam-Winget Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 40 Conflicts to Avoid: Chair Conflict: TLS DOTS SFC ADD DPRIVE OPSAWG rats mile masque opsec Technology Overlap: cose Key Participant Conflict: intarea v6ops 6man oauth suit People who must be present: Nancy Cam-Winget Tirumaleswar Reddy.K Benjamin Kaduk Resources Requested: Special Requests: ---------------------------------------------------------