Draft: draft-ietf-rats-architecture

Commentary: Uses text copied from the TEEP arch draft .   - 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 .
Paragraph (version A):
By definition, the Attester role generates Evidence.  An Attester may
consist of one or more nested environments (layers).  The root layer
of an Attester includes at least one root of trust.  In order to
appraise Evidence generated by an Attester, the Verifier needs to
trust the Attester's root of trust.  Trust in the Attester's root of
trust can be established either directly (e.g., the Verifier puts the
root of trust's public key into its trust anchor store) or
transitively via an Endorser (e.g., the Verifier puts the Endorser's
public key into its trust anchor store).  In layered attestation, a
root of trust is the initial Attesting Environment.  Claims can be
collected from or about each layer.  The corresponding Claims can be
structured in a nested fashion that reflects the nesting of the
Attester's layers.  Normally, Claims are not self-asserted, rather a
previous layer acts as the Attesting Environment for the next layer.
Claims about a root of trust typically are asserted by an Endorser.
Paragraph (version B):
By definition, the Attester role generates Evidence.  An Attester may
consist of one or more nested environments (layers).  The root layer
of an Attester includes at least one root of trust.  In order to
appraise Evidence generated by an Attester, the Verifier needs to
trust the Attester's root of trust.  Trust in the Attester's root of
trust can be established in various ways as discussed in verifier.
Paragraph (version B):
In layered attestation, a root of trust is the initial Attesting
Environment.  Claims can be collected from or about each layer.  The
corresponding Claims can be structured in a nested fashion that
reflects the nesting of the Attester's layers.  Normally, Claims are
not self-asserted, rather a previous layer acts as the Attesting
Environment for the next layer.  Claims about a root of trust
typically are asserted by an Endorser.
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.  In a
typical solution, a Verifier comes to trust an Attester indirectly by
having an Endorser (such as a manufacturer) vouch for the Attester's
ability to securely generate Evidence.
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 a secure
location known as a trust anchor store.
Paragraph (version B):
As defined in RFC6024, "A trust anchor represents an authoritative
entity via a public key and associated data.  The public key is used
to verify digital signatures, and the associated data is used to
constrain the types of information for which the trust anchor is
authoritative."  The Trust Anchor may be a certificate or it may be a
raw public key along with additional data if necessary such as its
public key algorithm and parameters.
Paragraph (version B):
In a typical solution, a Verifier comes to trust an Attester
indirectly by having an Endorser (such as a manufacturer) vouch for
the Attester's ability to securely generate Evidence, in which case
the Endorser's key material is stored in the Verifier's trust anchor
store.