Draft: draft-ietf-rats-architecture

Commentary: Also add a brief security considerations section , based on text from the TEEP architecture draft . Signed - off - by :   
 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 . 
 The last sentence of the abstract is : but " such " remote attestation procedures are not defined earlier .
Paragraph (version A):
This document covers scenarios for which a Relying Party trusts a
Verifier that can appraise the trustworthiness of information about
an Attester.  Such trust might come by the Relying Party trusting the
Verifier (or its public key) directly, or might come by trusting an
entity (e.g., a Certificate Authority) that is in the Verifier's
certificate chain.
Paragraph (version B):
This document covers scenarios for which a Relying Party trusts a
Verifier that can appraise the trustworthiness of information about
an Attester.  Such trust might come by the Relying Party trusting the
Verifier (or its public key) directly, or might come by trusting an
entity (e.g., a Certificate Authority) that is in the Verifier's
certificate path.  Such trust is expressed by storing one or more
"trust anchors" in a secure location known as a trust anchor store.
Paragraph (version A):
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
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.
Paragraph (version B):
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
appraise the trustworthiness of that manufacturer's devices.  Such
trust is expressed by storing one or more trust anchors in the
Verifier's trust anchor store.
Paragraph (version B):
As noted in trustmodel, Verifiers and Relying Parties have trust
anchor stores that must be secured.  Specifically, a trust anchor
store must resist modification against unauthorized insertion,
deletion, and modification.
Paragraph (version B):
If certificates are used as trust anchors, Verifiers and Relying
Parties are also responsible for validating the entire certificate
path up to the trust anchor, which includes checking for certificate
revocation.  See Section 6 of RFC5280 for details.