---
v: 3

title: Epoch Markers
abbrev: Epoch Markers
docname: draft-birkholz-rats-epoch-markers-latest
stand_alone: true
area: Security
wg: RATS Working Group
kw: Internet-Draft

venue:
email: [e-mail]
github: https://github.com/ietf-rats/draft-birkholz-rats-epoch-marker

cat: std
consensus: true
submissiontype: IETF

author:
- name: Henk Birkholz
org: Fraunhofer SIT
abbrev: Fraunhofer SIT
email: [e-mail]
street: Rheinstrasse 75
code: '64295'
city: Darmstadt
country: Germany
- name: Thomas Fossati
organization: Arm Limited
email: [e-mail]
country: UK
- name: Wei Pan
org: Huawei Technologies
email: [e-mail]
- name: Carsten Bormann
org: Universität Bremen TZI
street: Bibliothekstr. 1
city: Bremen
code: D-28359
country: Germany
phone: [phone]
email: [e-mail]

normative:
RFC3161: TSA
RFC5652: CMS
RFC8610: CDDL
STD94:
-: CBOR
=: RFC8949
STD96:
-: COSE
=: RFC9052
I-D.ietf-cbor-time-tag: CBOR-ETIME
X.690:
title: >
Information technology — ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER)
author:
org: International Telecommunications Union
date: 2015-08
seriesinfo:
ITU-T: Recommendation X.690
target: https://www.itu.int/rec/T-REC-X.690

informative:
I-D.ietf-rats-architecture: rats-arch
I-D.ietf-rats-reference-interaction-models: rats-models
I-D.birkholz-scitt-receipts: scitt-receipts

venue:
mail: [e-mail]
github: ietf-rats/draft-birkholz-rats-epoch-marker

entity:
SELF: "RFCthis"

--- abstract

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.

--- middle

# 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 {{Appendix A of -rats-arch}} 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 {{-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 {{-TSA}}, a DER-encoded TSTInfo value wrapped in a CMS envelope {{-CMS}}.
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 {{-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 {{-scitt-receipts}} associated with the trust status of the Epoch Bell.

## Requirements Notation

{::boilerplate bcp14-tagged}

In this document, CDDL {{-CDDL}} is used to describe the data formats. The examples in {{examples}} use CBOR diagnostic notation as defined in {{Section 8 of -CBOR}} and {{Appendix G of -CDDL}}.

# 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 {{-rats-arch}}.

# Interaction Models {#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 {{-rats-models}}
* unsolicited distribution (e.g., via uni-directional methods, such as broad- or multicasting from Epoch Bells), corresponding to Section 7.2 in {{-rats-models}}
* solicited distribution (e.g., via a subscription to Epoch Bells), corresponding to Section 7.3 in {{-rats-models}}

# 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.

~~~~ CDDL
{::include cddl/epoch-marker.cddl}
~~~~
{: #fig-epoch-marker-cddl artwork-align="left"
title="Epoch Marker definition"}

## 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 {{Section 3 of -CBOR-ETIME}} for the (many) details about the CBOR extended
time format.

~~~~ CDDL
{::include cddl/cbor-time-tag.cddl}
~~~~

The following describes each member of the concise-swid-tag root map.

- etime: A cbor time-tag

- nonce:

### Classical RFC 3161 TST Info {#sec-rfc3161-classic}

DER-encoded {{X.690}} TSTInfo {{-TSA}}. See {{classic-tstinfo}} for the layout.

~~~~ CDDL
{::include cddl/classical-rfc3161-tst-info.cddl}
~~~~

The following describes each member of the concise-swid-tag root map.

- classical-rfc3161-TST-info: reference to RFC 3161 with exact type name from ASN.1

### CBOR-encoded RFC3161 TST Info {#sec-rfc3161-fancy}

Semantically equivalent to classical RFC3161 TSTInfo rewritten using the CBOR
type system.

~~~~ CDDL
{::include cddl/tst-info.cddl}
~~~~

The following describes each member of the TST-info-based-on-CBOR-time-tag map.

- version:

- policy: oid #6.110(bstr) / #6.111(bstr) / #6.112(bstr)

- messageImprint: MessageImprint, hashAlg : int, hashValue : bstr

- serialNumber: int

- eTime: profiled-etime, #6.1001(timeMap) with 1 and -8 (profiled-duration = #6.1002({* int => any})) keys in timeMap, and int => any at the end

- ordering: bool .default false

- nonce: int

- tsa: GeneralName (GeneralName = [ GeneralNameType : int, GeneralNameValue : any ])

- $$TSTInfoExtensions: Socket

### Multi-Nonce {#sec-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.

~~~~ CDDL
{::include cddl/multi-nonce.cddl}
~~~~

### Multi-Nonce-List {#sec-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

~~~~ CDDL
{::include cddl/multi-nonce-list.cddl}
~~~~

### Strictly Monotonically Increasing Counter {#sec-strictly-monotonic}

A strictly monotonically increasing counter.

The counter context is defined by the Epoch bell.

~~~~ CDDL
{::include cddl/strictly-monotonic-counter.cddl}
~~~~

### Stateless Nonce {#sec-stateless-nonce}

In a highly available service (e.g., a cloud attestation verifier) having to
keep per-session nonce state poses scalablity problems. An alternative is to
use time-synchronised servers that share a symmetric key, which produce and
consume nonces based on coarse-grained clock ticks that are signed using the
shared secret.

~~~~ CDDL
{::include cddl/stateless-nonce.cddl}
~~~~

Thomas defines his thing here like above

# Security Considerations

TODO

# IANA Considerations {#sec-iana-cons}

[^rfced-replace]

[^rfced-replace]: RFC Editor: please replace {{&SELF}} with the RFC
number of this RFC and remove this note.

## New CBOR Tags {#sec-iana-cbor-tags}

IANA is requested to allocate the following tags in the "CBOR Tags" registry
{{!IANA.cbor-tags}}, preferably with the specific CBOR tag value requested:

| Tag | Data Item | Semantics | Reference |
| -- | -- | -- | -- |
| 26980 | bytes | DER-encoded RFC3161 TSTInfo | {{sec-rfc3161-classic}} of {{&SELF}} |
| 26981 | map | CBOR-encoding of RFC3161 TSTInfo semantics | {{sec-rfc3161-fancy}} of {{&SELF}} |
| 26982 | tstr / bstr / int | a nonce that is shared among many participants but that can only be used once by each participant | {{sec-multi-nonce}} of {{&SELF}} |
| 26983 | array | a list of multi-nonce | {{sec-multi-nonce-list}} of {{&SELF}} |
| 26984 | uint | strictly monotonically increasing counter | {{sec-strictly-monotonic}} of {{&SELF}} |
| 26985 | array | stateless nonce | {{sec-stateless-nonce}} of {{&SELF}} |
{: #tbl-cbor-tags align="left" title="New CBOR Tags"}

--- back

# Examples {#examples}

The example in {{fig-ex-1}} shows an epoch marker with a cbor-epoch-id and no
bell veracity proof.

~~~~ CBOR-DIAG
{::include cddl/examples/1.diag}
~~~~
{: #fig-ex-1 artwork-align="center"
title="CBOR epoch id without bell veracity proof"}

## RFC 3161 TSTInfo {#classic-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 {{-TSA}}.

~~~~ ASN.1
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
{:unnumbered}

TBD