jiebi/TextFlow huggingface dataset:
Original text:
generates the Evidence about the layout of the Composite Device, while sub-Attesters generate Evidence about their respective modules. <del> An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  The combination of roles can be arbitrary.  For example, in this Composite Device scenario, the entity inside the lead Attester can also take on the role of a Verifier, and the outside entity of Verifier can take on the role of a Relying Party.  After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and appraisal policies (obtained the same way as any other Verifier) in the verification process to generate Attestation Results.  The inside Verifier then conveys the Attestation Results of other Attesters, whether in the same conveyance protocol as the Evidence or not, to the outside Verifier. </del> In this situation, the trust model described in trustmodel is also suitable for this inside Verifier.  4. This document uses the following terms.

Reviewer comments:
2nd to last para. in composite device section should be be given its own section heading - ## Entity
The second to last paragraph in Composite Device section is not describing composite devices. Instead it describes role-entity semantics. It should be given its own section heading e.g. "Entities" and the last paragraph / sentence should be moved up (into the composite device section).

Revised text:
generates the Evidence about the layout of the Composite Device, while sub-Attesters generate Evidence about their respective modules.  In this situation, the trust model described in trustmodel is also suitable for this inside Verifier. <ins> 3.6. An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  Multiple entities can cooperate to implement a single RATS role as well.  The combination of roles and entities can be arbitrary.  For example, in the Composite Device scenario, the entity inside the lead Attester can also take on the role of a Verifier, and the outer entity of Verifier can take on the role of a Relying Party.  After collecting the Evidence of other Attesters, this inside Verifier uses Endorsements and appraisal policies (obtained the same way as any other Verifier) in the verification process to generate Attestation Results.  The inside Verifier then conveys the Attestation Results of other Attesters to the outside Verifier, whether in the same conveyance protocol as the Evidence or not. </ins> 4. This document uses the following terms.
Original text:
One way to provision a key is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality of the generator, as well as the path over which the <del> key is provisioned, is necessary.  This can be achieved in a number of ways. </del>  Confidentiality can be achieved entirely with physical provisioning facility security involving no encryption at all.  For low-security

