Draft: draft-ietf-rats-architecture

Commentary: attempt to bring the manufacturer / attester / verifier full circle without insisting that endorsements always occuring .
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
solutions with weaker security, a Verifier might be configured to
implicitly trust firmware or even software (e.g., a hypervisor).
That is, it might appraise the trustworthiness of an application
component, operating system component, or service under the
assumption that information provided about it by the lower-layer
hypervisor or firmware is true.  A stronger level of assurance of
security comes when information can be vouched for by hardware or by
ROM code, especially if such hardware is physically resistant to
hardware tampering.  The component that is implicitly trusted is
often referred to as a root of trust.
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.  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):
In some solutions, a Verifier might be configured to directly trust
an Attester by having the Verifier have the Attester's key material
(rather than the Endorser's) in its trust anchor store.
Paragraph (version B):
Such direct trust must first be established at the time of trust
anchor store configuration either by checking with an Endorser at
that time, or by conducting a security analysis of the specific
device.  Having the Attester directly in the trust anchor store
narrows the Verifier's trust to only specific devices rather than all
devices the Endorser might vouch for, such as all devices
manufactured by the same manufacturer in the case that the Endorser
is a manufacturer.
Paragraph (version B):
Such narrowing is often important since physical possession of a
device can also be used to conduct a number of attacks, and so a
device in a physically secure environment (such as one's own
premises) may be considered trusted whereas devices owned by others
would not be.  This often results in a desire to either have the
owner run their own Endorser that would only Endorse devices one
owns, or to use Attesters directly in the trust anchor store.  When
there are many Attesters owned, the use of an Endorser becomes more
scalable.
Paragraph (version B):
That is, it might appraise the trustworthiness of an application
component, operating system component, or service under the
assumption that information provided about it by the lower-layer
firmware or software is true.  A stronger level of assurance of
security comes when information can be vouched for by hardware or by
ROM code, especially if such hardware is physically resistant to
hardware tampering.  In most cases, components that have to be
vouched for via Endorsements because no Evidence is generated about
them are referred to as roots of trust.
Paragraph (version B):
The manufacturer of the Attester arranges for its Attesting
Environment to be provisioned with key material.  The key material is
typically in the form of an asymmetric key pair (e.g., an RSA or
ECDSA private key and a manufacturer-signed IDevID certificate)
secured in the Attester.
Paragraph (version B):
The Verifier is provided with an appropriate trust anchor, or
provided with a database of public keys (rather than certificates),
or even carefully secured lists of symmetric keys.  The nature of how
the Verifier manages to validate the signatures produced by the
Attester is critical to the secure operation an Attestation system,
but is not the subject of standardization within this architecture.
Paragraph (version B):
See security-considerations for discussion on security strength.