Original text:
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 device illustrated in layered includes (A) a BIOS stored in read- only memory, (B) an operating system kernel, and (C) an application or workload. Attesting Environment A, the read-only BIOS in this example, has to ensure the integrity of the bootloader (Target Environment B).  There are potentially multiple kernels to boot, and the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, the Claims relating to the integrity of the bootloader have to be measured securely.  At this stage of the boot-cycle of the device, the Claims collected typically cannot be composed into Evidence. </del>  After the boot sequence is started, the BIOS conducts the most important and defining feature of layered attestation, which is that <del> the successfully measured Target Environment B now becomes (or contains) an Attesting Environment for the next layer.  This procedure in layered attestation is sometimes called "staging".  It is important that the new Attesting Environment B not be able to alter any Claims about its own Target Environment B.  This can be ensured having those Claims be either signed by Attesting Environment A or stored in an untamperable manner by Attesting Environment A. </del>  Continuing with this example, the bootloader's Attesting Environment <del> B is now in charge of collecting Claims about Target Environment C, which in this example is the kernel to be booted.  The final Evidence thus contains two sets of Claims: one set about the bootloader as measured and signed by the BIOS, plus a set of Claims about the kernel as measured and signed by the bootloader. </del>  This example could be extended further by making the kernel become another Attesting Environment for an application as another Target environment before the next environment is started.  In general, the number of layers may vary by device or implementation, and an Attesting Environment might even have multiple Target Environments <del> that it measures, rather than only one as shown in layered. </del>  3.5.

Reviewer comments:
Signed-off-by: Dave Thaler
The relatively abstract text in Layered Attestation Environments could really benefit from a common real world example, e.g. the thing formerly referred to as Secure Boot.
Are you saying that layered attestation is a form of staged boot with Verifiers on the local device? If so, Figure 3 is wrong since it doesn't show the local Verifiers. I think it is an overreach for RATS to classify all staged boot as a form of layered Attestation. See .
The example is so long that the reader misses that it's an example, and the details are too deep.
The illustration is no longer an abstract example.

Revised text:
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 kernel. The first Attesting Environment, the read-only BIOS in this example, has to ensure the integrity of the bootloader (the first Target Environment).  There are potentially multiple kernels to boot, and the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, the Claims relating to the integrity of the bootloader have to be measured securely.  At this stage of the boot-cycle of the device, the Claims collected typically cannot be composed into Evidence. </ins> After the boot sequence is started, the BIOS conducts the most important and defining feature of layered attestation, which is that  <ins> the successfully measured bootloader now becomes (or contains) an Attesting Environment for the next layer.  This procedure in layered attestation is sometimes called "staging".  It is important that the bootloader not be able to alter any Claims about itself that were collected by the BIOS.  This can be ensured having those Claims be either signed by the BIOS or stored in a tamper-proof manner by the BIOS. </ins> Continuing with this example, the bootloader's Attesting Environment  <ins> is now in charge of collecting Claims about the next Target Environment, which in this example is the kernel to be booted.  The final Evidence thus contains two sets of Claims: one set about the bootloader as measured and signed by the BIOS, plus a set of Claims about the kernel as measured and signed by the bootloader. </ins> This example could be extended further by making the kernel become another Attesting Environment for an application as another Target environment before the next environment is started.  In general, the number of layers may vary by device or implementation, and an Attesting Environment might even have multiple Target Environments  <ins> that it measures, rather than only one as shown by example in layered. </ins> 3.5.