jiebi/CodeConvo huggingface dataset:
Change:
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.

Discussion:
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> <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 <del> (TPMs), or BIOS firmware. </del> <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
Change:
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

Discussion:
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
Change:
`
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:

Discussion:
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> <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.
Change:
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."

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
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"

Discussion:
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,
Change:
maybe unclear if this was what was intended
massaged the change a bit to retain the previous statement better
` I'm not convinced this analogy is helpful. Yes, it conveys the need for detailed information but it also immediately suggests Attestation Results might include PII or privacy sensitive identifiers.
I agree that the analogy to physical passports is misleading. The paragraph tries to justify AR as being detailed and privacy sensitive then in the next paragraph tries to describe them as not needing to be too specific; "Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence." It is sufficient to say that both Evidence and Attestation Results can contain privacy sensitive content. The Attester may rely on the Verifier to obfuscate privacy sensitive Claims that were shared as part of Evidence.
It should be clear that appraising Evidence involves various procedures that are part of the appraisal and that these can be quite resource intensive (like creating a passport), in contrast to Attestation Results that are intended to be easily digestible and universal understood (like using a passport)!
add, "URL contain privacy sensitive information as discussed in section {Privacy}"

Discussion:
expected values, or to apply complex analysis of other information contained in the Attestation Result. <del> Thus, Attestation Results often need to include detailed information about the Attester, for use by Relying Parties, much like physical passports and drivers licenses include personal information such as name and date of birth.  Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. </del> <ins> Thus, Attestation Results can contain detailed information about an Attester, which can include privacy sensitive information as discussed in section privacy-considerations.  Unlike Evidence, which is often very device- and vendor-specific, Attestation Results can be vendor-neutral, if the Verifier has a way to generate vendor-agnostic information based on the appraisal of vendor-specific information in Evidence.  This allows a Relying Party's appraisal policy to be simpler, potentially based on standard ways of expressing the information, while still allowing interoperability with heterogeneous devices. </ins> Finally, whereas Evidence is signed by the device (or indirectly by a manufacturer, if Endorsements are used), Attestation Results are
Change:
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

Discussion:
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> <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
Change:
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.

Discussion:
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> <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
Change:
** 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.

Discussion:
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
Change:
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".

Discussion:
attestation defined by RATS is thus a candidate for use in the FIDO protocol. <del> Every FIDO Authenticator contains an Attester. </del> <ins> FIDO Authenticator. </ins> Any web site, mobile application back-end, or service that relies on authentication data based on biometric information.
Change:
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."

Discussion:
12.4. As noted in trustmodel, Verifiers and Relying Parties have trust <del> anchor stores that must be secured.  Specifically, a trust anchor </del> <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.
Change:
purpose statement into beginning of Security Considerations. I moved the statement to the beginning of section 12, but maybe some wanted it moved to the beginning of 12.1.
** Section 12.1.1 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. Is it more accurate to say that an "A foundational security assumption of a RATS architecture is that a Relying Party is able to trust the Attester even if the user or owner is not trusted"
Section 12.1.1 Is it more accurate to say that an "A foundational security assumption of a RATS architecture is that a Relying Party is able to trust the Attester even if the user or owner is not trusted" I think the statement is closer to "A foundational security assumption of a RATS architecture it that a Relying Party is able to establish the basis for trusting the Attester functions, or Attester users.
Remove word "assumption", as this is an input, and we are talking about the output. move this sentence to the beginning of that section. "The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester."

Discussion:
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 <del> 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). </del> <ins> 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). The fundamental purpose of the RATS architecture is to allow a Relying Party to establish a basis for trusting the Attester. </ins> 12.1.

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 <del> 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. </del> <ins> authenticator. </ins> Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and