Draft: draft-ietf-rats-architecture

Commentary: Per offline discussion between  and  , trying this annotation to see if it helps Also try combining VG and AA into  since nothing in doc uses AA , and any example could use either VG or AA , so combining makes any example work for both . Signed - off - by :
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.
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.  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):
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 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)-time(VG), then it can determine
recency by checking "time(RG)-time(NS) + time(EG)-time(VG) <
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) - 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 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)-time(RG), then the Relying
Party can check "time(OP) - time(NS') < time(RX)-time(RG)".
Paragraph (version B):
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 B):
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 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_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 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_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 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_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):
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".
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_r)-time(NR_r) < Threshold".