10. <del> A remote entity (Verifier or Relying Party) may 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 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>  Freshness is assessed based on a policy defined by the consuming entity, Verifier or Relying Party, that compares the estimated epoch mechanism. A second approach places the onus of timekeeping solely on the <del> appraising entity, i.e., the Verifier (for Evidence), or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time </del>  synchronisation is otherwise impaired.  In this approach, a non- predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or

Looked at all uses of "entity" in the doc to be sure it wasn't referring to Verifier or RP which are roles and found a few issues in the Freshness section.

10.  <ins> A Verifier or Relying Party may 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 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. </ins> Freshness is assessed based on a policy defined by the consuming entity, Verifier or Relying Party, that compares the estimated epoch mechanism. A second approach places the onus of timekeeping solely on the  <ins> appraiser, i.e., the Verifier (for Evidence), or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time </ins> synchronisation is otherwise impaired.  In this approach, a non- predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or


9.  10. The conveyance of Evidence and the resulting Attestation Results 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 <del> use cases. </del>  To evaluate the security provided by a particular Appraisal Policy, it is important to understand the strength of the Root of Trust,

Based on discussion at IETF about including a very high level summary, and text in the arch docs, draft-birkholz-rats-reference-interaction-model, and draft-birkholz-rats-tuda. Signed-off-by: Dave Thaler
A quick review of the strawman, using the strawman to highlight a few points for discussion.

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. To do so, some mechanism of ensuring that the Evidence and Attestation Result are fresh, meaning that there is some degree of assurance that they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence.  There is, however, always a race condition possible in that the state of the Attester, and the Appraisal Policy for Evidence, may change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow the time window to something the Verifier (for Evidence) or Relying Party (for an Attestation Result) is willing to accept. There are two common approaches to providing some assurance of freshness.  The first approach is that a nonce is generated by a remote entity (e.g., the Verifier for Evidence, or the Relying Party for an Attestation Result), and the nonce is then signed and included along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed after the nonce was generated. A second approach is to rely on synchronized clocks, and include a signed timestamp (e.g., using I.D.draft-birkholz-rats-tuda) along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed at that time, as long as it has some assurance that the timestamp is correct.  This typically requires additional claims about the signer's time synchronization mechanism in order to provide such assurance. In either approach, it is important to note that the actual values in claims might have been generated long before the claims are signed. If so, it is the signer's responsibility to ensure that the values are still correct when they are signed.  For example, values might 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. The conveyance of Evidence and the resulting Attestation Results 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  <ins> use cases.  freshness discusses ways in which freshness can be used in this architecture to protect against replay attacks. </ins> To evaluate the security provided by a particular Appraisal Policy, it is important to understand the strength of the Root of Trust,


16.2. The following example illustrates a hypothetical Passport Model <del> solution that uses nonces and thus 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. </del>  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) <

Line had the closing "}" in the wrong place in the diagram. While touching this text, added phrase about disadvantage of the nonce approach, to provide more balanced discussion of timestamps vs nonces vs handles. Signed-off-by: Dave Thaler

16.2. The following example illustrates a hypothetical Passport Model  <ins> 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. </ins> 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) <


3.6. <del> One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This is a significant problem, because it allows a fleet of devices to be held hostage for ransom. </del>  In the case, the Relying Party is the watchdog timer in the TPM/ secure enclave itself, as described in TCGarch section 43.3.  The 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 any users the device is associated with.  In many </del>  cases, the whole point of the Attestation process is to provide reliable information about the type of the device and the firmware/ software that the device is running.  This information might be Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning <del> the Attestation Key Material.  When either of these are compromised, </del>  the remote attestation becomes worthless because the attacker can forge Evidence.

The remaining nit is one I disagree with. Signed-off-by: Dave Thaler
From URL Five separate trivial updates requested Section 2: Reference Value Provider Currently: ...Reference Values help Verifiers appraise the authenticity of Evidence Proposed: ...Reference Values help Verifiers appraise Evidence to determine if only known and acceptable claims have been recorded by the Attester Section 3.6: Currently: One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This is a significant problem, Proposed: There is a class of malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This can be a significant problem, Section 4: Currently: pppraisal policy Proposed: appraisal policy Section 11: Currently: as well as any users the device is associated with. Proposed: as well as potentially any users of the device. Section 12.1 Currently: Key Material Proposed: key material
I disagree with the first nit: if only known and acceptable claims have been recorded by the Attester Reasons I disagree: 1) Evidence might be considered trustworthy even if additional (not "known" to the Verifier) claims are inserted. E.g. there may be vendor-specific claims whereas the Verifier might only care about standard claims. 2) The appraisal process is not just about claims and the proposed text narrows it to only be about claims. The rest of the process includes checks like whether the signature is valid, whether the signer chains to something in the Verifier's trust anchor store, etc. These are not claims. As such, the current text is more correct.
The issue I have with the current text is that it intertwines authenticity and Reference Values. Evidence can still be authentic even if Reference Values are not what is passed. As part of WGLC, I have reviewed draft-ietf-rats-architecture-07, and believe it an excellent document. Below are three minor comments and five nits which I believe are worth addressing. Major Comments None Minor Comments Section 4: General Comment (this comment could also apply to Section 12) It is up to the Relying Party to evaluate the Verifier. And not all Verifiers should be seen as equivalently trustworthy. Additionally, any particular Verifier might be able to provide a consistent level of certainty in the "Attestation Results". This is because the capabilities of the Attesting Environment will vary. This section does not hint at the varying levels of certainty in the "Attestation Results" based on the varying quality and quantity of available Evidence of different types of Attesters. I am not sure if this truism belongs in this section. Or if this truism belongs in the document at all. But without having this nuance being described somewhere, it could leave the perception of a higher level of confidence in the Appraisals being from a deployable RATS architecture made than might necessarily be warranted. Note that this issue is also alluded to in Section 7.4 and Section 12. But neither address things like whether Attestation Result values should provide a minimum level of confidence regardless of the type of Attester being evaluated. In the end, I am fine if nothing changes in the document as a result of this comment, but I wanted to have the authors consider whether this is worth a statement or two. Section 5.1 Current Text: If the Attestation Result was a successful one, the Attester can then present the Attestation Result to a Relying Party, which then compares the Attestation Result against its own appraisal policy. Proposed Text: If the Attestation Result was a successful one, the Attester can then present the Attestation Result (and possibly additional Evidence) to a Relying Party, which then compares this information against its own appraisal policy. Alternative way to address comment: In Section 5.3 is a discussion on "Combinations". A final sentence or paragraph could be added on another example of a combination where the Attestation Result from a Passport Model can be a form of Evidence coming into a background check model. Rationale : There are multiple statements in Section 5.1, including the diagram which do not show additional Evidence allowed to be included as part of the passport model. We need at least one statement within Section 5 which shows this to be a valid scenario. I do not think Figure 7 covers this option sufficiently. (Note: this goes back to previous email list discussions showing that a even a government issued passport is stamped with supplemental information as people transit country borders.) Rationale : Section 8.3 on Attestation Results do not reference "Combinations", nor that Attestation Results can be a type of Evidence. Rationale : Section 16.2 includes a Nonce2 as supplemental evidence as part of the passport model diagram. Section 16.3 The notational convention for the use of ' (i.e., prime) after timestamps is not described. E.g. time(HR'_v). I think its meaning can be figured out by the diagram. But it might be worth making it an explicit notification convention. And other subsequent documents might want '' as well. Nits: Section 2: Reference Value Provider Currently: ...Reference Values help Verifiers appraise the authenticity of Evidence Proposed: ...Reference Values help Verifiers appraise Evidence to determine if only known and acceptable claims have been recorded by the Attester Section 3.6: Currently: One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This is a significant problem, Proposed: There is a class of malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This can be a significant problem, Section 4: Currently: pppraisal policy Proposed: appraisal policy Section 11: Currently: as well as any users the device is associated with. Proposed: as well as potentially any users of the device. Section 12.1 Currently: Key Material Proposed: key material Thanks, Eric

