jiebi/CodeConvo huggingface dataset:
Change:
Signed-off-by: Dave Thaler
** Section 12.2 Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or appraisal policy ... Should reference values be included?
same changes, conceptual messages

Discussion:
value of specific Claims if it knew that only certain values were accepted by the Relying Party. <del> 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. </del> <ins> Conceptual messages (see 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

12.2. <del> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or appraisal policy must support end-to-end integrity protection and replay attack prevention, and often also needs to support additional security properties, including: </del> <ins> Any solution that conveys information in any conceptual message (see messages) must support end-to-end integrity protection and replay attack prevention, and often also needs to support additional security properties, including: </ins> end-to-end encryption,

Security protections in RATS may be applied at different layers, whether by a conveyance protocol, or an information encoding format. <del> This architecture expects conceptual messages (see messages) to be end-to-end protected based on the role interaction context.  For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence. </del> <ins> This architecture expects conceptual messages to be end-to-end protected based on the role interaction context.  For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence. </ins> 12.3.
Change:
Section 10 first paragraph has the phrase "Claims and their values "; which is redundant. "Claims" is sufficient.

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

Discussion:
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> <ins> revocation.  For an example of such a proceedure see Section 6 of RFC5280. </ins> 13.
Change:
related to There is something foundational I am not following about this section. The interactions described here do not conform behaviors described in the terminology in Section 4 or the high-level reference architecture of Figure 1. I'm not sure how to reconcile this discrepancy. Minimally, these discrepancies in Figure 5 and 6 are not consistent with the roles defined in Section 4. [restated here but same feedback on -13] -- Figure 5. Shows the Attester consuming Attestation Results -- Figure 5. Shows the Attester producing Attestation Results -- Figure 6: Shows Relying party consuming Evidence -- Figure 6: Shows the Relying Party producing/passing Evidence The introductory text states that "[t]he discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns." I don't follow what is being illustrated in the context of RATS. What is the takeaway for implementers or designers from this section? [Author's response] URL [Roman's response on -15] The above github comment addressed a few issues from the -13 review, but not this one.
Reply by email: "The Attester does not consume the Attestation Result, but might cache it. "
The text explains the intent correctly regardless of how the lines are drawn. I can convince myself that it is correct draw the line through the box (or not). The important clarifying point should be that the end-to-end message flow as described in the conceptual architecture is preserved through the various topology models that may exist. Second point is there can be a large variety of topology models (aka hybrids) but none of these hybrids changes the expectation of end-to-end message flow.
also helps.

Discussion:
Evidence, and again needs to take into account the maximum permitted clock skew between the Verifier and the Attester. <ins> The Attester does not consume the Attestation Result, but might cache it. </ins> The Relying Party can check whether the Attestation Result is fresh when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v) < Threshold", where the Relying Party's threshold is large enough to

