Draft: draft-ietf-rats-architecture

Commentary: This puts the timestamp example back in and removes the problematic handle example until it is fixed up and has a citable reference . It can be put back in after that if desired . Signed - off - by :   
 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 . 
 This action seems to be redundant to and I think one of your comments actually says so ? Now I am confused . What does cover that not already cover ? What exactly is the problematic example here ? How is it resolved differently ? I have the feeling I am missing something very obvious here :-) [ edit ] Ah ! I think there were problematic git dependencies that inhibited separate handling of the original example 3 in , easily . Therefore , ? If that is the case , thanks ! probably has to take that change into account now .
Paragraph (version A):
The following example illustrates a hypothetical Background-Check
Model solution that uses centrally generated identifiers for explicit
time-keeping (referred to as "handle" in this example).  Handles can
be qualifying data, such as nonces or signed timestamps.  In this
example, centrally generated signed timestamps and - and synchronized
clocks between all entities - are distributed in periodic intervals
as handles.  If the Attester lacks a source of time based on an
absolute timescale, a relative source of time, such as a tick counter
can be used, alternatively.  In this example, evidence generation is
not triggered at value generation, but at events at which the
Attesting Environment becomes of changes to the Target Environment.
Paragraph (version A):
In comparison with example 1, the time considerations in this example
go into more detail with respect to the life-cycle of Claims and
Evidence.  While the goal is to create up-to-date and recent Evidence
as soon as possible, typically there is a latency between value
generation and Attester awareness.
Paragraph (version A):
At time(AA) the Attesting Environment is able to trigger an event
(e.g. based on an Event-Condition-Action model) to create attestation
Evidence that is as recent as possible.  In essence, at time(AA) the
Attesting Environment is aware of new values that where generated at
time(VG) and corresponding Claim values are collected immediately.
Consecutively, Evidence based on relevant "old" Claims and the just
collected "new" Claims is generated at time(EG).  In essence, the
Claims used to generate the Evidence are generated at various
time(VG) before time(AA).
Paragraph (version A):
In order to create attestation Evidence at at time(AA), the Attester
requires a fresh (i.e. not expired) centrally generated handle that
has been distributed to all involved entities.
Paragraph (version A):
In general, The duration a handle remains fresh depends on the
content-type of the handle.  If it is a (relative or absolute)
timestamp, clocks synchronized with a shared and trustworthy source
of time are required.  If another value type is used as a handle, the
reception time of the handle time(HD) provides an epoch (relative
time of zero) for measuring the duration of validity (similar to a
heart-beat timeout).  From the point of view of a Verifier, validity
of Evidence is only given if the handle used in Evidence satisfies
delta(time(HD),time(EG))distribution-interval.
Paragraph (version A):
In this usage scenario, time(VG), time(AA), and time(EG) are tightly
coupled.  Also, the absolute point in time at which a handle is
received by all three entities is assumed to be close to identical.