The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a <del> device as well as potentially any users of the device.  In many cases, the whole point of attestation procedures is to provide reliable information about the type of the device and the firmware/ software that the device is running.  This information might be particularly interesting to many attackers.  For example, knowing that a device is running a weak version of firmware provides a way to aim attacks better. 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. </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 boot, or immutable hardware/ROM. It is also important that the appraisal policy was itself obtained <del> securely.  If an attacker can configure appraisal policies for a Relying Party or for a Verifier, then integrity of the process is compromised. </del>  Security protections in RATS may be applied at different layers, whether by a conveyance protocol, or an information encoding format.

May be duplicated by dthaler pull request , second part might belong in privacy considerations instead of here. NAME to redraft.
** Section 12.2 It is also important that the appraisal policy was itself obtained securely. If an attacker can configure appraisal policies for a Relying Party or for a Verifier, then integrity of the process is compromised. In addition to reconfiguration, wouldn't the ability to intercept either the appraisal policy for evidence or attestation results potentially provide the attacker insight into defensive mitigations? This suggests that this policy might need confidentiality protection.
see .
Maybe fixed this one along with
-- The overall Section 12 seems silent on: o Endorsers and endorsements? o Reference values? o What is the implication of combining roles into a single entity as described in Section 3.4 and 6. Does this lack of separation present any additional issues? o Compositional devices per Section 3.3?
"If an attacker can modify appraisal policies, Endorsements, or Reference Values, then integrity of the process is compromised."
`
maybe already fixed with recent changes
maybe helps?

The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a  <ins> device as well as potentially any users of the device. In many cases, the whole point of attestation procedures is to provide reliable information about the type of the device and the firmware/software that the device is running. This information might be particularly interesting to many attackers. For example, knowing that a device is running a weak version of firmware provides a way to aim attacks better. In some circumstances, if an attacker can become aware of Endorsements, Reference Values, or appraisal policies, it could potentially provide an attacker with insight into defensive mitigations.  It is recommended that attention be paid to confidentiality of such information. Additionally, 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 boot, or immutable hardware/ROM. It is also important that the appraisal policy was itself obtained  <ins> securely.  If an attacker can configure or modify appraisal policies, Endorsements or Reference Values for a Relying Party or for a Verifier, then integrity of the process is compromised. </ins> Security protections in RATS may be applied at different layers, whether by a conveyance protocol, or an information encoding format.


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>  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>  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>  12.3.

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

value of specific Claims if it knew that only certain values were accepted by the Relying Party.  <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.  <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.  <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.


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.

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

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.


devices from getting access to the network and potentially harming others. <del> Typically, solutions start with a specific component (called a root of trust) that is intended to provide trustworthy device identity and protected storage for measurements.  The system components perform a series of measurements that may be signed via functions provided by a root of trust, considered as Evidence about present system components, such as hardware, firmware, BIOS, software, etc. </del>  A device desiring access to a network. 3.2. By definition, the Attester role generates Evidence.  An Attester may <del> consist of one or more nested environments (layers).  The root layer of an Attester includes at least one root of trust.  In order to appraise Evidence generated by an Attester, the Verifier needs to trust the Attester's root of trust.  Trust in the Attester's root of trust can be established in various ways as discussed in verifier. In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer.  Claims about a root of trust typically are asserted by an Endorser. </del>  The example device illustrated in layered includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system by the Attesting Environment that has the key material that protects the conveyance channel <del> The root of trust protects both the conveyance channel key material and the Attesting Environment with equivalent strength protections. </del>  As illustrated in I-D.birkholz-rats-uccs, an entity that receives unprotected Evidence via a trusted conveyance channel always takes on

Reworded sections containing root of trust leaving a single parenthetical that associates the term loosely with an attesting environment that is implicitly trusted.
It makes sense to remove the term 'root of trust' since the document doesn't define it. It might make sense to reference other industry specs that have relevant definitions such as NISTIR 8320A.
NAME apparently, this taks has no assignees. Do you want to do that?
OK, assign it to me.

devices from getting access to the network and potentially harming others.  <ins> Typically, a trustworthy solution starts with a specific component (sometimes referred to as a root of trust) that often provides trustworthy device identity, and performs a series of operations that enables trustworthiness appraisals for other components.  Such components perform operations that help determine the trustworthiness of yet other components, by collecting, protecting or signing measurements.  Measurements that have been signed by such components comprise Evidence that when evaluated either supports or refutes a claim of trustworthiness.  Measurements can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc. </ins> A device desiring access to a network. 3.2. By definition, the Attester role generates Evidence.  An Attester may  <ins> consist of one or more nested environments (layers).  The bottom layer of an Attester has an Attesting Environment that is typically designed to be immutable or difficult to modify by malicious code. In order to appraise Evidence generated by an Attester, the Verifier needs to trust various layers, including the bottom Attesting Environment.  Trust in the Attester's layers, including the bottom layer, can be established in various ways as discussed in verifier. In layered attestation, Claims can be collected from or about each layer beginning with an initial layer.  The corresponding Claims can be 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. Claims about an initial layer typically are asserted by an Endorser. </ins> The example device illustrated in layered includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system by the Attesting Environment that has the key material that protects the conveyance channel  <ins> A trusted environment protects the conveyance channel's key material which may depend on other Attesting Environments 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


independent of protocol or use case. The text below summarizes the activities conducted by the roles <del> illustrated in dataflow. </del>  <del> An Attester creates Evidence that is conveyed to a Verifier. </del>  <del> A Verifier uses the Evidence, any Reference Values from Reference Value Providers, and any Endorsements from Endorsers, by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester.  This procedure is called the appraisal of Evidence. </del>  <del> Subsequently, the Verifier generates Attestation Results for use by Relying Parties. </del>  The Appraisal Policy for Evidence might be obtained from the Verifier Owner via some protocol mechanism, or might be configured into the Verifier by the Verifier Owner, or might be programmed into the Verifier, or might be obtained via some other mechanism. <del> A Relying Party uses Attestation 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. </del>  The Appraisal Policy for Attestation Results might be obtained from the Relying Party Owner via some protocol mechanism, or might be some other mechanism. See messages for further discussion of the conceptual messages shown <del> in dataflow. </del>  3.1. As shown in twotypes-env, an Attester consists of at least one <del> Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and compositedevice.  Other examples may exist.  All compositions of Attesting and Target Environments discussed in this architecture can be combined into more complex implementations. </del>  Claims are collected from Target Environments.  That is, Attesting Environments collect the values and the information to be represented

The word 'device' is used dozens of times throughout the document. However, it often doesn't imply 'device' but rather a component of the device. RFC4949 defines 'system component' as: system component (I) A collection of system resources that (a) forms a physical or logical part of the system, (b) has specified functions and interfaces, and (c) is treated (e.g., by policies or specifications) as existing independently of other parts of the system. (See: subsystem.) (O) /ITSEC/ An identifiable and self-contained part of a TOE. Usage: Component is a relative term because components may be nested; i.e., one component of a system may be a part of another component of that system. Tutorial: Components can be characterized as follows: A "physical component" has mass and takes up space. A "logical component" is an abstraction used to manage and coordinate aspects of the physical environment, and typically represents a set of states or capabilities of the system. This definition seems appropriate for most of the places where 'device' is used. Alternatively, 'system' could be used if 'system component' would be to narrow.
I think that we struggled a lot to arrive at the compromise of saying "device". I agree with you that there are composite devices which contain "system components". But, if we do the direction of using that term, we will lose readers and lose comprehension. I do not agree with this proposal. If it is unclear that "device" is a role, then I guess we could add that to the Terminology.
If I were to be pedantic about what a device is using capital letter names, it is both, it's an entity (that performs the role). The Architecture is a description while normative drafts are more precise / formal descriptions or definitions. I don't feel strongly about it. But some people seem to feel strongly that device is used too much. Does it make sense to talk about how we use 'device' and refer to 4949 system component as being roughly equivalent?
We could say one time early in the text that we mean "system component" when we mean device, but for the sake of simplicity use device as a representative concept throughout the document.
Makes sense.

independent of protocol or use case. The text below summarizes the activities conducted by the roles  <ins> illustrated in dataflow.  Roles are assigned to entities.  Entities are often system components RFC4949, such as devices.  As the term device is typically more intuitive than the term entity or system component, device is often used as a illustrative synonym throughout this document. </ins>  <ins> The Attester role is assigned to entities that create Evidence that is conveyed to a Verifier. </ins>  <ins> The Verifier role is assigned to entities that use the Evidence, any Reference Values from Reference Value Providers, and any Endorsements from Endorsers, by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester.  This procedure is called the appraisal of Evidence. </ins>  <ins> Subsequently, the Verifier role generates Attestation Results for use by Relying Parties. </ins> The Appraisal Policy for Evidence might be obtained from the Verifier Owner via some protocol mechanism, or might be configured into the Verifier by the Verifier Owner, or might be programmed into the Verifier, or might be obtained via some other mechanism.  <ins> 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.  This procedure is called the appraisal of Attestation Results. </ins> The Appraisal Policy for Attestation Results might be obtained from the Relying Party Owner via some protocol mechanism, or might be some other mechanism. See messages for further discussion of the conceptual messages shown  <ins> in dataflow.  Section terminology provides a more complete definition of all RATS roles. </ins> 3.1. As shown in twotypes-env, an Attester consists of at least one  <ins> Attesting Environment and at least one Target Environment co-located in one entity.  In some implementations, the Attesting and Target Environments might be combined into one environment.  Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and compositedevice.  Other examples may exist. All compositions of Attesting and Target Environments discussed in this architecture can be combined into more complex implementations. </ins> Claims are collected from Target Environments.  That is, Attesting Environments collect the values and the information to be represented


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.

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.

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.


In this model, an Attester conveys Evidence to a Verifier, which compares the Evidence against its appraisal policy.  The Verifier then gives back an Attestation Result which the Attester treats as <del> opaque data.  The Attester does not consume the Attestation Result, but might cache it.  The Attester can then present the Attestation Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy. </del>  Three ways in which the process may fail include: The resource access protocol between the Attester and Relying Party includes Evidence rather than an Attestation Result, but that <del> Evidence is not processed by the Relying Party.  Since the Evidence is merely forwarded on to a trusted Verifier, any serialization format can be used for Evidence because the Relying Party does not need a parser for it.  The only requirement is that the Evidence can be _encapsulated in_ the format required by the resource access protocol between the Attester and Relying Party. </del>  However, like in the Passport model, an Attestation Result is still consumed by the Relying Party.  Code footprint and attack surface

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.

In this model, an Attester conveys Evidence to a Verifier, which compares the Evidence against its appraisal policy.  The Verifier then gives back an Attestation Result which the Attester treats as  <ins> opaque data. The Attester does not consume the Attestation Result, but might cache it.  The Attester can then present the Attestation Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy.  The Attester may also present the same Attestation Result to other Relying Parties. </ins> Three ways in which the process may fail include: The resource access protocol between the Attester and Relying Party includes Evidence rather than an Attestation Result, but that  <ins> Evidence is not processed by the Relying Party. Since the Evidence is merely forwarded on to a trusted Verifier, any serialization format can be used for Evidence because the Relying Party does not need a parser for it.  The only requirement is that the Evidence can be _encapsulated in_ the format required by the resource access protocol between the Attester and Relying Party. </ins> However, like in the Passport model, an Attestation Result is still consumed by the Relying Party.  Code footprint and attack surface


Evidence, and again needs to take into account the maximum permitted clock skew between the Verifier and the Attester.  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>  The time considerations in this example are equivalent to those discussed under Example 1 above.

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


4.  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>  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>  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>  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>  Consumed by: Relying Party

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?
`

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  <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  <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  <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  <ins> Verifiers.  Compare: /security policy/ in RFC4949. </ins> Consumed by: Relying Party


