Draft: draft-ietf-rats-architecture

Commentary: This is a draft PR . More prose is needed around the sequence diagram . 
 fixed the required event tables entries The new sequence diagram illustrate a more concise " real life " story now and st the same time intends to fixes some ambiguities that snuck in when augmenting the overall diagram layout . Now ready for first walk - through in editors meeting . 
 looks good to me . 
 Personally , I find the new text much less clear than the old text 
  the impact that altering the distribution of handles ( e.g. , delaying , suppressing ) has on the security of the protocol . Add relevant text to the Security Consideration section . 
 Is this more than just finishing ? If so , what ? 
 The scope is different : deals with the example in the appendix , this one is for text that belongs to the security considerations . Regarding the " what " : is the issue description insufficient ? If so , do you have any suggestion on how to make it clearer ? 
 The appendix on Handles needs some work to better clarify the concepts and simplify the flow . Some things about the text : Clearly define what is a handle ; Explain its relation with epoch establishment ; Clarify network jitter impact on handle validity ; Explain what are the base rules for working with handles ; Some further points on the sequence diagram : Fix confusing legend ; Add some accompanying prose to explain the depicted use case as it 's not self - evident ; 
 fix all time to be delta
Paragraph (version A):
The following example illustrates a hypothetical Passport Model
solution that uses handles instead of nonces or timestamps.  In this
example, Evidence generation based on received handles always uses
the current (most recent) handle.  As handles are distributed over
the network, all involved entities receive a fresh handle at roughly
the same time.  Due to distribution over the network, there is some
jitter with respect to the time the Handle is received, time(HR), for
each involved entity.  To compensate for this jitter, there is a
small period of overlap (a specified offset) in which both a current
handle and corresponding former handle are valid in Evidence
appraisal: "validity-duration = time(HR'_v) + offset - time(HR_v)".
The offset is typically based on a network's round trip time.
Analogously, the generation of valid Evidence is only possible, if
the age of the handle used is lower than the validity-duration:
"time(HR_v) - time(EG_a) < validity-duration".
Paragraph (version A):
From the point of view of a Verifier, the generation of valid
Evidence is only possible, if the age of the handle used in the
Evidence generation is younger than the duration of the distribution
interval - "(time(HR'_v)-time(HR_v)) - (time(HR_a)-time(EG_a)) <
validity-duration".
Paragraph (version A):
Due to the validity-duration of handles, multiple different pieces of
Evidence can be generated based on the same handle.  The resulting
granularity (time resolution) of Evidence freshness is typically
lower than the resolution of clock-based tickcounters.
Paragraph (version A):
The following example illustrates a hypothetical Background-Check
Model solution that uses handles and requires a trustworthy time
source available to the Handle Distributor role.
Paragraph (version B):
The example in fig-handle-passport illustrates a hypothetical
Passport Model solution that uses handles instead of nonces or
timestamps.
Paragraph (version B):
The Handle Distributor broadcasts handle "H" which starts a new epoch
"E" for a protocol participant upon reception at "time(HR)".
Paragraph (version B):
The Attester generates Evidence incorporating handle "H" and conveys
it to the Verifier.
Paragraph (version B):
The Verifier appraises that the received handle "H" is "fresh"
according to the definition provided in epochfreshness whereby
retries are required in the case of mismatching handles, and
generates an Attestation Result.  The Attestation Result is conveyed
to the Attester.
Paragraph (version B):
After the transmission of handle "H'" a new epoch "E'" is established
when "H'" is received by each protocol participant.  The Attester
relays the Attestation Result obtained during epoch "E" (associated
with handle "H") to the Relying Party using the handle for the
current epoch "H'".  If the Relying Party had not yet received "H'",
then the Attestation Result would be rejected, but in this example,
it is received.
Paragraph (version B):
In the illustrated scenario, the handle for relaying an Attestation
Result to the Relying Party is current, while a previous handle was
used to generate Verifier evaluated evidence.  This indicates that at
least one epoch transition has occurred, and the Attestation Results
may only be as fresh as the previous epoch.