Draft: draft-ietf-rats-architecture

Commentary: Add time considerations into an appendix and reference it from the freshness section . 
 For readability , I have removed extraneous event times and only kept the ones used in the discussion after at least one diagram . My goal is to keep the discussion easy to understand and not include excess details or complexity that could be left to other docs . 
 will look into additions around purple items . to work on moving table to section 9 ( freshness )
Paragraph (version B):
A more detailed discussion with examples appears in time-
considerations.
Paragraph (version B):
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 Coordinated
Universal Time, or might be defined relative to some other timestamp
or timeticks counter.
Paragraph (version B):
We now walk through a number of hypothetical examples of how a
solution might be built.  This list is not intended to be complete,
but is just representative enough to highlight various timing
considerations.
Paragraph (version B):
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.
Paragraph (version B):
The Verifier can check whether the Evidence is fresh when appraising
it at time(RG) by checking "time(RG) - time(EG) < 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 B):
If time(VG) 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) value, the Verifier can also determine whether the
claim value is recent by checking "time(RG) - time(VG) < Threshold",
again where the threshold is large enough to account for the maximum
permitted clock skew between the Verifier and the Attester.
Paragraph (version B):
The Relying Party can check whether the Attestation Result is fresh
when appraising it at time(RA) by checking "time(RA) - time(RG) <
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)).  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)) as long as "time(OP)
- time(RG) < Threshold".  However, if the Attestation Result contains
an expiry time time(RX) then it could explicitly check "time(OP) <
time(RX)".
Paragraph (version B):
The following example illustrates a hypothetical Passport Model
solution that uses nonces and thus does not require that any clocks
are synchronized.
Paragraph (version B):
In this example solution, the Verifier can check whether the Evidence
is fresh at time(RG) by verifying that "time(RG) - time(NS) <
Threshold".
Paragraph (version B):
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)-time(VG), then it can determine
recency by checking "time(RG)-time(NS) + time(EG)-time(VG) <
Threshold".
Paragraph (version B):
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) - time(NS') +
time(RR)-time(EG) < Threshold".  Although the Nonce2 and time(RR)-
time(EG) 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 B):
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)-time(RG), then the Relying
Party can check "time(OP) - time(NS') < time(RX)-time(RG)".
Paragraph (version B):
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.
Paragraph (version B):
The time considerations in this example are equivalent to those
discussed under Example 1 above.
Paragraph (version B):
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 B):
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 B):
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) - time(NR) < Threshold".