The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized <del> clocks between the Attester, Verifier, and Relying Party. </del> <ins> clocks between the Attester, Verifier, and Relying Party.  The Attester conveys Evidence to the Relying Party, which treats it as opaque and simply forwards it on to the Verifier. </ins> The time considerations in this example are equivalent to those discussed under Example 1 above.
Change:
Despite fixes in , Roman asks: [Roman's comments on -13] -- Section 4.1. In the definition of relying party, what does the sentence fragment "Compare /relying party/ in [RFC4949]" mean? -- Section 4.2. Per the definition of "Claim", what does "Compare /claim/ in [RFC7519]" mean? -- Section 4.2. Per the definition of "Appraisal Policy for Attestation Results", what does "Compare /security policy/ in [RFC4949]" mean? I continue to hold the position that this language "Compare /xxx/ in RFC####" is not clear. In the natural language sense, that phrase doesn't parse. If the semantics are being taken from Section 2.6 of RFC4949, please explain that. However, it seems confusing to explicitly be listing antonyms (which RF4949 suggests is the meaning of the "Compare" notation). In the case of a claim, is it an antonym -- isn't a claim here in fact similar to the one in Section 2 of RFC7519?
`

Discussion:
4. <ins> RFC4949 has defined a number of terms that are also used in this document.  Some of the terms are close to, but not exactly the same. Where the terms are similar, they are noted below with references. As explained in RFC4949, Section 2.6 when this document says "Compare:", the terminology used in this document differs significantly from the definition in the reference. </ins> This document uses the following terms. 4.1.

A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying <del> application specific actions.  Compare /relying party/ in RFC4949. </del> <ins> application specific actions.  Compare: /relying party/ in RFC4949. </ins> Consumes: Attestation Results, Appraisal Policy for Attestation Results

A piece of asserted information, often in the form of a name/value pair.  Claims make up the usual structure of Evidence and other <del> RATS artifacts.  Compare /claim/ in RFC7519. </del> <ins> RATS artifacts.  Compare: /claim/ in RFC7519. </ins> A secure statement that an Endorser vouches for the integrity of an Attester's various capabilities such as Claims collection and

Produced By: Verifier A set of rules that informs how a Verifier evaluates the validity <del> of information about an Attester.  Compare /security policy/ in </del> <ins> of information about an Attester.  Compare: /security policy/ in </ins> RFC4949. Consumed By: Verifier

A set of rules that direct how a Relying Party uses the Attestation Results regarding an Attester generated by the <del> Verifiers.  Compare /security policy/ in RFC4949. </del> <ins> Verifiers.  Compare: /security policy/ in RFC4949. </ins> Consumed by: Relying Party
Change:
insert text suggested by Roman about how deep down the security properties
[github said: URL] ==[ snip ]== We need to acknowledge that there is a deep hole (not infinitely deep, but not trivial) where we need to look at integrity of all of the different platforms. The way that the compositions are composed is a bit tricky, and the results are sometimes different than other people would naively assume. Are there references here to other papers that we should include? ==[ snip ]== I completely agree, that's why I mentioned it. Composition is hard and can alter the security assumptions of the individual components and introduce emergent risk. I don't think it can be solved generically. However, we do need cautionary text here. Perhaps: NEW (roughly) The RATS architecture allows for an entity to function in multiple roles (Section 6) and for composite devices (Section 3.3). Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still holds despite the lack of separation, and that emergent risk is not introduced. The specifics of this evaluation will depend on the implementation and use case is out of scope for this document.

Discussion:
then the relaying entity should not expect to have access to the Evidence. <del> 12.3. </del> <ins> The RATS architecture allows for an entity to function in multiple roles (rolesentities) and for composite devices (compositedevice). Implementers need to evaluate their designs to ensure that the assumed security properties of the individual components and roles still hold despite the lack of separation, and that emergent risk is not introduced.  The specifics of this evaluation will depend on the implementation and the use case and hence is out of scope for this document.  Isolation mechanisms in software or hardware that separate Attesting Environments and Target Environments twotypes can support an implementer's evaluation and resulting design decisions.  ## Epoch ID-based Attestation {#epochids-sec} </ins> Epoch IDs, described in epochfreshness, can be tampered with, replayed, dropped, delayed, and reordered by an attacker.

provides the ability to detect reordering and drop.  However, the delay attack described above can't be thwarted in this manner. <del> 12.4. </del> <ins> 12.3. </ins> As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  RFC6024 contains more discussion
Change:
The Relying Party role is assigned to entities that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions. should be >The Relying Party role is assigned to entities that use Attestation Results by applying their own appraisal policies to make application-specific decisions, such as authorization decisions. or >The Relying Party role is assigned to an entity that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions.
I'm in favor of the second option: The Relying Party role is assigned to an entity that uses Attestation Results by applying its own appraisal policy to make application-specific decisions, such as authorization decisions.
I am okay with second option.

Discussion:
Verifier by the Verifier Owner, or might be programmed into the Verifier, or might be obtained via some other mechanism. <del> The Relying Party role is assigned to entities that uses Attestation </del> <ins> The Relying Party role is assigned to an entity that uses Attestation </ins> Results by applying its own appraisal policy to make application- specific decisions, such as authorization decisions.  This procedure is called the appraisal of Attestation Results.
Change:
You want to say "Certification Authority" not "Certificate Authority"
yeah. thanks for catching that!

Discussion:
Thus, trusting a Verifier might be expressed by having the Relying Party store the Verifier's key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate <del> of an entity (e.g., a Certificate Authority) that is in the </del> <ins> of an entity (e.g., a Certification Authority) that is in the </ins> Verifier's certificate path.  For example, the Relying Party can verify that the Verifier is an expected one by out-of-band establishment of key material, combined with a protocol like TLS to
Change:
Incorporates both text from birkholz arch draft and thaler arch draft. Avoids using normative language per IETF 106 discussion. Signed-off-by: Dave Thaler
The Birkholz draft had the idea of roles to describe higher level concepts (independent of transport layer security considerations). It also defined "Actors" that focused on trust model relationships (and their fungibility). Also a higher-layer concept from transport layer security considerations. Each section in the arch spec addresses security considerations appropriate for the level of abstraction. Maybe this security considerations is aimed at transport level security considerations?

Discussion:
11. <ins> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, or Endorsements, or Appraisal Policy, needs to support end- to-end integrity protection and replay attack prevention, and often also needs to support additional security protections.  For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many use cases. To evaluate the security provided by a particular Appraisal Policy, it is important to understand the strength of the Root of Trust, e.g., whether it is mutable software, or firmware that is read-only after boot, or immutable hardware/ROM. It is also important that the Appraisal Policy was itself obtained securely.  As such, if Appraisal Policy in a Relying Party or Verifier can be configured via a network protocol, the ability to attest to the health of the client providing the Appraisal Policy needs to be considered. </ins> 12. This document does not require any actions by IANA.
Change:
Provide forward references Use "measure" in English text Signed-off-by: Dave Thaler
(I had to do this right away before I forgot what I was suggesting during the meeting :)

Discussion:
An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations <del> might have multiple Attesting and Target Environments.  One example is a set of components in a boot sequence (e.g., ROM, firmware, OS, and application) where a Target Environment is the Attesting Environment for the next environment in the boot sequence. Another example is that of a Composite Devices: Composite Devices are defined below, and are inherently composed of multiple nested environments. </del> <ins> might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and compositeattester.  Other examples may exist, and the examples discussed could even be combined into even more complex implementations. </ins> Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be <del> represented in claims.  Attesting Environments then format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence. Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </del> <ins> represented in claims, such as by doing some measurement of a Target Environment's code, memory, and/or registers.  Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </ins> 4.2.
Change:
describe the basic Topological Model without complicating the draft
I am uncertain about the state of this PR. NAME were your comments addressed?
~ In both the passport and background-check models, the Attester communicates directly with the Relying Party to access some resources. But in some cases, the Attester doesn't need to access resources from the Relying Party. Assume that the Attester is a network device (router, switch, etc.), and the Relying Party is the network management system (NMS) of the network operator. In such a case, the NMS monitors the health of the device by retrieving the Attestation Result of the device from a Verifier. If the device fails the attestation process, the NMS can take countermeasures like quarantining it. So the figure above depicts this situation.
Is this topological model covered by the passport model or background-check model?
The above flow is always the information flow. The passport model and background-check are models for how the conveyance works.
Also, we had that diagram in the architecture documents, and we have the above diagram as figure 1 already.
This is also a way in which the conveyance can work. I add two sentences to describe this basic one without duplicating the diagram.
We conclude that there is not a need for this additional topological flow.

Discussion:
5. <del> There are multiple possible models for communication between an Attester, a Verifier, and a Relying Party.  This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist. </del> <ins> dataflow shows a basic model for communication between an Attester, a Verifier, and a Relying Party.  The Attester sends its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Results from the Verifier.  There are multiple other possible models.  This section includes some reference models, but this is not intended to be a restrictive list, and other variations may exist. </ins> 5.1.
Change:
Signed-off-by: Dave Thaler
I don't understand the text Ned added. Suggest moving it to a separate PR.
The existing text listed HSM and TEE as examples of Attesting Environments. However, an HSM that only provides crypto acceleration and key storage wasn’t designed for claims collection. Therefore, it isn’t an Attesting Environment (necessarily). The text I added explains that the Attesting Environment is designed in such a way that it is capable of claims collection. For example, if the HSM was designed to have exposed a shared memory region that is shared with the Target Environment’s executable code pages.
Will fix broken kramdown after pull.
Approve of the changes. But also have an additional comment suggested change.

Discussion:
discussed could even be combined into even more complex implementations. <del> Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be represented in claims, such as by doing some measurement of a Target Environment's code, memory, and/or registers.  Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </del> <ins> Claims are collected from Target Environments, as shown in twotypes- env.  That is, Attesting Environments collect the raw values and the information to be represented in claims, such as by doing some measurement of a Target Environment's code, memory, and/or registers. Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Places that Attesting Environments can exist include 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.  Attesting Environments are designed specifically with claims collection in mind. </ins> 4.2.
Change:
I think we must define claim in the terminology section. The term claim originates from JWT, but JWT doesn't really define it.
The fact that "claim" is used throughout both RFC 7519 (JWT) and RFC 8392 (CWT) without any formal definition, means that it's clearly ok to have an RFC that does not define claim in its terminology section or anywhere else. I would favor following those precedents and not trying to retroactively invent some definition we have to agree on.
URL defines Claim as: Claim A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value.
If the term is defined elsewhere, is that definition used consistently with ours? Claim A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value. URL Claim: : A piece of information asserted about a subject. (consistently with {{RFC7519}}) A claim is usually represented by as a name/value pair.

Discussion:
deciding whether the entity is authorized to perform some operation <ins> A piece of asserted information, often in the form of a name/value pair.  (Compare /claim/ in RFC7519) </ins> A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability