jiebi/TextFlow huggingface dataset:
Original text:
Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning <del> the Attestation key material.  When either of these are compromised, </del>  the remote attestation becomes worthless because the attacker can forge Evidence. 12.1.1. <del> It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key. The Attester must be protected from unauthorized modification to ensure it behaves correctly.  There must also be confidentiality so that the signing key is not captured and used elsewhere to forge evidence. </del>  In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the

Reviewer comments:
Signed-off-by: Dave Thaler
"It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key." The grammar seems off to me. Should be: "It is assumed that the Attester is located in an isolated environment of a device such as; a process, a dedicated chip, a TEE, a virtual machine, a secure mode of operation or other forms of domain isolation that allows collection of Claims from the target environment where the target environment cannot lie or interfere with the claims collection function. Additionally, the Attester formats collected Claims and integrity protects them with an Attestation Key that also is domain isolated such that the target environment or some other entity other than the Attester is not able to undermine the Attester's protections"

Revised text:
Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning  <ins> the Attestation key material.  If either of these are compromised, </ins> the remote attestation becomes worthless because the attacker can forge Evidence. 12.1.1.  <ins> It is assumed that an Attesting Environment is sufficiently isolated from the Target Environment it collects Claims for and signs them with an Attestation Key, so that the Target Environment cannot forge Evidence about itself.  Such an isolated environment might be provided by a process, a dedicated chip, a TEE, a virtual machine, or another secure mode of operation.  The Attesting Environment must be protected from unauthorized modification to ensure it behaves correctly.  There must also be confidentiality so that the signing key is not captured and used elsewhere to forge Evidence. </ins> In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the
Original text:
Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence) <del> or Relying Party (for Attestation Result) is willing to accept. Freshness is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </del>  There are two common approaches for determining the epoch of an Evidence or Attestation Result.

Reviewer comments:
Signed-off-by: Dave Thaler
` I think what you mean is that “some flexibility on the requirement for freshness is a key component…”, i.e., it’s the willingness to accept a result that’s been around for a while enables caching.
agree.

Revised text:
Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence)  <ins> or Relying Party (for Attestation Result) is willing to accept.  Some flexibility on the freshness requirement, however, is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </ins> There are two common approaches for determining the epoch of an Evidence or Attestation Result.
Original text:
functions together.  In this case, there is no need for a protocol between the two. <del> It is also worth pointing out that the choice of model is generally up to the Relying Party.  The same device may need to create Evidence for different Relying Parties and/or different use cases.  For instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </del>  combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an

Reviewer comments:
We say: I'm not sure it "is up to the RP"_. Maybe better saying it "depends on the RP application" (or similar) because it's typically not a choice of the RP but of the use case / protocol flow in which the RP operates...
+1
Proposal: "Individual applications, use cases or protocol flows interacting with the same Attester can use different models."

Revised text:
functions together.  In this case, there is no need for a protocol between the two.  <ins> It is also worth pointing out that the choice of model depends on the use case, and that different Relying Parties may use different topological patterns. The same device may need to create Evidence for different Relying Parties and/or different use cases.  For instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </ins> combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an
Original text:
5. <del> dataflow shows a basic model for communication between an Attester, a Verifier, and a Relying Party.  The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier.  There are multiple other possible models.  This section includes some reference models.  This is not intended to be a restrictive list, and other variations may exist. </del>  5.1.

Reviewer comments:
The three sentences "There are multiple [...]", "This section includes [...]" and "This is not intended [...]" are slightly vague. It doesn't seem to me that their information content is enough to justify them being independent sentences. They should probably be combined.
OLD: NEW:
(slight refinement) "Figure 1 shows an abstract model for communication between an Attester, a Verifier, and a Relying Party. The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier. This section refines it by describing two reference interaction schemes (topological models), as well as one possible compositions thereof. The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns."
Reads good to me. Any other comments? (starting a virtual going once...)

Revised text:
5.  <ins> dataflow shows a data-flow diagram for communication between an Attester, a Verifier, and a Relying Party.  The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier.  This section refines it by describing two reference models, as well as one example composition thereof.  The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns. </ins> 5.1.
Original text:
The device that should be protected from being held hostage for a long period of time <del> A remote server that will securely grant the Attester permission to continue operating (i.e., not reboot) for a period of time </del>  2.7.

Reviewer comments:
There seems to be some confusion: initially it is said that the "Relying Party is the watchdog timer in the TPM." Subsequently, the Relying Party is defined as "A remote server that will securely grant the Attester [...]". So, what is it?
For context, this is now: https://ietf-rats-URL This is plainly wrong (probably due being left over as an artifact after revising the text). How about: "Relying Party: The watchdog capable to trigger a procedure that resets a device into a remediatable operational state."
WFM, except I am not sure "remediatable" is a word. You want to use "known, good" instead?
Sry for my native language habit of concatenating and mangling existing terms. "Known, good" reads very appropriate. Thanks!
The sentence above says that the replying party is inside the TPM?? I think this sentence, relying party is a remote server, is more likely what you mean. In the above paragraph, it says that the Relying Party is inside the TPM. I think this is the correct description. The Relying Party isn't remote in this use case because it has the essential capability to force the device to reboot.
This issue is the same as

Revised text:
The device that should be protected from being held hostage for a long period of time  <ins> A watchdog capable of triggering a procedure that resets a device into a known, good operational state. </ins> 2.7.
Original text:
protocol between the Attester and Relying Party. However, like in the Passport model, an Attestation Result is still <del> consumed by the Relying Party and so the serialization format of the Attestation Result is still important.  If the Relying Party is a constrained node whose purpose is to serve a given type resource using a standard resource access protocol, it already needs the parser(s) required by that existing protocol.  Hence, the ability to let the Relying Party obtain an Attestation Result in the same serialization format allows minimizing the code footprint and attack surface area of the Relying Party, especially if the Relying Party is a constrained node. </del>  5.3.

Reviewer comments:
Signed-off-by: Dave Thaler
The paragraph: seems to reshuffle the content of the preceding one. The two can be combined / streamlined.
Maybe: "However, like in the Passport model, an Attestation Result is still consumed by the Relying Party and so the ability to convey it in the same serialization format as the Evidence allows minimizing the code footprint and attack surface area, which is especially important if the Relying Party is a constrained node."
Personally, I like the new content here that elaborates on motivation and intent. Anyone else like to chime in here to have in impact on that expositional text?
The meaning of is wrong, i.e., format same as the Evidence. Instead the meaning is format same as the resource access protocol natively uses.

Revised text:
protocol between the Attester and Relying Party. However, like in the Passport model, an Attestation Result is still  <ins> consumed by the Relying Party.  Code footprint and attack surface area can be minimized by using a serialization format for which the Relying Party already needs a parser to support the protocol between the Attester and Relying Party, which may be an existing standard or widely deployed resource access protocol.  Such minimization is especially important if the Relying Party is a constrained node. </ins> 5.3.
Original text:
Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  There is no limit <del> to or requirement on the places that an Attesting Environment can exist, but they typically are in Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware.  An execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed to be capable of claims collection are referred to in this document as Attesting Environments. </del>  3.4.

Reviewer comments:
Why not? What’s the message you want to convey here? What would disqualify an execution environment from being capable of claims collection? How would you know if an Execution Environment is an Attesting Environment?
What does it mean to be capable of claims collection? If this example had a TPM, then this function would be entirely inside the TPM, no?
subsequent line now reads: ` Should this explicitely say, "TPM" as well, or is that implied?