3.6.  <ins> There is a class of malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied.  This can be a significant problem, because it allows a fleet of devices to be held hostage for ransom. </ins> In the case, the Relying Party is the watchdog timer in the TPM/ secure enclave itself, as described in TCGarch section 43.3.  The 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 </ins> cases, the whole point of the Attestation process is to provide reliable information about the type of the device and the firmware/ software that the device is running.  This information might be Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning  <ins> the Attestation key material.  When either of these are compromised, </ins> the remote attestation becomes worthless because the attacker can forge Evidence.


An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence <del> A set of information about an Attester that is to be appraised by a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences. </del>  An entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known

Signed-off-by: Dave Thaler
` What’s the difference between claim and evidence? Maybe you start with a Claim, then sign it and that makes it into Evidence? Is Evidence a ‘set of claims’? [and what’s the difference between a ‘set of information’ and ‘information’?]
Maybe "A signed set of Claims about an Attester..."? (Want to make sure it's not "just" a set of claims, since the signing is important too.)

An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence  <ins> A set of Claims generated by an Attester to be appraised by a Verifier.  Evidence may include configuration data, measurements, telemetry, or inferences. </ins> An entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known


4.2. <del> Reference Values used in appraisal might be specified as part of the appraisal policy itself, or might be obtained from a separate source, such as an Endorsement, and then used by the appraisal policy. </del>  The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document

Signed-off-by: Dave Thaler
` Huh? I thought a Reference Value came from a Reference Value Provider

4.2.  <ins> Reference Values used in appraisal come from a Reference Value Provider and are then used by the appraisal policy.  They might be conveyed in any number of ways, including: * as part of the appraisal policy itself, if the Verifier Owner either: acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; * as part of an Endorsement, if the Endorser either acquires Reference Values from a Reference Value Provider or is itself a Reference Value Provider; or * via separate communication. </ins> The actual data format and semantics of any Reference Values are specific to claims and implementations.  This architecture document


measurements, telemetry, or inferences. An entity (typically a manufacturer) whose Reference Values help <del> Verifiers appraise the authenticity of Evidence. </del>  A set of values against which values of Claims can be compared as part of applying an Appraisal Policy for Evidence.  Reference

From URL Five separate trivial updates requested Section 2: Reference Value Provider Currently: ...Reference Values help Verifiers appraise the authenticity of Evidence Proposed: ...Reference Values help Verifiers appraise Evidence to determine if only known and acceptable claims have been recorded by the Attester Section 3.6: Currently: One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This is a significant problem, Proposed: There is a class of malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This can be a significant problem, Section 4: Currently: pppraisal policy Proposed: appraisal policy Section 11: Currently: as well as any users the device is associated with. Proposed: as well as potentially any users of the device. Section 12.1 Currently: Key Material Proposed: key material
I disagree with the first nit: if only known and acceptable claims have been recorded by the Attester Reasons I disagree: 1) Evidence might be considered trustworthy even if additional (not "known" to the Verifier) claims are inserted. E.g. there may be vendor-specific claims whereas the Verifier might only care about standard claims. 2) The appraisal process is not just about claims and the proposed text narrows it to only be about claims. The rest of the process includes checks like whether the signature is valid, whether the signer chains to something in the Verifier's trust anchor store, etc. These are not claims. As such, the current text is more correct.
The issue I have with the current text is that it intertwines authenticity and Reference Values. Evidence can still be authentic even if Reference Values are not what is passed. As part of WGLC, I have reviewed draft-ietf-rats-architecture-07, and believe it an excellent document. Below are three minor comments and five nits which I believe are worth addressing. Major Comments None Minor Comments Section 4: General Comment (this comment could also apply to Section 12) It is up to the Relying Party to evaluate the Verifier. And not all Verifiers should be seen as equivalently trustworthy. Additionally, any particular Verifier might be able to provide a consistent level of certainty in the "Attestation Results". This is because the capabilities of the Attesting Environment will vary. This section does not hint at the varying levels of certainty in the "Attestation Results" based on the varying quality and quantity of available Evidence of different types of Attesters. I am not sure if this truism belongs in this section. Or if this truism belongs in the document at all. But without having this nuance being described somewhere, it could leave the perception of a higher level of confidence in the Appraisals being from a deployable RATS architecture made than might necessarily be warranted. Note that this issue is also alluded to in Section 7.4 and Section 12. But neither address things like whether Attestation Result values should provide a minimum level of confidence regardless of the type of Attester being evaluated. In the end, I am fine if nothing changes in the document as a result of this comment, but I wanted to have the authors consider whether this is worth a statement or two. Section 5.1 Current Text: If the Attestation Result was a successful one, the Attester can then present the Attestation Result to a Relying Party, which then compares the Attestation Result against its own appraisal policy. Proposed Text: If the Attestation Result was a successful one, the Attester can then present the Attestation Result (and possibly additional Evidence) to a Relying Party, which then compares this information against its own appraisal policy. Alternative way to address comment: In Section 5.3 is a discussion on "Combinations". A final sentence or paragraph could be added on another example of a combination where the Attestation Result from a Passport Model can be a form of Evidence coming into a background check model. Rationale : There are multiple statements in Section 5.1, including the diagram which do not show additional Evidence allowed to be included as part of the passport model. We need at least one statement within Section 5 which shows this to be a valid scenario. I do not think Figure 7 covers this option sufficiently. (Note: this goes back to previous email list discussions showing that a even a government issued passport is stamped with supplemental information as people transit country borders.) Rationale : Section 8.3 on Attestation Results do not reference "Combinations", nor that Attestation Results can be a type of Evidence. Rationale : Section 16.2 includes a Nonce2 as supplemental evidence as part of the passport model diagram. Section 16.3 The notational convention for the use of ' (i.e., prime) after timestamps is not described. E.g. time(HR'_v). I think its meaning can be figured out by the diagram. But it might be worth making it an explicit notification convention. And other subsequent documents might want '' as well. Nits: Section 2: Reference Value Provider Currently: ...Reference Values help Verifiers appraise the authenticity of Evidence Proposed: ...Reference Values help Verifiers appraise Evidence to determine if only known and acceptable claims have been recorded by the Attester Section 3.6: Currently: One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This is a significant problem, Proposed: There is a class of malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. This can be a significant problem, Section 4: Currently: pppraisal policy Proposed: appraisal policy Section 11: Currently: as well as any users the device is associated with. Proposed: as well as potentially any users of the device. Section 12.1 Currently: Key Material Proposed: key material Thanks, Eric

measurements, telemetry, or inferences. An entity (typically a manufacturer) whose Reference Values help  <ins> Verifiers appraise Evidence to determine if acceptable known claims have been recorded by the Attester </ins> A set of values against which values of Claims can be compared as part of applying an Appraisal Policy for Evidence.  Reference


