Change:
This is about the text that describes layered attestation and Figure 3, the one with environments A, B and C. I think the critical point about layered attestation (if I understand it) is that the remote Verifier must evaluate the evidence for target environment B with a positive result as a precondition to evaluating the evidence for C. This critical point isn't mentioned in the text. The other possibility is Attesting Environment A is also the Verifier for the evidence from target environment B. There are two roles in the same box, Attester and Verifier. This seems to be implied by the paragraph after Figure 3. The paragraph that starts "Attesting Environment A... has to ensure the integrity of the boot loader (Target Environment B)". However, figure 3 only shows a remote Verifier. A third possibility is A does ensure integrity of B, but it's not Attestation. It is just typical staged boot that is being described. It is not layered attestation. I think we should distinguish staged boot from local Attestation Verification. It doesn't seem right to claim that all staged boot is local Attestation Verification and thus RATS applies to all staged boot. In the cases where A does locally ensure the integrity of B either via staged boot or a local Verifier, then the remote verifier can actually trust the evidence about C without first evaluating the evidence from B. Or, all three of the above could be intended. There is nothing wrong with implementations that do any of these or combinations of them. I think the text should decide which of the three it is going after here and be clear about them.
Agreedtrust relations between different layers should be clarified. It seems that the concept of trust chain could be used to describe this trust and attestation relations in different layers.
I think the intent of the text is the first approach, i.e., the one for which Laurence says:
In the first approach, if A is the BIOS (root of trust ?), and B is the bootloader, I'm not sure if bootloader has the ability to communicate with remote verifier via network or other methods.
Typically the evidence is provided to some service or application running in or on top of the kernel, that can send the evidence to the verifier or relying party.
I understand and agree with your opinion. But that means the fiuge 3 may be inaccurate. The arrow mark orignated from B and pointed to verifier may mislead readers. And the integrity and confidentiality of evidence also need to be protected carefully. : )
Rather than adjust the diagram to show conveyance of bootloader has no network stack, instead, we shall add note to the effect that the diagram is a conceptual flow of how the trust is conveyed, not how the data is "physically" transmitted.
See PR for EAT claims for layered attestation. URL This PR supports types of layered attestation: 1) the Verifier decided on the trust and 2) the Device / root / lower layer attesting environment decides.
NAME to validate that this was done.
Maybe closed in URL
Seems to have found consensus for WGLC

Discussion:
Owner, and/or are programmed into the Relying Party.  This procedure is called the appraisal of Attestation Results. <del> 3.1. The Verifier, when appraising Evidence, or the Relying Party, when appraising Attestation Results, checks the values of some Claims against constraints specified in its appraisal policy.  Examples of such constraints checking include: comparison for equality against a Reference Value, or a check for being in a range bounded by Reference Values, or membership in a set of Reference Values, or a check against values in other Claims. The actual data format and semantics of any Appraisal Policy is implementation specific. 3.2. Reference Values used in appraisal procedures come from a Reference Value Provider and are then used by the appraisal policy. The actual data format and semantics of any Reference Values are specific to Claims and implementations.  This architecture document does not define any general purpose format for Reference Values or general means for comparison. 3.3. </del> <ins> See messages for further discussion of the conceptual messages shown in dataflow.  ## Two Types of Environments of an Attester </ins> As shown in twotypes-env, an Attester consists of at least one Attesting Environment and at least one Target Environment.  In some

the combination of the TPM together with whatever component is feeding it the measurements. <del> 3.4. </del> <ins> 3.1. </ins> By definition, the Attester role generates Evidence.  An Attester may consist of one or more nested environments (layers).  The root layer

that it measures, rather than only one as shown by example in layered. <del> 3.5. </del> <ins> 3.2. </ins> A composite device is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by the appraisal

In this scenario, the trust model described in trustmodel can also be applied to an inside Verifier. <del> 3.6. </del> <ins> 3.3. </ins> An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  Multiple entities can

8. <ins> dataflow illustrates the flow of a conceptual messages between various roles.  This section provides additional elaboration and implementation considerations.  It is the responsibility of protocol specifications to define the actual data format and semantics of any relevant conceptual messages. </ins> 8.1. Evidence is a set of Claims about the target environment that reveal

8.3. <ins> Reference Values used in appraisal procedures come from a Reference Value Provider and are then used by the Verifier to compare to Evidence.  Reference Values with matching Evidence produces acceptable Claims.  Additionally, appraisal policy may play a role in determining the acceptance of Claims. 8.4. </ins> Attestation Results are the input used by the Relying Party to decide the extent to which it will trust a particular Attester, and allow it to access some data or perform some operation.

relationship with one entity, rather than a larger set of entities, for purposes of its appraisal policy. <ins> 8.5. The Verifier, when appraising Evidence, or the Relying Party, when appraising Attestation Results, checks the values of matched Claims against constraints specified in its appraisal policy.  Examples of such constraints checking include: comparison for equality against a Reference Value, or a check for being in a range bounded by Reference Values, or membership in a set of Reference Values, or a check against values in other Claims. Upon completing all appraisal policy constraints, the remaining Claims are accepted as input toward determining Attestation Results, when appraising Evidence, or as input to a Relying Party, when appraising Attestation Results. </ins> 9. The following diagram illustrates a relationship to which remote