]> Arm

Simon.Frost@arm.com

Linaro

Thomas.Fossati@linaro.org

Siemens

Hannes.Tschofenig@siemens.com

Security Remote ATtestation ProcedureS EAT measurements claim measured component This document defines a "measured components" format that can be used with the EAT Measurements claim. Discussion Venues Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction defines a Measurements claim that:

• "[c]ontains descriptions, lists, evidence or measurements of the software that exists on the entity or any other measurable subsystem of the entity."

This claim allows for different measurement formats, each identified by a different CoAP Content-Format (). Initially, the only specified format is CoSWID of type "evidence", as per . This document introduces the "measured components" format that can be used with the EAT Measurements claim in addition or as an alternative to CoSWID.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. In this document, CDDL is used to describe the data formats.

Information Model A measured component information element includes the computed digest on the software or configuration payload, along with metadata that helps in identifying the measurement and the authorizing entity for component installation. describes the information model of a measured component. Measured Component Information Elements

IE	Description	Requirement Level
Component Name	The name given to a measured component. It is important that this name remains consistent across different releases to allow for better tracking of the same measured item across updates. When combined with a consistent versioning scheme, it enables better signaling from the appraisal procedure to the relying parties.	REQUIRED
Component Version	A value representing the specific release or development version of the measured component. Using Semantic Versioning is RECOMMENDED.	OPTIONAL
Digest Value	Hash of the invariant part of the component that is loaded in memory at startup time.	REQUIRED
Digest Algorithm	Hash algorithm used to compute the Digest Value.	REQUIRED
Signer	A unique identifier of the entity authorizing installation of the measured component.	REQUIRED
Countersigners	One or more unique identifiers of further authorizing entities for component installation	OPTIONAL

Data Model The data model is inspired by the "PSA software component" claim (), which has been slightly refactored to take into account the recommendations about new EAT claims design in . The following types and semantics have been reused:

• COSE Key Thumbprint , for signer and countersigners;
• CoSWID software name and version , for component name and version;
• CoRIM digest , for digest value and algorithm.

CDDL The measured-component data item: The CDDL extending the EAT Measurements format:

CWT

content-type (CoAP C-F equivalent)	content-format
application/measured-component+cbor	bytes .cbor measured-component
application/measured-component+json	text .b64u measured-component

JWT

content-type (CoAP C-F equivalent)	content-format
application/measured-component+json	text .json measured-component
application/measured-component+cbor	text .b64u measured-component

Examples (The examples are CBOR only. JSON examples will be added in a future version of this document.) The example in is a measured component with all the fields populated.

Complete Measured Component

The example in is the same measured component as above but used as the format of a measurements claim in a EAT claims-set. Note that the example uses a CoAP Content-Format value from the experimental range (65000), which will change to the value assigned by IANA for the application/measured-component+cbor Content-Format. Note also that the array contains only one measured component, but additional entries could be added if the measured TCB is made of multiple, individually measured components.

EAT Measurements Claim using a Measured Component > ] ] } ]]>

Security Considerations TODO

IANA Considerations RFC Editor: replace "RFCthis" with the RFC number assigned to this document.

Media Types Registrations IANA is requested to add the following media types to the "Media Types" registry . Measured Component Media Types

Name	Template	Reference
mc+cbor	application/measured-component+cbor	RFCthis
mc+json	application/measured-component+json	RFCthis

application/measured-component+cbor

Type name:

application

Subtype name:

measured-component+cbor

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (CBOR)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attesters, Verifiers and Relying Parties

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/cbor". (No fragment identification syntax is currently defined for "application/cbor".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

application/measured-component+json

Type name:

application

Subtype name:

measured-component+json

Required parameters:

n/a

Optional parameters:

n/a

Encoding considerations:

binary (JSON is UTF-8-encoded text)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

Attesters, Verifiers and Relying Parties

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". (No fragment identification syntax is currently defined for "application/json".)

Person & email address to contact for further information:

RATS WG mailing list (rats@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

none

Author/Change controller:

IETF

Provisional registration:

no

Measured Component Content-Format Registrations IANA is requested to register two Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry , as follows:

Content-Type	Content Coding	ID	Reference
application/measured-component+cbor	-	TBD1	RFCthis
application/measured-component+json	-	TBD2	RFCthis

References Normative References The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed:,, and for the construction of constants; / for including ABNF (RFC 5234 and RFC 7405) in CDDL specifications; and for indicating the use of a non-basic feature in an instance. Universität Bremen TZI At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9165. The latter has used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for corrections and additional features has become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. Universität Bremen TZI The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. RFCs have added to this extension point both in an application-specific and a more general way. The present document defines a number of additional generally applicable control operators for text conversion (Bytes, Integers, JSON, Printf-style formatting), operations on text, and deterministic encoding. ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. Security Theory LLC Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. SECOM CO., LTD. Transmute This specification defines a method for computing a hash value over a COSE Key. It defines which fields in a COSE Key structure are used in the hash computation, the method of creating a canonical form of the fields, and how to hash the byte sequence. The resulting hash value can be used for identifying or selecting a key that is the subject of the thumbprint. Fraunhofer SIT arm arm Intel Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. IANA IANA Informative References Arm Limited Arm Limited HP Labs Linaro The Arm Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant can produce attestation tokens as described in this memo, which are the basis for many different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by PSA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with ARM's architecture. It is not a standard nor a product of the IETF.

Collected CDDL TODO

Open Issues The list of currently open issues for this documents can be found at . Note to RFC Editor: please remove before publication.

Acknowledgments The authors would like to thank TBD for their comments, reviews and suggestions.