Re: [Rats] EAT claims needed by TEEP

Simon Frost <Simon.Frost@arm.com> Wed, 28 October 2020 18:14 UTC

Return-Path: <Simon.Frost@arm.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189F63A011B; Wed, 28 Oct 2020 11:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.266
X-Spam-Level:
X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, LH_URI_DOM_IN_PATH=1.533, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=sx2KhL0B; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=sx2KhL0B
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 C1saqwp6qZlC; Wed, 28 Oct 2020 11:14:19 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150082.outbound.protection.outlook.com [40.107.15.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902CB3A00E3; Wed, 28 Oct 2020 11:14:18 -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=LUg4ZHLEcgj1qYIW8WStl4CDTJ/t4TiOKvy5TImZNC4=; b=sx2KhL0BQ3CMSsaz4mhMC51KgY13kwAHFM//J8G57HWMQkPKzOKRJEsqSmtLZZ+7sQAmI6SGrzJrskNZoHBNzjVMUS6qUBtTqvVq28bbQL64+3ssZEFbetYPi+hnWEnIsgrgwAxJtUh4TYEnbJH+lJcTc8Owp0BnheS+5+DOvgc=
Received: from AM0PR04CA0062.eurprd04.prod.outlook.com (2603:10a6:208:1::39) by DBAPR08MB5621.eurprd08.prod.outlook.com (2603:10a6:10:1a3::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 28 Oct 2020 18:14:15 +0000
Received: from AM5EUR03FT042.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:1:cafe::cb) by AM0PR04CA0062.outlook.office365.com (2603:10a6:208:1::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Wed, 28 Oct 2020 18:14:15 +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=pass 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 AM5EUR03FT042.mail.protection.outlook.com (10.152.17.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3520.15 via Frontend Transport; Wed, 28 Oct 2020 18:14:15 +0000
Received: ("Tessian outbound e6c55a0b9ba9:v64"); Wed, 28 Oct 2020 18:14:15 +0000
X-CR-MTA-TID: 64aa7808
Received: from 4b6e4b607713.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 698E68BE-74CE-409A-975B-7BFFF59C08C5.1; Wed, 28 Oct 2020 18:14:10 +0000
Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 4b6e4b607713.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 28 Oct 2020 18:14:10 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N4IR/qP2XA1X0B3It3/UxBwmpG7wU5RIhZiE2ZRv2uoX4Jj806d1WDIgZRvdowLxxCoHocsq6AVHMkY0+RwMFaTwT9FPWz431zBmyzPDrRZbfFPGGz3E3vuTmnwAtqmvoU9/k/CO9pu3jY7kzCre4N8qy5rYebTlu5VFUGipMmDNKkjM9uvXzs60owzsTj3p6R3iVwgCRykEypX6a0PzviKsH2lv9Y/QgjBIsn1EldyyjSqFHwy8iiw37Fsc48hBxFeSVlsrTlv4k4Si04K9Cj7y87INXWbedE3UFueUDW1Z2QiW2Q33DsZNQ5tFnHJ0SfSsVXEtGZlpggdIthzxuw==
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=LUg4ZHLEcgj1qYIW8WStl4CDTJ/t4TiOKvy5TImZNC4=; b=AVgyNH8WFGN++GgeAJ3dk9F7JAL+T7qKc5ffoCZyaHEx2L9uGcP1gEJbgNIeVWwsN6DwHOuMfgIptv/bUQ2R2li7DOBoluCSoMzPGes23JHHJLfVj5e7VILMWm6QMawJLlCWXw9Tv6Tc8biBjoBVxd63z+Qx7aVUrOqUzijiSQgAbpB40L4D6wNrbPX2/qYGoBR5MHn2ausJ/n3fHpbNIZkDdefG8f+RoRPdAHRggQmcZwFSiQSqMK13jBbVlFsMALLl1QWm8H+P6tiVfgO0drs/UWL3RTM8mzsN99qbUS/PCkhfmLUIdMwgGlqjC0yoDHhlcLlb1FHUeABBeVKitQ==
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=LUg4ZHLEcgj1qYIW8WStl4CDTJ/t4TiOKvy5TImZNC4=; b=sx2KhL0BQ3CMSsaz4mhMC51KgY13kwAHFM//J8G57HWMQkPKzOKRJEsqSmtLZZ+7sQAmI6SGrzJrskNZoHBNzjVMUS6qUBtTqvVq28bbQL64+3ssZEFbetYPi+hnWEnIsgrgwAxJtUh4TYEnbJH+lJcTc8Owp0BnheS+5+DOvgc=
Received: from AM6PR08MB3429.eurprd08.prod.outlook.com (2603:10a6:20b:49::19) by AS8PR08MB5880.eurprd08.prod.outlook.com (2603:10a6:20b:29f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.18; Wed, 28 Oct 2020 18:14:08 +0000
Received: from AM6PR08MB3429.eurprd08.prod.outlook.com ([fe80::8172:b5dd:6ef:651a]) by AM6PR08MB3429.eurprd08.prod.outlook.com ([fe80::8172:b5dd:6ef:651a%7]) with mapi id 15.20.3499.019; Wed, 28 Oct 2020 18:14:08 +0000
From: Simon Frost <Simon.Frost@arm.com>
To: Laurence Lundblade <lgl@island-resort.com>, Dave Thaler <dthaler@microsoft.com>
CC: "rats@ietf.org" <rats@ietf.org>, teep <teep@ietf.org>
Thread-Topic: [Rats] EAT claims needed by TEEP
Thread-Index: AQHWrKIiv/EmefyVEkmgXFAWEI4pIqmtTcSQ
Date: Wed, 28 Oct 2020 18:14:08 +0000
Message-ID: <AM6PR08MB342916CCDD01E8698BB3C883EF170@AM6PR08MB3429.eurprd08.prod.outlook.com>
References: <BL0PR2101MB102770B8E03B95A44497004CA3190@BL0PR2101MB1027.namprd21.prod.outlook.com> <7607E6BF-459C-4A32-AAE2-08117A97E06B@island-resort.com> <BL0PR2101MB1027EA205417DAF375BA7085A3160@BL0PR2101MB1027.namprd21.prod.outlook.com> <B1FDD70B-2530-454C-90AF-F44EEDC4F1F3@island-resort.com>
In-Reply-To: <B1FDD70B-2530-454C-90AF-F44EEDC4F1F3@island-resort.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ts-tracking-id: DF99B57E8F92104EB7C1D4971A0A86DA.0
x-checkrecipientchecked: true
Authentication-Results-Original: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=arm.com;
x-originating-ip: [212.69.61.73]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 30c830eb-9063-4e87-1b1f-08d87b6d478d
x-ms-traffictypediagnostic: AS8PR08MB5880:|DBAPR08MB5621:
X-Microsoft-Antispam-PRVS: <DBAPR08MB5621D85CA92AE7974A4093D7EF170@DBAPR08MB5621.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:9508;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: YqVF2w2PS/aIfRvcMZdFpDNKpoa/W01SwJOsuGkJ5QqsEG6Aw93oLja74u/BvAVii0DTdrYlYxBKqN5woTMi4zscaBY5LtKDWnWgoJPASWPxFvjYTW7JNQUx9m1aaH4STStGWTuJlLmd1pg1wzAbMeO9+x5p1/zs8ycZqLnvNi8DSS7lifHW3KnLY5erw3JJSMDYwFwGcKCxQWFYeuMHoBMCe5TGX6aHhBsZAEPUa4QLgD6Yscv3e8KuYjDQpAcVuxj5BdzGsLTIiLhBCBEdVKjAfZjLs3z8l3sHRBd7RfoLiHiDhYgMdwIINOBFmvx1RFfC9Z0320fbOxQLdo9fJuRqAMAFo+ztTqpsedsH3rQxIF14waer32w2UViq0ZAB7Y2JkYpcUwdy0lljAkKDCA==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB3429.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(39860400002)(366004)(376002)(136003)(76116006)(9686003)(6506007)(8676002)(64756008)(7696005)(66946007)(5660300002)(54906003)(186003)(53546011)(66556008)(66446008)(8936002)(110136005)(4326008)(66476007)(316002)(52536014)(83380400001)(55016002)(166002)(86362001)(26005)(71200400001)(478600001)(45080400002)(33656002)(2906002)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Ou0hfEwDGmhEHQdF5fvAPc3/Bup9UK/5fDdClHGkLnvbCZjK+tepFf3JGD3GrzL2tALpKHjdN0Zd2B/qXLLRF+k/BCprBEIxRUSQtmvqrACtCNFtpj1srmatvC4Zpk8kNkzetNAlJwWhJkNbOexxGoIWdiG2pOrQeNbs1igcXandXUpVDIsE7srfHdpn8j2zJFPSCysE1wqekBR9JFfur13gynYD+2VCi+3dAlI6nAzXX5bU5kgU08nGr3ehPOsd0VCCPljGwiB5nA3ewAUv1IdLfvg/ZekA3F+8y9FP1+DzWJccm+TtotMM4/um7YEV/lVw/hLWJCSHxf7jiRRHEjd+1SujvT84+G4VcGdVF13rQGfXzQKvd77oXoouEJ8bAIEVWStsYsoSwq4mwrt1Hpocpic8Z9sSDKSAxdBszBhIoGnIIE41aV0QQvC2elltbu1QTxpJackUMC5GVhJYoBBD1Q0jeXJZqP4XIU4uxZ5RCe0uwHhC8SoXgelDRm7+YCctRTMpKtGCApPBKUWF447BExkn4SveHDrm6kKwq3gBEjfqW3liigkuykj1QzRxLKETnqWzBKFg3Y4C6NGhKRh9VP6frs5QE8it3SDPDoqzjH9ymvKvkIr9YLlEw5XmAihdvMi+iHornmfM1Q2GRg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM6PR08MB342916CCDD01E8698BB3C883EF170AM6PR08MB3429eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB5880
Original-Authentication-Results: island-resort.com; dkim=none (message not signed) header.d=none;island-resort.com; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT042.eop-EUR03.prod.protection.outlook.com
X-MS-Office365-Filtering-Correlation-Id-Prvs: 09f65f92-eaec-4699-b978-08d87b6d4370
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: xhI8jGSGpNWAI94LJn1L6rMSz2BYTKwo+C2+6XdrLL0/DVi9khOLUYBnFuvBXAjMEsR71iTi4UmIcY0+e0z9r34QH/kVpPg4Q+H+8hZ0pYzF1WaVssnpAQIGZozYtz7+H6jYve9HQafteuIJnev7hip5fSssBVy4x/fA1/PPpL2raPZQwpAlu3sMr9K2miPrQlfjHZxFYQFtT2hqURdEZSNzp44YRXKZ/8hQz+t650p4Fk9syW6hLfSey18gN4F1X588o/1pmlVZs243DkuDu6PPdeNGBT6BfUZaiJm7716R4W9K+gBXbwopsX8b933zTcX/MXwOdHJRjvx4+vQgvBoCEemIbZLVxR9PlZwKKP93Lnq3Fi3ItZbIjW+altTjWuLBHMgvMbHfChzkHCCTJPE8mTt+KPUJvBfMms3hXDei0xmHaqEOgCfdnebl0lpayUE5xpp33PijAOnR5z+MNe+ZwKCFd/m7TWH9D7N2T3o=
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; SFS:(4636009)(136003)(376002)(39860400002)(346002)(396003)(46966005)(966005)(5660300002)(186003)(86362001)(54906003)(166002)(8936002)(33656002)(478600001)(8676002)(336012)(26005)(45080400002)(6506007)(9686003)(2906002)(55016002)(36906005)(110136005)(450100002)(7696005)(4326008)(33964004)(53546011)(356005)(30864003)(70586007)(81166007)(316002)(52536014)(83380400001)(70206006)(82310400003)(47076004)(82740400003)(579004); DIR:OUT; SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2020 18:14:15.3867 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 30c830eb-9063-4e87-1b1f-08d87b6d478d
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-AuthSource: AM5EUR03FT042.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR08MB5621
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/kWguQFlI8KIeW6ywMDDuILwZkX8>
Subject: Re: [Rats] EAT claims needed by TEEP
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 18:14:22 -0000

Note that some of the Arm team will be attending the upcoming hackathon and had been discussing doing some work there on describing components with CoSWID via EAT. This builds on some implementation work already completed as part of an Arm project that will shortly be upstreamed.

The PSA EAT profile originally introduced a hardware version based on an EAN-13. This was used as a reference to a general set of hardware in a certification scheme. Further work has shown this format is not suitable and it has will be deprecated in a future releases of the profile. The PSA profile also contains an ‘ImplementationID’ claim (byte string of sufficient size to hold a SHA2 hash) which is intended to be used as a much more specific identifier of a hardware group. The intent here is that reference values for an ImplementationID can be known by a verifier to assist appraisal policy.

Thanks
Simon

From: Laurence Lundblade <lgl@island-resort.com>
Sent: 27 October 2020 20:45
To: Dave Thaler <dthaler@microsoft.com>
Cc: rats@ietf.org; teep <teep@ietf.org>
Subject: Re: [Rats] EAT claims needed by TEEP

CoSWID should cover all the identification of vendors, models, versions and stuff for SW. If it doesn’t talk to Henk about fixes to CoSWID. :-)

For HW, there is OEMID and recently proposed chip version, board version and device version. It seems like we need a model number claim for HW. I will work on that.

Seems like submodules would be used to organize claims for layered attestation and all of the above claims can occur in any submodule they need to.

Does this mostly cover it?

I worry that the HW claims are bit too rigid in their use of EAN-13 and IEEE registries. Might need to do something about that.

LL



On Oct 27, 2020, at 1:26 PM, Dave Thaler <dthaler@microsoft.com<mailto:dthaler@microsoft.com>> wrote:

Inline below…

From: Laurence Lundblade <lgl@island-resort.com<mailto:lgl@island-resort.com>>
Sent: Tuesday, October 27, 2020 11:57 AM
To: Dave Thaler <dthaler@microsoft.com<mailto:dthaler@microsoft.com>>
Cc: rats@ietf.org<mailto:rats@ietf.org>; teep <teep@ietf.org<mailto:teep@ietf.org>>
Subject: Re: [Rats] EAT claims needed by TEEP

Personally, I think attestation of TEE’s is pretty important and should be handled well in EAT. So I’m interested in working on and adding claims for this to EAT.

After reading section 7.1 in TEEP architecture, it does seem like there some work to do here to get to specific standardized interoperable claims.

More comments below.



On Oct 26, 2020, at 3:15 PM, Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org<mailto:dthaler=40microsoft.com@dmarc.ietf.org>> wrote:

As discussed in previous IETF meetings, if there are claims beyond the base set that
other WGs need, they can be specified by the other WGs with review by RATS.

The TEEP WG needs the following in EATs and I am not sure whether they can be
covered by existing claims or whether TEEP-specific claims are needed.  From
section 7.1 of draft-ietf-teep-architecture:

>     -  Device Identifying Information: TEEP attestations may need to
>        uniquely identify a device to the TAM.  Unique device
>        identification allows the TAM to provide services to the device,
>        such as managing installed TAs, and providing subscriptions to
>        services, and locating device-specific keying material to
>        communicate with or authenticate the device.

I believe the Universal Entity ID Claim (ueid) is claim that meets the above requirement.
But the TEEP arch then goes on to say:

>        In some use cases it
>        may be sufficient to identify only the class of the device.  The
>        security and privacy requirements regarding device identification
>        will vary with the type of TA provisioned to the TEE.
Which EAT claim contains the device class? The closest thing I see is OEM Identification by IEEE (oemid)
but I am not sure that is sufficient since it's only the OEM not the device class from that OEM.
This doesn’t seem like something that should be TEEP specific though, so can someone tell me how to
represent device class using the claims in the EAT spec?

I don’t think the OEMID, UEID or other should be (ab)used  to represent device class. That would result in them being less reliable and useful in a generic sense. We should come up with a new claim.

+1

We can define a claim to be  the device class and make it a byte string like a UEID, but I think we have to go further to make it useful as an interoperable standardize claim. There has to be some method for the classification. TrustZone vs hypervisor based? Fast vs slow? Has a protected mode kernel and TAs? The TEEP document doesn’t say. This seems problematic without a classification scheme.

[DT] I’m not sure we need a classification scheme, at least for TEEP.  A simple device class byte string as you suggest would suffice in my opinion.

I wonder if the intent is more about grouping, in which case we can define a GEID (Group Entity ID) that looks a lot like a UEID. That seems useful and sensible to me. It is not about classification based on any characteristics. It lines up with the privacy preserving technique of one key per 100,000 devices.


>     -  TEE Identifying Information: The type of TEE that generated this

>        attestation must be identified, including version identification

>        information such as the hardware, firmware, and software version

>        of the TEE, as applicable by the TEE type.  TEE manufacturer

>        information for the TEE is required in order to disambiguate the

>        same TEE type created by different manufacturers and address

>        considerations around manufacturer provisioning, keying and

>        support for the TEE.


Similarly for this requirement, the closest thing I see is Origination Claim (origination) but I am not sure
that is sufficient since it's just the manufacturer not the "version identification information such as the
hardware, firmware, and software version of the TEE”

Definitely not origination claim.

+1

The intent of it something like Endorser identification and I think it should be replaced by an Endorser/X.509 cert URL.

I would say, this is a combination of claims

It’s just used:
1)     For a Verifier in appraising the evidence (nothing TEEP specific here, appraisal policy can involve any claim), and
2)     To be used by a TAM to decide which TA’s apply to the TEE.  In that sense it’s just like any other vendor id + device class for any non TEE, and I believe if there were a byte string for device class as you suggest that would be sufficient in my opinion.

Keeping in mind the “layered attestation” concept in the arch doc, as long as we have a claimset per layer, then I think the same “vendor id” and “class” claims that would apply to any device could be reused for the TEE, and reused for describing each layer.  E.g., a “version” claim would apply at the hardware layer and be the hardware version, at the firmware layer and be a firmware version, at the OS layer and be an OS version, etc.


I’ve just added a PR<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-rats-wg%2Feat%2Fpull%2F68&data=04%7C01%7Cdthaler%40microsoft.com%7Cab1ee7788f1f4d449c5508d87aaa3006%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637394218658895685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JyNCTwUJvkCPk3H9uYmD0BLfUXPu6vhnQomkIqiqiUM%3D&reserved=0> for HW version claims.

The intent for SW version claims is to use CoSWID. We should probably create some examples to see if it can represent what TEEP wants to represent.

Agree this sounds promising.

The paragraph mentions “type of TEE”. I’m not sure what is intended. I don’t know of any common taxonomy for classifying TEEs.

A unique identifier is sufficient in my view, no “classification” or “taxonomy” is required by anything that the TEEP WG has discussed to date, as far as I know.


Should the TEEP WG define TEEP-specific claims for such information?

I’d like to see most of them go into EAT unless they are super specific to TEEP (TEEP not TEEs). I think there is value in broad standardize claims as it promotes interoperability of RATS.

Sounds good to me.   Consider this a request to add some way to express “vendor id”, “model” (or “class” or whatever you want to call it), and “version” as claims that can be applied in claimsets at various layers.   I glanced at the PR you referenced and it seems to be a chip-specific version, not a generic version claim that can be used at multiple layers, so is not sufficient to meet the TEEP arch draft’s requirements, we still need other claims added.

Thanks!
Dave

LL





Dave
_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&data=04%7C01%7Cdthaler%40microsoft.com%7Cab1ee7788f1f4d449c5508d87aaa3006%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637394218658895685%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=O5LJZBw%2B6huYU7BrNSgOUQNw2H5uoDGwZj09%2FPghKrI%3D&reserved=0>


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