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

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

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

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

--- abstract

Abstract Text

--- middle

# Introduction

Systems that are required to interact via secure interactions often require a shared understanding of the freshness of conveyed information, especially in the domain of remote attestation procedures.
Establishing a notion of freshness between various involved entities taking on roles that rely on information that is not outdated is not simple.
In general, establishing a shared understanding of freshness in a secure manner is not simple.
The RATS architecture {{-rats-arch}} dedicates an extensive appendix solely on the topic of freshness considerations and that fact alone should be considered a telltale sign on how necessary yet complex establishing a trusted and shared understanding of freshness between systems actually is.

This document provides a prominent way to establish a notion of freshness between systems: Epoch Markers.
Epoch Markers are messages that are like time ticks produced and conveyed by a system in a freshness domain: the Epoch Bell.
Systems that receive Epoch Markers do not have to track freshness with their own local understanding of time (e.g., a local real time clock).
Instead, each reception of a specific Epoch Marker rings in a new age of freshness 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.

The layout of the freshness domain in which Epoch Markers are conveyed like the ticks of a clock, introduces a domain-specific latency -- and therefore a certain uncertainty about tick accuracy.

While all Epoch Markers share the common characteristic of being like clock ticks in a freshness domain, there are various payload types that can make up the content of an Epoch Marker.
These different types of Epoch Marker payloads address several specific use cases and are laid out in this document.
While Epoch Markers are encoded in CBOR and many of the payload types are encoded in CBOR as well, a prominent payload is the Time Stamp Token content as defined by {{RFC3161}}: a DER-encoded TSTInfo value.
Time Stamp Tokens (TST) produced by Time Stamp Authorities (TSA) are conveyed by the Time Stamp Protocol (TSP).
At the time of writing,
TSAs are the most common world-wide implemented secure timestamp token systems.
Reusing the essential TST payload structure as a payload type for CBOR encoded Epoch Markers makes sense with respect to migration paths and general interoperability.
But there is more than one way to represent a signed timestamp and other kinds of freshness ticks that can be used for Epoch Markers.

In this document, basic interaction models on how to convey Epoch Marchers are illustrated as they impact the message design of a generic Epoch Marker.
Then, the structure of Epoch Markers is specified using CDDL and the corresponding payload types are introduced and elaborated on.
To increase the level of trustworthiness in the Epoch Bell and the
system that produces them,
Epoch Markers also provide the option to include (concise) remote attestation evidence or corresponding remote attestation results.

## Requirements Notation

{::boilerplate bcp14-tagged}

# 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 and provides several means to identify a new freshness epoch. Some of these methods are introduced and discussed in Section 10.3 by the RATS architecture {{-rats-arch}}.

# Interaction Models

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

* 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 ID Payloads

* this memo comes with a set of predefined payloads
* payl
* 32 from 26980 (196964 -> 19 "id")- (three bytes: 19 + 2 bytes unsigned )

# Epoch Marker CDDL

~~~~ CDDL
epoch-marker = [
header,
$tagged-payload,
]

header = {
? challenge-response-nonce,
? remote-attestation-evidence, ; could be EAT or Concise Evidence
? remote-attestation-results, ; hopefully EAT with AR4SI Claims
}

challenge-response-nonce = (1: "PLEASE DEFINE")
remote-attestation-evidence = (2: "PLEASE DEFINE")
remote-attestation-results = (3: "PLEASE DEFINE")

;payload types independent on interaction model

$tagged-payload /= ecbor-epoch-id
$tagged-payload /= #6.26980(classical-rfc3161-TST-info)
$tagged-payload /= #6.26981(TST-info-based-on-CBOR-time-tag)
$tagged-payload /= #6.26983(multi-nonce)
$tagged-payload /= #6.26983(multi-nonce-list)
$tagged-payload /= #6.26984(strictly-monotonically-increasing-counter)

~~~~

# CBOR Time Tag (etime)

Thomas: a versatile CBOR time representation, potentially bundled with a Nonce

~~~~ CDDL

cbor-epoch-id = [
etime,
? nonce,
]
etime = #6.1001({* (int/tstr) => any})

~~~~

# Classical RFC 3161 TST Info

Thomas: DER-encoded value of TSTInfo

~~~~ CDDL

classical-rfc3161-TST-info = bytes

~~~~

# CBOR-encoded RFC 2161 TST Info

Thomas tells us here what beautiful things we concocted here with CBOR magic

~~~~ CDDL
; ~~~
; ~~~ translation with a few poetic licenses of ASN.1 TSTInfo into CDDL
; ~~~

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
; ? &(accuracy : 5) => rfc3161-accuracy ; subsumed by 4
&(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 from 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

Thomas (FIXME): 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

; a single nonce used by multiple entities
multi-nonce = tstr / bstr / int

~~~~

# Multi-Nonce-List

Thomes: 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

; a list of nonces potentially used by multiple entities
multi-nonce-list = [+ multi-nonce]

~~~~

# Strictly Monotonically Increasing Counter

Thomas beautiful context fable

~~~
; counter++
; counter context? per issuer? per indicator?
strictly-monotonically-increasing-counter = uint
~~~~

--- back

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

~~~~ DER
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