Draft: draft-ietf-rats-architecture

Commentary: A proposal for addressing a FIXME as called out in issue Signed - off - by :   
 Since people did n't like the previous version of this PR , I rewrote the layered attestation section to not need to define a term at all . Now it just uses one specific example to illustrate the concept , rather than trying to combine multiple variations in the same text . 
 Section 3.1 of the draft says : This fixme needs to be fixed somehow . 
 There are also still statements like these in section 4.3 : and 
 Regarding " we are looking for a better term than UEFI / BIOS / Firmware " , what do folks think about " first mutable environment " ? Example in context : OLD : The very first Attesting Environment has to ensure the integrity of the ( U)EFI / BIOS / Firmware that initially boots up a composite device ( e.g. , a cell phone ) . NEW : he very first Attesting Environment has to ensure the integrity of the first mutable environment that initially boots up a composite device ( e.g. , a cell phone ) . 
 We have a terminology convention for the thing being referred to as “ UEFI / BIOS / FW / FMC etc . ” called “ Target Environment ” . We should use our preferred abstract terminology then provide intuition in the form of examples NEW2 : The very first Attesting Environment has to ensure the integrity of the Target Environment ( e.g. the BIOS , firmware or first mutable environment that initially boots up a composite device ) . I do n’t believe the example of a cell phone is helpful . Cell phones neither use BIOS ( AFAIK ) or commonly use the term ‘ first mutable environment ’ . 
 No , those terms are not synonymous . In layered attestation , the UEFI / BIOS / firmware is also an " Attesting Environment " , and software above it ( or started later than it ) are also Target Environments , so we can not use the term Target Environment to mean UEFI / BIOS / firmware in general . See PR for proposed use in context . 
 I agree with the text in as it does n’t use either   or Target Env . The issue I have with NEW is the asymmetrical use of terms “ Attesting Env ” and other stuff not “ Target Env ” . If use of Target Env is wrong then so is use of   . The section on “ Two Environments ” makes these terms clear and their applicationin a Layered Device attestation also clear ( in terms of cascaded measurement , attestations and executions ) . Are you suggesting the resolution to is to substitute with text from ? Thx ,  
 I believe this can be closed now that is merged .
Paragraph (version A):
A very common example is elaborated on to illustrate Layered
Attestation.
Paragraph (version A):
The very first Attesting Environment has to ensure the integrity of
the (U)EFI / BIOS / Firmware that initially boots up a composite
device (e.g., a cell phone).
Paragraph (version A):
These Claims have to be measured securely.  At this stage of the
boot-cycle of a composite device, the Claims collected typically
cannot be composed into Evidence.
Paragraph (version A):
The very first Attesting Environment in this example can be a
hardware component that is a Static Code Root of Trust.  As in any
other scenario, this hardware component is the first Attesting
Environment.  It collects a rather concise number of Claims about the
Target Environment.  The Target Environment in this example is the
(U)EFI / BIOS / Firmware After the boot sequence started, the Target
Environment conducts the most important and defining feature of
Layered Attestation: The successfully measured environment that is
the (U)EFI / BIOS / Firmware now becomes the Attesting Environment.
Analogously, the Attesting Environment hands off its duty to one of
its Target Environments.  This procedure in Layered Attestation is
called Staging.
Paragraph (version A):
Now, the duties have been transferred and Layered Attestation takes
place.  The initial Attesting Environment relinquishes its duties to
the Target Environment.  It is important to note that the new
Attesting Environment cannot alter the content about its own
measurements.  If the Attesting Environment would be able to do that,
Layered Attestation would become unfeasible.
Paragraph (version A):
In this example the duty of being the Attesting Environment is now
taken over by the (U)EFI / BIOS / Firmware that was the Attested
Environment before.  This transfer of duty is the essential part of
Layered Attestation.  The (U)EFI / BIOS / Firmware now is the
Attesting Environment.  The next Target Environment is, in this
example, a bootloader.  There are potentially multiple kernels to
boot, the decision is up to the bootloader.  Only a bootloader with
intact integrity will make an appropriate decision.  Therefore,
Claims about the integrity of a bootloader are now collected by the
freshly appointed Attesting Environment that is the (U)EFI / BIOS /
Firmware.  Collected Claims have to be stored by the current
Attesting Environment in a similar shielded and secured manner, so
that the next Attesting Environment is not capable of altering the
collection of claims stored.
Paragraph (version A):
Continuing with this example, the bootloader is now in charge of
collecting Claims about the next execution environment.  The next
execution environment in this example is the kernel to be booted up.
Analogously, the next transfer of duties in this Layered Attestation
example occurs: The duty of being an Attesting Environment is
transferred to a successfully measured kernel.  In this sequence, the
kernel is now collecting additional Claims and is storing them in a
secure and shielded manner.
Paragraph (version A):
The essence of this example is a cascade of staged boot environments.
Each environment (after the initial one that is a root-of-trust) has
the duty of measuring its next environment before it is started.
Therefore, creating a layered boot sequence and correspondingly
enabling Layered Attestation.
Paragraph (version B):
By definition, the Attester role takes on the duty to create
Evidence.  The fact that an Attester role is composed of environments
that can be nested or staged adds complexity to the architectural
layout of how an Attester can be composed and therefore has to
conduct the Claims collection in order to create believable
attestation Evidence.
Paragraph (version B):
layered depicts an example of a device that includes (A) a BIOS
stored in read-only memory in this example, (B) an updatable
bootloader, and (C) an operating system kernel.
Paragraph (version B):
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, these Claims have to be measured
securely.  At this stage of the boot-cycle of the device, the Claims
collected typically cannot be composed into Evidence.
Paragraph (version B):
After the boot sequence is started, the BIOS conducts the most
important and defining feature of layered attestation, which is that
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.
Paragraph (version B):
Continuing with this example, the bootloader's Attesting Environment
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.
Paragraph (version B):
This example could be extended further by, say, making the kernel
become another Attesting Environment for an application as another
Target Environment, resulting in a third set of Claims in the
Evidence pertaining to that application.
Paragraph (version B):
The essence of this example is a cascade of staged environments.
Each environment has the responsibility of measuring the next
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
that it measures, rather than only one as shown in layered.