]> Fraunhofer SIT

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

Linaro

CH Thomas.Fossati@linaro.org

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 means 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 known as the Epoch Bell. Systems receiving Epoch Markers do not need to track freshness using their own understanding of time (e.g., via a local real-time clock). Instead, the reception of a specific Epoch Marker establishes a new epoch that is shared among all recipients. This document defines Epoch Marker types, including CBOR time tags, RFC 3161 TimeStampToken, and nonce-like structures. It also defines a CWT Claim to embed Epoch Markers in RFC 8392 CBOR Web Tokens, which serve as vehicles for signed protocol messages. 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 distributed systems. Epoch Markers are similar to "time ticks" and are produced and distributed by a dedicated system, the Epoch Bell. Actors in a system 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, with these ticks being conveyed over 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" values are defined as Epoch Marker types in this document to accommodate different use cases and diverse kinds of Epoch Bells. While most Epoch Markers types are encoded in CBOR , and many of the Epoch ID types are themselves encoded in CBOR, a prominent format in this space is the TimeStampToken (TST) defined by , a DER-encoded TSTInfo value wrapped in a CMS envelope . TSTs 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 or the start of a new freshness epoch, respectively, and therefore other Epoch Marker types. To inform the design, this document discusses a number of interaction models in which Epoch Markers are expected to be exchanged. The default top-level structure of Epoch Markers described in this document is CBOR Web Tokens (CWT) . The present document specifies an extensible set of Epoch Marker types, along with the em CWT claim to include them in CWTs. CWTs are signed using COSE and benefit from wide tool support. However, CWTs are not the only containers in which Epoch Markers can be embedded. Epoch Markers can be included in any type of message that allows for the embedding of opaque bytes or CBOR data items. Examples include the Collection CMW in , Evidence formats such as or , Attestation Results formats such as , or the CWT Claims Header Parameter of .

Terminology This document makes use of the following terms from other documents:

• "conceptual messages" as defined in
• "freshness" and "epoch" as defined in
• "handle" as defined in
• "Time-Stamp Authority" as defined by

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 the CBOR Extended Diagnostic Notation (EDN, ).

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 (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 major interaction models used in remote attestation:

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

In all three interaction models, Epoch Markers can be used as content for the generic information element handle as introduced by . Handles are used to establish freshness in ad-hoc, unsolicited, and solicited distribution mechanisms of an Epoch Bell. For example, 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). If embedded in a CWT, an Epoch Marker can be used as a handle by extracting the value of the em Claim or by using the complete CWT including an em Claim (e.g., functioning as a signed time-stamp token). 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 Epoch Markers are tagged CBOR data items. As a default, Epoch Markers are transported via the em Claim in CWTs. In cases of challenge-response interactions that employ a nonce to show recentness, the em Claim can be paired with a Nonce Claim to bind the nonce with the Epoch Marker as a response message in an ad-hoc request. This in fact means that it is possible to request an Epoch Marker via a challenge-response interaction using a nonce to then use the received CWT or the Epoch Marker included as a different nonce in a separate RATS reference interaction model.

Epoch Marker types (tag numbers 2698x are suggested, not yet allocated)

Epoch Marker as a CWT Claim (CWT claim number 2000 is suggested, not yet allocated) epoch-marker) ]]>

Epoch Marker Types This specification comes with a set of predefined Epoch Marker types.

CBOR Time Tags CBOR Time Tags are CBOR time representations 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). any}) ]]> The CBOR Time Tag represents a freshly sourced timestamp represented as either time or tdate (Sections and of RFC 8949 , ), or etime ().

Creation To generate the cbor-time value, the emitter MUST follow the requirements in .

Classical RFC 3161 TST Info DER-encoded TSTInfo . See for the layout. 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: This is the sha-256 hash of the string "EPOCH_BELL". The TimeStampToken obtained from 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. 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: 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. 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 (handle) included in conceptual messages . Similarly to the use of nonces, this allows the conceptual messages to be associated with a certain epoch. However, unlike nonces (which require uniqueness), Epoch Markers can be used in multiple interactions by every consumer involved.

Creation The emitter MUST follow the requirements in .

Epoch Tick List A list of Epoch Ticks sent to multiple consumers. The consumers use each Epoch Tick in the list sequentially. Similarly to the use of nonces, this allows each interaction to be associated with a certain epoch. However, unlike nonces (which require uniqueness), Epoch Markers can be used in multiple interactions by every consumer involved. The following describes the Epoch Tick List type.

epoch-tick-list:

