]> Arm

Simon.Frost@arm.com

Security Remote ATtestation ProcedureS EAT collection container The default top-level definitions for an EAT assume a hierarchy involving a leading signer within the Attester. Some token use cases do not match that model. This specification defines an extension to EAT allowing the top-level of the token to consist of a collection of otherwise defined tokens. About This Document Status information for this document may be found at . Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (), which is archived at .

Introduction An Attestation Token conforming to EAT has a default top level definition for a token to be constructed principally as a claim set within a CBOR Web Token (CWT) with the associated COSE envelope providing at least integrity and authentication. An equivalent JSON encoding for a JWT in a JWS envelope is supported as an alternative at the top-level definition. The top level token can be augmented with related claims in a Detached Bundle (DEB). For the use case of transmitting a claim set through a secure channel, the top-level definition can be extended to use an Unprotected CWT Claim Set (UCCS) . This document outlines an additional top-level extension for which neither of the above top level definitions match exactly: the attestation token consists of a collection of objects, each with their own integrity and some internally defined relationship through which the integrity of the whole collection can be determined. i.e. there is no top-level signer for the set. The objects may all share the same logical hierarchy in a device or have a hierarchy which is internally defined within the object set.

Design Considerations / Use Cases Take a device with an attestation system consisting of a platform claim set and a workload claim set, each controlled by different components and with an underlying hardware Root of Trust. The two claim sets are delivered together to make up the overall attestation token. Depending upon the implementation and deployment use case, the signing system can either be entirely centric to the platform RoT or can have separate signers for the two claim sets. In either case, a cryptographic binding is established between the two parts of the token. A specific manifestation of such a device is one incorporating the Arm Confidential Compute Architecture (CCA) attestation token . In trying to prepare the attestation token using EAT, there were no issues constructing the claim sets or incorporating them into individual CWTs where appropriate. However, in trying to design an 'envelope structure' to convey the two parts as a single report it was found that maintaining EAT compatibility would require very different shaped compound tokens for different models, for example one based on a submod arrangement and another based on a DEB, though with different 'leading' objects. This would create extra code and explanation in areas where keeping things simple is desirable. There was an alternative approach considered, which stays close to existing thinking on EAT, which would be to create the wrapper from the UCCS EAT extension containing only submods for the respective components. This however stretches the current use case for UCCS beyond its existing description. The RATS WG approach of separating UCCS from the core EAT specification to be an extension also encourages proposing this further extension. To support the CCA use case, it is also relevant to consider current attestation technologies which are based on certificate chains (e.g. SPDM, DICE, several key attestation systems). Here also are multiple objects with their own integrity and an internally defined relationship. If attempting to move such a technology to the EAT world, the same challenges apply.

Token Collection The proposed extension for the top-level definition is to add a 'Token Collection' type. The contents of the type are a map of CWTs (JWTs). The DEB top-level entry for EAT is included for completeness, and the UCCS extension can also be embraced, though the use cases for these have not been explored. The identification of collection members and the intra collection integrity mechanism is considered usage specific. A verifier will be expected to extract each of the members of the collection and check their validity both individually and as a set. A map was chosen rather than an unbounded array to give the opportunity to add identifying map tags to each entry. The interpretation of the tags will be usage specific, but may correspond to registered identities of specific token types. To assist a verifier correlate the expected contents a profile entry can be added as the 'profile-label' identity in the map. See for a CDDL description of the proposed extension. While most of the use cases for collections are for scenarios where there will be at least two entries in a collection, the CDDL allows for >= 1 entries in a collection to allow for the scenario where only one entry is currently available even though the normal set is larger.

Security Considerations A verifier for an attestation token must apply a verification process for the full set of entries contained within the Token Collection. This process will be custom to the relevant profile for the Token Collection and take into account any individual verification per entry and/or verification for the objects considered collectively, including the intra token integrity scheme. As there is no overall signature for the Collection, protection against malicious modification must be contained within the entries. It is expected that there exists a cryptographic binding between entries, this can for example be one to many or one to one in a (chain) series. Depending upon the use case and associated threat model, the freshness of entries may need extra consideration.

IANA Considerations In the registry , IANA is requested to allocate the tag in from the FCFS space, with the present document as the specification reference. EAT Collection

Tag	Data Item	Semantics
TBD399	map	EAT Collection RFCthis

References Normative References Security Theory LLC Qualcomm Technologies Inc. Qualcomm Technologies Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a phone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine how much it wishes to trust the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. To a large degree, all this document does is extend CWT and JWT. IANA 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. Informative References Fraunhofer SIT Qualcomm Technologies Inc. Cisco Systems Universität Bremen TZI CBOR Web Token (CWT, RFC 8392) Claims Sets sometimes do not need the protection afforded by wrapping them into COSE, as is required for a true CWT. This specification defines a CBOR tag for such unprotected CWT Claims Sets (UCCS) and discusses conditions for its proper use. // The present version (-01) has a few editorial improvements over // -00 and attempts to address points from Thomas Fossati's // 2021-03-16 review, for further discussion at IETF 111. CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. Arm Ltd n.d.

CDDL = 1 entry to allow the scenario where only one entry is currently available even ; though the normal set is larger TL-Collection = { ? eat-collection-identifier, + cwt-collection-entries // jwt-collection-entries // DEB-collection-entries } eat-collection-identifier = ( profile-label => general-uri / general-oid ) cwt-collection-entries = ( collection-entry-label => CWT-Messages ) jwt-collection-entries = ( collection-entry-label => JWT-Messages ) DEB-collection-entries = ( collection-entry-label => DEB-Messages ) collection-entry-label = JC ]]>

Acknowledgments Thomas Fossati and Yogesh Deshpande provided insightful comments and review for this proposal.