]> Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@ietf.contact

NVIDIA

Switzerland tfossati@nvidia.com

Huawei Technologies

william.panwei@huawei.com

Arm

United Kingdom ionut.mihalcea@arm.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. Finally, it registers RATS Conceptual Message Wrapper (CMW) Indicators for Epoch ID and Nonce. 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 container for Epoch Bell-signed 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 . registers new Conceptual Message Wrapper (CMW) Indicators for Epoch ID and Nonce, so that they can be identified and carried as first-class conceptual messages. Epoch markers can be used in the following ways:

• as embeddings in other data formats
• as information elements in protocols
• in systems that integrate the aforementioned protocols or data formats
• in the deployment of such systems

All of these can be considered "users" of Epoch Markers and will be referred to as entities "using Epoch Markers” throughout the document.

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 Diagnostic Notation described in Section of RFC 8949 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 .

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 Epoch Bell-signed 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. When an Epoch Marker is used as the handle in the Passport or Background-Check challenge-response flows defined by , the Verifier MUST follow the relevant Epoch Marker validation and acceptance policy. That policy MUST fulfil the applicable requirements presented in this document, such as accepted epoch windows, replay or rollback detection state, and deployment-specific skew introduced by the Evidence path. For Background-Check, the policy MUST account for the additional path through the Relying Party before Evidence reaches the Verifier. For Passport, any Attestation Result derived from such Evidence MUST remain bound to the Epoch Marker, or to the handle containing it, so that subsequent freshness decisions can be made according to Relying Party policy.

Epoch Marker Structure This section specifies the structure of Epoch Marker types using CDDL and illustrates their usage and relationship with other IETF work (e.g, ) where applicable. In general, Epoch Markers are intended to be conveyed securely, e.g., by being included in a signed data structure, such as a CBOR Web Token (CWT), or by being sent via a secure channel. The specification of such "outer" structures and protocols and the means how to secure them is beyond the scope of this document. This document defines the different types of Epoch Markers in . When the media type application/epoch-marker+cbor is used to label content as an Epoch Marker, the em-type media type parameter can optionally specify the Epoch Marker type by referencing its CBOR tag number. For example, an Epoch Marker can be used to construct a CBOR-based trusted time stamp token, similar in function to a TimeStampToken, using CWT and the em Claim defined in this document (see for an illustration). The value(s) that an Epoch Marker represents are intended to demonstrate freshness of messages and protocols. Epoch Bell-signed Epoch Markers can also serve other purposes in cases where trusted timestamps or time intervals are required. Taken as an opaque value, it is possible to use Epoch Markers as values for a nonce field in existing data structures or protocols that already support extra data fields, such as extraData in TPMS_ATTEST . Similarities in the usage of nonces and Epoch Markers can sometimes lead to applications where both are used in the same interaction, albeit in different places and for different purposes. One example of such an application scenario is the "nested" use of classical nonces and Epoch Markers, whereby an Epoch Marker is requested to be used as a nonce value for a specific data structure, while a locally generated nonce is used to retrieve that Epoch Marker via an "outer" ad hoc interaction (e.g., nonce retrieval protocols that interact with an Epoch Bell to fetch an Epoch Marker to be used as a nonce). As some Epoch Marker types represent certain timestamp variants, these Epoch Markers or the secure conveyance method they are used in do not necessarily have a hard-coded message imprint, as is always the case with TimeStampTokens. This means that not all Epoch Marker types support binding a message to an Epoch Marker (unlike the example in . The following Epoch Marker types are defined in this document:

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 section specifies the Epoch Marker types listed in .

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). The CBOR Time Tag represents a freshly sourced timestamp represented as either time or tdate (Sections and of RFC 8949 , ), or etime (). The etime rule shown in the CDDL above is imported from ; RFC 9581 remains the authoritative specification of CBOR tag 1001, and this document neither updates nor redefines it. This document merely profiles etime for use with Epoch Markers. No dedicated CBOR tag is allocated for the CBOR Time Tags type: the existing tags 0, 1 and 1001 are reused as-is. The context (e.g., the em Claim or the application/epoch-marker+cbor media type) identifies the item as an Epoch Marker.

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. A TSTInfo structure is conveyed in an Epoch Bell-signed Epoch Marker. The COSE signature supplies the protection formerly supplied by the discarded TSA envelope.