Revised text:
Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  There is no limit  <ins> to or requirement on the types of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.  An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments. </ins> 3.4.
Original text:
Every FIDO Authenticator contains an Attester. <del> Any web site, mobile application back end or service that does biometric authentication. </del>  3.

Reviewer comments:
` It sounds like the Verifier “does” the authentication, and the relying party relies on the answer?
Besides, there's a slight imprecision here: the web site / mobile app backend service don't do biometric auth. Instead, the authenticator binds biometric info to crypto material so that the web site can deal with usual crypto auth.
For context, this is https://ietf-rats-URL How about:

Revised text:
Every FIDO Authenticator contains an Attester.  <ins> Any web site, mobile application back-end, or service that relies on authentication data based on biometric information. </ins> 3.
Original text:
3.4. <del> By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding complexity to the architectural structure.  The unifying component is the root of trust and the nested, staged, or chained attestation Evidence produced.  The nested or chained structure includes Claims, collected by the Attester to aid in the assurance or believability of the attestation Evidence. </del>  The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system

Reviewer comments:
Based on Henk's proposal and Dave's comments.
NAME : This is a complete re-write of the paragraph which needs to be read in its entirety. I'm not sure whether a line-by-line diff is of any help? That said, if you really want I could do that easily.
Thomas Fossati wrote: It helps with the next edit that comes along.
OK, done in f778919
I don't understand what this para is supposed to communicate: Also, pick one of "nested", "staged" or "chained" and drop the rest.
For context: this is now https://ietf-rats-URL "Layered Attestation Environments" How about this as a new starting point: Effectively, I removed the last sentence, as I had a hard time to understand what it intended to add to the content here. My proposal is intended as a rework of this paragraph that goes beyond editorial changes. The current last sentence still seems a bit out of place to me.
Looks very good as a starting point. Thanks!
All good so far. This sentence can be confusing, since I think it could include claims about itself in Evidence, as admitted in your point below ("Claims can be collected from or about each layer, including roots of trust.") Disagree with "must be endorsed". Either the verifier has to trust the root of trust itself (e.g., put the root of trust's public key into its trust anchor store directly) OR must be endorsed (e.g., put the endorser's public key into the verifier's trust anchor store). Fine.

Revised text:
3.4.  <ins> By definition, the Attester role generates Evidence.  An Attester may consist of one or more nested environments (layers).  The root layer of an Attester includes at least one root of trust.  In order to appraise Evidence generated by an Attester, the Verifier needs to trust the Attester's root of trust.  Trust in the Attester's root of trust can be established either directly (e.g., the Verifier puts the root of trust's public key into its trust anchor store) or transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding claims can be structured in a nested fashion that reflects the nesting of the Attester's layers. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system
Original text:
Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy. <del> There are three ways in which the process may fail.  First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence.  The second way in which the process may fail is when the Attestation Result is examined by the Relying Party, and based upon the Appraisal Policy for Attestation Results, the result does not pass the policy.  The third way is when the Verifier is unreachable or unavailable. </del>  Since the resource access protocol between the Attester and Relying Party includes an Attestation Result, in this model the details of

Reviewer comments:
` Is there a reason to enumerate the failure cases? How can it be argued that there are only three? What if the device fails part way through? What if the relying party fails? What if the relying party is unreachable? What if something happens that wasn’t anticipated in the appraisal policy? Put another way, what are we learning about RATS from this example?

