Draft: draft-ietf-rats-architecture

Commentary: This is an evolution of PR and based on Issue Attester Awareness time(AA ) is not included in this PR ( see ) , but a concise definition of Handle received ( HR ) . The included diagram might need more work . Also a " background - check version " might be perceived as missing . Do we need one ? ( oh and the compilations errors due to malformed references are also fixed in this PR . pls always make sure your commit compiles before push ) 
 PR and PR merged text that I had , and continue to have , problems with . A summary of the problems follows : 1 ) It includes events ( CC , RP ) that are not used in any checks in the text . I had pointed this out before when the PR was generated , but the PR was merged without addressing this comment . 2 ) The section about using timestamps with synchronized clocks was removed and replaced with a section that talks about a different mechanism ( handles ) that is not in any RFC or WG document . I believe that such replacement is inappropriate . If the WG adopts a document that talks about a handle distribution mechanism , then a section can be . Or if there is a standard from another org that can be referenced then it 's fine to add one in that case too . But I think it should not replace the section discussing the well known technique of synchronized clocks ( e.g. , using secure NTP , or PTP ( IEEE 1588 - 2002 ) or whatever other standard mechanism ) . 3 ) time(HD ) is problematic as phrased since all the other events are times as seen by a single entity , whereas time(HD ) does not clearly say whose perspective ( i.e. , whose clock ) it is from ... is it the distributor 's ? Text is unclear . 4 ) It talks about nonces in a timestamp section , which I think causes confusion since there 's already a separately section about nonces and this section is labeled to be scoped to timestamps . Addressing might address this naturally , if it uses a different section title . 5 ) There are some editorial typos , such as capital " The " in the middle of a sentence , etc . 6 ) I have no idea what " delta(time(HD),time(EG))distribution - interval " is supposed to mean . Normally I would expect an equality for any condition to be evaluated , but I have no idea what this check is . 7 ) time(HD ) and time(EG ) are according to different clocks ( if my guess about point 3 above is right ) and so the delta is not directly comparable . I 'm not sure how point 6 accounts for this . 8) The phrase " A nonce not predictable to an Attester ( recentness & uniqueness ) is sent to an Attester " has " ( recentness & uniqueness ) " which does n't read well ( sounds like bad grammar ) to me , and is not explained . 
 Hopefully PR now addresses this issue . 
 PR reverts the text , leaving the work in progress in PR 
 fixed by . 
 Much better than previous PR but needs some cleanup
Paragraph (version B):
Handles are a third option to establish time-keeping next to nonces
or timestamps.  Handles are opaque data intended to be available to
all RATS roles that interact with each other, such as the Attester or
Verifier, in specified intervals.  To enable this availability,
handles are distributed centrally by the Handle Distributor role over
the network.  As any other role, the Handle Distributor role can be
taken on by a dedicated entity or collapsed with other roles, such as
a Verifier.  The use of handles can compensate for a lack of clocks
or other sources of time on entities taking on RATS roles.  The only
entity that requires access to a source of time is the entity taking
on the role of Handle Distributor.
Paragraph (version B):
Handles are different from nonces as they can be used more than once
and can be used by more than one entity at the same time.  Handles
are different from timestamps as they do not have to convey
information about a point in time, but their reception creates that
information.  The reception of a handle is similar to the event that
increments a relative tickcounter.  Receipt of a new handle
invalidates a previously received handle.
Paragraph (version B):
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.  The time that represents this event is named
Handle received: time(HR).  Due to distribution over the network,
there is some jitter with respect to 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') + offset - time(HR)".  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) - time(EG)
< validity-duration".
Paragraph (version B):
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(HD')-time(HD)) - (time(HR)-time(EG)) < validity-
duration".
Paragraph (version B):
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 B):
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.