CBOR-encoded RFC3161 TST Info 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. A separate tag is unnecessary because the profiled form remains an etime item carried with tag 1001. RFC 9581 defines tag 1001 and its semantics; this document constrains one valid etime shape for Epoch Markers but does not introduce a new CBOR tag or alter the definition of etime. The resulting profiled-etime remains a subset/profile of etime encoded with tag 1001 and is defined as follows:

• The "base time" is encoded using key 1, indicating POSIX time as int or float, to align the profile with the baseline representation defined in .
• 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 specialized to the needs of this profile.
• The map MUST include key 1 and MAY include additional negative integer keys, which can be used to encode supplementary information. Unsigned integer keys, including 4, 5, and the keys in the $$ETIME-CRITICAL group choice, MUST NOT be used, unless the emitter wants to ensure that only implementations that understand the critical key interoperate.

Fixing key 1 for the base time and profiling key -8 provide a consistent shape for the profiled etime maps consumed by Epoch Markers without changing the meaning of the corresponding keys in . Key 1 is pinned so all profiled etime values share the same base-time representation, and key -8 is specialized to carry the accuracy bound expected by the TSA-style timestamps used here. The permissive * int => any entry remains to allow other members defined by and future extensions; implementations still rely on for the full semantics and validation of etime beyond the constraints listed here.

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.

The Epoch Bell MUST provide the entire epoch-tick-list as an Epoch Bell-signed Epoch Marker. Once a receiver has verified and retained that list, it can use each extracted Epoch Tick value independently, with no attached Epoch Bell signature. Epoch Tick List cannot be used in cases where the issuer needs to be verified for each Epoch Tick individually during use.

Creation The emitter MUST follow the requirements in .

Usage Proving freshness requires receiver-side state to identify the “next unused” tick. Systems using Epoch Tick lists SHOULD define how missing/out-of-order ticks are handled and how resynchronization occurs, as per .

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.

Creation The Epoch Bell MUST NOT emit a counter value lower than or equal to one it has already emitted in the same counter context, including after a crash or restart. To this end, the Epoch Bell SHOULD persist its counter state, or otherwise resume from a value that is guaranteed to exceed the last one emitted before the failure. For example, the Epoch Bell can write the counter to non-volatile storage every K increments and, after restart, resume from the stored value plus K plus a margin F that accounts for failed or delayed writes, as described in . If such a margin cannot be guaranteed, the Epoch Bell MUST start a new counter context, e.g., by switching to a new signing key or Epoch Bell identity, so that receivers do not mistake the new values for rollback. The Epoch Bell MUST NOT wrap the counter on overflow. When the counter space is about to be exhausted, the Epoch Bell MUST start a new counter context.

Usage Systems that use Epoch Markers SHOULD follow the guidance in in establishing an Epoch Marker acceptance policy for receivers. To prove freshness, receivers SHOULD track the highest accepted counter and ensure it fulfills the acceptance policy.

Epoclet In a highly available service (e.g., a cloud attestation Verifier), maintaining per-session nonce state can cause scalability issues. One alternative is to use time-synchronized servers that share a symmetric key and produce and consume nonces based on epoch ticks signed using the shared secret. This means that a nonce minted by one server can be processed by any other server, avoiding the need for session "stickiness". An epoclet is an Epoch ID variant that supports the above use case by encoding a POSIX time (i.e., the epoch identifier) alongside a minimal set of metadata. This is all data-origin-authenticated with a symmetric key in a self-contained and compact token that fits within 64 bytes. This makes it easy to use with common Evidence retrieval ABIs, which tend to limit the size of the challenge parameter to 64 bytes. The following describes the epoclet type.

KeyID:

A one-byte opaque identifier that is shared across the server pool. It is used to identify the key used to compute the AuthTag. Its interpretation is deployment-specific.

Timestamp:

The time associated with the current epoch encoded as the CBOR tag for POSIX time. It MUST use the int format. The CBOR tag MUST be removed. Note that this encoding restricts the granularity of this Epoch ID to one second.

Pad:

Zero or more (up to 20) bytes of padding. This field is used to adjust the overall size of the epoclet, ranging from a minimum of 44 bytes (0 bytes of padding) to a maximum of 64 bytes (20 bytes of padding). The padding bytes can assume any value.

