jiebi/TextFlow huggingface dataset:
Original text:
material and the Attesting Environment with equivalent strength protections.  See security-considerations for discussion on security strength. 7.5.

Reviewer comments:
Maybe a sentence to tie unprotected Evidence to the "concept of trust" in the Verifier section of the Trust Model super-rsection might be useful in order to illustrate to the reader why that is covered there? At the moment it talks about "secure channels" and the ties to trust are mainly implied?

Revised text:
material and the Attesting Environment with equivalent strength protections. <ins> As illustrated in I-D.birkholz-rats-uccs, an entity that receives unprotected Evidence via a trusted conveyance channel always takes on the responsibility of vouching for the Evidence's authenticity and freshness.  If protected Evidence is generated, the Attester's Attesting Environments take on that responsibility.  In cases where unprotected Evidence is processed by a Verifier, Relying Parties have to trust that the Verifier is capable of handling Evidence in a manner that preserves the Evidence's authenticity and freshness. Generating and conveying unprotected Evidence always creates significant risk and the benefits of that approach have to be carefully weighed against potential drawbacks. </ins> See security-considerations for discussion on security strength. 7.5.
Original text:
A Trusted Application Manager (TAM) server is responsible for managing the applications running in a Trusted Execution Environment <del> (TEE) of a client device.  To achieve its purpose, the TAM needs to assess the state of a TEE, or of applications in the TEE, of a client device.  The TEE conducts Remote Attestation Procedures with the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy.  If not, the TAM has to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. </del>  A device with a TEE capable of running trusted applications that can be updated. 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 <del> (TPMs), or BIOS firmware. </del>  An arbitrary execution environment may not, by default, be capable of Claims collection for a given Target Environment.  Execution

Reviewer comments:
added reference to TEEP, cited TPM reference in section 3.3.
First mentioning of TEE, eSE, and TPM need reference in section Two Types of Environments of an Attester.
These terms need to have references: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.
We don't think we need to expand BIOS, and that it should be on the RFC editor Acronym list.

Revised text:
A Trusted Application Manager (TAM) server is responsible for managing the applications running in a Trusted Execution Environment  <ins> (TEE) of a client device, as described in TEEParch.  To achieve its purpose, the TAM needs to assess the state of a TEE, or of applications in the TEE, of a client device.  The TEE conducts Remote Attestation Procedures with the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy.  If not, the TAM has to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. </ins> A device with a TEE capable of running trusted applications that can be updated. 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  <ins> (TPMs) TCGarch, or BIOS firmware. </ins> An arbitrary execution environment may not, by default, be capable of Claims collection for a given Target Environment.  Execution
Original text:
16.  The table below defines a number of relevant events, with an ID that is used in subsequent diagrams.  The times of said events might be defined in terms of an absolute clock time, such as the Coordinated

Reviewer comments:
Note that section 10.4 (Freshness.Discussion) already said: So the intro text tries to be consistent with that phrasing. Signed-off-by: Dave Thaler
pushed 7c75ffe to fix the CI
Appendix A needs more introduction text to highlight its value to the reader.
LGTM

Revised text:
16. <ins> freshness discussed various issues and requirements around freshness of evidence, and summarized three approaches that might be used by different solutions to address them.  This appendix provides more details with examples to help illustrate potential approaches, to inform those creating specific solutions. </ins> The table below defines a number of relevant events, with an ID that is used in subsequent diagrams.  The times of said events might be defined in terms of an absolute clock time, such as the Coordinated
Original text:
operational status, health, configuration or construction that have security relevance.  Evidence is appraised by a Verifier to establish its relevance, compliance, and timeliness.  Claims need to be <del> collected in a manner that is reliable.  Evidence needs to be securely associated with the target environment so that the Verifier cannot be tricked into accepting Claims originating from a different environment (that may be more trustworthy).  Evidence also must be protected from man-in-the-middle attackers who may observe, change or misdirect Evidence as it travels from Attester to Verifier.  The timeliness of Evidence can be captured using Claims that pinpoint the time or interval when changes in operational status, health, and so forth occur. </del>  8.2.