Peter Loscocco contributed critical review feedback as part of the weekly design team meetings that added precision and depth to several sections. <del> 16. 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. 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 Universal Time timescale, or might be defined relative to some other timestamp or timeticks counter, such as a clock resetting its epoch each time it is powered on. Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. All times are relative to the local clocks, indicated by an "_a" (Attester), "_v" (Verifier), or "_r" (Relying Party) suffix. Times with an appended Prime (') indicate a second instance of the same event. How and if clocks are synchronized depends upon the model. 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. 16.1. The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party, which depends on using a secure clock synchronization mechanism.  As a result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps. 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 maximum permitted clock skew between the Verifier and the Attester. If time(VG_a) is also included in the Evidence along with the Claim value generated at that time, and the Verifier decides that it can trust the time(VG_a) value, the Verifier can also determine whether the Claim value is recent by checking "time(RG_v) - time(VG_a) < Threshold".  The threshold is decided by the Appraisal Policy for Evidence, and again needs to take into account the maximum permitted clock skew between the Verifier and the Attester. The Attester does not consume the Attestation Result, but might cache it. 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 account for the maximum permitted clock skew between the Relying Party and the Verifier.  The result might then be used for some time (e.g., throughout the lifetime of a connection established at time(RA_r)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold". However, if the Attestation Result contains an expiry time time(RX_v) then it could explicitly check "time(OP_r) < time(RX_v)". 16.2. The following example illustrates a hypothetical Passport Model solution that uses nonces instead of timestamps.  Compared to the timestamp-based example, it requires an extra round trip to retrieve a nonce, and requires that the Verifier and Relying Party track state to remember the nonce for some period of time. The advantage is that it does not require that any clocks are synchronized.  As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps.  Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver. In this example solution, the Verifier can check whether the Evidence is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) < Threshold". The Verifier cannot, however, simply rely on a Nonce to determine whether the value of a Claim is recent, since the Claim value might have been generated long before the nonce was sent by the Verifier. However, if the Verifier decides that the Attester can be trusted to correctly provide the delta "time(EG_a)-time(VG_a)", then it can determine recency by checking "time(RG_v)-time(NS_v) + time(EG_a)- time(VG_a) < Threshold". Similarly if, based on an Attestation Result from a Verifier it trusts, the Relying Party decides that the Attester can be trusted to correctly provide time deltas, then it can determine whether the Attestation Result is fresh by checking "time(OP_r)-time(NS_r) + time(RR_a)-time(EG_a) < Threshold".  Although the Nonce2 and "time(RR_a)-time(EG_a)" values cannot be inside the Attestation Result, they might be signed by the Attester such that the Attestation Result vouches for the Attester's signing capability. The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a validity lifetime in terms of "time(RX_v)-time(RG_v)", then the Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)". 16.3. The example in fig-epochid-passport illustrates a hypothetical Passport Model solution that uses epoch IDs instead of nonces or timestamps. The Epoch ID Distributor broadcasts epoch ID "I" which starts a new epoch "E" for a protocol participant upon reception at "time(IR)". The Attester generates Evidence incorporating epoch ID "I" and conveys it to the Verifier. The Verifier appraises that the received epoch ID "I" is "fresh" according to the definition provided in epochfreshness whereby retries are required in the case of mismatching epoch IDs, and generates an Attestation Result.  The Attestation Result is conveyed to the Attester. After the transmission of epoch ID "I'" a new epoch "E'" is established when "I'" is received by each protocol participant.  The Attester relays the Attestation Result obtained during epoch "E" (associated with epoch ID "I") to the Relying Party using the epoch ID for the current epoch "I'".  If the Relying Party had not yet received "I'", then the Attestation Result would be rejected, but in this example, it is received. In the illustrated scenario, the epoch ID for relaying an Attestation Result to the Relying Party is current, while a previous epoch ID was used to generate Verifier evaluated evidence.  This indicates that at least one epoch transition has occurred, and the Attestation Results may only be as fresh as the previous epoch.  If the Relying Party remembers the previous epoch ID "I" 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. 16.4. The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized 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. The time considerations in this example are equivalent to those discussed under Example 1 above. 16.5. The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any clocks are synchronized.  In this example solution, a nonce is generated by a Verifier at the request of a Relying Party, when the Relying Party needs to send one to an Attester. The Verifier can check whether the Evidence is fresh, and whether a Claim value is recent, the same as in Example 2 above. However, unlike in Example 2, the Relying Party can use the Nonce to determine whether the Attestation Result is fresh, by verifying that "time(OP_r)-time(NR_r) < Threshold". The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a validity lifetime in terms of "time(RX_v)-time(RG_v)", then the Relying Party can check "time(OP_r)-time(ER_r) < time(RX_v)- time(RG_v)". </del>

