Draft: draft-ietf-rats-architecture

Commentary: Diffs look longer than they really are just because text was moved around due to the ordering point raised on the design team call . Also , I found that " Verifying Relying Party " was used in this section without actually being defined so I defined it in context in that sentence ( line 686 ) . Also subsection headings for each role to make it easier to read and refer to . The " recursion " aspect is dealt with by example in the new text starting at line 692 , which was the simplest way I could find to do it , where I found that trying to use the term " recurse " or similar just made it harder for me to understand . Other places just refer back to that example . Signed - off - by :
Paragraph (version A):
This typically works by having some protected environment in the
device attest to some manufacturer service.  If remote attestation
succeeds, then the manufacturer service releases either the model, or
a key to decrypt a model the Attester already has in encrypted form,
to the requester.
Paragraph (version B):
This typically works by having some protected environment in the
device go through a remote attestation with some manufacturer service
that can assess its trustworthiness.  If remote attestation succeeds,
then the manufacturer service releases either the model, or a key to
decrypt a model the Attester already has in encrypted form, to the
requester.
Paragraph (version A):
A "Trusted Application Manager (TAM)" server is responsible for
managing the applications running in the TEE of a client device.  To
do this, the TAM wants to assess the state of a TEE, or of
applications in the TEE, of a client device.  The TEE attests to the
TAM, which can then decide whether the TEE is already in compliance
with the TAM's latest policy, or if the TAM needs to uninstall,
update, or install approved applications in the TEE to bring it back
into compliance with the TAM's policy.
Paragraph (version B):
A "Trusted Application Manager (TAM)" server is responsible for
managing the applications running in the TEE of a client device.  To
do this, the TAM wants to assess the state of a TEE, or of
applications in the TEE, of a client device.  The TEE conducts a
remote attestation procedure with the TAM, which can then decide
whether the TEE is already in compliance with the TAM's latest
policy, or if the TAM needs to uninstall, update, or install approved
applications in the TEE to bring it back into compliance with the
TAM's policy.
Paragraph (version A):
The scope of this document is 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.  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 assess the
trustworthiness of the Verifier before accepting its Attestation
Results.
Paragraph (version A):
The Endorser and Verifier Owner may need to trust the Verifier before
giving the Endorsement and Appraisal Policy to it.  Such trust can
also be established directly or indirectly, implicitly or explicitly.
One explicit way to establish such trust may be the Verifier first
acts as an Attester and creates Evidence about itself to be consumed
by the Endorser and/or Verifier Owner as the Relying Parties.  If it
is accepted as trustworthy, then they can provide Endorsements and
Appraisal Policies that enable it to act as a Verifier.
Paragraph (version B):
The scope of this document is 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):
The Relying Party might implicitly trust a Verifier, such as in a
Verifier/Relying Party combination where the Verifier and Relying
Party roles are combined.  Or, for a stronger level of security, the
Relying Party might require that the Verifier first provide
information about itself that the Relying Party can use to assess the
trustworthiness of the Verifier before accepting its Attestation
Results.
Paragraph (version B):
For example, one explicit way for a Relying Party "A" to establish
such trust in a Verifier "B", would be for B to first act as an
Attester where A acts as a combined Verifier/Relying Party.  If A
then accepts B as trustworthy, it can choose to accept B as a
Verifier for other Attesters.
Paragraph (version B):
Similarly, the Relying Party also needs to trust the Relying Party
Owner for providing its Appraisal Policy for Attestation Results, and
in some scenarios the Relying Party might even require that the
Relying Party Owner go through a remote attestation procedure with it
before the Relying Party will accept an updated policy.  This can be
done similarly to how a Relying Party could establish trust in a
Verifier as discussed above.
Paragraph (version B):
In some scenarios, Evidence might contain sensitive information such
as Personally Identifiable Information.  Thus, an Attester must trust
entities to which it conveys Evidence, to not reveal sensitive data
to unauthorized parties.  The Verifier might share this information
with other authorized parties, according to rules that it controls.
In the background-check model, this Evidence may also be revealed to
Relying Party(s).
Paragraph (version B):
In some cases where Evidence contains sensitive information, an
Attester might even require that a Verifier first go through a remote
attestation procedure with it before the Attester will send the
sensitive Evidence.  This can be done by having the Attester first
act as a Verifier/Relying Party, and the Verifier act as its own
Attester, as discussed above.
Paragraph (version B):
The Relying Party Owner might also require that the Relying Party
first act as an Attester, providing Evidence that the Owner can
appraise, before the Owner would give the Relying Party an updated
policy that might contain sensitive information.  In such a case,
mutual attestation might be needed, in which case typically one
side's Evidence must be considered safe to share with an untrusted
entity, in order to bootstrap the sequence.
Paragraph (version A):
In some scenarios, Evidence might contain sensitive information such
as Personally Identifiable Information.  Thus, an Attester must trust
entities to which it conveys Evidence, to not reveal sensitive data
to unauthorized parties.  The Verifier might share this information
with other authorized parties, according rules that it controls.  In
the background-check model, this Evidence may also be revealed to
Relying Party(s).
Paragraph (version B):
In some scenarios, the Endorser and Verifier Owner may need to trust
the Verifier before giving the Endorsement and Appraisal Policy to
it.  This can be done similarly to how a Relying Party might
establish trust in a Verifier as discussed above, and in such a case,
mutual attestation might even be needed as discussed in rpowner-
trust.