This document uses the following terms. <del> A set of rules that informs how a Verifier evaluates the validity of information about an Attester.  Compare /security policy/ in A set of rules that direct how a Relying Party uses the Attestation Results regarding an Attester generated by the Verifiers.  Compare /security policy/ in The output generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the validity of the results </del>  A role performed by an entity (typically a device) whose Evidence must be appraised in order to infer the extent to which the Attester is considered trustworthy, such as when deciding whether <del> it is authorized to perform some operation </del>  A piece of asserted information, often in the form of a name/value <del> pair.  (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 <del> Evidence signing An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence </del>  A set of Claims generated by an Attester to be appraised by a Verifier.  Evidence may include configuration data, measurements, <del> telemetry, or inferences. </del>  <del> An entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known claims have been recorded by the Attester </del>  A set of values against which values of Claims can be compared as part of applying an Appraisal Policy for Evidence.  Reference values, golden measurements, or nominal values, although those terms typically assume comparison for equality, whereas here Reference Values might be more general and be used in any sort of <del> comparison. A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying application specific actions.  Compare /relying party/ in An entity (typically an administrator), that is authorized to configure Appraisal Policy for Attestation Results in a Relying Party A role performed by an entity that appraises the validity of Evidence about an Attester and produces Attestation Results to be used by a Relying Party An entity (typically an administrator), that is authorized to configure Appraisal Policy for Evidence in a Verifier </del>  5.

This reworks the pull request: using the latest text. Commit 1 - move all the text. Commit 2 - add produces/consumes. Commit 3 - move the text into categories. Reviewing the commits individually is probably better.
Please review NAME

This document uses the following terms.  <ins> 4.1. </ins> A role performed by an entity (typically a device) whose Evidence must be appraised in order to infer the extent to which the Attester is considered trustworthy, such as when deciding whether  <ins> it is authorized to perform some operation.  Produces: Evidence. A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying application specific actions.  Compare /relying party/ in RFC4949. Consumes: Attestation Results. A role performed by an entity that appraises the validity of Evidence about an Attester and produces Attestation Results to be used by a Relying Party.  Consumes: Evidence, Reference Values, Endorsements, Appraisal Policy for Evidence; Produces: Attestation Results. An entity (typically an administrator), that is authorized to configure Appraisal Policy for Attestation Results in a Relying Party.  Produces: Appraisal Policy for Attestation Results. An entity (typically an administrator), that is authorized to configure Appraisal Policy for Evidence in a Verifier.  Produces: Appraisal Policy for Evidence. An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence.  Produces: Endorsements. An entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known claims have been recorded by the Attester.  Produces: Reference Values. 4.2. </ins> A piece of asserted information, often in the form of a name/value  <ins> pair.  Claims make up the usual structure of Evidence.  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  <ins> Evidence signing Used By: Verifier; Produced By: Endorser. </ins> A set of Claims generated by an Attester to be appraised by a Verifier.  Evidence may include configuration data, measurements,  <ins> telemetry, or inferences.  Used By: Verifier; Produced By: Attester. </ins>  <ins> The output generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the validity of the results.  Used By: Relying Party; Produced By: Verifier. A set of rules that informs how a Verifier evaluates the validity of information about an Attester.  Compare /security policy/ in RFC4949.  Used by: Verifier; Produced by: Verifier Owner. A set of rules that direct how a Relying Party uses the Attestation Results regarding an Attester generated by the Verifiers.  Compare /security policy/ in RFC4949.  Used by: Relying Party; Produced by: Relying Party Owner. </ins> A set of values against which values of Claims can be compared as part of applying an Appraisal Policy for Evidence.  Reference values, golden measurements, or nominal values, although those terms typically assume comparison for equality, whereas here Reference Values might be more general and be used in any sort of  <ins> comparison.  Used By: Verifier; Produced By: Reference Value Provider. </ins> 5.


Abstract <del> In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about a remote peer to assess the peer's trustworthiness, and a way to appraise such evidence.  The evidence is typically a set of claims about its software and hardware platform.  This document describes an architecture for such remote attestation procedures (RATS). </del>  1.

The last sentence of the abstract is: but "such" remote attestation procedures are not defined earlier.
This abstract literally reads more self-consistent. +1

Abstract  <ins> In network protocol exchanges it is often the case that one entity requires believable evidence about the operational state of a remote peer.  Such evidence is typically conveyed as claims about the peer's software and hardware platform, and is subsequently appraised in order to assess the peer's trustworthiness.  The process of generating and appraising this kind of evidence is known as remote attestation.  This document describes an architecture for remote attestation procedures that generate, convey, and appraise evidence about a peer's operational state. </ins> 1.


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) < <del> Threshold", again where the threshold is large enough to account for the maximum permitted clock skew between the Verifier and the Attester. </del>  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)

Clarify that recentness of Evidence depends primarily on the appraisal policy and that clock skew is only secondary.
Section "16.1. Example 1", third para: I find the reference to clock skew slightly confusing. The Threshold value here is more likely to depend on a verification policy that defines what is an acceptable "age" of the sampled claim rather than on considerations about clocks drifting.

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) <  <ins> 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. </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)


Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning <del> the Attestation key material.  When either of these are compromised, </del>  the remote attestation becomes worthless because the attacker can forge Evidence. 12.1.1. <del> It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key. The Attester must be protected from unauthorized modification to ensure it behaves correctly.  There must also be confidentiality so that the signing key is not captured and used elsewhere to forge evidence. </del>  In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the

Signed-off-by: Dave Thaler
"It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key." The grammar seems off to me. Should be: "It is assumed that the Attester is located in an isolated environment of a device such as; a process, a dedicated chip, a TEE, a virtual machine, a secure mode of operation or other forms of domain isolation that allows collection of Claims from the target environment where the target environment cannot lie or interfere with the claims collection function. Additionally, the Attester formats collected Claims and integrity protects them with an Attestation Key that also is domain isolated such that the target environment or some other entity other than the Attester is not able to undermine the Attester's protections"

Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning  <ins> the Attestation key material.  If either of these are compromised, </ins> the remote attestation becomes worthless because the attacker can forge Evidence. 12.1.1.  <ins> It is assumed that an Attesting Environment is sufficiently isolated from the Target Environment it collects Claims for and signs them with an Attestation Key, so that the Target Environment cannot forge Evidence about itself.  Such an isolated environment might be provided by a process, a dedicated chip, a TEE, a virtual machine, or another secure mode of operation.  The Attesting Environment must be protected from unauthorized modification to ensure it behaves correctly.  There must also be confidentiality so that the signing key is not captured and used elsewhere to forge Evidence. </ins> In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the


Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence) <del> or Relying Party (for Attestation Result) is willing to accept. Freshness is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </del>  There are two common approaches for determining the epoch of an Evidence or Attestation Result.

Signed-off-by: Dave Thaler
` I think what you mean is that “some flexibility on the requirement for freshness is a key component…”, i.e., it’s the willingness to accept a result that’s been around for a while enables caching.
agree.

Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence)  <ins> or Relying Party (for Attestation Result) is willing to accept.  Some flexibility on the freshness requirement, however, is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </ins> There are two common approaches for determining the epoch of an Evidence or Attestation Result.


In this diagram, the protocol between Attester and a Relying Party can be any new or existing protocol (e.g., HTTP(S), COAP(S), ROLIE <del> RFC8322, 802.1x, OPC UA, etc.), depending on the use case.  Such protocols typically already have mechanisms for passing security </del>  information for purposes of authentication and authorization.  Common formats include JWTs RFC7519, CWTs RFC8392, and X.509 certificates. <del> To enable remote attestation to be added to existing protocols, enabling a higher level of assurance against malware for example, it is important that information needed for appraising the Attester be usable with existing protocols that have constraints around what formats they can transport.  For example, OPC UA OPCUA (probably the most common protocol in industrial IoT environments) is defined to carry X.509 certificates and so security information must be embedded into an X.509 certificate to be passed in the protocol.  Thus, remote attestation related information could be natively encoded in X.509 certificate extensions, or could be natively encoded in some other format (e.g., a CWT) which in turn is then encoded in an X.509 certificate extension. Especially for constrained nodes, however, there is a desire to minimize the amount of parsing code needed in a Relying Party, in order to both minimize footprint and to minimize the attack surface area.  So while it would be possible to embed a CWT inside a JWT, or a JWT inside an X.509 extension, etc., there is a desire to encode the information natively in the format that is natural for the Relying Party. </del>  This motivates having a common "information model" that describes the set of remote attestation related information in an encoding-agnostic

This sentence: it's quite hard to digest. But more generally, the motivating use case (OPC UA) is slightly convoluted, and I'm wondering whether it is really needed? But assuming it were, the exposition needs to be improved to present a clear and compelling case.
I cannot speak for the applicability of OPC UA here. It seems to be an item in an already long list. I actually wonder more why EAP is not in there to add some diversity. Having said that, how about:
Looks much better, thanks! Elaborating a bit further: "Retrofitting already deployed protocols with remote attestation requires adding RATS conceptual messages to the existing data flows. This must be done in a way that doesn't degrade the security properties of the protocol and should use the native extension mechanisms (if available). For example, if an authentication protocol (e.g., the TLS handshake) has to be extended with remote attestation capabilities, attestation Evidence may be embedded in an ad-hoc X.509 certificate extension, or into a new TLS Certificate Type."
You had me at "retro". In my kickstarting proposal, I barged on with "DER", which is now gone but now there are TLS and Certificate Type for elaboration. None, one, or all? I don't want to overload that paragraph with arbitrary examples. Unfortunately, now these start to seem arbitrary to me. What is the reasoning for choosing examples here, actually?
These are both existing mechanisms: the first (new cert extension) is , the second (new TLS cert type) is . I dropped DER as it's a necessity when using x.509 certs, and looked redundant.
That actually helped me a lot! Maybe we should pull these reference in? I am aware that it is sometimes better to shy away from specifica, but in this case I think it would help the reader to be more specific. Thoughts?
Doing a background check on OP CUA, I've found that the is not open, and that there are only two research papers that talk about adding attestation to the existing model: (2020) and (2017). This paucity of related content makes its presence as a "demo" use case a bit brittle. I suggest we remove it. DICE and TLS-CWT should be enough.

In this diagram, the protocol between Attester and a Relying Party can be any new or existing protocol (e.g., HTTP(S), COAP(S), ROLIE  <ins> RFC8322, 802.1x, OPC UA OPCUA, etc.), depending on the use case. Such protocols typically already have mechanisms for passing security </ins> information for purposes of authentication and authorization.  Common formats include JWTs RFC7519, CWTs RFC8392, and X.509 certificates.  <ins> Retrofitting already deployed protocols with remote attestation requires adding RATS conceptual messages to the existing data flows. This must be done in a way that doesn't degrade the security properties of the system and should use the native extension mechanisms provided by the underlying protocol.  For example, if the TLS handshake is to be extended with remote attestation capabilities, attestation Evidence may be embedded in an ad hoc X.509 certificate extension (e.g., TCG-DICE), or into a new TLS Certificate Type (e.g., I-D.tschofenig-tls-cwt). Especially for constrained nodes there is a desire to minimize the amount of parsing code needed in a Relying Party, in order to both minimize footprint and to minimize the attack surface area.  So while it would be possible to embed a CWT inside a JWT, or a JWT inside an X.509 extension, etc., there is a desire to encode the information natively in the format that is natural for the Relying Party. </ins> This motivates having a common "information model" that describes the set of remote attestation related information in an encoding-agnostic


functions together.  In this case, there is no need for a protocol between the two. <del> It is also worth pointing out that the choice of model is generally up to the Relying Party.  The same device may need to create Evidence for different Relying Parties and/or different use cases.  For instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </del>  combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an

We say: I'm not sure it "is up to the RP"_. Maybe better saying it "depends on the RP application" (or similar) because it's typically not a choice of the RP but of the use case / protocol flow in which the RP operates...
+1
Proposal: "Individual applications, use cases or protocol flows interacting with the same Attester can use different models."

functions together.  In this case, there is no need for a protocol between the two.  <ins> It is also worth pointing out that the choice of model depends on the use case, and that different Relying Parties may use different topological patterns. The same device may need to create Evidence for different Relying Parties and/or different use cases.  For instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </ins> combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an


5. <del> dataflow shows a basic model for communication between an Attester, a Verifier, and a Relying Party.  The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier.  There are multiple other possible models.  This section includes some reference models.  This is not intended to be a restrictive list, and other variations may exist. </del>  5.1.

The three sentences "There are multiple [...]", "This section includes [...]" and "This is not intended [...]" are slightly vague. It doesn't seem to me that their information content is enough to justify them being independent sentences. They should probably be combined.
OLD: NEW:
(slight refinement) "Figure 1 shows an abstract model for communication between an Attester, a Verifier, and a Relying Party. The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier. This section refines it by describing two reference interaction schemes (topological models), as well as one possible compositions thereof. The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns."
Reads good to me. Any other comments? (starting a virtual going once...)

5.  <ins> dataflow shows a data-flow diagram for communication between an Attester, a Verifier, and a Relying Party.  The Attester conveys its Evidence to the Verifier for appraisal, and the Relying Party gets the Attestation Result from the Verifier.  This section refines it by describing two reference models, as well as one example composition thereof.  The discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns. </ins> 5.1.


The device that should be protected from being held hostage for a long period of time <del> A remote server that will securely grant the Attester permission to continue operating (i.e., not reboot) for a period of time </del>  2.7.

There seems to be some confusion: initially it is said that the "Relying Party is the watchdog timer in the TPM." Subsequently, the Relying Party is defined as "A remote server that will securely grant the Attester [...]". So, what is it?
For context, this is now: https://ietf-rats-URL This is plainly wrong (probably due being left over as an artifact after revising the text). How about: "Relying Party: The watchdog capable to trigger a procedure that resets a device into a remediatable operational state."
WFM, except I am not sure "remediatable" is a word. You want to use "known, good" instead?
Sry for my native language habit of concatenating and mangling existing terms. "Known, good" reads very appropriate. Thanks!
The sentence above says that the replying party is inside the TPM?? I think this sentence, relying party is a remote server, is more likely what you mean. In the above paragraph, it says that the Relying Party is inside the TPM. I think this is the correct description. The Relying Party isn't remote in this use case because it has the essential capability to force the device to reboot.
This issue is the same as

The device that should be protected from being held hostage for a long period of time  <ins> A watchdog capable of triggering a procedure that resets a device into a known, good operational state. </ins> 2.7.


16.3. <del> The following example illustrates a hypothetical Passport Model solution that uses handles instead of nonces or timestamps.  In this example, Evidence generation based on received handles always uses the current (most recent) handle.  As handles are distributed over the network, all involved entities receive a fresh handle at roughly the same time.  Due to distribution over the network, there is some jitter with respect to the time the Handle is received, time(HR), for each involved entity.  To compensate for this jitter, there is a small period of overlap (a specified offset) in which both a current handle and corresponding former handle are valid in Evidence appraisal: "validity-duration = time(HR'_v) + offset - time(HR_v)". The offset is typically based on a network's round trip time. Analogously, the generation of valid Evidence is only possible, if the age of the handle used is lower than the validity-duration: "time(HR_v) - time(EG_a) < validity-duration". From the point of view of a Verifier, the generation of valid Evidence is only possible, if the age of the handle used in the Evidence generation is younger than the duration of the distribution interval - "(time(HR'_v)-time(HR_v)) - (time(HR_a)-time(EG_a)) < validity-duration". Due to the validity-duration of handles, multiple different pieces of Evidence can be generated based on the same handle.  The resulting granularity (time resolution) of Evidence freshness is typically lower than the resolution of clock-based tickcounters. The following example illustrates a hypothetical Background-Check Model solution that uses handles and requires a trustworthy time source available to the Handle Distributor role. </del>  16.4.

This is a draft PR. More prose is needed around the sequence diagram.
fixed the required event tables entries The new sequence diagram illustrate a more concise "real life" story now and st the same time intends to fixes some ambiguities that snuck in when augmenting the overall diagram layout. Now ready for first walk-through in editors meeting.
looks good to me.
Personally, I find the new text much less clear than the old text
Discuss the impact that altering the distribution of handles (e.g., delaying, suppressing) has on the security of the protocol. Add relevant text to the Security Consideration section.
Is this more than just finishing ? If so, what?
The scope is different: deals with the example in the appendix, this one is for text that belongs to the security considerations. Regarding the "what": is the issue description insufficient? If so, do you have any suggestion on how to make it clearer?
The appendix on Handles needs some work to better clarify the concepts and simplify the flow. Some things about the text: Clearly define what is a handle; Explain its relation with epoch establishment; Clarify network jitter impact on handle validity; Explain what are the base rules for working with handles; Some further points on the sequence diagram: Fix confusing legend; Add some accompanying prose to explain the depicted use case as it's not self-evident;
fix all time to be delta

16.3.  <ins> The example in fig-handle-passport illustrates a hypothetical Passport Model solution that uses handles instead of nonces or timestamps. The Handle Distributor broadcasts handle "H" which starts a new epoch "E" for a protocol participant upon reception at "time(HR)". The Attester generates Evidence incorporating handle "H" and conveys it to the Verifier. The Verifier appraises that the received handle "H" is "fresh" according to the definition provided in epochfreshness whereby retries are required in the case of mismatching handles, and generates an Attestation Result.  The Attestation Result is conveyed to the Attester. After the transmission of handle "H'" a new epoch "E'" is established when "H'" is received by each protocol participant.  The Attester relays the Attestation Result obtained during epoch "E" (associated with handle "H") to the Relying Party using the handle for the current epoch "H'".  If the Relying Party had not yet received "H'", then the Attestation Result would be rejected, but in this example, it is received. In the illustrated scenario, the handle for relaying an Attestation Result to the Relying Party is current, while a previous handle was used to generate Verifier evaluated evidence.  This indicates that at least one epoch transition has occurred, and the Attestation Results may only be as fresh as the previous epoch. </ins> 16.4.


protocol between the Attester and Relying Party. However, like in the Passport model, an Attestation Result is still <del> consumed by the Relying Party and so the serialization format of the Attestation Result is still important.  If the Relying Party is a constrained node whose purpose is to serve a given type resource using a standard resource access protocol, it already needs the parser(s) required by that existing protocol.  Hence, the ability to let the Relying Party obtain an Attestation Result in the same serialization format allows minimizing the code footprint and attack surface area of the Relying Party, especially if the Relying Party is a constrained node. </del>  5.3.

Signed-off-by: Dave Thaler
The paragraph: seems to reshuffle the content of the preceding one. The two can be combined / streamlined.
Maybe: "However, like in the Passport model, an Attestation Result is still consumed by the Relying Party and so the ability to convey it in the same serialization format as the Evidence allows minimizing the code footprint and attack surface area, which is especially important if the Relying Party is a constrained node."
Personally, I like the new content here that elaborates on motivation and intent. Anyone else like to chime in here to have in impact on that expositional text?
The meaning of is wrong, i.e., format same as the Evidence. Instead the meaning is format same as the resource access protocol natively uses.

protocol between the Attester and Relying Party. However, like in the Passport model, an Attestation Result is still  <ins> consumed by the Relying Party.  Code footprint and attack surface area can be minimized by using a serialization format for which the Relying Party already needs a parser to support the protocol between the Attester and Relying Party, which may be an existing standard or widely deployed resource access protocol.  Such minimization is especially important if the Relying Party is a constrained node. </ins> 5.3.


Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  There is no limit <del> to or requirement on the places that an Attesting Environment can exist, but they typically are in 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.  Execution environments that are designed to be capable of claims collection are referred to in this document as Attesting Environments. </del>  3.4.

Why not? What’s the message you want to convey here? What would disqualify an execution environment from being capable of claims collection? How would you know if an Execution Environment is an Attesting Environment?
What does it mean to be capable of claims collection? If this example had a TPM, then this function would be entirely inside the TPM, no?
subsequent line now reads: ` Should this explicitely say, "TPM" as well, or is that implied?

Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  There is no limit  <ins> to or requirement on the types of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.  An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments. </ins> 3.4.


Every FIDO Authenticator contains an Attester. <del> Any web site, mobile application back end or service that does biometric authentication. </del>  3.

` It sounds like the Verifier “does” the authentication, and the relying party relies on the answer?
Besides, there's a slight imprecision here: the web site / mobile app backend service don't do biometric auth. Instead, the authenticator binds biometric info to crypto material so that the web site can deal with usual crypto auth.
For context, this is https://ietf-rats-URL How about:

Every FIDO Authenticator contains an Attester.  <ins> Any web site, mobile application back-end, or service that relies on authentication data based on biometric information. </ins> 3.


2.4. <del> In this use case, potentially dangerous physical equipment (e.g., power grid, traffic control, hazardous chemical processing, etc.) is </del>  connected to a network.  The organization managing such infrastructure needs to ensure that only authorized code and users <del> can control such processes, and they are protected from malware or other threats.  When a protocol operation can affect some critical system, the device attached to the critical equipment thus wants some assurance that the requester has not been compromised.  As such, remote attestation can be used to only accept commands from requesters that are within policy. </del>  A device or application wishing to control physical equipment

Guy says: This section seems to say that the Connected IoT valve is going attest the cloud-based industrial control system before accepting an Open or Close command? I’d guess what you mean is that the control system should check that the valve it’s about to open is the right one, and is probably sane, no?
... and even more importantly that the sensor that provides critical input into the controller needs to give evidence of its trustworthiness before the controller can comfortably act upon its stimulus (e.g., opening the valve.)
For context, this is now: https://ietf-rats-URL While trying to address both MCR's and Thomas' comments, I realized that Michael's "valve is the right one" seems already to be subsumed by "are within policy". I felt that adding an explicit example here added more words then content. To address Thomas' comment it now says "the requester and the triggering sensor have not been compromised". After including a few editorial changes, the resulting proposal does not look vastly different: "In this use case, potentially harmful physical equipment (e.g., power grid, traffic control, hazardous chemical processing, etc.) is connected to a network. The organization managing such infrastructure needs to ensure that only authorized code and users can control such processes, and that these processes are protected from unauthorized manipulation or other threats. When a protocol operation can affect a component of a critical system, the device attached to the critical equipment requires some assurances depending on the security context, including that: the requester and the triggering sensor have not been compromised, and the requesters and actors act on applicable policies, As such, remote attestation can be used to only accept commands from requesters that are within policy."

2.4.  <ins> In this use case, potentially harmful physical equipment (e.g., power grid, traffic control, hazardous chemical processing, etc.) is </ins> connected to a network.  The organization managing such infrastructure needs to ensure that only authorized code and users  <ins> can control such processes, and that these processes are protected from unauthorized manipulation or other threats.  When a protocol operation can affect a component of a critical system, the device attached to the critical equipment requires some assurances depending on the security context, including that: the requesting device or application has not been compromised, and the requesters and actors act on applicable policies, As such, remote attestation can be used to only accept commands from requesters that are within policy. </ins> A device or application wishing to control physical equipment


3.4. <del> By definition, the Attester role creates Evidence.  An Attester may consist of one or more nested or staged environments, adding complexity to the architectural structure.  The unifying component is the root of trust and the nested, staged, or chained attestation Evidence produced.  The nested or chained structure includes Claims, collected by the Attester to aid in the assurance or believability of the attestation Evidence. </del>  The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system

Based on Henk's proposal and Dave's comments.
NAME : This is a complete re-write of the paragraph which needs to be read in its entirety. I'm not sure whether a line-by-line diff is of any help? That said, if you really want I could do that easily.
Thomas Fossati wrote: It helps with the next edit that comes along.
OK, done in f778919
I don't understand what this para is supposed to communicate: Also, pick one of "nested", "staged" or "chained" and drop the rest.
For context: this is now https://ietf-rats-URL "Layered Attestation Environments" How about this as a new starting point: Effectively, I removed the last sentence, as I had a hard time to understand what it intended to add to the content here. My proposal is intended as a rework of this paragraph that goes beyond editorial changes. The current last sentence still seems a bit out of place to me.
Looks very good as a starting point. Thanks!
All good so far. This sentence can be confusing, since I think it could include claims about itself in Evidence, as admitted in your point below ("Claims can be collected from or about each layer, including roots of trust.") Disagree with "must be endorsed". Either the verifier has to trust the root of trust itself (e.g., put the root of trust's public key into its trust anchor store directly) OR must be endorsed (e.g., put the endorser's public key into the verifier's trust anchor store). Fine.

3.4.  <ins> By definition, the Attester role generates Evidence.  An Attester may 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 either directly (e.g., the Verifier puts the root of trust's public key into its trust anchor store) or transitively via an Endorser (e.g., the Verifier puts the Endorser's public key into its trust anchor store).  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. </ins> The device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an updatable bootloader, and (C) an operating system


generated using the latest Appraisal Policy for Evidence. Freshness is assessed based on the Appraisal Policy for Evidence or <del> Attestation Results, that compares the estimated epoch against an </del>  "expiry" threshold defined locally to that policy.  There is, however, always a race condition possible in that the state of the Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence) or Relying Party (for Attestation Result) is willing to accept.  Some <del> flexibility on the freshness requirement, however, is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </del>  <del> There are two common approaches for determining the epoch of an Evidence or Attestation Result. </del>  The first approach is to rely on synchronized and trustworthy clocks, and include a signed timestamp (see I-D.birkholz-rats-tuda) along with the Claims in the Evidence or Attestation Result.  Timestamps <del> can be added on a per-Claim basis, to distinguish the time of </del>  creation of Evidence or Attestation Result from the time that a specific Claim was generated.  The clock's trustworthiness typically requires additional Claims about the signer's time synchronization mechanism.  A second approach places the onus of timekeeping solely on the <del> Verifier (for Evidence), or the Relying Party (for Attestation </del>  Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the The time between the creation of Claims and the collection of Claims is indistinguishable.  Implicit and explicit timekeeping can be combined into hybrid mechanisms.  For example, if clocks exist and are considered trustworthy but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved <del> peers, followed by any number of timestamp based exchanges.  In another setup where all Roles (Attesters, Verifiers and Relying Parties) share the same broadcast channel, the nonce-based approach may be used to anchor all parties to the same (relative) timeline, without requiring synchronized clocks, by having a central entity emit nonces at regular intervals and have the "current" nonce included in the produced Evidence or Attestation Result. </del>  It is important to note that the actual values in Claims might have been generated long before the Claims are signed.  If so, it is the 16.3. <del> Handles are a third option to establish time-keeping next to nonces or timestamps.  Handles are opaque data intended to be available to all RATS roles that interact with each other, such as the Attester or Verifier, in specified intervals.  To enable this availability, handles are distributed centrally by the Handle Distributor role over the network.  As any other role, the Handle Distributor role can be taken on by a dedicated entity or collapsed with other roles, such as a Verifier.  The use of handles can compensate for a lack of clocks or other sources of time on entities taking on RATS roles.  The only entity that requires access to a source of time is the entity taking on the role of Handle Distributor. Handles are different from nonces as they can be used more than once and can be used by more than one entity at the same time.  Handles are different from timestamps as they do not have to convey information about a point in time, but their reception creates that information.  The reception of a handle is similar to the event that increments a relative tickcounter.  Receipt of a new handle invalidates a previously received handle. In this example, Evidence generation based on received handles always uses the current (most recent) handle.  As handles are distributed over the network, all involved entities receive a fresh handle at roughly the same time.  Due to distribution over the network, there is some jitter with respect to the time the Handle is received, time(HR), for each involved entity.  To compensate for this jitter, there is a small period of overlap (a specified offset) in which both a current handle and corresponding former handle are valid in Evidence appraisal: "validity-duration = time(HR'_v) + offset - time(HR_v)".  The offset is typically based on a network's round trip time.  Analogously, the generation of valid Evidence is only possible, if the age of the handle used is lower than the validity- duration: "time(HR_v) - time(EG_a) < validity-duration". </del>  From the point of view of a Verifier, the generation of valid Evidence is only possible, if the age of the handle used in the

Per last week's design team discussion. Signed-off-by: Dave Thaler
In general, I like the re-introduction of the "timekeeping" subsections a lot. +1

generated using the latest Appraisal Policy for Evidence. Freshness is assessed based on the Appraisal Policy for Evidence or  <ins> Attestation Results that compares the estimated epoch against an </ins> "expiry" threshold defined locally to that policy.  There is, however, always a race condition possible in that the state of the Attester, and the appraisal policies might change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow their recentness to something the Verifier (for Evidence) or Relying Party (for Attestation Result) is willing to accept.  Some  <ins> flexibility on the freshness requirement is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). </ins>  <ins> There are three common approaches for determining the epoch of Evidence or an Attestation Result. 10.1. </ins> The first approach is to rely on synchronized and trustworthy clocks, and include a signed timestamp (see I-D.birkholz-rats-tuda) along with the Claims in the Evidence or Attestation Result.  Timestamps  <ins> can also be added on a per-Claim basis to distinguish the time of </ins> creation of Evidence or Attestation Result from the time that a specific Claim was generated.  The clock's trustworthiness typically requires additional Claims about the signer's time synchronization mechanism. <ins> 10.2. </ins> A second approach places the onus of timekeeping solely on the  <ins> Verifier (for Evidence) or the Relying Party (for Attestation </ins> Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronization is otherwise impaired.  In this approach, a non-predictable nonce is sent by the The time between the creation of Claims and the collection of Claims is indistinguishable. <ins> 10.3. A third approach relies on having epoch "handles" periodically sent to both the sender and receiver of Evidence or Attestation Results by some "Handle Distributor". Handles are different from nonces as they can be used more than once and can even be used by more than one entity at the same time. Handles are different from timestamps as they do not have to convey information about a point in time, i.e., they are not necessarily monotonically increasing integers. Like the nonce approach, this allows associating a "rough" epoch without requiring a reliable clock or time synchronization in order to generate or appraise the freshness of Evidence or Attestation Results.  Only the Handle Distributor requires access to a clock so it can periodically send new epoch handles. The most recent handle is included in the produced Evidence or Attestation Results, and the appraising entity can compare the handle in received Evidence or Attestation Results against the latest handle it received from the Handle Distributor to determine if it is within the current epoch.  An actual solution also needs to take into account race conditions when transitioning to a new epoch, such as by using a counter signed by the Handle Distributor as the handle, or by including both the current and previous handles in messages and/or checks, by requiring retries in case of mismatching handles, or by buffering incoming messages that might be associated with a handle that the receiver has not yet obtained. Whereas the nonce approach typically requires the appraising entity to keep state for each nonce generated, the handle approach minimizes the state kept to be independent of the number of Attesters or Verifiers from which it expects to receive Evidence or Attestation Results, as long as all use the same Handle Distributor. 10.4. </ins> Implicit and explicit timekeeping can be combined into hybrid mechanisms.  For example, if clocks exist and are considered trustworthy but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved  <ins> peers, followed by any number of timestamp based exchanges. </ins> It is important to note that the actual values in Claims might have been generated long before the Claims are signed.  If so, it is the 16.3.  <ins> The following example illustrates a hypothetical Passport Model solution that uses handles instead of nonces or timestamps.  In this example, Evidence generation based on received handles always uses the current (most recent) handle.  As handles are distributed over the network, all involved entities receive a fresh handle at roughly the same time.  Due to distribution over the network, there is some jitter with respect to the time the Handle is received, time(HR), for each involved entity.  To compensate for this jitter, there is a small period of overlap (a specified offset) in which both a current handle and corresponding former handle are valid in Evidence appraisal: "validity-duration = time(HR'_v) + offset - time(HR_v)". The offset is typically based on a network's round trip time. Analogously, the generation of valid Evidence is only possible, if the age of the handle used is lower than the validity-duration: "time(HR_v) - time(EG_a) < validity-duration". </ins> From the point of view of a Verifier, the generation of valid Evidence is only possible, if the age of the handle used in the


Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy. <del> There are three ways in which the process may fail.  First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence.  The second way in which the process may fail is when the Attestation Result is examined by the Relying Party, and based upon the Appraisal Policy for Attestation Results, the result does not pass the policy.  The third way is when the Verifier is unreachable or unavailable. </del>  Since the resource access protocol between the Attester and Relying Party includes an Attestation Result, in this model the details of

` Is there a reason to enumerate the failure cases? How can it be argued that there are only three? What if the device fails part way through? What if the relying party fails? What if the relying party is unreachable? What if something happens that wasn’t anticipated in the appraisal policy? Put another way, what are we learning about RATS from this example?

Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy.  <ins> Three ways in which the process may fail include: First, the Verifier may not issue a positive Attestation Result due to the Evidence not passing the Appraisal Policy for Evidence. The second way in which the process may fail is when the Attestation Result is examined by the Relying Party, and based upon the Appraisal Policy for Attestation Results, the result does not pass the policy. The third way is when the Verifier is unreachable or unavailable. </ins> Since the resource access protocol between the Attester and Relying Party includes an Attestation Result, in this model the details of


A role performed by an entity (typically a device) whose Evidence must be appraised in order to infer the extent to which the Attester is considered trustworthy, such as when deciding whether <del> it is authorized to perform some operation.  Produces: Evidence. </del>  A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying application specific actions.  Compare /relying party/ in RFC4949. <del> Consumes: Attestation Results. </del>  A role performed by an entity that appraises the validity of Evidence about an Attester and produces Attestation Results to be <del> used by a Relying Party.  Consumes: Evidence, Reference Values, Endorsements, Appraisal Policy for Evidence; Produces: Attestation Results. </del>  <del> An entity (typically an administrator), that is authorized to configure Appraisal Policy for Attestation Results in a Relying Party.  Produces: Appraisal Policy for Attestation Results. </del>  <del> An entity (typically an administrator), that is authorized to configure Appraisal Policy for Evidence in a Verifier.  Produces: Appraisal Policy for Evidence. </del>  <del> An entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence.  Produces: Endorsements. </del>  <del> An entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known claims have been recorded by the Attester.  Produces: Reference Values. </del>  4.2. A piece of asserted information, often in the form of a name/value <del> pair.  Claims make up the usual structure of Evidence.  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 <del> Evidence signing Used By: Verifier; Produced By: Endorser. </del>  A set of Claims generated by an Attester to be appraised by a Verifier.  Evidence may include configuration data, measurements, <del> telemetry, or inferences.  Used By: Verifier; Produced By: Attester. </del>  The output generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the <del> validity of the results.  Used By: Relying Party; Produced By: Verifier. </del>  A set of rules that informs how a Verifier evaluates the validity of information about an Attester.  Compare /security policy/ in <del> RFC4949.  Used by: Verifier; Produced by: Verifier Owner. </del>  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.  Used by: Relying Party; Produced by: Relying Party Owner. </del>  A set of values against which values of Claims can be compared as part of applying an Appraisal Policy for Evidence.  Reference values, golden measurements, or nominal values, although those terms typically assume comparison for equality, whereas here Reference Values might be more general and be used in any sort of <del> comparison.  Used By: Verifier; Produced By: Reference Value Provider. </del>  5.

