[Rats] draft-birkholz-rats-epoch-markers-04 early review

[Carl Wallace <[e-mail]>]

I realize it may be a bit early to review the draft, but I gave it a read and had some comments and questions. 

- How/where is this intended to be used? Some elements seem useful to conveying a (pool of) nonces that would be used in a claim like eat_nonce, others seem like they would serve as a new claim type (i.e., the 3161-focused options).
- What is Concise Evidence? It is listed as alternative to EAT in section 4.
- The draft is currently a description of a format. It might benefit from sections describing creation and verification (or at least some considerations for each). 
- Is the epoch-marker structure intended to be authenticated? Some of the options can be authenticated already, i.e., 4.1.2 and 4.1.7. It's not clear what the plan is for the top level (or if encryption is required).
- It's not clear to me what the “never-repeating byte string” phrase in sections 4.1.4 and 4.1.5 means? Is this phrase intended to avoid confusion because the nonces may be used one time by multiple parties? As written, it could be read as referring to the contents of the value.
- Are each of the possible types applicable to each model? 
- For the RFC3161-based types, what does the message imprint in response cover, i.e., what data was hashed? This seems likely to vary with the model.
- In section 4.1.2, it's probably worth explicitly excluding failed RFC3161 responses or maybe just conveying the timeStampToken field instead of the response.
- Section 4.1.7 describes a "stateless nonce" but there is state, i.e., the symmetric key and synchronized clocks. To assure one time use, there would also need to be state up until some window size elapses. This feels a bit like TOTP (RFC6238), in which case, why is the time field needed at all? If you want to use a key and a time value, just use one of the timestamp token options.
- It'd be helpful to include words on nonce handling for unsolicited and subscription models and how this varies for each role (since storage burden will vary for attester and verifier, for example). 
- Section 7.3 of draft-ietf-rats-reference-interaction-models-07 states "While a Handle Distributor is not required in this model, it is also limited to bi-lateral subscription relationships in which each Verifier has to create and provide its individual Handle." This suggests reuse is possible.
- Given the ordering requirements on multi-nonce, this feels less like a nonce and more like a one-time pad. Some words on what happens if a message gets lost would be helpful. Ought this type require the verifier to be able to distinguish between attesters (in order to maintain state)? Given the ordering requirement, probably worth noting storage burden is diminished for the verifier.