fix appendix to actually be back matter.
One editorial matter that got introduced somewhere after -15, please make this a proper appendix. It's currently " 16. Appendix A: Time Considerations", that is, Section 16 with word "appendix" in the title. Perhaps this is a rendering issue.


then the relaying entity should not expect to have access to the Evidence. <del> 12.3. </del>  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>  As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  RFC6024 contains more discussion

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.

then the relaying entity should not expect to have access to the Evidence.  <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.  <ins> 12.3. </ins> As noted in trustmodel, Verifiers and Relying Parties have trust anchor stores that must be secured.  RFC6024 contains more 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>  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.

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.

Verifier by the Verifier Owner, or might be programmed into the Verifier, or might be obtained via some other mechanism.  <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.


trustworthiness appraisals for other components.  Such components perform operations that help determine the trustworthiness of yet other components, by collecting, protecting or signing measurements. <del> Measurements that have been signed by such components comprise Evidence that when evaluated either supports or refutes a claim of </del>  trustworthiness.  Measurements can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc. artifact means that a given role introduces it into the RATS architecture.  To consume an artifact means that a given role has responsibility for processing it in the RATS architecture.  Roles <del> also have the ability to perform additional actions such caching or forwarding artifacts as opaque data.  As depicted in overview, these additional actions can be performed by several roles. </del>  4.