Revised text:
Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy.  <ins> Three ways in which the process may fail include: First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence. The second way in which the process may fail is when the Attestation Result is examined by the Relying Party, and based upon the Appraisal Policy for Attestation Results, the result does not pass the policy. The third way is when the Verifier is unreachable or unavailable. </ins> Since the resource access protocol between the Attester and Relying Party includes an Attestation Result, in this model the details of
Original text:
this architecture. A conveyance protocol that provides authentication and integrity <del> protection can be used to convey unprotected Evidence, assuming the following properties exists: </del>  The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the <del> Attesting Environment(s) that collected claims about the Target </del>  Environment(s). All unprotected Evidence that is conveyed is supplied exclusively

Reviewer comments:
I assume this is an escape hatch for unsigned CBOR. But I’m not sure the sentence makes sense… if the conveyance protocol provides protection, then it’s not unprotected evidence? Or is there some other point we’re trying to get at?
"URL to convey Evidence that is otherwise unprotected, relies on the conveyance protocol for the following protections: ..." I think unsigned CBOR (the UCCS draft) is one example of "unprotected Evidence". Maybe we can add a reference pointing to the UCCS draft.
` Maybe we can say "URL to convey Evidence that is otherwise unprotected itself", or "URL to convey Evidence that is otherwise not signed itself"?

Revised text:
this architecture. A conveyance protocol that provides authentication and integrity  <ins> protection can be used to convey Evidence that is otherwise unprotected (e.g., not signed).  Appropriate conveyance of unprotected Evidence (e.g., I-D.birkholz-rats-uccs) relies on the following conveyance protocol's protection capabilities: </ins> The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the  <ins> Attesting Environment(s) that collected Claims about the Target </ins> Environment(s). All unprotected Evidence that is conveyed is supplied exclusively
Original text:
In the Composite Device, each Attester generates its own Evidence by its Attesting Environment(s) collecting the claims from its Target <del> Environment(s).  The lead Attester collects the Evidence of all other Attesters and then generates the Evidence of the whole Composite Attester. </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

Reviewer comments:
Updated paragraph describing collection of Evidence from sub-attesters
Should this section include an Informative Reference to the Trusted Computing Group “Guidance for Securing Network Equipment” URL It seems to repeat more or less the same thing, but using the RATS lexicon
Another comment I have on this section is about the trust model of a composite device: it looks like the lead attester needs to be trusted to collect the most fresh evidence from the other slots? Is this discussed anywhere?
Who do you mean the lead Attester needs to be trusted by? The Verifier/Relying Party or other slots/Attesters? The collecting capability is one of the characteristics the lead Attester has. So after the Verifier verifies the Evidence of the lead Attester successfully, it can trust the lead Attester's collecting capability. The Evidence of other slots are signed by these slots themselves, and these slots can send Evidence to the lead Attester just as the lead Attester sends Evidence to the on-path router to the Verifier.
I meant the latter - apologies for the lack of precision. In particular, I am interested in the scenario where a compromised lead that has cached some previously collected evidences, can forward those instead of fresh slots' attestations.

Revised text:
In the Composite Device, each Attester generates its own Evidence by its Attesting Environment(s) collecting the claims from its Target  <ins> Environment(s).  The lead Attester collects the Evidence from the other Attesters and conveys it to a Verifier.  Collection of Evidence from sub-entities may itself be a form of Claims collection that results in Evidence asserted by the lead Attester.  The lead Attester generates the Evidence about the layout of the Composite Device, while sub-Attesters generate Evidence about their respective modules. </ins> An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  The combination of roles can