Yet another update to Time Considerations #88
Conversation
…it a bit added a few periods to text that seems to express sentences
draft-ietf-rats-architecture.md
Outdated
|
|
||
| We now walk through a number of hypothetical examples of how | ||
| Using the table above, the examples following below illustrate a number of hypothetical examples of how |
There was a problem hiding this comment.
Duplicate "examples".
(I really prefer how it read before.)
There was a problem hiding this comment.
Yes. Redundant "example" is redundant. Alas, we cannot start standards text with "We now walk". The alternate text was written too hastily be me.
There was a problem hiding this comment.
Maybe we can say:
Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below.
There was a problem hiding this comment.
Fine with me. Thx! Objections or request for polish?
There was a problem hiding this comment.
We should not add IDs to this doc unless they are used in a later section in text that says what specific security check uses them. (Protocol/mechanism docs are welcome to add their own, since there may be events that are very specific to a particular protocol/mechanism.)
| | RR | Result relayed | A Relying Party relays an Attestation Result to a Relying Party | ||
| | RA | Result appraised | The Relying Party appraises Attestation Results | ||
| | VG | Value generation | A value to appear in a Claim was created. | ||
| | AA | Attester awareness | An Attesting Environment starts to be aware of a new/changed Claim value. |
There was a problem hiding this comment.
This ID is never used in later sections, so should not be added unless it is used in the doc.
There was a problem hiding this comment.
Which ID do you mean here, exactly? It is had to read from the diff illustrated, I think.
There was a problem hiding this comment.
I think Dave's meaning is that the newly added 3 events (AA, CC, and HD) are not used in later sections.
There was a problem hiding this comment.
ah okay. Thx Wei. I created a commit (620ef97) based on that identified gap.
draft-ietf-rats-architecture.md
Outdated
|
|
||
| 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 as recent as possible. As soon as the Attesting Environment is aware, the new values are collected for composition into semantically enriched Claims at time Time(CC). Immediately after that, Evidence based on relevant "old" Claims and the most recent collected "new" Claims is generated at time(EG). | ||
|
|
||
| In order to create attestation on demand due to the event trigger time(AA) at the time(EG), the Attester has be in synchronized state with respect to the Verifiers perception of global time. In order to accomplish his, the Attester has to have an identifier for time-bound recentness available at any time(HD) before time(EG) where the time interval between time(HD) and time(EG) is not too large due to time drift or other synchronization disablers (delta(time(HD),time(EG)<threshold)). |
There was a problem hiding this comment.
time(AA) seems to be irrelevant for any security purpose, only time(EG) is relevant, so I don't think time(AA) belongs in this doc.
time(HD) also seems very confusing. since time(HD) and time(EG) are on the same entity, and that same entity compares against a threshold, what security threat is this trying to address? I don't follow.
There was a problem hiding this comment.
In order to always create the most recent Evdence possible, the Attester has to be aware of a changed Value as soon as possible. Otherwise Evidence is outdated and could even convey a misleading picture about an Attester's Target Environments, ultimately leading to incorrect risk assessments. Hence time(AA) is quite relevant, I think.
There are scenarios where this is less relevant (e.g. boot-time integrity) and some scenarios where this is more relevant (e.g. run-time integrity).
I agree that time(HD) is "squeezed" into the diagram it is actually the reception of the distributed handles. I did not want to add a "distributor of the handles" the the actors in the diagram. Maybe we can address this by rewording time(HD) correspondingly? In essence, I understand why this is difficult to follow at the moment and we have to fix this.
There was a problem hiding this comment.
Agreed that "HD" is not a good term, but a better term will be worked on.
draft-ietf-rats-architecture.md
Outdated
|
|
||
| The goal is to create up-to-date and recent Evidence as soon as possible, in general. | ||
|
|
||
| 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 as recent as possible. As soon as the Attesting Environment is aware, the new values are collected for composition into semantically enriched Claims at time Time(CC). Immediately after that, Evidence based on relevant "old" Claims and the most recent collected "new" Claims is generated at time(EG). |
There was a problem hiding this comment.
there is no time(CC) in the diagram, but I think time(CC) is irrelevant for any security purpose, only time(EG) matters and time(CC) can be ignored
There was a problem hiding this comment.
I think that we can actually skip time(CC). It seemed important to various people, but I can see how you can work around that just with time(AA) and time(EG). Other thoughts?
homogenized the text based in Thomas' input
…chitecture into more-time-considerations
only the most essential items: