Draft: draft-ietf-rats-architecture

Commentary: Here 's a first attempt to combine terminology sections , and trust model . Includes new terms  and   per recent discussion . Signed - off - by :   
    . ( But if you have feedback on a sentence like this in the future , please attach the comment directly to the code line under the " Files changed " tab , to make it easy to find which phrase you 're referring to . ) 
    . How about now ? 
 I would like to discuss the possibility of combining the terms " Endorsement " and " Attestation Result " . Just like we have    for a verifier and an   for a relying party , some might view an Attestation Result as an Endorsement for use by the relying party . I 'm ok either way , but wanted to discuss this in our next call to see if others think it would help or confuse things . 
 I still believe my original definition of Attestation is good , I have n't seen any comments here about what the problem was . For comparison , says it 's " The process of validating the integrity of a computing device such as a server needed for trusted computing . " . I 'm also ok with that definition . 
 I ’m OK with that wording for introducing the concept . It may break down if the terminology for ‘ device ’ and ‘ trusted computing ’ become overly specified / specific . 
 The word ' health ' is generally being used where other words such as ' trustworthiness ' , or ' state ' could be used . I 'm concerned that ' health ' might not easily be synonymous with ' trust ' . It also seems to bias the architecture toward NEA ( RFC5209 ) which IMO does not define attestation .
Paragraph (version B):
The document defines the term "Remote Attestation" as follows: A
process by which one entity (the "Attester") provides evidence about
its identity and state to another remote entity (the "Relying
Party"), which then assesses the Attester's trustworthiness for the
Relying Party's own purposes.
Paragraph (version B):
Appraisal Policy for Evidence: A set of rules that direct how a
verifier evaluates the validity of information about an Attester.
Compare /security policy/ in [RFC4949].
Paragraph (version B):
Appraisal Policy for Attestation Result: A set of rules that
direct how a Relying Party evaluates the validity of information
about an Attester.  Compare /security policy/ in [RFC4949].
Paragraph (version B):
Attestation Result: The evaluation results generated by a
Verifier, typically including information about an Attester, where
the Verifier vouches for the validity of the results.
Paragraph (version B):
Attester: An entity whose attributes must be evaluated in order to
determine whether the entity is considered trustworthy, such as
when deciding whether the entity is authorized to perform some
operation.
Paragraph (version B):
Endorsement: A secure statement that some entity (typically a
manufacturer) vouches for the integrity of an Attester's signing
capability.
Paragraph (version B):
Endorser: An entity that creates Endorsements that can be used to
help evaluate trustworthiness of Attesters.
Paragraph (version B):
Evidence: A set of information about an Attester that is to be
evaluated by a Verifier.
Paragraph (version B):
Relying Party: An entity that depends on the validity of
information about another entity, typically for purposes of
authorization.  Compare /relying party/ in [RFC4949].
Paragraph (version B):
Relying Party Owner: An entity, such as an administrator, that is
authorized to configure Appraisal Policy for Attestation Results
in a Relying Party.
Paragraph (version B):
Verifier: An entity that evaluates the validity of Evidence about
an Attester.
Paragraph (version B):
Verifier Owner: An entity, such as an administrator, that is
authorized to configure Appraisal Policy for Evidence in a
Verifier.
Paragraph (version B):
The term Attestation and Remote Attestation are not defined in this
document, at this time.  This document will include pointers to
industry uses of the terms, in an attempt to gain consensus around
the term, and be consistent with the charter text defining this term.
Paragraph (version B):
dataflow depicts the data that flows between different roles,
independent of protocol or use case.
Paragraph (version B):
An Attester creates Evidence that is conveyed to a Verifier.
Paragraph (version B):
The Verifier uses the Evidence, and any Endorsements from Endorsers,
by applying an Evidence Appraisal Policy to assess the
trustworthiness of the Attester, and generates Attestation Results
for use by Relying Parties.  The Evidence Appraisal Policy might be
obtained from an Endorser along with the Endorsements, or might be
obtained via some other mechanism such as being configured in the
Verifier by an administrator.
Paragraph (version B):
The Relying Party uses Attestation Results by applying its own
Appraisal Policy to make application-specific decisions such as
authorization decisions.  The Attestation Result Appraisal Policy
might, for example, be configured in the Relying Party by an
administrator.
Paragraph (version B):
An Attester consists of at least one Attesting Environment and
Attested Environment.  In some implementations, the Attesting and
Attested Environments might be combined.  Other implementations might
have multiple Attesting and Attested Environments.
Paragraph (version B):
The scope of this document is scenarios for which a Relying Party
trusts a Verifier that can evaluate 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.  The Relying Party might implicitly
trust a Verifier (such as in the Verifying Relying Party
combination).  Or, for a stronger level of security, the Relying
Party might require that the Verifier itself provide information
about itself that the Relying Party can use to evaluate the
trustworthiness of the Verifier before accepting its Attestation
Results.
Paragraph (version B):
In solutions following the background-check model, the Attester is
assumed to trust the Verifier (again, whether directly or indirectly
via a Certificate Authority that it trusts), since the Attester
relies on an Attestation Result it obtains from the Verifier, in
order to access resources.
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
evaluate 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 evaluate the trustworthiness of an application
component, or 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 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.