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

Discussion:
The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a <del> device as well as potentially any users of the device.  In many cases, the whole point of attestation procedures is to provide reliable information about the type of the device and the firmware/ software that the device is running.  This information might be particularly interesting to many attackers.  For example, knowing that a device is running a weak version of firmware provides a way to aim attacks better. Many Claims in Evidence, many Claims in Attestation Results, and Appraisal Policies potentially contain Personally Identifying Information (PII) depending on the end-to-end use case of the remote attestation procedure.  Remote attestation that includes containers and applications, e.g., a blood pressure monitor, may further reveal details about specific systems or users. </del> <ins> device as well as potentially any users of the device. In many cases, the whole point of attestation procedures is to provide reliable information about the type of the device and the firmware/software that the device is running. This information might be particularly interesting to many attackers. For example, knowing that a device is running a weak version of firmware provides a way to aim attacks better. In some circumstances, if an attacker can become aware of Endorsements, Reference Values, or appraisal policies, it could potentially provide an attacker with insight into defensive mitigations.  It is recommended that attention be paid to confidentiality of such information. Additionally, many Claims in Evidence, many Claims in Attestation Results, and appraisal policies potentially contain Personally Identifying Information (PII) depending on the end-to-end use case of the remote attestation procedure.  Remote attestation that includes containers and applications, e.g., a blood pressure monitor, may further reveal details about specific systems or users. </ins> In some cases, an attacker may be able to make inferences about the contents of Evidence from the resulting effects or timing of the

boot, or immutable hardware/ROM. It is also important that the appraisal policy was itself obtained <del> securely.  If an attacker can configure appraisal policies for a Relying Party or for a Verifier, then integrity of the process is compromised. </del> <ins> securely.  If an attacker can configure or modify appraisal policies, Endorsements or Reference Values for a Relying Party or for a Verifier, then integrity of the process is compromised. </ins> Security protections in RATS may be applied at different layers, whether by a conveyance protocol, or an information encoding format.