Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

Arm Limited

UK Thomas.Fossati@arm.com

Huawei Technologies

william.panwei@huawei.com

Universität Bremen TZI

Bibliothekstr. 1 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Security RATS Working Group Internet-Draft This document defines Epoch Markers as a way to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system, the Epoch Bell. Systems that receive Epoch Markers do not have to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a certain Epoch Marker establishes a new epoch that is shared between all recipients. About This Document Status information for this document may be found at . Discussion of this document takes place on the rats Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Systems that need to interact securely often require a shared understanding of the freshness of conveyed information. This is certainly the case in the domain of remote attestation procedures. In general, securely establishing a shared notion of freshness of the exchanged information among entities in a distributed system is not a simple task. The entire deals solely with the topic of freshness, which is in itself an indication of how relevant, and complex, it is to establish a trusted and shared understanding of freshness in a RATS system. This document defines Epoch Markers as a way to establish a notion of freshness among actors in a distributed system. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system, the Epoch Bell. Systems that receive Epoch Markers do not have to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a certain Epoch Marker establishes a new epoch that is shared between all recipients. In essence, the emissions and corresponding receptions of Epoch Markers are like the ticks of a clock where the ticks are conveyed by the Internet. In general (barring highly symmetrical topologies), epoch ticking incurs differential latency due to the non-uniform distribution of receivers with respect to the Epoch Bell. This introduces skew that needs to be taken into consideration when Epoch Markers are used. While all Epoch Markers share the same core property of behaving like clock ticks in a shared domain, various "epoch id" types are defined to accommodate different use cases and diverse kinds of Epoch Bells. While Epoch Markers are encoded in CBOR , and many of the epoch id types are themselves encoded in CBOR, a prominent format in this space is the Time-Stamp Token defined by , a DER-encoded TSTInfo value wrapped in a CMS envelope . Time-Stamp Tokens (TST) are produced by Time-Stamp Authorities (TSA) and exchanged via the Time-Stamp Protocol (TSP). At the time of writing, TSAs are the most common providers of secure time-stamping services. Therefore, reusing the core TSTInfo structure as an epoch id type for Epoch Markers is instrumental for enabling smooth migration paths and promote interoperability. There are, however, several other ways to represent a signed timestamp, and therefore other kinds of payloads that can be used to implement Epoch Markers. To inform the design, this document discusses a number of interaction models in which Epoch Markers are expected to be exchanged. The top-level structure of Epoch Markers and an initial set of epoch id types are specified using CDDL . To increase trustworthiness in the Epoch Bell, Epoch Markers also provide the option to include a "veracity proof" in the form of attestation evidence, attestation results, or SCITT receipts associated with the trust status of the Epoch Bell.

Requirements Notation 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. The examples in use CBOR diagnostic notation as defined in and .

Epoch IDs The RATS architecture introduces the concept of Epoch IDs that mark certain events during remote attestation procedures ranging from simple handshakes to rather complex interactions including elaborate freshness proofs. The Epoch Markers defined in this document are a solution that includes the lessons learned from TSAs, the concept of Epoch IDs defined in the RATS architecture, and provides several means to identify a new freshness epoch. Some of these methods are introduced and discussed in Section 10.3 of the RATS architecture .

Interaction Models The interaction models illustrated in this section are derived from the RATS Reference Interaction Models. In general, there are three interaction models:

• ad-hoc requests (e.g., via challenge-response requests addressed at Epoch Bells), corresponding to Section 7.1 in
• unsolicited distribution (e.g., via uni-directional methods, such as broad- or multicasting from Epoch Bells), corresponding to Section 7.2 in
• solicited distribution (e.g., via a subscription to Epoch Bells), corresponding to Section 7.3 in

In all three interaction models, Epoch Markers can be used as content for the generic information element 'handle'. Handles are most useful to establish freshness in unsolicited and solicited distribution by the Epoch Bell. An Epoch Marker can be used as a nonce in challenge-response remote attestation (e.g., for limiting the number of ad-hoc requests by a Verifier). Using an Epoch Marker requires the challenger to acquire an Epoch Marker beforehand, which may introduce a sensible overhead compared to using a simple nonce.

