Draft: draft-ietf-rats-architecture

Commentary: Throughout the document the term " trust anchor " is meant in the to be a public key and associated ( meta)data . This definition does not cover attestation schemes based on symmetric crypto , e.g. , , and   , and should be extended to also cover such cases . 
 Was there specific text that you believe needs to be changed ? 
 yes , we identified at least two places : § 7.1 and § 12.4 . 
 Reads great to me . Any other opinions ?
Paragraph (version A):
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 A):
Thus, trusting a Verifier might be expressed by having the Relying
Party store the Verifier's public key or certificate in its trust
anchor store, or might be expressed by storing the public key or
certificate of an entity (e.g., a Certificate Authority) that is in
the Verifier's certificate path.  For example, the Relying Party can
verify that the Verifier is an expected one by out of band
establishment of key material, combined with a protocol like TLS to
communicate.  There is an assumption that between the establishment
of the trusted key material and the creation of the Evidence, that
the Verifier has not been compromised.
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.  In the context of this
document, a trust anchor may also be a symmetric key, as in TCG-DICE-
SIBDA or the symmetric mode described in I-D.tschofenig-rats-psa-
token.
Paragraph (version B):
Thus, trusting a Verifier might be expressed by having the Relying
Party store the Verifier's key or certificate in its trust anchor
store, or might be expressed by storing the public key or certificate
of an entity (e.g., a Certificate Authority) that is in the
Verifier's certificate path.  For example, the Relying Party can
verify that the Verifier is an expected one by out of band
establishment of key material, combined with a protocol like TLS to
communicate.  There is an assumption that between the establishment
of the trusted key material and the creation of the Evidence, that
the Verifier has not been compromised.
Paragraph (version A):
As noted in trustmodel, Verifiers and Relying Parties have trust
anchor stores that must be secured.  RFC6024 contains more discussion
of trust anchor store requirements.  Specifically, a trust anchor
store must resist modification against unauthorized insertion,
deletion, and modification.
Paragraph (version B):
As noted in trustmodel, Verifiers and Relying Parties have trust
anchor stores that must be secured.  RFC6024 contains more discussion
of trust anchor store requirements for protecting public keys.
Section 6 of NIST-800-57-p1 contains a comprehensive treatment of the
topic, including the protection of symmetric key material.
Specifically, a trust anchor store must resist modification against
unauthorized insertion, deletion, and modification.  Additionally, if
the trust anchor is a symmetric key, the trust anchor store must not
allow unauthorized read.