AuthTag:

32 bytes string which is the result of applying HMAC with SHA-256 over the CBOR serialization of the TimeToken array. The serialization MUST use the CBOR deterministic encoding as specified in Section of RFC 8949 .

Creation The emitter MUST follow the requirements in . Furthermore, when used in a server farm, the clocks of the servers that participate in the protocol MUST be synchronized. The emitter builds the TimeToken array from the identifier of the current key, the current time and, optionally, padding, and computes the AuthTag over it as described above. It is RECOMMENDED that the handling (i.e., storage, replication and rotation) of the symmetric key used to generate the authentication tag follows the recommendations and best practices described in .

Usage The same size limit defined in applies: the encoded epoclet array MUST be no more than 64 bytes in length. The limit applies to the size of the epoclet value only, i.e., it does not include the Epoch Marker CBOR tag (26985).

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.

State and Sequencing Management Data structures containing Epoch Markers could be reordered in-flight even without malicious intent, leading to perceived sequencing issues. Some Epoch Marker types thus require receiver state to detect replay/rollback or establish sequencing. Systems that use Epoch Markers SHOULD define an explicit acceptance policy (e.g., bounded acceptance window) that accounts for reordering of markers. Usage of variable emission timings or counter increments when emitting Epoch Markers (see ) SHOULD be coupled with an assessment of acceptance window sizes. The maximum timing variability used by the Epoch Bell, marker distribution latency, expected in-flight reordering, and conceptual message delivery latency SHOULD all be considered when determining the minimum practical acceptance window. Excessive timing variability reduces the effective lifetime of epochs, and so can cause freshness failures for distant participants. There is a trade-off between keeping a single “global” epoch view versus per-Attester state at the Verifier: global-only policies can exacerbate latency-induced false replay rejections, while per-Attester tracking can be costly. Systems that use Epoch Markers SHOULD document whether they use global epoch tracking or per-Attester state and, if necessary, the associated window.

Signature Requirements An Epoch Marker does not intrinsically include a signature. An Epoch Bell-signed Epoch Marker is an Epoch Marker conveyed in a signed data structure whose signature was generated by an Epoch Bell. When a recipient needs to establish that an Epoch Marker was issued by an authorized Epoch Bell, the Epoch Marker MUST be an Epoch Bell-signed Epoch Marker and its Epoch Bell signature MUST be validated. This is an alternative Epoch Marker distribution mechanism to the one described in . An Epoch ID value is often intended to be extracted from an Epoch Bell-signed Epoch Marker and included in another protected message, or conveyed via a secure channel. Protection of that other message does not by itself make the extracted value an Epoch Bell-signed Epoch Marker, nor does it make its signer an Epoch Bell.

Epoch Bell Certification Relying Parties that receive Epoch Bell-signed Epoch Markers directly or as part of other RATS conceptual messages need a way to determine whether the Bell signing key was authorized to do so. This section defines a mechanism for conveying that authorization when the Epoch Bell is certified using an X.509 public-key certificate . Authorization of Epoch Bells that are not certified using X.509 (e.g., ecosystems that convey authorization semantics via CBOR-native structures) is out of scope of this document. An X.509 certificate for an Epoch Bell signing key MUST assert this specific purpose using the id-kp-epochBell extended key purpose identifier, defined below, in the certificate's Extended Key Usage (EKU) extension . Certificates conforming to this specification:

• MUST include the EKU extension, marked critical, containing id-kp-epochBell;
• MUST NOT include the anyExtendedKeyUsage value in the EKU extension; and
• MUST NOT include EKU values other than id-kp-epochBell, so that the key is not authorized for any purpose besides generating Epoch Markers.

Relying parties that require X.509-certified Epoch Bells MUST reject Epoch Bell-signed Epoch Markers whose signing certificate does not satisfy these constraints. The following module adheres to ASN.1 specifications and .

Epoch Bell Extended Key Usage ASN.1 Module