Epoch Marker Structure At the top level, an Epoch Marker is a CBOR array carrying the actual epoch id () and an optional veracity proof about the Epoch Bell.

Epoch Marker definition remote-attestation-evidence = (1: "PLEASE DEFINE") remote-attestation-result = (2: "PLEASE DEFINE") scitt-receipt = (3: "PLEASE DEFINE") ; epoch-id types independent of interaction model $tagged-epoch-id /= cbor-epoch-id $tagged-epoch-id /= #6.26980(classical-rfc3161-TST-info) $tagged-epoch-id /= #6.26981(TST-info-based-on-CBOR-time-tag) $tagged-epoch-id /= #6.26982(epoch-tick) $tagged-epoch-id /= #6.26983(epoch-tick-list) $tagged-epoch-id /= #6.26984(strictly-monotonic-counter) ]]>

The veracity proof can be encoded in an Evidence or Attestation Result conceptual message , e.g., using , , , or SCITT receipts .

Epoch Marker Payloads This memo comes with a set of predefined payloads.

CBOR Time Tags A CBOR time representation choosing from CBOR tag 0 (tdate, RFC3339 time as a string), tag 1 (time, Posix time as int or float) or tag 1001 (extended time data item), optionally bundled with a nonce. See for the (many) details about the CBOR extended time format (tag 1001). See for tdate (tag 0) and time (tag 1). cbor-epoch-id = [ cbor-time ? nonce ] etime = #6.1001({* (int/tstr) => any}) cbor-time = tdate / time / etime nonce = tstr / bstr / int The following describes each member of the cbor-epoch-id map.

etime:

A freshly sourced timestamp represented as either time or tdate (, ) or etime .

nonce:

An optional random byte string used as extra data in challenge-response interaction models (see ).

Creation To generate the cbor-time value, the emitter MUST follow the requirements in . If a nonce is generated, the emitter MUST follow the requirements in .

Classical RFC 3161 TST Info DER-encoded TSTInfo . See for the layout. classical-rfc3161-TST-info = bytes The following describes the classical-rfc3161-TST-info type.

classical-rfc3161-TST-info:

The DER-encoded TSTInfo generated by a Time Stamping Authority.

Creation The Epoch Bell MUST use the following value as MessageImprint in its request to the TSA: SEQUENCE { SEQUENCE { OBJECT 2.16.840.1.101.3.4.2.1 (sha256) NULL } OCTET STRING BF4EE9143EF2329B1B778974AAD445064940B9CAE373C9E35A7B23361282698F } This is the sha-256 hash of the string "EPOCH_BELL". The TimeStampToken obtained by the TSA MUST be stripped of the TSA signature. Only the TSTInfo is to be kept the rest MUST be discarded. The Epoch Bell COSE signature will replace the TSA signature.

CBOR-encoded RFC3161 TST Info Issue tracked at: https://github.com/ietf-rats/draft-birkholz-rats-epoch-marker/issues/18 The TST-info-based-on-CBOR-time-tag is semantically equivalent to classical TSTInfo, rewritten using the CBOR type system. TST-info-based-on-CBOR-time-tag = { &(version : 0) => v1 &(policy : 1) => oid &(messageImprint : 2) => MessageImprint &(serialNumber : 3) => integer &(eTime : 4) => profiled-etime ? &(ordering : 5) => bool .default false ? &(nonce : 6) => integer ? &(tsa : 7) => GeneralName * $$TSTInfoExtensions } v1 = 1 oid = #6.111(bstr) / #6.112(bstr) MessageImprint = [ hashAlg : int hashValue : bstr ] profiled-etime = #6.1001(timeMap) timeMap = { 1 => ~time ? -8 => profiled-duration * int => any } profiled-duration = {* int => any} GeneralName = [ GeneralNameType : int, GeneralNameValue : any ] ; See Section 4.2.1.6 of RFC 5280 for type/value The following describes each member of the TST-info-based-on-CBOR-time-tag map.

