[Rats] The context claim -- classification of intended use

Laurence Lundblade <lgl@island-resort.com> Tue, 17 November 2020 19:41 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D11CB3A1587 for <rats@ietfa.amsl.com>; Tue, 17 Nov 2020 11:41:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0LUxBT4Z3CjT for <rats@ietfa.amsl.com>; Tue, 17 Nov 2020 11:41:00 -0800 (PST)
Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net []) (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 7944D3A1591 for <rats@ietf.org>; Tue, 17 Nov 2020 11:41:00 -0800 (PST)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id f6qZkjXPT5Lb5f6qZkwjIP; Tue, 17 Nov 2020 12:40:59 -0700
X-CMAE-Analysis: v=2.4 cv=LcD5VhTi c=1 sm=1 tr=0 ts=5fb4274b a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=0XtbOteLAAAA:20 a=9JhsGrYYF2F6rbtlz-sA:9 a=QEXdDO2ut3YA:10 a=-jJQxvaMhLe9h8WyCO0A:9 a=5oBD0mwZTAuwfQMY:21 a=_W_S_7VecoQA:10 a=WQnItmPV2fbdzLaCP6-h:22 a=pHzHmUro8NiASowvMSCR:22 a=Ew2E2A-JSTLzCXPT_086:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_08437C93-823E-42CC-8B6E-B29D8B636ED9"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Message-Id: <3203DE09-BF78-4F63-9DD5-01F8E0D56462@island-resort.com>
Date: Tue, 17 Nov 2020 11:40:59 -0800
To: rats@ietf.org
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfKo+tNso/d3wMXr4RcOcSryVNIJcZ0Heh0QdzSHoxv7n/HMhn7pI5ZjtVAoM2pTt6laxwRTYXJIcOzqVG6ChVVH/ZPgGn0xD6uBaHNvKiPG1Uk+BEAnl npky1rt6kCmw9alA1h3OVh9GnRibjGdjIt9Ecwh5ZWkwTw0aqP8xGurISiC7/leBS9u8+pdDLZmNpQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/fEqpwPHy6X4idmT1ivNafSlhC_s>
Subject: [Rats] The context claim -- classification of intended use
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: Tue, 17 Nov 2020 19:41:02 -0000

This is about the context claim proposed in this PR <https://github.com/ietf-rats-wg/eat/pull/60>.

It classifies the use intended by the create of an attestation into the five listed below. Protocols using EAT can use this claim if they want to tell the RP the intended use if they want to.

My question to the list is whether this classification system is reasonably complete. Does it work for the FIDO, IoT on-boarding, Android attestation, the router use cases, TEEP…

Since this is claim is optional and there is a generic classification, the classification doesn’t need to be perfect, but it seems useful to check it against the use cases folks have in mind for EAT.



1 — On-demand (generic)
: On-demand attestation describes an application where the EAT consumer
requres the most up-to-date security assessment of the attesting entity. It
is expected that this is the most commonly-used application of EAT.

2-- Registration
: Entities that are registering for a new service may be expected to 
provide an attestation as part of the registration process.  This context
setting indicates that the attestation is not intended for any use but registration.

3 -- Provisioning
: Entities may be provisioned with different values or settings by an EAT
consumer.  Examples include key material or device management trees.  The consumer
may require an EAT to assess device security state of the entity prior to provisioning.

4 -- Certificate Issuance (Certificate Signing Request)
: Certifying authorities (CA's) may require attestations prior to
the issuance of certificates related to keypairs hosted at the entity.  An
EAT may be used as part of the certificate signing request (CSR).

5 -- Proof-of-Possession
: An EAT consumer may require an attestation as part of an accompanying 
proof-of-possession (PoP) appication.  This may be neceesary to verify the
security state of the entity storing the private key used in a PoP application.