Security Considerations In distributed systems that rely on Epoch Markers for conveyance of freshness, the Epoch Bell plays a significant role in the assumed trust model. Freshness decisions derived from Epoch Bell-signed Epoch Markers depend on the Epoch Bell’s key(s) and correct behavior. If the Epoch Bell key is compromised, or the Bell is malicious/misconfigured, an attacker can emit valid-looking “fresh” Epoch Bell-signed Epoch Markers. System deployments using Epoch Markers generally need to protect Bell signing keys (secure storage, rotation, revocation) and scope acceptance to the intended trust domain (e.g., expected issuer/trust anchor). Similarly, the Bell's clock needs to be securely sourced and managed, to prevent attacks that skew the Bell's perception of time.

Epoch Bell Authorization Because Epoch Bell-signed Epoch Markers are only as trustworthy as the process that authorizes an entity to act as an Epoch Bell, relying parties need means to verify that a signing key was actually authorized for that purpose, and that the key is not shared with, or reused for, unrelated duties. Deployments that certify Epoch Bells via X.509 SHOULD rely on the id-kp-epochBell Extended Key Usage defined in to authorize and constrain Epoch Bell signing keys. Extended Key Usage is checked by conforming path-validation implementations and, when a single-purpose EKU is asserted critical (as mandated in ), provides an explicit, enforceable signal that a key's use is restricted to signing Epoch Markers. This mechanism only addresses X.509-certified Epoch Bells; it is an intermediate approach pending broader work on expressing authorization semantics for CBOR-native trust structures, which is out of scope of this document.

Epoch Signalling Issues provides a good introduction to attacks on conveyance of Epoch Markers. A network adversary can replay valid Epoch Bell-signed Epoch Markers or delay distribution, and differential latency can lead to different parties having different views of the “current” epoch. The epoch (acceptable window) duration is an operational security parameter: if too long, an Attester can create “good” Evidence in a good state and release it later while the epoch is still acceptable (notably for epoch-tick, epoch-tick-list, and strictly-monotonic-counter); if too short, distant Attesters may be rejected as stale due to latency. Epoch Markers are also designed to be reusable by multiple consumers, unlike nonces. Where per-session uniqueness is required, protocols typically need to bind Epoch Markers to an explicit nonce (e.g., see ). Finally, system deployments using Epoch Markers are normally required to pin which Epoch Marker types are acceptable for a given trust domain to avoid downgrade.

Operational Examples The following illustrative cases highlight “reasonable best practice” choices for balancing freshness, replay protection, and scalability.

• Nonce-bound Bell interaction: When a Verifier uses a nonce challenge to trigger Evidence creation, the Attester can forward that nonce to the Epoch Bell to request an Epoch Bell-signed Epoch Marker with the nonce echoed inside. For reuse and caching, the typical pattern is to keep the marker generic and embed the Verifier nonce alongside the marker in the Evidence: if the Bell signs a nonce-echoed marker, that marker is not reusable across sessions. The nonce and marker are thus either bound by the Bell's signature, or by the attester's signature on the Evidence. The Verifier checks that (1) the nonce matches its challenge, (2) the Epoch Marker signature chains to the expected signing key (either the Bell's signing key, or the attester's Attesting Key), and (3) the marker satisfies the acceptance policy (e.g., highest-seen counter or time window). This pairing gives per-session uniqueness while still allowing Epoch Marker reuse by multiple consumers.
• Long-latency paths (e.g., LoRaWAN or DTN profiles): High propagation and queuing delays make tight epoch windows brittle. In system deployments using Epoch Markers, epoch-tick-list can be pre-provisioned to Attesters so that each interaction consumes the next tick, with the Verifier keeping per-Attester sequencing state (). Epoch duration should cover worst-case delivery plus clock skew of the Bell, and acceptance policies should allow an overlap (e.g., current and immediately previous epoch) to absorb in-flight drift while still rejecting replays beyond that window.
• Large fleets sharing a Bell: When many Attesters reuse the same Epoch Marker value, per-Attester state at the Verifier may be impractical. One approach is to accept a global highest-seen epoch (with a bounded replay window) while requiring each Evidence record to bind the Epoch Marker to the Attester identity and, when feasible, a Verifier-provided nonce. This limits cross-attester replay of a single Epoch Marker while keeping the Bell stateless, which allows Epoch Markers to be cached and enables their broadcast distribution at scale.