version:

The integer value 1. Cf. version, .

policy:

A object identifier tag (111 or 112) representing the TSA's policy under which the tst-info was produced. Cf. policy, .

messageImprint:

A COSE_Hash_Find array carrying the hash algorithm identifier and the hash value of the time-stamped datum. Cf. messageImprint, .

serialNumber:

A unique integer value assigned by the TSA to each issued tst-info. Cf. serialNumber, .

eTime:

The time at which the tst-info has been created by the TSA. Cf. genTime, . Encoded as extended time , indicated by CBOR tag 1001, profiled as follows:

• The "base time" is encoded using key 1, indicating Posix time as int or float.
• The stated "accuracy" is encoded using key -8, which indicates the maximum allowed deviation from the value indicated by "base time". The duration map is profiled to disallow string keys. This is an optional field.
• The map MAY also contain one or more integer keys, which may encode supplementary information Allowing unsigned integer (i.e., critical) keys goes counter interoperability.

ordering:

boolean indicating whether tst-info issued by the TSA can be ordered solely based on the "base time". This is an optional field, whose default value is "false". Cf. ordering, .

nonce:

int value echoing the nonce supplied by the requestor. Cf. nonce, .

tsa:

a single-entry GeneralNames array providing a hint in identifying the name of the TSA. Cf. tsa, .

$$TSTInfoExtensions:

A CDDL socket () to allow extensibility of the data format. Note that any extensions appearing here MUST match an extension in the corresponding request. Cf. extensions, .

Creation The Epoch Bell MUST use the following value as messageImprint in its request to the TSA: [ / hashAlg / -16, / sha-256 / / hashValue / h'BF4EE9143EF2329B1B778974AAD44506 4940B9CAE373C9E35A7B23361282698F' ] This is the sha-256 hash of the string "EPOCH_BELL".

Epoch Tick An Epoch Tick is a single opaque blob sent to multiple consumers. ; Epoch-Tick epoch-tick = tstr / bstr / int The following describes the epoch-tick type.

epoch-tick:

Either a string, a byte string, or an integer used by RATS roles within a trust domain as extra data included in conceptual messages to associate them with a certain epoch.

Creation The emitter MUST follow the requirements in .

Multi-Nonce-List A list of nonces send to multiple consumer. The consumers use each Nonce in the list of Nonces sequentially. Technically, each sequential Nonce in the distributed list is not used just once, but by every Epoch Marker consumer involved. This renders each Nonce in the list a Multi-Nonce ; Epoch-Tick-List epoch-tick-list = [ + epoch-tick ] The following describes the multi-nonce type.

multi-nonce-list:

A sequence of byte strings used by RATS roles in trust domain as extra data in the production of conceptual messages as specified by the RATS architecture to associate them with a certain epoch. Each nonce in the list is used in a consecutive production of a conceptual messages. Asserting freshness of a conceptual message including a nonce from the multi-nonce-list requires some state on the receiver side to assess if that nonce is the appropriate next unused nonce from the multi-nonce-list.

Creation The emitter MUST follow the requirements in .

Strictly Monotonically Increasing Counter A strictly monotonically increasing counter. The counter context is defined by the Epoch bell. strictly-monotonic-counter = uint The following describes the strictly-monotonic-counter type.

strictly-monotonic-counter:

An unsigned integer used by RATS roles in a trust domain as extra data in the production of of conceptual messages as specified by the RATS architecture to associate them with a certain epoch. Each new strictly-monotonic-counter value must be higher than the last one.

Time Requirements Time MUST be sourced from a trusted clock.

Nonce Requirements A nonce MUST be freshly generated. The generated value MUST have at least 64 bits of entropy (before encoding). The generated value MUST be generated via a cryptographically secure random number generator. A maximum nonce size of 512 bits is set to limit the memory requirements. All receivers MUST be able to accommodate the maximum size.

Security Considerations TODO

IANA Considerations RFC Editor: please replace RFCthis with the RFC number of this RFC and remove this note.

New CBOR Tags IANA is requested to allocate the following tags in the "CBOR Tags" registry , preferably with the specific CBOR tag value requested: New CBOR Tags