harmonized phrasing in the terminology section -> roles are finally roles and changed Terminology item format
This sentence: creates a bit of cognitive dissonance. In the Terminology section, the Endorser, Ref-val Provider, RP Owner and Verifier Owner are defined as "entities", however, they don't include any of the roles (Verifier, RP, Attester).
That is a weirdly persistent bug that we have to squash once and for all. Attester, Verifier, Endorser, RVP, RP, RP Owner, and Verifier Owner are all roles. Roles are instantiated by entities, which is the term we now use under the premisethat the well-established and understood term principal is to hard to understand for a reader (sry, got a bit rant'y here). I think I added all the changes that fixes this issue to a PR that was abandoned at the end. It seems we missed to rescue my corresponding changes from that PR, though. Can anybody provide a pointer to these changes? Otherwise we have to dig that up in the next meeting.

A role performed by an entity (typically a device) whose Evidence must be appraised in order to infer the extent to which the Attester is considered trustworthy, such as when deciding whether  <ins> it is authorized to perform some operation. Produces: Evidence </ins> A role performed by an entity that depends on the validity of information about an Attester, for purposes of reliably applying application specific actions.  Compare /relying party/ in RFC4949.  <ins> Consumes: Attestation Results </ins> A role performed by an entity that appraises the validity of Evidence about an Attester and produces Attestation Results to be  <ins> used by a Relying Party. Consumes: Evidence, Reference Values, Endorsements, Appraisal Policy for Evidence </ins>  <ins> Produces: Attestation Results </ins>  <ins> A role performed by an entity (typically an administrator), that is authorized to configure Appraisal Policy for Attestation Results in a Relying Party. Produces: Appraisal Policy for Attestation Results A role performed by an entity (typically an administrator), that is authorized to configure Appraisal Policy for Evidence in a Verifier. </ins>  <ins> Produces: Appraisal Policy for Evidence </ins>  <ins> A role performed by an entity (typically a manufacturer) whose Endorsements help Verifiers appraise the authenticity of Evidence. Produces: Endorsements A role performed by an entity (typically a manufacturer) whose Reference Values help Verifiers appraise Evidence to determine if acceptable known Claims have been recorded by the Attester. Produces: Reference Values </ins> 4.2. A piece of asserted information, often in the form of a name/value  <ins> pair.  Claims make up the usual structure of Evidence and other 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  <ins> Evidence signing. Consumed By: Verifier Produced By: Endorser </ins> A set of Claims generated by an Attester to be appraised by a Verifier.  Evidence may include configuration data, measurements,  <ins> telemetry, or inferences. Consumed By: Verifier Produced By: Attester </ins> The output generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the  <ins> validity of the results. Consumed By: Relying Party Produced By: Verifier </ins> A set of rules that informs how a Verifier evaluates the validity of information about an Attester.  Compare /security policy/ in  <ins> RFC4949. Consumed By: Verifier Produced By: Verifier Owner </ins> 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. Consumed by: Relying Party Produced by: Relying Party Owner </ins> A set of values against which values of Claims can be compared as part of applying an Appraisal Policy for Evidence.  Reference values, golden measurements, or nominal values, although those terms typically assume comparison for equality, whereas here Reference Values might be more general and be used in any sort of  <ins> comparison. Consumed By: Verifier Produced By: Reference Value Provider </ins> 5.


this architecture. A conveyance protocol that provides authentication and integrity <del> protection can be used to convey unprotected Evidence, assuming the following properties exists: </del>  The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the <del> Attesting Environment(s) that collected claims about the Target </del>  Environment(s). All unprotected Evidence that is conveyed is supplied exclusively

I assume this is an escape hatch for unsigned CBOR. But I’m not sure the sentence makes sense… if the conveyance protocol provides protection, then it’s not unprotected evidence? Or is there some other point we’re trying to get at?
"URL to convey Evidence that is otherwise unprotected, relies on the conveyance protocol for the following protections: ..." I think unsigned CBOR (the UCCS draft) is one example of "unprotected Evidence". Maybe we can add a reference pointing to the UCCS draft.
` Maybe we can say "URL to convey Evidence that is otherwise unprotected itself", or "URL to convey Evidence that is otherwise not signed itself"?

this architecture. A conveyance protocol that provides authentication and integrity  <ins> protection can be used to convey Evidence that is otherwise unprotected (e.g., not signed).  Appropriate conveyance of unprotected Evidence (e.g., I-D.birkholz-rats-uccs) relies on the following conveyance protocol's protection capabilities: </ins> The key material used to authenticate and integrity protect the conveyance channel is trusted by the Verifier to speak for the  <ins> Attesting Environment(s) that collected Claims about the Target </ins> Environment(s). All unprotected Evidence that is conveyed is supplied exclusively


first act as an Attester, providing Evidence that the Owner can appraise, before the Owner would give the Relying Party an updated policy that might contain sensitive information.  In such a case, <del> mutual authentication or attestation might be needed, in which case typically one side's Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence. </del>  7.4. Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or appraisal policy to it.  This can be done similarly to how a Relying Party might establish trust in a <del> Verifier as discussed above, and in such a case, mutual authentication or attestation might even be needed as discussed in rpowner-trust. </del>  8. a Relying Party would appraise an Attestation Result for any other purpose.  12. 12.1.

1) Avoid the term "mutual attestation" 2) Add reference to CCC whitepaper for discussion of anonymous attestation Signed-off-by: Dave Thaler
Does this term (Mutual Authentication) need to be defined? Aren’t there lots of cases where mutual attestation might be employed?
We have not defined Mutual Authentication, why would Mutual Attestation be any different?
Could there be a reference to this other document, C3 document. I don’t know what it means, but all the cases here seem to ultimately rely on a unitary Verifier/Relying-Party somewhere in the chain. Maybe that’s not true… if the verifier and relying party trust each other by fiat, the roles need not be combined.
It means this: Say you have devices A (normally an Attester) and V (normally a Verifier) and RP (normally a Relying Party). A can say it won't send Evidence to V unless V first attests to A. Thus, A starts by acting as a Relying Party where V is the Attester. If A devices that V is trustworthy, then A can start sending sensitive Evidence to V. Note this does not require anywhere have a combined Verifier/Relying Party.
I can see how: "Verifier/Relying Party" looks misleading here Dave illustrated well that this text is not about a "unitary Verifier/Relying-Party" this is related to the current mutual authentication/attestation discussion that recently emerged I'll try to pitch this issues in the next meeting so we can deal with it in the same swoop as mutual authentication. Personally, I'd simply leave the text as is.
reference
closed with email: URL
Closing since Michael's comment above says "closed with email" but didn't actually close the issue EMAIL wrote: The design team closed a few remaining issues and pull requests. Two pull requests turned out to fix the same text, so we needed to be sure we really liked the text we chose. On issue , wontfix: URL -- Attester We discussed the issue of how the RP trusts that the Verifier is operating correctly. (Who Verifies the Verifier?) This does not lead to architecting a "unitary Verifier/Relying-Party somewhere in the chain", as the roles can still be split out. When we dealt with the "mutual attestation" issue, in URL we changed text that has relevance to this issue. We have no issues open. No pull requests. If the Shepherd hasn't already started, then they should please start. Michael Richardson . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

first act as an Attester, providing Evidence that the Owner can appraise, before the Owner would give the Relying Party an updated policy that might contain sensitive information.  In such a case,  <ins> authentication or attestation in both directions might be needed, in which case typically one side's Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence. See privacy-considerations for more discussion. </ins> 7.4. Verifier Owner may need to trust the Verifier before giving the Endorsement, Reference Values, or appraisal policy to it.  This can be done similarly to how a Relying Party might establish trust in a  <ins> Verifier. As discusssed in rpowner-trust, authentication or attestation in both directions might be needed, in which case typically one side's identity or Evidence must be considered safe to share with an untrusted entity, in order to bootstrap the sequence.  See privacy- considerations for more discussion. </ins> 8. a Relying Party would appraise an Attestation Result for any other purpose. <ins> Another approach to deal with Evidence is to remove PII from the Evidence while still being able to verify that the Attester is one of a large set.  This approach is often called "Direct Anonymous Attestation".  See CCC-DeepDive section 6.2 for more discussion. </ins> 12. 12.1.


3.3. <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, such as in the examples described in more detail in layered-attestation and compositedevice.  Other examples may exist.  Besides, the examples discussed could be combined into even more complex implementations. Claims are collected from Target Environments, as shown in twotypes- env.  That is, Attesting Environments collect the values and the information to be represented in Claims, by reading system registers and variables, calling into subsystems, taking measurements on code, memory, or other security related assets of the Target Environment. Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  There is no limit to or requirement on the types of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.  An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments. </del>  3.4.

` Can you say what these are? I don’t think they need to be in the glossary, but some clue as to how you tell one from another might help see why there’s a distinction
My opinion is that the 2nd paragraph of the section (the paragraph after the sentence quoted) already defines them. I don't know how to make that clearer.
fixed by .

3.3.  <ins> As shown in twotypes-env, 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, such as in the examples described in more detail in layered-attestation and compositedevice.  Other examples may exist.  Besides, the examples discussed could be combined into even more complex implementations. Claims are collected from Target Environments.  That is, Attesting Environments collect the values and the information to be represented in Claims, by reading system registers and variables, calling into subsystems, taking measurements on code, memory, or other security related assets of the Target Environment.  Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  There is no limit to or requirement on the types of hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.  An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments. </ins> 3.4.


In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the Attester.  For example the owner or user of a mobile phone or FIDO <del> authenticator is not trusted.  The point of remote attestation is for the Relying Party to be able to trust the Attester even though they don't trust the user or owner. Some of the measures for low level security include process or application isolation by a high-level operating system, and perhaps restricting access to root or system privilege.  For extremely simple single-use devices that don't use a protected mode operating system, like a Bluetooth speaker, the isolation might only be the plastic housing for the device. At medium level security, a special restricted operating environment like a Trusted Execution Environment (TEE) might be used.  In this case, only security-oriented software has access to the Attester and key material. For high level security, specialized hardware will likely be used providing protection against chip decapping attacks, power supply and clock glitching, faulting injection and RF and power side channel attacks. </del>  12.1.2.

Update section on-device attesters
This section, as put, is kind of a big leap, no? I think the important part of this next level, is the introduction of a hardware root of trust like a TPM to eliminate the need to trust the device’s operating system software in reporting attestation results.
NAME How about "For strongest security,...." to avoid confusion with high level OS.
This also already fixed by existing text . 1) This wording implies that there are other cases where it’s acceptable to exfiltrate or modify keys. Do those still count as Attestation? I know RATS must be ‘inclusive’, but is it meant to include absolutely everything? For example: If I had a router with the following features: A root password A serial number in a file owned by root TLS A shell script that computes the hash of the kernel and stores it in a file on startup A Show command that prints the serial number, software version string, date and the hash. … would I have a RATS-Compliant Attestation System? It provides evidence The evidence is protected by encryption (TLS) There are a zillion different formats for evidence, so I assume ASCII strings count The Attesting Environment is protected by the root password Freshness is assured by the date, which in turn is protected by the root password. 2) The example goes on to say that this statement is not true; you don’t need process isolation. 3) What does a plastic case have to do with attestation? 4)
The last three paragraphs have to be taken together as they're describing three hardening levels ('low'. 'medium', 'high'). I don't believe the goal of the security considerations is to define hardening levels. If so, it should be in a different part of the document. The preceding paragraph - "In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the Attester. For example the owner or user of a mobile phone or FIDO authenticator is not trusted. The point of remote attestation is for the Relying Party to be able to trust the Attester even though they don't trust the user or owner." - introduces the concept that the Attester's domain isolation can have multiple levels of hardening. It would be cleaner to capture this idea as the security consideration. e.g. "The Attester's domain isolation technique may have differing protection properties that rely on different hardening strategies. These differences can be accounted for by including endorsement Claims that describes protection properties and hardening strategy applied to the Attester". Some examples may follow if that makes sense where the examples already provided seems to be: FIDO Process / app isolation (aka memory ring protections) physical housing TEE side channel attack mitigations

In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the Attester.  For example the owner or user of a mobile phone or FIDO  <ins> authenticator, having full control over the keys, might not be trusted to use the keys to report Evidence about the environment that protects the keys.  The point of remote attestation is for the Relying Party to be able to trust the Attester even though they don't trust the user or owner. Some of the measures for a minimally protected system might include process or application isolation by a high-level operating system, and perhaps restricting access to root or system privilege.  For extremely simple single-use devices that don't use a protected mode operating system, like a Bluetooth speaker, the isolation might only be the plastic housing for the device. Measures for a moderately protected system could include a special restricted operating environment like a Trusted Execution Environment (TEE) might be used.  In this case, only security-oriented software has access to the Attester and key material. Measures for a highly protected system could include specialized hardware that is used to provide protection against chip decapping attacks, power supply and clock glitching, faulting injection and RF and power side channel attacks. </ins> 12.1.2.