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

Discussion:
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> <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 <del> Attesting Environment(s) that collected claims about the Target </del> <ins> Attesting Environment(s) that collected Claims about the Target </ins> Environment(s). All unprotected Evidence that is conveyed is supplied exclusively
Change:
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.

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

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

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

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

Discussion:
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.
Change:
The list in sec 3.2 didn't render properly. Also fix Pete's surname which got garbled for some reason.

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

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

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

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

Discussion:
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 <del> specific to Claims and implementations.  This architecture document does not define any general purpose format for them or general means for comparison. </del> <ins> specific to Claims and implementations. </ins> 3.3.
Change:
Signed-off-by: Dave Thaler
What is the “it” in “That is, it”

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

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

Discussion:
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. <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
Change:
Many of the things that we are writing in the security considerations are really security requirements on implementations, rather than concerns with the architecture.

Discussion:
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
Change:
What is that sentence trying to tell me? Control over which keys? Not the attestation keys, I think.

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

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

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