Reviewer comments:
`
This is trying say that the Target Environment can't lie to the Attesting Environment about its trustworthiness properties.
Spot on. A text proposal (NEW) based on Ned's comment:

Revised text:
operational status, health, configuration or construction that have security relevance.  Evidence is appraised by a Verifier to establish its relevance, compliance, and timeliness.  Claims need to be  <ins> collected in a manner that is reliable such that a Target Environment cannot lie to the Attesting Environment about its trustworthiness properties.  Evidence needs to be securely associated with the target environment so that the Verifier cannot be tricked into accepting Claims originating from a different environment (that may be more trustworthy).  Evidence also must be protected from man-in-the-middle attackers who may observe, change or misdirect Evidence as it travels from Attester to Verifier.  The timeliness of Evidence can be captured using Claims that pinpoint the time or interval when changes in operational status, health, and so forth occur. </ins> 8.2.
Original text:
Evidence and Attestation Results are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If <del> confidentiality protection of the conceptual messages is omitted or unavailable, the protecting protocols that convey Evidence or Attestation Results are responsible for detailing what kinds of information are disclosed, and to whom they are exposed. </del>  As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted

Reviewer comments:
Fixes line in privacy section that was unclear about using encryption as a privacy protection approach.
In we now explicitly say that "confidentiality protection of Evidence and Attestation Results" is required in some form. In we now explicitly say that "Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII)". See my point already? Maybe protection of Appraisal Policies is "technically out-of-scope", but expressing this side by side makes a curious impression to me.
`
I suggest sticking to defined terminology such as 'conveyance protocol' instead of 'protecting protocols'. The 'kinds of information disclosed' is terminology for 'Claims'. It might make sense to include the line "If there isn't confidentiality protection of Evidence and Attestation Results in the conceptual messages, the underlying conveyance protocol should provide these protections."
"for example, if there isn't object-level confidentiality protection of messages, then the transport protocol should provide it" "If there isn't confidentiality protection of Evidence and Attestation Results in the conceptual messages, the underlying conveyance protocol should provide these protections."

Revised text:
Evidence and Attestation Results are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If  <ins> there isn't confidentiality protection of Evidence and Attestation Results, the underlying conveyance protocol should provide these protections. </ins> As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted
Original text:
that a device is running a weak version of firmware provides a way to aim attacks better. <del> Many Claims in Evidence and Attestation Results are potentially Personally Identifying Information (PII) depending on the end-to-end use case of the remote attestation procedure.  Remote attestation that goes up to include containers and applications, e.g., a blood pressure monitor, may further reveal details about specific systems or users. </del>  In some cases, an attacker may be able to make inferences about the contents of Evidence from the resulting effects or timing of the

