Original text:
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 <del> 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.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer. Claims about a root of trust typically are asserted by an Endorser. </del>  The example device illustrated in layered includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to <del> appraise the trustworthiness of that manufacturer's devices.  In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for the Attester's ability to securely generate Evidence. </del>  In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material

Reviewer comments:
Uses text copied from the TEEP arch draft. Addresses Signed-off-by: Dave Thaler
Does “trust anchor store” in Layered Attestation Environments require an introduction?
I advocate taking it out. See and . If / when "trust anchor store" is in the architecture document it should be in the establishment of trust in the basic non-layered Attester. It should be somewhere in section 7.
PR addresses the original issue but there is more needed than just what is in PR to fully address this in my view. Two pieces remain: 1) Currently the trust anchor store is mentioned in the Verifier but not the Relying Party, and appropriate language should be updated in the Relying Party section also. 2) Unlike the TEEP architecture, the Security Consideration section focuses on the attester and so does not mention securing the trust anchor store on the Verifier and Relying Party.
Having merged , the definition of trust-anchor store definition will get moved upwards so that it can be referenced in Relying Party section, and then also a SC paragraph about securing the store.

Revised text:
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  <ins> trust can be established in various ways as discussed in verifier. In layered attestation, a root of trust is the initial Attesting Environment.  Claims can be collected from or about each layer.  The corresponding Claims can be structured in a nested fashion that reflects the nesting of the Attester's layers.  Normally, Claims are not self-asserted, rather a previous layer acts as the Attesting Environment for the next layer.  Claims about a root of trust typically are asserted by an Endorser. </ins> The example device illustrated in layered includes (A) a BIOS stored in read-only memory, (B) a bootloader, and (C) an operating system The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to  <ins> appraise the trustworthiness of that manufacturer's devices.  Such trust is expressed by storing one or more "trust anchors" in a secure location known as a trust anchor store. As defined in RFC6024, "A trust anchor represents an authoritative entity via a public key and associated data.  The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative."  The Trust Anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its public key algorithm and parameters. In a typical solution, a Verifier comes to trust an Attester indirectly by having an Endorser (such as a manufacturer) vouch for the Attester's ability to securely generate Evidence, in which case the Endorser's key material is stored in the Verifier's trust anchor store. </ins> In some solutions, a Verifier might be configured to directly trust an Attester by having the Verifier have the Attester's key material