[Rats] Charter text revisions from the January 16 Call

Roman Danyliw <rdd@cert.org> Thu, 17 January 2019 13:57 UTC

Return-Path: <rdd@cert.org>
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 831D2127133 for <rats@ietfa.amsl.com>; Thu, 17 Jan 2019 05:57:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 XrY8Cq75KLmx for <rats@ietfa.amsl.com>; Thu, 17 Jan 2019 05:57:28 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 5557C12426E for <rats@ietf.org>; Thu, 17 Jan 2019 05:57:28 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0HDvQj8020033 for <rats@ietf.org>; Thu, 17 Jan 2019 08:57:27 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x0HDvQj8020033
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1547733447; bh=mIlLbuKEBtVRSsIACqqTaDRLpqf8oOaWIjtH5EHtPJY=; h=From:To:Subject:Date:From; b=hC+di9mS+p7oIxYTRq76kpoyGygiQCEJsmf7jXK3rWbVL+opWPajGH6MrGbnyEAJv sRGPHa/KRYNmrKnXPo65/arzLDTpPRdHp8QmdYW7yGSTDeF3cUSXuxO9y2H9mhH2JX R6Ycd8FxdsiY0SS0PEVI/4HjLpV+d6fbIuyFKRa4=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x0HDvPeq027575 for <rats@ietf.org>; Thu, 17 Jan 2019 08:57:25 -0500
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0435.000; Thu, 17 Jan 2019 08:57:25 -0500
From: Roman Danyliw <rdd@cert.org>
To: "rats@ietf.org" <rats@ietf.org>
Thread-Topic: Charter text revisions from the January 16 Call
Thread-Index: AdSuanGo2WLOx3ixTse/npymj9Oitw==
Date: Thu, 17 Jan 2019 13:57:23 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC018579136E@marathon>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: multipart/mixed; boundary="_002_359EC4B99E040048A7131E0F4E113AFC018579136Emarathon_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/MQLZIkIK23ZlSBMB5wJjo71bOr0>
Subject: [Rats] Charter text revisions from the January 16 Call
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: Thu, 17 Jan 2019 13:57:32 -0000

Hello RATS!

During the January 16 webex meeting, the group discussed and refined the proposed charter language based with a narrower scope for a WG.  The resulting text is below.  For convenience, a PDF with tracked changes from the pre-meeting version (https://mailarchive.ietf.org/arch/msg/rats/-rq_gQq2LNTeofG55xH_wPSB1_I/2) is also attached.

--[ snip ]--
Introduction
==========

Relying parties require evidence about the trustworthiness of remote system components [RFC4949] they interact with. Remote attestation procedures (RATS) enable relying parties to establish a level of confidence in the trustworthiness of remote system components by creating and processing attestation evidence. A relying party can then decide whether to consider a remote system component trustworthy or not.

To improve the confidence in a system component's trustworthiness a relying party may require evidence about:
* system component identity,
* composition of system components, including nested components,
* roots of trust,
* assertion/claim origination or provenance,
* manufacturing origin,
* system component integrity,
* system component configuration, or
* operational state and measurements of steps which led to the operational state.

While domain-specific attestation mechanisms such as Trusted Computing Group (TCG) Trusted Platform Module (TPM)/Trusted Software Stack (TSS), Fast Identity Online (FIDO) Alliance attestation and Android Keystore attestation exist, there is no interoperable way to create and process attestation evidence to make determinations about system components among relying parties of different manufactures and origins. 

Goals
=====

This WG will standardize formats for describing assertions/claims about system components and associated evidence; and procedures and protocols to convey these assertions/claims to the relying parties.  While a relying party may use reference values to assess the assertions/claims the procedures for this activity are out of scope for this WG.

The working group will cooperate and coordinate with other IETF WG such as TEEP, SUIT and SACM as appropriate.  The WG will also evaluate prior work such as NEA and proprietary attestation technologies.

Program of Work
==============

The working group will develop standards supporting interoperable remote attestation procedures for system components. The main deliverables are as follows.

1. Specify a terminology, architecture and use cases that enable explicit (a set of verifiable assertion/claims is transported in the attestation) and implicit (a set of assertions/claims is implied by possession of a secret) attestation techniques.  The architecture may include a system security model for the signing key material and involve at least the system component, system component provider, and the relying authority.

2. Standardize an information model for assertions/claims which provide information about system components characteristics scoped by the specified use-cases.

3. Standardize data models that implements and secures the defined information model (e.g., CBOR Web Token structures [RFC8392], JSON Web Token structures [RFC7519]).

4. Standardize interoperable protocols to securely convey assertions/claims.
--[ snip ]--