Privacy Considerations When issued at predictable time intervals or with predictably sequential values, Epoch Markers can act as system-wide synchronization signals. Observers may be able to infer epoch boundaries, correlate messages produced within the same epoch, identify entities using the same Epoch Bell, and learn the cadence of specific operations. This linking may be performed even when the conceptual messages are otherwise protected. System deployments using Epoch Markers where traffic analysis is a concern should make Epoch Marker values and issuance patterns less predictable. Epoch Bells can make their Epoch Marker emission timing variable. When monotonic-counter-based markers are used, the increments between successive marker values can be made variable. As an additional step, the scoping of markers (per trust domain, audience, or protocol context) should be considered.

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
26985	array	an "epoclet"	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/epoch-marker+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:

em-type: the CBOR tag number that identifies the specific Epoch Marker. This value is encoded as an unsigned decimal integer, without leading zeroes, except for the actual number 0. For example, em-type=26982 identifies an Epoch Tick.

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-Formats IANA is requested to register the following Content-Format IDs in the "CoAP Content-Formats" registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group : New CoAP Content Formats

Content-Type	Content Coding	ID	Reference
application/epoch-marker+cbor	-	TBD1	RFCthis
application/epoch-marker+cbor; em-type=0	-	TBD2	of RFCthis
application/epoch-marker+cbor; em-type=1	-	TBD3	of RFCthis
application/epoch-marker+cbor; em-type=1001	-	TBD4	of RFCthis
application/epoch-marker+cbor; em-type=26980	-	TBD5	of RFCthis
application/epoch-marker+cbor; em-type=26981	-	TBD6	of RFCthis
application/epoch-marker+cbor; em-type=26982	-	TBD7	of RFCthis
application/epoch-marker+cbor; em-type=26983	-	TBD8	of RFCthis
application/epoch-marker+cbor; em-type=26984	-	TBD9	of RFCthis
application/epoch-marker+cbor; em-type=26985	-	TBD10	of RFCthis

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

New CMW Indicators IANA is requested to allocate the following values in the "RATS Conceptual Message Wrapper (CMW) Indicators" registry within the registry group: New CMW Indicators

Indicator Value	Conceptual Message Name	Reference
TBD13	Epoch ID	of RFCthis
TBD14	Nonce

New SMI Numbers Registrations IANA is requested to assign a new value for the Extended Key Usage defined in in the "SMI Security for PKIX Extended Key Purpose" registry of the "SMI Numbers" registry group, as follows: New PKIX Extended Key Purpose

Decimal	Description	References
TBD12	id-kp-epochBell	of RFCthis

IANA is requested to assign a new value for the ASN.1 Module defined in in the "SMI Security for PKIX Module Identifier" registry of the "SMI Numbers" registry group: New ASN.1 Module OID

Decimal	Description	References
TBD11	id-mod-epoch-bell	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 memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [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 University of Glasgow RISE AB IN Groupe NIO Inc. 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 common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. National Institute of Standards and Technology International Telephone and Telegraph Consultative Committee International Telephone and Telegraph Consultative Committee 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. This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind IANA IANA 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. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. 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. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) 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 and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (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 a JSON Web Token (JWT) with attestation-oriented claims. Cryptic Forest Software Siemens Fraunhofer SIT Independent Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification. The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol. Trusted Computing Group Version 1.00 Cisco Systems Fraunhofer SIT MIT NVIDIA 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 Trusted Computing Group Version 184

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

CBOR Epoch Marker based on `etime`)

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 an Epoch Marker with an etime as the Epoch Marker type carried within a CWT.

CBOR Epoch Marker based on `etime` carried within a CWT >, / unprotected / {}, / payload / << { / epoch marker / 2000: / etime / 1001({ 1: 851042397, -10: "America/Los_Angeles", -11: { "u-ca": "hebrew" } }), / eat_nonce / 10: h'\ c53a8c924f5a27877951ace250709aa64a45311840ca1c55da09af026a7a9c1c', / iss / 1 : "ACME epoch bell", / aud / 3 : "ACME protocol clients", / nbf / 5 : 1757929800, / exp / 4 : 1757929860 } >>, / signature / h'737461747574617279' ]) ]]>

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

CBOR Epoch Marker based on `etime` carried within a CWT (pretty hex)

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 The authors would like to thank Carl Wallace, Jeremy O'Donoghue, Jun Zhang, and Antoine Fressancourt for their reviews, suggestions and comments.