Trustworthiness Vectors for the Software Updates of Internet of Things (SUIT) Workflow Model

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 14 January 2022.¶

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

Attestation Results are an essential output of Verifiers as defined in the Remote ATtestation procedureS (RATS) architecture [I-D.ietf-rats-architecture]. They are consumed by Relying Parties: the entities that intend to build future decisions on trustworthiness assessments of remote peers. Attestation Results must be easily appraised by Relying Parties -- in contrast to the rather complex or domain-specific Evidence appraised by Verifiers.¶

In order to create Attestation Results, a Verifier must consume Evidence generated by a given Attester (amongst other Conceptual Messages, such as Endorsements and Attestation Policies). Both Evidence and Attestation Results are composed of Claims. This document highlights and defines a set of Claims to be used in Evidence and Attestation Results that are based on the SUIT Workflow Model [I-D.ietf-suit-manifest]. In the scope of this document, an Attester takes on the role of a SUIT Recipient: the system that receives a SUIT Manifest.¶

2. Trustworthiness Vectors

While there are usage scenarios where Attestation Results can be binary decisions, more often than not the assessment of trustworthiness is represented by a more fine-grained spectrum or based on multiple factors. These shades of Attestation Results are captured by the definition of Trustworthiness Vectors in Trusted Path Routing [I-D.voit-rats-trusted-path-routing]. Trustworthiness Vectors are sets of Claims representing appraisal outputs created by a Verifier. Each of these Claims is called a Trustworthiness Level. Multiple Trustworthiness Levels are composed into a vector.¶

An Attester processing SUIT Manifests can create three types of Claims about its Target Environments. This includes Claims about:¶

• installed manifests including initial state (e.g. factory default),¶
• hardware component identifiers that represent the targets of updates, and¶
• SUIT Interpreter results (e.g. test-failed) created during updates.¶

Every SUIT Manifest maps to a certain intended state of a device. Every intended device composition of software components associated with hardware components can therefore be expressed based on a SUIT Manifest. The current operational state of a device can be represented in the same form, including the initial state.¶

As a result, the Claims defined in this document are bundled by the scope of the information represented in SUIT Manifests, i.e., dedicated blobs of software that are the payload of a SUIT Manifest. All Claims associated with an identifiable SUIT Manifest must always be bundled together in a Claims set that is limited to the Claims defined in this document.¶

3. SUIT Claims

The Claim description in this document uses CDDL as the formal modeling language for Claims. This approach is derived from [I-D.ietf-rats-eat]. All Claims are based on information elements as used in the SUIT Manifest specification [I-D.ietf-suit-manifest]. For instance, a SUIT Vendor ID is represented as an UUID. Analogously, the corresponding vendor-identifier Claim found below is based on a UUID. SUIT Claims are differentiated in:¶

• software and hardware characteristics (System Properties), and¶
• reports about updates their SUIT Commands (SUIT Records).¶

Both types of Claims are always bundled in dedicated Claim Sets. Implementations can encode this information in various different ways (data models), e.g., sets, sequences, or nested structures. The following subsections define the SUIT Report Claims for RATS and are structured according to the following CDDL expression.¶

suit-report = {
  suit-system-properties => [ + system-property-claims ],
  suit-records => [ + interpreter-record-claims ],
}

system-property-claims => { + $$system-property-claim }
interpreter-record-claims => { + $$interpreter-record-claim }

$$system-property-claim //= ( vendor-identifier => RFC4122_UUID )

$$system-property-claim //= ( class-identifier => RFC4122_UUID )

$$system-property-claim //= ( device-identifier => RFC4122_UUID )

$$system-property-claim //=  ( class-identifier => [ + identifier ] )

$$system-property-claim //= ( image-digest => digest )

$$system-property-claim //= ( image-size => size )

$$system-property-claim //= ( minimum-battery => charge )

$$system-property-claim //= ( version => version-value )

$$interpreter-record-claim //= ( record-success => bool )

$$system-property-claim //= ( component-index => uint )

$$interpreter-record-claim //= ( dependency-index => digest )

$$interpreter-record-claim //= ( command-index => uint )

$$interpreter-record-claim //= ( nominal-parameters => parameter-list )

$$interpreter-record-claim //= ( actual-parameters => parameter-list )

4. List of Commands (TBD)

• Check Vendor Identifier¶
• Check Class Identifier¶
• Verify Image¶
• Set Component Index¶
• Override Parameters¶
• Set Dependency Index¶
• Set Parameters¶
• Process Dependency¶
• Run¶
• Fetch¶
• Use Before¶
• Check Component Offset¶
• Check Device Identifier¶
• Check Image Not Match¶
• Check Minimum Battery¶
• Check Update Authorized¶
• Check Version¶
• Abort¶
• Try Each¶
• Copy¶
• Swap¶
• Wait For Event¶
• Run Sequence¶
• Run with Arguments¶

Authors' Addresses