Reviewer comments:
It seems that all that’s relevant to RATS is “if the key is generated externally, the manufacturer needs to take care to protect it with measures consistent with its value” ` This case does seem different – there is simply no known way to extract the key.
I agree with MCR's summary that “if the key is generated externally, the manufacturer needs to take care to protect it with measures consistent with its value”. Can we replace the bulk of section 12.1.2 with this single sentence? The expectation is that private keys can't be extracted (read) once provisioned. That should be a stated security assumption. This section reads like a tutorial or primer. That isn't the goal IMO. Security Considerations should state our our security assumptions.
{not my comment. Guy's. If you like that part, generate a pull request please!}

Revised text:
One way to provision a key is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality of the generator, as well as the path over which the  <ins> key is provisioned, is necessary.  The manufacturer needs to take care to protect it with measures consistent with its value.  This can be achieved in a number of ways. </ins> Confidentiality can be achieved entirely with physical provisioning facility security involving no encryption at all.  For low-security
Original text:
buffering incoming messages that might be associated with a handle that the receiver has not yet obtained.  Whereas the nonce approach typically requires the appraising entity to keep state for each nonce generated, the handle approach minimizes the state kept to be independent of the number of Attesters or

Reviewer comments:
The handle-related portion of the Freshness section should provide some guidance on the extent of the "epoch window", i.e., the number of previously received handles that need to be kept by an appraiser to deal with propagation delay.

Revised text:
buffering incoming messages that might be associated with a handle that the receiver has not yet obtained. <ins> More generally, in order to prevent an appraising entity from generating false negatives (e.g., discarding Evidence that is deemed stale even if it is not), the appraising entity should keep an "epoch window" consisting of the most recently received handles.  The depth of such epoch window is directly proportional to the maximum network propagation delay between the first to receive the handle and the last to receive the handle, and it is inversely proportional to the epoch duration. The appraising entity shall compare the handle carried in the received Evidence or Attestation Result with the handles in its epoch window to find a suitable match. </ins> Whereas the nonce approach typically requires the appraising entity to keep state for each nonce generated, the handle approach minimizes the state kept to be independent of the number of Attesters or
Original text:
A more detailed discussion with examples appears in time- considerations.  11. The conveyance of Evidence and the resulting Attestation Results or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence.  13. This document does not require any actions by IANA.

Reviewer comments:
Discuss the impact that altering the distribution of handles (e.g., delaying, suppressing) has on the security of the protocol. Add relevant text to the Security Consideration section.
Is this more than just finishing ? If so, what?
The scope is different: deals with the example in the appendix, this one is for text that belongs to the security considerations. Regarding the "what": is the issue description insufficient? If so, do you have any suggestion on how to make it clearer?

Revised text:
A more detailed discussion with examples appears in time- considerations. <ins> For a discussion on the security of handles see handles-sec. </ins> 11. The conveyance of Evidence and the resulting Attestation Results or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence. <ins> 12.3. Handles, described in epochfreshness, can be tampered with, dropped, delayed and reordered by an attacker. An attacker could be either external or belong to the distribution group, for example if one of the Attester entities have been compromised. An attacker who is able to tamper with handles can potentially lock all the participants in a certain epoch of choice for ever, effectively freezing time.  This is problematic since it destroys the ability to ascertain freshness of Evidence and Attestation Results. To mitigate this threat, the transport should be at least integrity protected and provide origin authentication. Selective dropping of handles is equivalent to pinning the victim node to a past epoch.  An attacker could drop handles to only some entities and not others, which will typically result in a denial of service due to the permanent staleness of the Attestation Result or Evidence. Delaying or reordering handles is equivalent to manipulating the victim's timeline at will.  This ability could be used by a malicious actor (e.g., a compromised router) to mount a confusion attack where, for example, a Verifier is tricked into accepting Evidence coming from a past epoch as fresh, while in the meantime the Attester has been compromised. Reordering and dropping attacks are mitigated if the transport provides the ability to detect reordering and drop.  However, the delay attack described above can't be thwarted in this manner. </ins> 13. This document does not require any actions by IANA.
Original text:
Reference Values used in appraisal come from a Reference Value Provider and are then used by the appraisal policy.  They might be <del> conveyed in any number of ways, including: * as part of the appraisal policy itself, if the Verifier Owner either: acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; * as part of an Endorsement, if the Endorser either acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; or * via separate communication. </del>  The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document

Reviewer comments:
The list in sec 3.2 didn't render properly. Also fix Pete's surname which got garbled for some reason.

Revised text:
Reference Values used in appraisal come from a Reference Value Provider and are then used by the appraisal policy.  They might be  <ins> conveyed in any number of ways, including: as part of the appraisal policy itself, if the Verifier Owner either: acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; as part of an Endorsement, if the Endorser either acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; or via separate communication. </ins> The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document
Original text:
Result to the Relying Party is current, while a previous handle was used to generate Verifier evaluated evidence.  This indicates that at least one epoch transition has occurred, and the Attestation Results <del> may only be as fresh as the previous epoch. </del>  16.4.

Reviewer comments:
Biggest bug in the last pull request is that the diagram had the attester sending a different Attestation Result than the one the Verifier gave it, which would invalidate the signature. Second issue was that the lines didn't line up. Third issue was that it was missing the tie to the "epoch window" discussion in {{epochfreshness}} to explain how the Relying Party deals with the mismatched handles that the example diagram has. Signed-off-by: Dave Thaler
The appendix on Handles needs some work to better clarify the concepts and simplify the flow. Some things about the text: Clearly define what is a handle; Explain its relation with epoch establishment; Clarify network jitter impact on handle validity; Explain what are the base rules for working with handles; Some further points on the sequence diagram: Fix confusing legend; Add some accompanying prose to explain the depicted use case as it's not self-evident;
Thanks for aligning the diagram, I knew I had forgotten something. The changes look good to me.Ship it!

Revised text:
Result to the Relying Party is current, while a previous handle was used to generate Verifier evaluated evidence.  This indicates that at least one epoch transition has occurred, and the Attestation Results  <ins> may only be as fresh as the previous epoch.  If the Relying Party remembers the previous handle H during an epoch window as discussed in epochfreshness, and the message is received during that window, the Attestation Result is accepted as fresh, and otherwise it is rejected as stale. </ins> 16.4.
Original text:
that protocol constrain the serialization format of the Attestation Result.  The format of the Evidence on the other hand is only constrained by the Attester-Verifier remote attestation protocol.  5.2.

Reviewer comments:
` Yes but for real passports, the Relying Party must separately evaluate the trustworthiness of 192 different Verifiers, i.e., nation states, no? This seems to imply that relying parties had better get ready to validate a limitless variety of Attestation Results? [mcr: yes, in fact, in real passports, Relying Parties do not treat all 192 nation states equally, which is why, I'm told, Israeli Mossad agents apprently like Canadian passports...]
The detail of how the Relying Party should trust the Verifiers is described in the "Trust Model" Section. Besides, there may be Appraisal Policies for Attestation Results, which will guide the Relying Party on validating the Attestation Results. I don't think an update is needed here.
The passport analogy shows that there is a cardinality of: Individual (1)(1) Passport Agency Individual (1)(N) Immigration Desk The text currently does not state that this implies that interoperability and standardization is more relevant for Attestation Results than it is for Evidence (in this model). The question I want to raise is, do we want to make that more explicit to the reader?

Revised text:
that protocol constrain the serialization format of the Attestation Result.  The format of the Evidence on the other hand is only constrained by the Attester-Verifier remote attestation protocol. <ins> This implies that interoperability and standardization is more relevant for Attestation Results than it is for Evidence. </ins> 5.2.
Original text:
structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. <del> Claims about a root of trust typically are asserted by Endorsers. </del>  The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an operating system kernel, and (C) an application

Reviewer comments:
Once we added Reference Value Provider as a role, the diagram wasn't updated. The "A, B, and C" part is about reference values, not the endorsing of signing capabilities, which is just about A. Signed-off-by: Dave Thaler

Revised text:
structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer.  <ins> Claims about a root of trust typically are asserted by an Endorser. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an operating system kernel, and (C) an application
Original text:
Values, or membership in a set of Reference Values, or a check against values in other Claims, or any other test.  3.2. Reference Values used in appraisal come from a Reference Value via separate communication. The actual data format and semantics of any Reference Values are <del> specific to Claims and implementations.  This architecture document does not define any general purpose format for them or general means for comparison. </del>  3.3.

Reviewer comments:
Signed-off-by: Dave Thaler
While Reference Values have a strong focus on conveyance and data format, Appraisal Policies do not. Is there a specific reason for this asymmetry? Additionally, there is a statement on scope on the Reference Value that does not exist for Appraisal Policies. Does that imply something?
Add some additional words to Appraisal policy like: URL
Agreed to also move to section 6, about appraisal/etc. combinations.

Revised text:
Values, or membership in a set of Reference Values, or a check against values in other Claims, or any other test. <ins> The actual data format and semantics of any Appraisal Policy is implementation specific. </ins> 3.2. Reference Values used in appraisal come from a Reference Value via separate communication. The actual data format and semantics of any Reference Values are  <ins> specific to Claims and implementations. </ins> 3.3.
Original text:
there are many Attesters owned, the use of an Endorser becomes more scalable. <del> That is, it might appraise the trustworthiness of an application component, operating system component, or service under the assumption that information provided about it by the lower-layer </del>  firmware or software is true.  A stronger level of assurance of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to

Reviewer comments:
Signed-off-by: Dave Thaler
What is the “it” in “That is, it”

Revised text:
there are many Attesters owned, the use of an Endorser becomes more scalable.  <ins> That is, a Verifier might appraise the trustworthiness of an application component, operating system component, or service under the assumption that information provided about it by the lower-layer </ins> firmware or software is true.  A stronger level of assurance of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to
Original text:
12.3. <del> Handles, described in epochfreshness, can be tampered with, dropped, delayed and reordered by an attacker. An attacker could be either external or belong to the distribution group, for example if one of the Attester entities have been compromised. </del>  An attacker who is able to tamper with handles can potentially lock all the participants in a certain epoch of choice for ever,

Reviewer comments:
by removing the sentence which didn't add any critical point. Also mention replaying in the list of potential nefarious activities. Signed-off-by: Dave Thaler
In context, I am not sure what that sentence is trying to tell me.
I think it means that an Attacker might or might not have actually received the epoch ids from the epoch id distributor.

Revised text:
12.3.  <ins> Handles, described in epochfreshness, can be tampered with, replayed, dropped, delayed, and reordered by an attacker. </ins> An attacker who is able to tamper with handles can potentially lock all the participants in a certain epoch of choice for ever,
Original text:
How and if clocks are synchronized depends upon the model.  16.1. The following example illustrates a hypothetical Passport Model result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps. <del> In the figures above and in subsequent sections, curly braces indicate containment.  For example, the notation Evidence{foo} indicates that 'foo' is contained in the Evidence and is thus covered by its signature. </del> The Verifier can check whether the Evidence is fresh when appraising it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold", where the Verifier's threshold is large enough to account for the

Reviewer comments:
Maybe move this paragraph to the super-section? Maybe this is intentional due to the proximity to a syntax example? Yet, the suffix syntax style is not placed here, correspondingly.

Revised text:
How and if clocks are synchronized depends upon the model. <ins> In the figures below, curly braces indicate containment.  For example, the notation Evidence{foo} indicates that 'foo' is contained in the Evidence and is thus covered by its signature. </ins> 16.1. The following example illustrates a hypothetical Passport Model result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps.  The Verifier can check whether the Evidence is fresh when appraising it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold", where the Verifier's threshold is large enough to account for the
Original text:
12.  12.1. Implementers need to pay close attention to the protection of the

Reviewer comments:
Many of the things that we are writing in the security considerations are really security requirements on implementations, rather than concerns with the architecture.

Revised text:
12. <ins> This document provides an architecture for doing remote attestation. No specific wire protocol is documented here.  Without a specific proposal to compare against, it is impossible to know if the security threats listed below have been mitigated well.  The security considerations below should be read as being essentially requirements against realizations of the RATS Architecture.  Some threats apply to protocols, some are against implementations (code), and some threats are against physical infrastructure (such as factories). </ins> 12.1. Implementers need to pay close attention to the protection of the
Original text:
protection of the Attesting Environment's signing key is vital so it cannot be misused to forge Evidence. <del> In many cases the user or owner of a device that takes on the role of Attester must not be able to modify or extract keys from its Attesting Environments.  For example, the owner or user of a mobile phone or FIDO authenticator might not be trusted to use the keys to report Evidence about the environment that protects the keys.  An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. </del>  Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and

Reviewer comments:
What is that sentence trying to tell me? Control over which keys? Not the attestation keys, I think.

Revised text:
protection of the Attesting Environment's signing key is vital so it cannot be misused to forge Evidence.  <ins> In many cases the user or owner of a device that includes the role of Attester must not be able to modify or extract keys from the Attesting Environments, to prevent creating forged Evidence.  Some common examples include the user of a mobile phone or FIDO authenticator.  An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. </ins> Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and
Original text:
they are presumed to exist in order to convey conceptual messages appropriately between roles. <del> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles. As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles.  As a wide-area network connected entity, it may implement an Attester role. </del> In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this document.

Reviewer comments:
The example used in roles and entities actually do not illustrate two aggregated/collapsed roles that talk with each other, as they seem to be entities in two different RATS setups?
Agreed to delete paragraph:"For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles. As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles. As a wide-area network connected entity, it may implement an Attester role."

Revised text:
they are presumed to exist in order to convey conceptual messages appropriately between roles.  In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this document.