Tag	Data Item	Semantics	Reference
26980	bytes	DER-encoded RFC3161 TSTInfo	of RFCthis
26981	map	CBOR-encoding of RFC3161 TSTInfo semantics	of RFCthis
26982	tstr / bstr / int	a nonce that is shared among many participants but that can only be used once by each participant	of RFCthis
26983	array	a list of multi-nonce	of RFCthis
26984	uint	strictly monotonically increasing counter	of RFCthis

 New EM CWT Claim This specification adds the following value to the "CBOR Web Token Claims" registry .

• Claim Name: em
• Claim Description: Epoch Marker
• Claim Key: 2000 (IANA: suggested assignment)
• Claim Value Type(s): CBOR array
• Change Controller: IETF
• Specification Document(s): of RFCthis

References Normative References This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] 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 Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined. The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services 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. This document, along with RFC 9053, obsoletes RFC 8152. Universität Bremen TZI Well-Typed Fraunhofer Institute for Secure Information Technology The Concise Binary Object Representation (CBOR, RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 8949 defines two tags for time: CBOR tag 0 (RFC3339 time as a string) and tag 1 (POSIX time as int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as related CBOR tags for duration and time period. This document is intended as the reference document for the IANA registration of the CBOR tags defined. // (This cref will be removed by the RFC editor:) The present // revision (-12) addresses the IESG reviews. Ericsson AB Ericsson AB RISE AB RISE AB Nexus Group This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 Certificates. The CBOR encoding supports a large subset of RFC 5280 and all certificates compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. When used to re-encode DER encoded X.509 certificates, the CBOR encoding can in many cases reduce the size of RFC 7925 profiled certificates with over 50% while also significantly reducing memory and code size compared to ASN.1. The CBOR encoded structure can alternatively be signed directly ("natively signed"), which does not require re- encoding for the signature to be verified. The document also specifies C509 Certificate Signing Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. International Telecommunications Union 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. Informative References In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Fraunhofer SIT Fraunhofer SIT Huawei Technologies Cisco Systems This document describes interaction models for remote attestation procedures (RATS). Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. Fraunhofer SIT Microsoft Research Microsoft Research ARM DataTrails Traceability of physical and digital Artifacts in supply chains is a long-standing, but increasingly serious security concern. The rise in popularity of verifiable data structures as a mechanism to make actors more accountable for breaching their compliance promises has found some successful applications to specific use cases (such as the supply chain for digital certificates), but lacks a generic and scalable architecture that can address a wider range of use cases. This document defines a generic, interoperable and scalable architecture to enable transparency across any supply chain with minimum adoption barriers. It provides flexibility, enabling interoperability across different implementations of Transparency Services with various auditing and compliance requirements. Issuers can register their Signed Statements on any Transparency Service, with the guarantee that any Relying Parties will be able to verify them. Security Theory LLC Mediatek USA 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. Trusted Computing Group Version 1.00 Cisco Systems Fraunhofer SIT MIT Linaro Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. IANA IANA

Examples The example in shows an epoch marker with a cbor-epoch-id and no bell veracity proof.

CBOR epoch id without bell veracity proof

RFC 3161 TSTInfo As a reference for the definition of TST-info-based-on-CBOR-time-tag the code block below depicts the original layout of the TSTInfo structure from . TSTInfo ::= SEQUENCE { version INTEGER { v1(1) }, policy TSAPolicyId, messageImprint MessageImprint, -- MUST have the same value as the similar field in -- TimeStampReq serialNumber INTEGER, -- Time-Stamping users MUST be ready to accommodate integers -- up to 160 bits. genTime GeneralizedTime, accuracy Accuracy OPTIONAL, ordering BOOLEAN DEFAULT FALSE, nonce INTEGER OPTIONAL, -- MUST be present if the similar field was present -- in TimeStampReq. In that case it MUST have the same value. tsa [0] GeneralName OPTIONAL, extensions [1] IMPLICIT Extensions OPTIONAL }

Acknowledgements TBD