Reviewer comments:
Fixes issue
In we now explicitly say that "confidentiality protection of Evidence and Attestation Results" is required in some form. In we now explicitly say that "Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII)". See my point already? Maybe protection of Appraisal Policies is "technically out-of-scope", but expressing this side by side makes a curious impression to me.
`
Yes. However, without a suitable privacy tracking identifier, it might not be possible to correlate privacy sensitive information in the policy with the actions of the Attester.
We should add privacy applies to appraisal policy to Privacy section.

Revised text:
that a device is running a weak version of firmware provides a way to aim attacks better.  <ins> Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII) depending on the end-to-end use case of the remote attestation procedure.  Remote attestation that includes containers and applications, e.g., a blood pressure monitor, may further reveal details about specific systems or users. </ins> In some cases, an attacker may be able to make inferences about the contents of Evidence from the resulting effects or timing of the
Original text:
the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence.  Freshness is assessed based on the Appraisal Policy for Evidence or Attestation Results that compares the estimated epoch against an "expiry" threshold defined locally to that policy.  There is,

Reviewer comments:
Section 10. I found the level of detail on this section on freshness out of place and inconsistent with the level of abstraction found in the rest of the test. In most other section, generic interaction of roles, artifacts, their associated topologies, and high level security properties was noted. This section delves into specific implementation choices. In particular, Is the WG sure that it needs all of the details of Section 10.3. Even among all of the Section in 10., this stands out. It doesn't seem to provide enough detail to be create interoperability but goes beyond simply introducing the concept. Section 12.3
I agree with the observation, but don't believe it requires any changes.
This was carefully discussed and weighed over the entire editorial WG phase, actually. We found delicate consensus that might have also resulted in an unusual high level of attention to detail, but that detailed is most certainly warranted here especially. I think the text reflects the WG consensus building in an appropriately nuanced fashion today and am very hesitant with trying to refactor it again (even if it suddenly spikes to a maybe surprising level of detail) as I deem it unlikely that it will improve by that, tbh.
"This section is intended for those creating protocols or solutions to understand the options available to ensure freshness"

Revised text:
the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. <ins> This section provides a number of details.  It does not however define any protocol formats, the interactions shown are abstract. This section is intended for those creating protocols and solutions to understand the options available to ensure freshness.  The way in which freshness is provisioned in a protocol is an architectural decision.  Provisioning of freshness has an impact on the number of needed round trips in a protocol, and therefore must be made very early in the design.  Different decisions will have significant impacts on resulting interoperability, which is why this section goes into sufficient detail such that choices in freshness will be compatible across interacting protocols, such as depicted in multievidence_diag. </ins> Freshness is assessed based on the Appraisal Policy for Evidence or Attestation Results that compares the estimated epoch against an "expiry" threshold defined locally to that policy.  There is,
Original text:
In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for <del> the Attester's ability to securely generate Evidence, in which case the Endorser's key material is stored in the Verifier's trust anchor store. </del>  In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material

Reviewer comments:
Reworded paragraph following the word 'vouch' to better explain the how Endorsements affect Verifier's trust in the Attester.
`
"... vouch for the Attester's ability to securely generate Evidence by asserting endorsement claims regarding the ways in which attestation keys are protected. Consequently, the Endorser's key material is stored in the Verifier's trust anchor store so that Endorsements can be included in the Verifier's appraisal."
This proposal is definitely a step into the right direction. We should not overload this, but I think this is appropriately improved.
"attestation keys are protected" is too narrow
See PR

Revised text:
In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for  <ins> the Attester's ability to securely generate Evidence through Endorsements (see endorsements).  Endorsements might describe the ways in which the Attester resists attack, protects secrets and measures Target Environments.  Consequently, the Endorser's key material is stored in the Verifier's trust anchor store so that Endorsements can be authenticated and used in the Verifier's appraisal process. </ins> In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material
Original text:
value of specific Claims if it knew that only certain values were accepted by the Relying Party. <del> Evidence and Attestation Results are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If there isn't confidentiality protection of Evidence and Attestation Results, the underlying conveyance protocol should provide these protections. </del>  As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted

Reviewer comments:
Signed-off-by: Dave Thaler
In we now explicitly say that "confidentiality protection of Evidence and Attestation Results" is required in some form. In we now explicitly say that "Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII)". See my point already? Maybe protection of Appraisal Policies is "technically out-of-scope", but expressing this side by side makes a curious impression to me.

Revised text:
value of specific Claims if it knew that only certain values were accepted by the Relying Party.  <ins> Conceptual messages carrying sensitive or confidential information are expected to be integrity protected (i.e., either via signing or a secure channel) and optionally might be confidentiality protected via encryption.  If there isn't confidentiality protection of conceptual messages themselves, the underlying conveyance protocol should provide these protections. </ins> As Evidence might contain sensitive or confidential information, Attesters are responsible for only sending such Evidence to trusted
Original text:
and the validation key material off the device.  Sometimes this procedure is referred to as personalization or customization.  12.1.2.1. One way to provision key material is to first generate it external to

Reviewer comments:
** Section 12.1.2. I didn't see any of the obvious text that regardless of whether the key is generated on or off device, high quality randomness is needed.

