Code change:
12. <ins> 12.1. Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning the Attestation Key Material.  When either of these are compromised, the remote attestation becomes worthless because the attacker can forge Evidence. Remote attestation applies to use cases with a range of security requirements, so the protections discussed here range from low to high security where low security may be only application or process isolation by the device's operating system and high security involves specialized hardware to defend against physical attacks on a chip. 12.1.1. 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. 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. 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. 12.1.2. Attestation key provisioning is the process that occurs in the factory or elsewhere that establishes the signing key material on the device and the verification key material off the device.  Sometimes this is referred to as "personalization". One way to provision a key is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality of the generator, as well as the path over which the key is provisioned, is necessary.  This can be achieved in a number of ways. Confidentiality can be achieved entirely with physical provisioning facility security involving no encryption at all.  For low-security use cases, this might be simply locking doors and limiting personnel that can enter the facility.  For high-security use cases, this might involve a special area of the facility accessible only to select security-trained personnel. Cryptography can also be used to support confidentiality, but keys that are used to then provision attestation keys must somehow have been provisioned securely beforehand (a recursive problem). In many cases both some physical security and some cryptography will be necessary and useful to establish confidentiality. Another way to provision the key material is to generate it on the device and export the verification key.  If public key cryptography is being used, then only integrity is necessary.  Confidentiality is not necessary. In all cases, the Attestation Key provisioning process must ensure that only attestation key material that is generated by a valid Endorser is established in Attesters and then configured correctly. For many use cases, this will involve physical security at the facility, to prevent unauthorized devices from being manufactured that may be counterfeit or incorrectly configured. 12.2. </ins> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy must support end-to-end

Related discussion:
text: This is to partially
In section 4.2 there is a list of "places an attesting environment can exist" that is limited. The text should be softened to say the list is only examples and there is no formal limitation or requirement on the security of an Attester. There should probably be a detailed description of Attester security in the document, but it should be in Security Considerations. This seems like a glaring omission from Security Considerations.
The considerations weren't the extent of the issue. There is still text in 4.2 that I think needs changing.