Draft: draft-ietf-rats-architecture

Commentary: fix appendix to actually be back matter . 
 One editorial matter that got introduced somewhere after -15 , please make this a proper appendix . It 's currently " 16 . Appendix A : Time Considerations " , that is , Section 16 with word " appendix " in the title . Perhaps this is a rendering issue .
Paragraph (version A):
freshness discussed various issues and requirements around freshness
of evidence, and summarized three approaches that might be used by
different solutions to address them.  This appendix provides more
details with examples to help illustrate potential approaches, to
inform those creating specific solutions.
Paragraph (version A):
The table below defines a number of relevant events, with an ID that
is used in subsequent diagrams.  The times of said events might be
defined in terms of an absolute clock time, such as the Coordinated
Universal Time timescale, or might be defined relative to some other
timestamp or timeticks counter, such as a clock resetting its epoch
each time it is powered on.
Paragraph (version A):
Using the table above, a number of hypothetical examples of how a
solution might be built are illustrated below.  This list is not
intended to be complete, but is just representative enough to
highlight various timing considerations.
Paragraph (version A):
All times are relative to the local clocks, indicated by an "_a"
(Attester), "_v" (Verifier), or "_r" (Relying Party) suffix.
Paragraph (version A):
Times with an appended Prime (') indicate a second instance of the
same event.
Paragraph (version A):
How and if clocks are synchronized depends upon the model.
Paragraph (version A):
In the figures below, curly braces indicate containment.  For
example, the notation Evidence{foo} indicates that 'foo' is contained
in the Evidence and is thus covered by its signature.
Paragraph (version A):
The following example illustrates a hypothetical Passport Model
solution that uses timestamps and requires roughly synchronized
clocks between the Attester, Verifier, and Relying Party, which
depends on using a secure clock synchronization mechanism.  As a
result, the receiver of a conceptual message containing a timestamp
can directly compare it to its own clock and timestamps.
Paragraph (version A):
The Verifier can check whether the Evidence is fresh when appraising
it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold",
where the Verifier's threshold is large enough to account for the
maximum permitted clock skew between the Verifier and the Attester.
Paragraph (version A):
If time(VG_a) is also included in the Evidence along with the Claim
value generated at that time, and the Verifier decides that it can
trust the time(VG_a) value, the Verifier can also determine whether
the Claim value is recent by checking "time(RG_v) - time(VG_a) <
Threshold".  The threshold is decided by the Appraisal Policy for
Evidence, and again needs to take into account the maximum permitted
clock skew between the Verifier and the Attester.
Paragraph (version A):
The Attester does not consume the Attestation Result, but might cache
it.
Paragraph (version A):
The Relying Party can check whether the Attestation Result is fresh
when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v)
< Threshold", where the Relying Party's threshold is large enough to
account for the maximum permitted clock skew between the Relying
Party and the Verifier.  The result might then be used for some time
(e.g., throughout the lifetime of a connection established at
time(RA_r)).  The Relying Party must be careful, however, to not
allow continued use beyond the period for which it deems the
Attestation Result to remain fresh enough.  Thus, it might allow use
(at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold".
However, if the Attestation Result contains an expiry time time(RX_v)
then it could explicitly check "time(OP_r) < time(RX_v)".
Paragraph (version A):
The following example illustrates a hypothetical Passport Model
solution that uses nonces instead of timestamps.  Compared to the
timestamp-based example, it requires an extra round trip to retrieve
a nonce, and requires that the Verifier and Relying Party track state
to remember the nonce for some period of time.
Paragraph (version A):
The advantage is that it does not require that any clocks are
synchronized.  As a result, the receiver of a conceptual message
containing a timestamp cannot directly compare it to its own clock or
timestamps.  Thus we use a suffix ("a" for Attester, "v" for
Verifier, and "r" for Relying Party) on the IDs below indicating
which clock generated them, since times from different clocks cannot
be compared.  Only the delta between two events from the sender can
be used by the receiver.
Paragraph (version A):
In this example solution, the Verifier can check whether the Evidence
is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) <
Threshold".
Paragraph (version A):
The Verifier cannot, however, simply rely on a Nonce to determine
whether the value of a Claim is recent, since the Claim value might
have been generated long before the nonce was sent by the Verifier.
However, if the Verifier decides that the Attester can be trusted to
correctly provide the delta "time(EG_a)-time(VG_a)", then it can
determine recency by checking "time(RG_v)-time(NS_v) + time(EG_a)-
time(VG_a) < Threshold".
Paragraph (version A):
Similarly if, based on an Attestation Result from a Verifier it
trusts, the Relying Party decides that the Attester can be trusted to
correctly provide time deltas, then it can determine whether the
Attestation Result is fresh by checking "time(OP_r)-time(NS_r) +
time(RR_a)-time(EG_a) < Threshold".  Although the Nonce2 and
"time(RR_a)-time(EG_a)" values cannot be inside the Attestation
Result, they might be signed by the Attester such that the
Attestation Result vouches for the Attester's signing capability.
Paragraph (version A):
The Relying Party must still be careful, however, to not allow
continued use beyond the period for which it deems the Attestation
Result to remain valid.  Thus, if the Attestation Result sends a
validity lifetime in terms of "time(RX_v)-time(RG_v)", then the
Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)-
time(RG_v)".
Paragraph (version A):
The example in fig-epochid-passport illustrates a hypothetical
Passport Model solution that uses epoch IDs instead of nonces or
timestamps.
Paragraph (version A):
The Epoch ID Distributor broadcasts epoch ID "I" which starts a new
epoch "E" for a protocol participant upon reception at "time(IR)".
Paragraph (version A):
The Attester generates Evidence incorporating epoch ID "I" and
conveys it to the Verifier.
Paragraph (version A):
The Verifier appraises that the received epoch ID "I" is "fresh"
according to the definition provided in epochfreshness whereby
retries are required in the case of mismatching epoch IDs, and
generates an Attestation Result.  The Attestation Result is conveyed
to the Attester.
Paragraph (version A):
After the transmission of epoch ID "I'" a new epoch "E'" is
established when "I'" is received by each protocol participant.  The
Attester relays the Attestation Result obtained during epoch "E"
(associated with epoch ID "I") to the Relying Party using the epoch
ID for the current epoch "I'".  If the Relying Party had not yet
received "I'", then the Attestation Result would be rejected, but in
this example, it is received.
Paragraph (version A):
In the illustrated scenario, the epoch ID for relaying an Attestation
Result to the Relying Party is current, while a previous epoch ID 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.  If the Relying Party
remembers the previous epoch ID "I" during an epoch window as
discussed in epochfreshness, and the message is received during that
window, the Attestation Result is accepted as fresh, and otherwise it
is rejected as stale.
Paragraph (version A):
The following example illustrates a hypothetical Background-Check
Model solution that uses timestamps and requires roughly synchronized
clocks between the Attester, Verifier, and Relying Party.  The
Attester conveys Evidence to the Relying Party, which treats it as
opaque and simply forwards it on to the Verifier.
Paragraph (version A):
The time considerations in this example are equivalent to those
discussed under Example 1 above.
Paragraph (version A):
The following example illustrates a hypothetical Background-Check
Model solution that uses nonces and thus does not require that any
clocks are synchronized.  In this example solution, a nonce is
generated by a Verifier at the request of a Relying Party, when the
Relying Party needs to send one to an Attester.
Paragraph (version A):
The Verifier can check whether the Evidence is fresh, and whether a
Claim value is recent, the same as in Example 2 above.
Paragraph (version A):
However, unlike in Example 2, the Relying Party can use the Nonce to
determine whether the Attestation Result is fresh, by verifying that
"time(OP_r)-time(NR_r) < Threshold".