A sequence of byte strings used by RATS roles in trust domain as extra data (handle) in the generation of conceptual messages as specified by the RATS architecture to associate them with a certain epoch. Each Epoch Tick in the list is used in a consecutive generation of a conceptual message. Asserting freshness of a conceptual message including an Epoch Tick from the epoch-tick-list requires some state on the receiver side to assess if that Epoch Tick is the appropriate next unused Epoch Tick from the epoch-tick-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. 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 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 (see ).

Nonce Requirements A nonce value used in a protocol or message to retrieve an Epoch Marker 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.

Signature Requirements The signature over an Epoch Marker MUST be generated by the Epoch Bell. Conversely, applying the first signature to an Epoch Marker always makes the issuer of a signed message containing an Epoch Marker an Epoch Bell.

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

New Media Type application/em+cbor IANA is requested to add the application/epoch-marker+cbor media types to the "Media Types" registry , using the following template:

Type name:

application

Subtype name:

epoch-marker+cbor

Required parameters:

no

Optional parameters:

no

Encoding considerations:

binary (CBOR)

Security considerations:

of RFCthis

Interoperability considerations:

n/a

Published specification:

RFCthis

Applications that use this media type:

RATS Attesters, Verifiers, Endorsers and Reference-Value providers, and Relying Parties that need to transfer Epoch Markers payloads over HTTP(S), CoAP(S), and other transports.

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

New CoAP Content-Format IANA is requested to register the following Content-Format ID in the "CoAP Content-Formats" registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group : New CoAP Content Format

Content-Type	Content Coding	ID	Reference
application/epoch-marker+cbor	-	TBD1	RFCthis

If possible, TBD1 should be assigned in the 256..9999 range.

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] 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. 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. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. CBOR Object Signing and Encryption (COSE) defines a set of security services for CBOR. This document defines a countersignature algorithm along with the needed header parameters and CBOR tags for COSE. This document updates RFC 9052. 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 (RFC 3339 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. Ericsson AB Ericsson AB RISE AB RISE AB IN Groupe 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 1.0, RPKI, GSMA eUICC, and CA/Browser Forum Baseline Requirements profiles. C509 is deployed in different settings including, in-vehicle and vehicle-to-cloud communication, Unmanned Aircraft Systems (UAS), and Global Navigation Satellite System (GNSS). 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 by 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 TLSA selectors registry defined in RFC 6698 is extended to include C509 certificates. The document also specifies C509 Certificate Requests, C509 COSE headers, a C509 TLS certificate type, and a C509 file format. Universität Bremen TZI This document formalizes and consolidates the definition of the Extended Diagnostic Notation (EDN) of the Concise Binary Object Representation (CBOR), addressing implementer experience. Replacing EDN's previous informal descriptions, it updates RFC 8949, obsoleting its Section 8, and RFC 8610, obsoleting its Appendix G. It also specifies and uses registry-based extension points, using one to support text representations of epoch-based dates/times and of IP addresses and prefixes. // (This cref will be removed by the RFC editor:) The present -18 // corrects a few omissions from -17; it is not intended to make // technical changes from -17. It is intended for use as an input // document for the CBOR WG meeting at IETF 123. 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. IANA IANA 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) [RFC9334]. 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 Traceability in supply chains is a growing security concern. While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. 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. Entrust Limited Siemens Fraunhofer SIT Intel Corporation A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of RATS conceptual messages (see Section 8 of [RFC9334], such as Evidence, Endorsements and Attestation Results, in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This provides an elegant and automatable mechanism for transporting attestation data to a Certification Authority. Including Evidence, Endorsements and Attestation Results along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. 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. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. IANA IANA

Examples The example in shows an Epoch Marker with an etime as the Epoch Marker type.

CBOR Epoch Marker based on `etime` (EDN)

The encoded data item in CBOR pretty-printed form (hex with comments) is shown in .

CBOR Epoch Marker based on `etime` (pretty hex)

The example in shows a CWT-signed Epoch Marker with epoch-tick as the Epoch Marker type.

CWT Epoch Marker based on `epoch-tick` (EDN) >, / unprotected / {}, / payload / << { / iss / 1 : "ACME epoch bell", / aud / 3 : "ACME protocol clients", / epoch marker / 2000: 26982(h'\ 482e829ad29ac6ea6eda2d47d1d93a002bf41d9d88710ba972c36e59038f78b3') / nbf / 5 : 1757929800, / exp / 4 : 1757929860 } >>, / signature / h'face5190' ]) ]]>

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 .

Acknowledgements Thank you , for your fixes and improvements.