Draft: draft-ietf-rats-architecture

Commentary: 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 is n'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 does n'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 . This PR supports types of layered attestation : 1 ) the Verifier decided on the trust and 2 ) the Device / root / lower layer attesting environment decides . 
 to validate that this was done . 
 Maybe closed in 
 Seems to have found consensus for WGLC
Paragraph (version A):
The actual data format and semantics of any Appraisal Policy is
implementation specific.
Paragraph (version A):
Reference Values used in appraisal procedures come from a Reference
Value Provider and are then used by the appraisal policy.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.