Revised text:
and the validation key material off the device.  Sometimes this procedure is referred to as personalization or customization. <ins> The keys generated in the factory, whether generated in the device or off-device by the factory SHOULD be generated by a Cryptographically Strong Sequence (RFC4086, Section 6.2). </ins> 12.1.2.1. One way to provision key material is to first generate it external to
Original text:
attestation defined by RATS is thus a candidate for use in the FIDO protocol. <del> Every FIDO Authenticator contains an Attester. </del>  Any web site, mobile application back-end, or service that relies on authentication data based on biometric information.

Reviewer comments:
The current attester description in §2.7 is ambiguous and inconsistent with the earlier ones. Right now it reads: "Attester: Every FIDO Authenticator contains an Attester." To clarify and align the attested description with the earlier ones, I suggest replacing this text with: "Attester component contained in a FIDO authenticator".
Both definitions seem OK to me. The goal of the use cases isn't to provide a technical decomposition of the FIDO device IMHO. Rather, it is to provide a cursory level mapping to the abstract roles / role messages. In fact, if a change is needed I would simply have it say "Attester: FIDO Authenticator".
I agree that a technical decomposition is not the goal, however the current formulation just differs too much from the other ones. The change you suggested - "Attested: FIDO Authenticator" - is a good alternative.
"Attester: A FIDO Authenticator".

Revised text:
attestation defined by RATS is thus a candidate for use in the FIDO protocol.  <ins> FIDO Authenticator. </ins> Any web site, mobile application back-end, or service that relies on authentication data based on biometric information.
Original text:
12.4. As noted in trustmodel, Verifiers and Relying Parties have trust <del> anchor stores that must be secured.  Specifically, a trust anchor </del>  store must resist modification against unauthorized insertion, deletion, and modification.

Reviewer comments:
Section 12.4. Is there any read sensitivity for the trust anchor store? Section 12.4. Since RFC5280 is being invoked here, is there an expectation that certificates in RATS would confirm to this profile?
-> "For example, see Section 6 of [RFC5280]" Discussion ensued about whether there is read sensitivity vs audit requirements, and whether this is even specific to RATS at all.
RFC6024 URL ?
"As noted in Section 7, Verifiers and Relying Parties have trust anchor stores that must be secured. RFC6024 contains more discussion of trust anchor store requirements."

Revised text:
12.4. As noted in trustmodel, Verifiers and Relying Parties have trust  <ins> anchor stores that must be secured.  RFC6024 contains more discussion of trust anchor store requirements.  Specifically, a trust anchor </ins> store must resist modification against unauthorized insertion, deletion, and modification.
Original text:
A Verifier or Relying Party might need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced.  This is essential in deciding whether the included Claims <del> and their values can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. </del>  This section provides a number of details.  It does not however define any protocol formats, the interactions shown are abstract.

Reviewer comments:
Section 10 first paragraph has the phrase "Claims and their values "; which is redundant. "Claims" is sufficient.

Revised text:
A Verifier or Relying Party might need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced.  This is essential in deciding whether the included Claims  <ins> can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. </ins> This section provides a number of details.  It does not however define any protocol formats, the interactions shown are abstract.
Original text:
If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which includes checking for certificate <del> revocation.  See Section 6 of RFC5280 for details. </del>  13.

Reviewer comments:
Document says: If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which includes checking for certificate revocation. See Section 6 of [RFC5280] for details.
The situation is very much use case dependant. If one is going to rely upon certificates and paths and trust anchors, then a profile should say this. It might be wise to do that. Whole document is non-normative.
Are there some other documents that we can cite that are more prescriptive? There are NIST documents that explain the issues, but are reluctant to be prescriptive.
If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which may include checking for certificate revocation.

Revised text:
If certificates are used as trust anchors, Verifiers and Relying Parties are also responsible for validating the entire certificate path up to the trust anchor, which includes checking for certificate  <ins> revocation.  For an example of such a proceedure see Section 6 of RFC5280. </ins> 13.