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

Discussion:
4.1. <ins> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments.  One example is a set of components in a boot sequence (e.g., ROM, firmware, OS, and application) where a Target Environment is the Attesting Environment for the next environment in the boot sequence. Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be represented in claims.  Attesting Environments then format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence. Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). 4.2. </ins> A Composite Attester is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by evaluating all these sub-entities.  Each sub-entity has at least one Attesting

6. <del> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments.  One example is a set of components in a boot sequence (e.g., ROM, firmware, OS, and application) where a Target Environment is the Attesting Environment for the next environment in the boot sequence. Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be represented in claims.  Attesting Environments then format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence. Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). 7. </del> The scope of this document is scenarios for which a Relying Party trusts a Verifier that can evaluate the trustworthiness of information about an Attester.  Such trust might come by the Relying

background-check model, this Evidence may also be revealed to Relying Party(s). <del> 8. </del> <ins> 7. </ins> <del> 8.1. </del> <ins> 7.1. </ins> Today, Evidence tends to be highly device-specific, since the information in the Evidence often includes vendor-specific

isolation would require Appraisal Policy to be based on device- specific details (e.g., a device public key). <del> 8.2. </del> <ins> 7.2. </ins> An Endorsement is a secure statement that some entity (e.g., a manufacturer) vouches for the integrity of the device's signing

may need device-specific information such as a public key for the device or component or user on the device. <del> 8.3. </del> <ins> 7.3. </ins> Attestation Results may indicate compliance or non-compliance with a Verifier's Appraisal Policy.  A result that indicates non-compliance

relationship with one entity, rather than a larger set of entities, for purposes of its Appraisal Policy. <del> 9. </del> <ins> 8. </ins> The following diagram illustrates a relationship to which attestation is desired to be added:

Evidence that encodes claims in one format, while issuing Attestation Results that encode claims in a different format. <del> 10. </del> <ins> 9. </ins> It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct.

have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. <del> 11. </del> <ins> 10. </ins> The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a

for detailing what kinds of information are disclosed, and to whom they are exposed. <del> 12. </del> <ins> 11. </ins> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation

attest to the health of the client providing the Appraisal Policy needs to be considered. <del> 13. </del> <ins> 12. </ins> This document does not require any actions by IANA. <del> 14. </del> <ins> 13. </ins> Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,