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

Epoch Marker Structure At the top level, an Epoch Marker is a CBOR array with a header carrying an optional veracity proof about the Epoch Bell and a payload.

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(multi-nonce) $tagged-epoch-id /= #6.26983(multi-nonce-list) $tagged-epoch-id /= #6.26984(strictly-monotonic-counter) ]]>

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

CBOR Time Tag (etime) CBOR extended time tag (1001) optionally bundled with a nonce. See for the (many) details about the CBOR extended time format. cbor-epoch-id = [ etime ? nonce ] etime = #6.1001({* (int/tstr) => any}) nonce = tstr / bstr / int

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

CBOR-encoded RFC3161 TST Info Semantically equivalent to classical RFC3161 TSTInfo rewritten using the CBOR type system. TST-info-based-on-CBOR-time-tag = { &(version : 0) => int .default 1 ; obsolete? &(policy : 1) => oid &(messageImprint : 2) => MessageImprint &(serialNumber : 3) => int &(eTime : 4) => profiled-etime &(ordering : 5) => bool .default false ? &(nonce : 6) => int ? &(tsa : 7) => GeneralName * $$TSTInfoExtensions } oid = #6.110(bstr) / #6.111(bstr) / #6.112(bstr) ; based on COSE_Hash_Find (draft-ietf-cose-hash-algs) MessageImprint = [ hashAlg : int hashValue : bstr ] ; timeMap profiles etime, see: ; https://datatracker.ietf.org/doc/html/draft-ietf-cbor-time-tag profiled-etime = #6.1001(timeMap) timeMap = { 1 => #6.1(int / float) ; TIME_T -8 => profiled-duration ; guarantee aka RFC 3161 accuracy * int => any } profiled-duration = #6.1002({* int => any}) ; Section 11.8 of I-D.ietf-cose-cbor-encoded-cert GeneralName = [ GeneralNameType : int, GeneralNameValue : any ]

Multi-Nonce Typically, a nonce is a number only used once. In the context of Epoch Markers, one Nonce can be distributed to multiple consumers, each of them using that Nonce only once. Technically, that is not a Nonce anymore. This type of Nonce is called Multi-Nonce in Epoch Markers. ; Multi-Nonce ; a single nonce used by multiple entities multi-nonce = tstr / bstr / int

Multi-Nonce-List A list of nonces send to multiple consumers. 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 ; Multi-Nonce-List ; a list of nonces potentially used by multiple entities multi-nonce-list = [ + multi-nonce ]

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

Security Considerations Epoch Markers are signed using and inheritance of security considerations will be addressed here.

IANA Considerations TODO

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) 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. It is intended as the reference document for the IANA registration of the CBOR tags defined. // The present version (-02) fills in proposals for all TBDs that // were outstanding. 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 Fraunhofer SIT Microsoft Sandelman Software Works Intel Corporation Huawei Technologies 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. An attempt is made to provide for 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 Microsoft Microsoft A transparent and authentic ledger service in support of a supply chain's integrity, transparency, and trust requires all peers that contribute to the ledgers operations to be trustworthy and authentic. In this document, a countersigning variant is specified that enables trust assertions on Merkle-tree based operations for global supply chain ledgers. A generic procedure for producing payloads to be signed and validated is defined and leverages solutions and principles from the Concise Signing and Encryption (COSE) space.

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 depects 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