The review is at: URL The review is positive, but asks for: `
I'm not sure how, in an abstract architecture, we can mitigate against timing attacks. A specific protocol could propose mechanisms to defeat traffic analysis, but I don't think that the architecture can do this. Other typos handled. Reviewer: Shawn Emery Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft specifies architectures and terminology for Remote ATtestation procedureS (RATS), which consists of, at a high-level overview, an Attester (which forwards claimant information), Verifier (that analyzes the claims sent from the Attester), and Relying Party (who receives the verification information and determines if the Attester adheres to the relying party’s policy before allowing access/operations to the targeted resource(s)). The draft also has a privacy section that covers the areas of sensitive data within the architecture; e.g. attestation results: which could consist of the type of firmware/software used, PII, etc. that the attester is claiming for. Confidentiality is recommended against these potential types of attacks. Even if confidentiality is provided, the section goes on to state that information can still be inferred by contextual or timing of the attestor exchange. The draft doesn’t describe ways to mitigate against this type of attack but should give some guidance. The section closes out with mitigating against trust with confidential information to the Verifier, in which the Attester can switch roles to a Relying Party where it requests attestation results from the Verifier or claimant information can be attested anonymously. I believe that the privacy aspects of the draft are comprehensive and mitigations prescribed, except for the contextual and timing attacks, are reasonable. The security considerations section exists and appropriately defers specific mitigations as this draft is an architectural document devoid of the multitude of use-cases that employ said architecture. However, the section does provide guidance on the various ways to attack the premise of the architecture: provide a foundation that allows the Relying Party to trust the Attester and their claims. Areas that are covered in this regards are: Protecting the attester (on or off device) and their key generation and protection Protecting message confidentiality, integrity, availability, authentication, authorization, auditing, trustworthiness, and thwarting replay. I believe that this section, as well, is comprehensive and accurately describes ways of mitigating against the corresponding attacks: Replay: freshness (e.g. epoch IDs and its limitations against delay attacks thereof (could you list ways of mitigating against delay attacks in section ?)) Trustworthiness: root of trust, secured trust anchors, and sw/hw compartmentalization CIA: End-to-end protection which also in turn references relevant RFCs/NIST SP to do so. General comments: Thank you for the privacy considerations section. Editorial comments: s/comprise Evidence/comprise of Evidence/ s/Section Section 4/Section 4/ s/such caching/such as caching/ s/where the Verifier/whether the Verifier/ s/for ever/forever/

trustworthiness appraisals for other components.  Such components perform operations that help determine the trustworthiness of yet other components, by collecting, protecting or signing measurements.  <ins> Measurements that have been signed by such components are comprised of Evidence that when evaluated either supports or refutes a claim of </ins> trustworthiness.  Measurements can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc. artifact means that a given role introduces it into the RATS architecture.  To consume an artifact means that a given role has responsibility for processing it in the RATS architecture.  Roles  <ins> also have the ability to perform additional actions such as caching or forwarding artifacts as opaque data.  As depicted in overview, these additional actions can be performed by several roles. </ins> 4.


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>  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

You want to say "Certification Authority" not "Certificate Authority"
yeah. thanks for catching that!

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  <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


4.1.  A Composite Attester is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by evaluating all these sub-entities.  Each sub-entity has at least one Attesting 6. <del> 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 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. Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be 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). 7. </del> The scope of this document is scenarios for which a Relying Party trusts a Verifier that can evaluate the trustworthiness of information about an Attester.  Such trust might come by the Relying background-check model, this Evidence may also be revealed to Relying Party(s). <del> 8. </del>  <del> 8.1. </del>  Today, Evidence tends to be highly device-specific, since the information in the Evidence often includes vendor-specific isolation would require Appraisal Policy to be based on device- specific details (e.g., a device public key). <del> 8.2. </del>  An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing may need device-specific information such as a public key for the device or component or user on the device. <del> 8.3. </del>  Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy.  A result that indicates non-compliance relationship with one entity, rather than a larger set of entities, for purposes of its Appraisal Policy. <del> 9. </del>  The following diagram illustrates a relationship to which attestation is desired to be added: Evidence that encodes claims in one format, while issuing Attestation Results that encode claims in a different format. <del> 10. </del>  It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct. have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. <del> 11. </del>  The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a for detailing what kinds of information are disclosed, and to whom they are exposed. <del> 12. </del>  Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation attest to the health of the client providing the Appraisal Policy needs to be considered. <del> 13. </del>  This document does not require any actions by IANA. <del> 14. </del>  Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,

Addresses issue There's no text changes in this PR, text is just moved without modification. Signed-off-by: Dave Thaler
otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand. Or, at least, have some general introduction or reference to section 6 about what is relation between them.
Agree, Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester". Something needs to change either move section 6 up, or section 4.1 down.

4.1. <ins> 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 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. Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be 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). 4.2. </ins> A Composite Attester is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by evaluating all these sub-entities.  Each sub-entity has at least one Attesting 6.  The scope of this document is scenarios for which a Relying Party trusts a Verifier that can evaluate the trustworthiness of information about an Attester.  Such trust might come by the Relying background-check model, this Evidence may also be revealed to Relying Party(s).  <ins> 7. </ins>  <ins> 7.1. </ins> Today, Evidence tends to be highly device-specific, since the information in the Evidence often includes vendor-specific isolation would require Appraisal Policy to be based on device- specific details (e.g., a device public key).  <ins> 7.2. </ins> An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing may need device-specific information such as a public key for the device or component or user on the device.  <ins> 7.3. </ins> Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy.  A result that indicates non-compliance relationship with one entity, rather than a larger set of entities, for purposes of its Appraisal Policy.  <ins> 8. </ins> The following diagram illustrates a relationship to which attestation is desired to be added: Evidence that encodes claims in one format, while issuing Attestation Results that encode claims in a different format.  <ins> 9. </ins> It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct. have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot.  <ins> 10. </ins> The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a for detailing what kinds of information are disclosed, and to whom they are exposed.  <ins> 11. </ins> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation attest to the health of the client providing the Appraisal Policy needs to be considered.  <ins> 12. </ins> This document does not require any actions by IANA.  <ins> 13. </ins> Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,


11.  12. This document does not require any actions by IANA.

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?

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.


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>  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>  4.2.

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 :)

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


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>  5.1.

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.

5.  <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.


and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and <del> compositeattester.  Other examples may exist, and the examples </del>  discussed could even be combined into even more complex implementations. 4.3. <del> A Composite Attester is an entity composed of multiple sub-entities </del>  such that its trustworthiness has to be determined by the appraisal <del> of all these sub-entities.  Each sub-entity has at least one Attesting Environment collecting the claims from at least one Target Environment, then this sub-entity generates Evidence about its trustworthiness.  Therefore each sub-entity can be called an Attester.  Among these Attesters, there may be only some, which can be called Lead Attesters, that have the ability to communicate with the Verifier.  Other Attesters don't have this ability, but they are connected to the Lead Attesters via internal links or network connections, and they are appraised by the Lead Attester's. For example, a carrier-grade router is a composite device consisting of a chassis and multiple slots.  The trustworthiness of the router depends on all its slots' trustworthiness.  Each slot has an Attesting Environment such as a TEE collecting the claims of its boot process, after which it generates Evidence from the claims.  Among these slots, only a main slot can communicate with the Verifier while other slots cannot.  But other slots can communicate with the main slot by the links between them inside the router.  So the main slot collects the Evidence of other slots, produces the final Evidence of the whole router and conveys the final Evidence to the Verifier. Therefore the router is a Composite Attester, each slot is an Attester, and the main slot is the Lead Attester. </del>  Another example is a multi-chassis router composed of multiple single carrier-grade routers.  The multi-chassis router provides higher treated as one router for simpler management.  Among these routers, there is only one main router that connects to the Verifier.  Other routers are only connected to the main router by the network cables, <del> and therefore they are managed and appraised via this main router. So, in this case, the multi-chassis router is the Composite Attester, each router is an Attester and the main router is the Lead Attester. </del>  composite depicts the conceptual data flow for a Composite Device. 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 </del>  Attesters and then generates the Evidence of the whole Composite Attester. <del> The Lead Attester's Attesting Environment may or may not include its own Verifier.  The first variant is that the Attesting Environment has no local Verifier.  In this variant, the Lead Attesting Environment simply combines the various Evidences into the final Evidence that is sent off to the remote Verifier, which appraises the trustworthiness of the Composite Device, including the Lead Attester's and other Attesters' trustworthiness. The second variant is that the Lead Attesting Environment has a local Verifier.  After collecting the Evidence of other Attesters, this Attesting Environment appraises them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier).  The Lead Attesting Environment combines the Attestation Results into the final Evidence of the whole Composite Attester which is sent off to the remote Verifier, which may treat the Claims obtained from the local Attestation Results as if they were Evidence.  In this situation, the trust model described in trustmodel is also suitable for the local Verifier. </del>  5.

This changes may of the Composite Attester->Composite Device. It updates the diagram a bit, but it does not go as far as . The terms "lead Attester" are retained, but not as new term ("lead", not "Lead"). The Attesting Environment is not pluralized.

and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments, such as in the examples described in more detail in layered-attestation and  <ins> compositedevice.  Other examples may exist, and the examples </ins> discussed could even be combined into even more complex implementations. 4.3.  <ins> A Composite Device is an entity composed of multiple sub-entities </ins> such that its trustworthiness has to be determined by the appraisal  <ins> of all these sub-entities. Each sub-entity has at least one Attesting Environment collecting the claims from at least one Target Environment, then this sub-entity generates Evidence about its trustworthiness.  Therefore each sub- entity can be called an Attester.  Among all the Attesters, there may be only some which have the ability to communicate with the Verifier while others do not. For example, a carrier-grade router is consists of a chassis and multiple slots.  The trustworthiness of the router depends on all its slots' trustworthiness.  Each slot has an Attesting Environment such as a TEE collecting the claims of its boot process, after which it generates Evidence from the claims.  Among these slots, only a main slot can communicate with the Verifier while other slots cannot.  But other slots can communicate with the main slot by the links between them inside the router.  So the main slot collects the Evidence of other slots, produces the final Evidence of the whole router and conveys the final Evidence to the Verifier.  Therefore the router is a Composite Device, each slot is an Attester, and the main slot is the transiting Attester. </ins> Another example is a multi-chassis router composed of multiple single carrier-grade routers.  The multi-chassis router provides higher treated as one router for simpler management.  Among these routers, there is only one main router that connects to the Verifier.  Other routers are only connected to the main router by the network cables,  <ins> and therefore they are managed and appraised via this main router's help.  So, in this case, the multi-chassis router is the Composite Device, each router is an Attester and the main router is the lead Attester. </ins> composite depicts the conceptual data flow for a Composite Device. In the Composite Device, each Attester generates its own Evidence by its Attesting Environment(s) collecting the claims from its Target  <ins> Environment(s).  The lead Attester collects the Evidence of all other </ins> Attesters and then generates the Evidence of the whole Composite Attester.  <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 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 verifies them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier), to generate Attestation Results.  The inside Verifier then sends the Attestation Results of other Attesters, whether in the same conveyance protocol as the Evidence or not, to the outside Verifier. In this situation, the trust model described in trustmodel is also suitable for this inside Verifier. </ins> 5.


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>  4.2.

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.

discussed could even be combined into even more complex implementations.  <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.


deciding whether the entity is authorized to perform some operation  A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability

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.

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


have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot.  10. The conveyance of Evidence and the resulting Attestation Results Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade, Wei Pan, Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten.

Add time considerations into an appendix and reference it from the freshness section.
For readability, I have removed extraneous event times and only kept the ones used in the discussion after at least one diagram. My goal is to keep the discussion easy to understand and not include excess details or complexity that could be left to other docs.
NAME will look into additions around purple items. NAME to work on moving table to section 9 (freshness)

have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. <ins> A more detailed discussion with examples appears in time- considerations. </ins> 10. The conveyance of Evidence and the resulting Attestation Results Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade, Wei Pan, Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten. <ins> 14. 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 Coordinated Universal Time, or might be defined relative to some other timestamp or timeticks counter. We now walk through a number of hypothetical examples of how a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. 14.1. The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party, which depends on using a secure clock synchronization mechanism. The Verifier can check whether the Evidence is fresh when appraising it at time(RG) by checking "time(RG) - time(EG) < Threshold", where the Verifier's threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. If time(VG) is also included in the Evidence along with the claim value generated at that time, and the Verifier decides that it can trust the time(VG) value, the Verifier can also determine whether the claim value is recent by checking "time(RG) - time(VG) < Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. The Relying Party can check whether the Attestation Result is fresh when appraising it at time(RA) by checking "time(RA) - time(RG) < Threshold", where the Relying Party's threshold is large enough to account for the maximum permitted clock skew between the Relying Party and the Verifier. The result might then be used for some time (e.g., throughout the lifetime of a connection established at time(RA)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if the Attestation Result contains an expiry time time(RX) then it could explicitly check "time(OP) < time(RX)". 14.2. The following example illustrates a hypothetical Passport Model solution that uses nonces and thus does not require that any clocks are synchronized. In this example solution, the Verifier can check whether the Evidence is fresh at time(RG) by verifying that "time(RG) - time(NS) < Threshold". The Verifier cannot, however, simply rely on a Nonce to determine whether the value of a claim is recent, since the claim value might have been generated long before the nonce was sent by the Verifier. However, if the Verifier decides that the Attester can be trusted to correctly provide the delta time(EG)-time(VG), then it can determine recency by checking "time(RG)-time(NS) + time(EG)-time(VG) < Threshold". Similarly if, based on an Attestation Result from a Verifier it trusts, the Relying Party decides that the Attester can be trusted to correctly provide time deltas, then it can determine whether the Attestation Result is fresh by checking "time(OP) - time(NS') + time(RR)-time(EG) < Threshold".  Although the Nonce2 and time(RR)- time(EG) values cannot be inside the Attestation Result, they might be signed by the Attester such that the Attestation Result vouches for the Attester's signing capability. The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a validity lifetime in terms of time(RX)-time(RG), then the Relying Party can check "time(OP) - time(NS') < time(RX)-time(RG)". 14.3. The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party. The time considerations in this example are equivalent to those discussed under Example 1 above. 14.4. The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any clocks are synchronized.  In this example solution, a nonce is generated by a Verifier at the request of a Relying Party, when the Relying Party needs to send one to an Attester. The Verifier can check whether the Evidence is fresh, and whether a claim value is recent, the same as in Example 2 above. However, unlike in Example 2, the Relying Party can use the Nonce to determine whether the Attestation Result is fresh, by verifying that "time(OP) - time(NR) < Threshold". The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a validity lifetime in terms of time(RX)-time(RG), then the Relying Party can check "time(OP) - time(ER) < time(RX)-time(RG)". </ins>


roles and their interaction via conceptual messages.  Additionally, this document defines a universal set of terms that can be mapped to various existing and emerging Remote Attestation Procedures.  Common <del> role compositions and data flows, such as the "Passport Model" and the "Background-Check Model" are illustrated to enable readers of this document to map their current and emerging solutions to the architecture provided and the corresponding terminology defined.  A common terminology that provides a well-understood semantic meaning to the concepts, roles, and models in this document is vital to create semantic interoperability between solutions and across different platforms. </del>  Amongst other things, this document is about trust and trustworthiness.  Trust is a decision being made.  Trustworthiness is 6.  The scope of this document is scenarios for which a Relying Party trusts a Verifier that can appraise the trustworthiness of information about an Attester.  Such trust might come by the Relying the background-check model, this Evidence may also be revealed to Relying Party(s). <del> 7. </del>  <del> 7.1. </del>  Today, Evidence tends to be highly device-specific, since the information in the Evidence often includes vendor-specific isolation would require Appraisal Policy to be based on device- specific details (e.g., a device public key). <del> 7.2. </del>  An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing may need device-specific information such as a public key for the device or component or user on the device. <del> 7.3. </del>  Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy.  A result that indicates non-compliance relationship with one entity, rather than a larger set of entities, for purposes of its Appraisal Policy. <del> 8. </del>  The following diagram illustrates a relationship to which remote attestation is desired to be added: Evidence that encodes claims in one format, while issuing Attestation Results that encode claims in a different format. <del> 9. </del>  It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct. have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. <del> 10. </del>  The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a Results are responsible for detailing what kinds of information are disclosed, and to whom they are exposed. <del> 11. </del>  Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation roles, then the relaying entity should not expect to have access to the Evidence. <del> 12. </del>  This document does not require any actions by IANA. <del> 13. </del>  Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,

added 4.4 "Roles and Entities", also removed the last occurrence of the artifact "role composition", and retained section 4.3 as is and added the usage scenario from issue
The introduction section uses the phrase "role compositions and data flows" then mentions "Passport Model" as an example of a role composition. In section 4.3 on Composite Device the second to last section describes "combinations of roles" using an example involving a Composite Device. I think the architecture should have crisper understanding of two concepts a) "topological models" (as defined by the section 5 heading that describes Passport, BKC and Hybrid; b) "role composition" which ought to refer to the "combining of roles" by a given entity. The terms "role composition" and "combining of roles" are too similar for them to have different meanings and "role composition" as an alias for "topological models" is unnecessary. I suggest pulling the second to the last paragraph in section 4.3 into a new section 4.4 titled "Role Composition" that has a paragraph defining role composition conceptually followed by the paragraph taken from section 4.3. Suggested Text for section 4.4: RATS roles are implemented by entities (e.g., devices). A simple realization of the architecture associates a single role to a single entity; for example, the topological models described in section 5.1 and 5.2 follow this convention. However, entities may host multiple roles as a way to accommodate more sophisticated use cases and deployment scenarios. An entity that both connects to a wide-area network and to a system bus may play both Attester and Verifier roles. As a system bus entity, a Verifier consumes Evidence from other devices connected to the system bus that implement an Attester role. As a wide-area network connected entity, it may implement an Attester role. The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. Alternatively, attestation results might reflect an aggregation of system bus operational state claims in the form of Evidence. For example, in the Composite Device scenario, the lead Attester... Additionally, the introduction section should change "role composition" terminology to "topological models" as it references Passport.
"Role Composition" will be worked out of document.
Also addressed in Issue55. I recommend closing this issue.
"role composition" no longer appears in the doc. I agree this can be closed.
Taking into account the recent trends in terminology used in draft text & PR, I am proposing to add Entity and Sub-Entity to the terminology section. We do not need to over-specify here. Hence, only mentioning Composite Device and Components as an examplew for each of the terms in the definition text could be enough. Are there any objections to this proposal? If not, we could create a PR and address it in next week's meeting.
Agree so long as it is understood that other words can be used in place of entity when they add context for readability such as component, sub-component, device, environment and so forth.
This now relates to the comments on

roles and their interaction via conceptual messages.  Additionally, this document defines a universal set of terms that can be mapped to various existing and emerging Remote Attestation Procedures.  Common  <ins> topological models and the data flows associated with them, such as the "Passport Model" and the "Background-Check Model" are illustrated.  The purpose is to enable readers of this document to map their current and emerging solutions to the architecture provided and the corresponding terminology defined.  A common terminology that provides a well-understood semantic meaning to the concepts, roles, and models in this document is vital to create semantic interoperability between solutions and across different platforms. </ins> Amongst other things, this document is about trust and trustworthiness.  Trust is a decision being made.  Trustworthiness is 6. <ins> An entity in the RATS architecture includes at least one of the roles defined in this document.  As a result, the entity can participate as a constituent of the RATS architecture.  Additionally, an entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles.  In these cases, interaction between these roles do not necessarily use the Internet Protocol. They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. 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 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.  The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this document. 7. </ins> The scope of this document is scenarios for which a Relying Party trusts a Verifier that can appraise the trustworthiness of information about an Attester.  Such trust might come by the Relying the background-check model, this Evidence may also be revealed to Relying Party(s).  <ins> 8. </ins>  <ins> 8.1. </ins> Today, Evidence tends to be highly device-specific, since the information in the Evidence often includes vendor-specific isolation would require Appraisal Policy to be based on device- specific details (e.g., a device public key).  <ins> 8.2. </ins> An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing may need device-specific information such as a public key for the device or component or user on the device.  <ins> 8.3. </ins> Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy.  A result that indicates non-compliance relationship with one entity, rather than a larger set of entities, for purposes of its Appraisal Policy.  <ins> 9. </ins> The following diagram illustrates a relationship to which remote attestation is desired to be added: Evidence that encodes claims in one format, while issuing Attestation Results that encode claims in a different format.  <ins> 10. </ins> It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct. have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot.  <ins> 11. </ins> The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a Results are responsible for detailing what kinds of information are disclosed, and to whom they are exposed.  <ins> 12. </ins> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation roles, then the relaying entity should not expect to have access to the Evidence.  <ins> 13. </ins> This document does not require any actions by IANA.  <ins> 14. </ins> Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,


tampering.  The component that is implicitly trusted is often referred to as a Root of Trust.  In some scenarios, Evidence might contain sensitive information such as Personally Identifiable Information.  Thus, an Attester must trust entities to which it conveys Evidence, to not reveal sensitive data when appraising it at time(RA) by checking "time(RA) - time(RG) < Threshold", where the Relying Party's threshold is large enough to account for the maximum permitted clock skew between the Relying <del> Party and the Verifier. The result might then be used for some time (e.g., throughout the lifetime of a connection established at time(RA)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if the Attestation Result contains an expiry time time(RX) then it could explicitly check "time(OP) < time(RX)". </del>  14.2.

replace pull request with one we can edit. This attempts to establish the architectural basis for implicit trust as a result of links.
new text from requires some new Security Considerations text.

tampering.  The component that is implicitly trusted is often referred to as a Root of Trust. <ins> A conveyance protocol that provides authentication and integrity protection can be used to convey unprotected Evidence, assuming the following properties exists: The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the Attesting Environment(s) that collected claims about the Target Environment(s). All unprotected Evidence that is conveyed is supplied exclusively by the Attesting Environment that has the key material that protects the conveyance channel The Root of Trust protects both the conveyance channel key material and the Attesting Environment with equivalent strength protections. </ins> In some scenarios, Evidence might contain sensitive information such as Personally Identifiable Information.  Thus, an Attester must trust entities to which it conveys Evidence, to not reveal sensitive data when appraising it at time(RA) by checking "time(RA) - time(RG) < Threshold", where the Relying Party's threshold is large enough to account for the maximum permitted clock skew between the Relying  <ins> Party and the Verifier.  The result might then be used for some time (e.g., throughout the lifetime of a connection established at time(RA)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if the Attestation Result contains an expiry time time(RX) then it could explicitly check "time(OP) < time(RX)". </ins> 14.2.