Cabo first look

draft-birkholz-rats-epoch-markers.md

@@ -39,8 +39,14 @@ author:
   email: cabo@tzi.org
 
 normative:
-
+  RFC3161:
+
 informative:
+  I-D.ietf-rats-architecture: rats-arch
+
+venue:
+  mail: rats@ietf.org
+  github: ietf-rats/draft-birkholz-rats-epoch-marker
 
 --- abstract
 
@@ -50,30 +56,33 @@ Abstract Text
 
 # Introduction
 
-Systems that are required to interact via secure interactions often require a shared understand of the freshness of conveyed information, especially in the domain of remote attestation procedures.
+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 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 system actually is.
+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 messages that are like time ticks produced and conveyed by a system in a freshness domain: the Epoch Bell.
+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.
+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 on this document.
-While Epoch Markers are encoded in CBOR and many of the payload types are encoded in CBOR as well, the most prominent payload is the Time Stamp Token content as defined by RFC 3161: a DER-encoded TSTInfo value.
+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).
-TSAs are the most common world-wide implemented secure timestamp token systems -- at the time of the writing of this document.
+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.
-Epoch Markers also provide the option to include (concise) remote attestation evidence or corresponding remote attestation results to increase the level of trustworthiness in the Epoch Bell and the system that produces Epoch Markers.
+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
 
@@ -82,7 +91,7 @@ Epoch Markers also provide the option to include (concise) remote attestation ev
 # 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.
-Epoch Markers are a tangible solution specification that includes the lessons learned from TSAs and provides several means to identify a new freshness epochs as illustrated by the RATS architecture.
+Epoch Markers are a solution that includes the lessons learned from TSAs and provides several means to identify a new freshness epoch as illustrated by the RATS architecture.
 
 # Interaction Models
 
@@ -97,16 +106,20 @@ In general there are three of them:
 
 ~~~~ CDDL
 epoch-marker = [
-header,
-$payload,
+  header,
+  $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,
+  ? 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
 $payload /= native-rfc3161-TST-info
 $payload /= TST-info-based-on-CBOR-time-tag
@@ -117,6 +130,8 @@ $payload /= strictly-monotonically-increasing-counter
 
 native-rfc3161-TST-info = bytes ;  DER-encoded value of TSTInfo
 
+TST-info-based-on-CBOR-time-tag = "PLEASE DEFINE"
+
 ; ~~~
 ; ~~~ verbatim translation of ASN.1 TSTInfo into CDDL
 ; ~~~ (GeneralName is TODO atm, due to its terrible callousness)
@@ -165,14 +180,17 @@ time-tag,
 ? nonce
 ]
 
+time-tag = "PLEASE DEFINE"
+nonce = "PLEASE DEFINE"
+
 multi-nonce = tstr / bstr / int
 
 multi-nonce-list = [+ multi-nonce]
 
 strictly-monotonically-increasing-counter = uint ; counter context? per issuer? per indicator?
 ~~~~
 
-## Native TSTInfo
+## RFC 3161 TSTInfo
 
 ~~~~ DER
 TSTInfo ::= SEQUENCE  {
@@ -195,3 +213,8 @@ TSTInfo ::= SEQUENCE  {
 ~~~~
 
 --- back
+
+# Acknowledgements
+{:unnumbered}
+
+TBD