Draft: draft-ietf-rats-architecture

Commentary: No technical changes , I think . Phrased introduction text side - by - side with charter . Many tiny nits polished . 
 In the 2nd paragraph of the Trust Model section , the third sentence is impossible for me to make sense of . Which trust relationships are addressed here and why should an Endorser consume Evidence - even in the case that a Verifier " acts " ( also not the best choice of words ) as an Attester ? 
 The  does n't consume the Evidence directly , it takes on the role of Relying Party and consumes the Attestation Results of the Verifier which now takes on the role of Attester . The purpose is to say the Verifier should be trusted by the Endorser . There should be another upper - level Verifier between the  and the Verifier in this ' explicit way ' 
 The trust model should describe what each entity ( in the capacity of a particular role ) trusts the other entity to do ( or not to do ) . In the context of Role messages , the direction the message flows is relevant to the trust model . An entity receiving a message is going to use the message to alter its behavior . The altered behavior has security relevance . Therefore , the trust model should describe the conditions in which acceptance of the message is warranted . For example , the Verifier accepts Endorsements from an Endorser because it believes the  is an authority for asserting claims about how an entity was constructed , manufactured , tested , etc ... Trust in the opposite direction of the message flow is also relevant but from a privacy context . The  trusts the Verifier to receive Endorsements to use them to satisfy appraisals ( and not for other purposes such as marketing or advertising ? ? ? ) . Though I do n't know if it is appropriate for the arch document to speculate on this . Nevertheless , the last paragraph in this section talks about privacy . But saying that  ( or any entity ) trusts  ( or any other entity ) without qualification is useless . Therefore , should n't appear in the document IMO . It might be better to treat each trust relationship in terms of each message and the direction of flow ? E.g. , E --Endorsements -- V : V trusts E for X ; E trusts V for Y. etc ... 
 I assume that segregating this into a permutation of examples is actually really helpful . It might make readers better understand when " Attester --Evidence -- Relying Party " happens although a  is defined as the consumer of Evidence . Would everybody agree with that ? We could create a complete list of required examples here in the comments and then put them into the draft . 
 Attestation Result is far more than compliance / non - compliance for many / most use cases . Attestation Results may contain lots claims that are passed through from the device ( e.g. , GPS location ) . I would also expect information from the Endorsement to be passed through , particularly in the case where the Verifier is an aggregator . Implied claims would also show up in the Attestation Result . 
 Section 7.3 starts out " Attestation Results may indicate compliance or non - compliance with a Verifier 's   " implying binary yes / no results . Section 7.3 needs to get rewritten some so results can be very rich with dozens of claims that are input to the RP 's risk engine . 
 The -05 draft with   moved to section 8.3 still has too much emphasis on compliance / non - compliance .
Paragraph (version A):
Remote Attestation, as used in this document, is 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 A):
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 A):
Appraisal Policy for Attestation Result: A set of rules that
direct how a Relying Party uses the evaluation results about an
Attester generated by the Verifiers.  Compare /security policy/ in
[RFC4949].
Paragraph (version A):
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 A):
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 A):
Endorsement: A secure statement that some entity (typically a
manufacturer) vouches for the integrity of an Attester's signing
capability.
Paragraph (version A):
Endorser: An entity that creates Endorsements that can be used to
help evaluate trustworthiness of Attesters.
Paragraph (version A):
Evidence: A set of information about an Attester that is to be
evaluated by a Verifier.
Paragraph (version A):
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 A):
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 A):
Verifier: An entity that evaluates the validity of Evidence about
an Attester.
Paragraph (version A):
Verifier Owner: An entity, such as an administrator, that is
authorized to configure Appraisal Policy for Evidence in a
Verifier.
Paragraph (version A):
This section covers a number of representative use cases for
attestation, independent of solution.  The purpose is to provide
motivation for various aspects of the architecture presented in this
draft.  Many other use cases exist, and this document does not intend
to have a complete list, only to have a set of use cases that
collectively cover all the functionality required in the
architecture.
Paragraph (version B):
In Remote Attestation Procedures (RATS), one peer (the "Attester")
produces believable information about itself - Evidence - to enable a
remote peer (the "Relying Party") to decide whether to consider that
Attester a trustworthy peer or not.  RATS are facilitated by an
additional vital party, the Verifier.  The Verifier appraises
Evidence via Appraisal Policies and creates the Attestation Results
to support Relying Parties in their decision process.
Paragraph (version B):
This documents defines a flexible architecture with corresponding
roles and their interaction via conceptual messages.  Additionally,
this document defines a universal set of terms that can be mapped to
various existing and emerging Remote Attestation Procedures.  Common
role compositions and data flows, such as the "Passport Model" and
the "Background-Check Model" are illustrated to enable readers of
this document to map their current and emerging solutions to the
architecture provided and the corresponding terminology defined.  A
common terminology that provides a well-understood semantic meaning
to the concepts, roles, and models in this document is vital to
create semantic interoperability between solutions and across
different platforms.
Paragraph (version B):
Amongst other things, this document is about trust and
trustworthiness.  Trust is a decision being made.  Trustworthiness is
a quality that is assessed via evidence created.  This is a subtle
difference and being familiar with the difference is crucial for
using this document.  Additionally, the concepts of freshness and
trust relationships with respect to RATS are elaborated on to enable
implementers in order to choose appropriate solutions to compose
their Remote Attestation Procedures.
Paragraph (version B):
This document uses the following terms.
Paragraph (version B):
An entity, such as an administrator, that is authorized to
configure Appraisal Policy for Attestation Results in a Relying
Party.
Paragraph (version B):
This section covers a number of representative use cases for remote
attestation, independent of specific solutions.  The purpose is to
provide motivation for various aspects of the architecture presented
in this draft.  Many other use cases exist, and this document does
not intend to have a complete list, only to have a set of use cases
that collectively cover all the functionality required in the
architecture.
Paragraph (version A):
Network operators want a trustworthy report of identity and version
of information of the hardware and software on the machines attached
to their network, for purposes such as inventory, auditing, and/or
logging.  The network operator may also want a policy by which full
access is only granted to devices that meet some definition of
health, and so wants to get claims about such information and verify
their validity.  Attestation is desired to prevent vulnerable or
compromised devices from getting access to the network and
potentially harming others.
Paragraph (version A):
Typically, solutions start with some component (called a "Root of
Trust") that provides device identity and protected storage for
measurements.  They then perform a series of measurements, and
express this with Evidence as to the hardware and firmware/software
that is running.
Paragraph (version A):
Relying Party: A network infrastructure device such as a router,
switch, or access point.
Paragraph (version B):
Network operators want a trustworthy report of identity and version
of information of the hardware and software on the machines attached
to their network, for purposes such as inventory, auditing, and/or
logging.  The network operator may also want a policy by which full
access is only granted to devices that meet some definition of
health, and so wants to get claims about such information and verify
their validity.  Remote attestation is desired to prevent vulnerable
or compromised devices from getting access to the network and
potentially harming others.
Paragraph (version A):
This typically works by having some protected environment in the
device attest to some manufacturer service.  If 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 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 A):
In this use case, potentially dangerous physical equipment (e.g.,
power grid, traffic control, hazardous chemical processing, etc.) is
connected to a network.  The organization managing such
infrastructure needs to ensure that only authorized code and users
can control such processes, and they are protected from malware or
other adversaries.  When a protocol operation can affect some
critical system, the device attached to the critical equipment thus
wants some assurance that the requester has not been compromised.  As
such, attestation can be used to only accept commands from requesters
that are within policy.
Paragraph (version A):
Attester: A device or application wishing to control physical
equipment.
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 verify 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 A):
Attester: A device with a trusted execution environment capable of
running trusted applications that can be updated.
Paragraph (version A):
Relying Party: A Trusted Application Manager.
Paragraph (version B):
In this use case, potentially dangerous physical equipment (e.g.,
power grid, traffic control, hazardous chemical processing, etc.) is
connected to a network.  The organization managing such
infrastructure needs to ensure that only authorized code and users
can control such processes, and they are protected from malware or
other adversaries.  When a protocol operation can affect some
critical system, the device attached to the critical equipment thus
wants some assurance that the requester has not been compromised.  As
such, remote attestation can be used to only accept commands from
requesters that are within 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 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 A):
A hardware watchdog can be implemented by forcing a reboot unless
attestation to a remote server succeeds within a periodic interval,
and having the reboot do remediation by bringing a device into
compliance, including installation of patches as needed.
Paragraph (version A):
Attester: The device that is desired to keep from being held
hostage for a long period of time.
Paragraph (version A):
Relying Party: A remote server that will securely grant the
Attester permission to continue operating (i.e., not reboot) for a
period of time.
Paragraph (version B):
A hardware watchdog can be implemented by forcing a reboot unless
remote attestation to a server succeeds within a periodic interval,
and having the reboot do remediation by bringing a device into
compliance, including installation of patches as needed.
Paragraph (version A):
A Composite Attester is an entity composed of multiple sub-entities
such that its trustworthiness has to be determined by evaluating all
these sub-entities.  Each sub-entity has at least one Attesting
Environment collecting the claims from at least one Target
Environment, then this sub-entity generates Evidence about its
trustworthiness.  Therefore each sub-entity can be called an
Attester.  Among these Attesters, there may be only some, which can
be called Lead Attesters, that have the ability to communicate with
the Verifier.  Other Attesters don't have this ability, but they are
connected to the Lead Attesters via internal links or network
connections, and they are evaluated via the Lead Attester's help.
Paragraph (version B):
A Composite Attester is an entity composed of multiple sub-entities
such that its trustworthiness has to be determined by the appraisal
of all these sub-entities.  Each sub-entity has at least one
Attesting Environment collecting the claims from at least one Target
Environment, then this sub-entity generates Evidence about its
trustworthiness.  Therefore each sub-entity can be called an
Attester.  Among these Attesters, there may be only some, which can
be called Lead Attesters, that have the ability to communicate with
the Verifier.  Other Attesters don't have this ability, but they are
connected to the Lead Attesters via internal links or network
connections, and they are appraised by the Lead Attester's.
Paragraph (version A):
Another example is a multi-chassis router composed of multiple single
carrier-grade routers.  The multi-chassis router provides higher
throughput by interconnecting multiple routers and can be logically
treated as one router for simpler management.  Among these routers,
there is only one main router that connects to the Verifier.  Other
routers are only connected to the main router by the network cables,
and therefore they are managed and verified via this main router.
So, in this case, the multi-chassis router is the Composite Attester,
each router is an Attester and the main router is the Lead Attester.
Paragraph (version B):
Another example is a multi-chassis router composed of multiple single
carrier-grade routers.  The multi-chassis router provides higher
throughput by interconnecting multiple routers and can be logically
treated as one router for simpler management.  Among these routers,
there is only one main router that connects to the Verifier.  Other
routers are only connected to the main router by the network cables,
and therefore they are managed and appraised via this main router.
So, in this case, the multi-chassis router is the Composite Attester,
each router is an Attester and the main router is the Lead Attester.
Paragraph (version A):
The Lead Attester's Attesting Environment may or may not include its
own Verifier.  One situation is that the Attesting Environment has no
local Verifier.  In this situation, the Lead Attesting Environment
simply combines the various Evidences into the final Evidence that is
sent off to the remote Verifier, which evaluates the trustworthiness
of the Composite Device, including the Lead Attester's and other
Attesters', trustworthiness.
Paragraph (version A):
The other situation is that the Lead Attesting Environment has an
local Verifier.  After collecting the Evidence of other Attesters,
this Attesting Environment verifies them using Endorsements and
Appraisal Policies (obtained the same way as any other Verifier), for
evaluating these Attesters' trustworthiness.  Then the Lead Attesting
Environment combines the Attestation Results into the final Evidence
of the whole Composite Attester which is sent off to the remote
Verifier, which might treat the claims obtained from the local
Attestation Results as if they were Evidence.  In this situation, the
trust model described in trustmodel is also suitable for the local
verifier.
Paragraph (version B):
The Lead Attester's Attesting Environment may or may not include its
own Verifier.  The first variant is that the Attesting Environment
has no local Verifier.  In this variant, the Lead Attesting
Environment simply combines the various Evidences into the final
Evidence that is sent off to the remote Verifier, which appraises the
trustworthiness of the Composite Device, including the Lead
Attester's and other Attesters' trustworthiness.
Paragraph (version B):
The second variant is that the Lead Attesting Environment has a local
Verifier.  After collecting the Evidence of other Attesters, this
Attesting Environment appraises them using Endorsements and Appraisal
Policies (obtained the same way as any other Verifier).  The Lead
Attesting Environment combines the Attestation Results into the final
Evidence of the whole Composite Attester which is sent off to the
remote Verifier, which may treat the Claims obtained from the local
Attestation Results as if they were Evidence.  In this situation, the
trust model described in trustmodel is also suitable for the local
Verifier.
Paragraph (version A):
Since the resource access protocol between the Attester and Relying
Party includes an Attestation Result, in this model the details of
that protocol constrain the serialization format of the Attestation
Result.  The format of the Evidence on the other hand is only
constrained by the Attester-Verifier attestation protocol.
Paragraph (version B):
Since the resource access protocol between the Attester and Relying
Party includes an Attestation Result, in this model the details of
that protocol constrain the serialization format of the Attestation
Result.  The format of the Evidence on the other hand is only
constrained by the Attester-Verifier remote attestation protocol.
Paragraph (version A):
It is also worth pointing out that the choice of model is generally
up to the Relying Party, and the same device may need to attest to
different Relying Parties for different use cases (e.g., a network
infrastructure device to gain access to the network, and then a
server holding confidential data to get access to that data).  As
such, both models may simultaneously be in use by the same device.
Paragraph (version B):
It is also worth pointing out that the choice of model is generally
up to the Relying Party, and the same device may need to create
Evidence for different Relying Parties and different use cases (e.g.,
a network infrastructure device to gain access to the network, and
then a server holding confidential data to get access to that data).
As such, both models may simultaneously be in use by the same device.
Paragraph (version A):
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):
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 attests to 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 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
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.
Paragraph (version B):
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 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, 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.
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 sends Evidence, to not reveal sensitive data to
unauthorized parties.  The Verifier may 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, Evidence might contain sensitive information such
as Personally Identifiable Information.  Thus, an Attester must trust
entities to which it sends 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 A):
Today, Evidence tends to be highly device-specific, since the
information in the Evidence often includes vendor-specific
information that is necessary to fully describe the manufacturer and
model of the device including its security properties, the health of
the device, and the level of confidence in the correctness of the
information.  Evidence is typically signed by the device (whether by
hardware, firmware, or software on the device), and evaluating it in
isolation would require Appraisal Policy to be based on device-
specific details (e.g., a device public key).
Paragraph (version B):
Today, Evidence tends to be highly device-specific, since the
information in the Evidence often includes vendor-specific
information that is necessary to fully describe the manufacturer and
model of the device including its security properties, the health of
the device, and the level of confidence in the correctness of the
information.  Evidence is typically signed by the device (whether by
hardware, firmware, or software on the device), and its appraisal in
isolation would require Appraisal Policy to be based on device-
specific details (e.g., a device public key).
Paragraph (version A):
An Endorsement is a secure statement that some entity (e.g., a
manufacturer) vouches for the integrity of the device's signing
capability.  For example, if the signing capability is in hardware,
then an Endorsement might be a manufacturer certificate that signs a
public key whose corresponding private key is only known inside the
device's hardware.  Thus, when Evidence and such an Endorsement are
used together, evaluating them can be done against Appraisal Policy
that may not be specific to the device instance, but merely specific
to the manufacturer providing the Endorsement.  For example, an
Appraisal Policy might simply check that devices from a given
manufacturer have information matching a set of known-good reference
values, or an Appraisal Policy might have a set of more complex logic
on how to evaluate the validity of information.
Paragraph (version A):
However, while an Appraisal Policy that treats all devices from a
given manufacturer the same may be appropriate for some use cases, it
would be inappropriate to use such an Appraisal Policy as the sole
means of authorization for use cases that wish to constrain _which_
compliant devices are considered authorized for some purpose.  For
example, an enterprise using attestation for Network Endpoint
Assessment may not wish to let every healthy laptop from the same
manufacturer onto the network, but instead only want to let devices
that it legally owns onto the network.  Thus, an Endorsement may be
helpful information in authenticating information about a device, but
is not necessarily sufficient to authorize access to resources which
may need device-specific information such as a public key for the
device or component or user on the device.
Paragraph (version B):
An Endorsement is a secure statement that some entity (e.g., a
manufacturer) vouches for the integrity of the device's signing
capability.  For example, if the signing capability is in hardware,
then an Endorsement might be a manufacturer certificate that signs a
public key whose corresponding private key is only known inside the
device's hardware.  Thus, when Evidence and such an Endorsement are
used together, an appraisal procedure can be conducted based on
Appraisal Policies that may not be specific to the device instance,
but merely specific to the manufacturer providing the Endorsement.
For example, an Appraisal Policy might simply check that devices from
a given manufacturer have information matching a set of known-good
reference values, or an Appraisal Policy might have a set of more
complex logic on how to appraise the validity of information.
Paragraph (version B):
However, while an Appraisal Policy that treats all devices from a
given manufacturer the same may be appropriate for some use cases, it
would be inappropriate to use such an Appraisal Policy as the sole
means of authorization for use cases that wish to constrain _which_
compliant devices are considered authorized for some purpose.  For
example, an enterprise using remote attestation for Network Endpoint
Assessment may not wish to let every healthy laptop from the same
manufacturer onto the network, but instead only want to let devices
that it legally owns onto the network.  Thus, an Endorsement may be
helpful information in authenticating information about a device, but
is not necessarily sufficient to authorize access to resources which
may need device-specific information such as a public key for the
device or component or user on the device.
Paragraph (version A):
Thus, Attestation Results often need to include detailed information
about the Attester, for use by Relying Parties, much like physical
passports and drivers licenses include personal information such as
name and date of birth.  Unlike Evidence, which is often very device-
and vendor-specific, Attestation Results can be vendor-neutral if the
Verifier has a way to generate vendor-agnostic information based on
evaluating vendor-specific information in Evidence.  This allows a
Relying Party's Appraisal Policy to be simpler, potentially based on
standard ways of expressing the information, while still allowing
interoperability with heterogeneous devices.
Paragraph (version B):
Thus, Attestation Results often need to include detailed information
about the Attester, for use by Relying Parties, much like physical
passports and drivers licenses include personal information such as
name and date of birth.  Unlike Evidence, which is often very device-
and vendor-specific, Attestation Results can be vendor-neutral if the
Verifier has a way to generate vendor-agnostic information based on
the appraisal of vendor-specific information in Evidence.  This
allows a Relying Party's Appraisal Policy to be simpler, potentially
based on standard ways of expressing the information, while still
allowing interoperability with heterogeneous devices.
Paragraph (version A):
To enable attestation to be added to existing protocols, enabling a
higher level of assurance against malware for example, it is
important that information needed for evaluating the Attester be
usable with existing protocols that have constraints around what
formats they can transport.  For example, OPC UA OPCUA (probably the
most common protocol in industrial IoT environments) is defined to
carry X.509 certificates and so security information must be embedded
into an X.509 certificate to be passed in the protocol.  Thus,
attestation-related information could be natively encoded in X.509
certificate extensions, or could be natively encoded in some other
format (e.g., a CWT) which in turn is then encoded in an X.509
certificate extension.
Paragraph (version B):
To enable remote attestation to be added to existing protocols,
enabling a higher level of assurance against malware for example, it
is important that information needed for appraising the Attester be
usable with existing protocols that have constraints around what
formats they can transport.  For example, OPC UA OPCUA (probably the
most common protocol in industrial IoT environments) is defined to
carry X.509 certificates and so security information must be embedded
into an X.509 certificate to be passed in the protocol.  Thus, remote
attestation related information could be natively encoded in X.509
certificate extensions, or could be natively encoded in some other
format (e.g., a CWT) which in turn is then encoded in an X.509
certificate extension.
Paragraph (version A):
This motivates having a common "information model" that describes the
set of attestation related information in an encoding-agnostic way,
and allowing multiple encoding formats (CWT, JWT, X.509, etc.) that
encode the same information into the claims format needed by the
Relying Party.
Paragraph (version B):
This motivates having a common "information model" that describes the
set of remote attestation related information in an encoding-agnostic
way, and allowing multiple encoding formats (CWT, JWT, X.509, etc.)
that encode the same information into the claims format needed by the
Relying Party.
Paragraph (version A):
To evaluate the security provided by a particular Appraisal Policy,
it is important to understand the strength of the Root of Trust,
e.g., whether it is mutable software, or firmware that is read-only
after boot, or immutable hardware/ROM.
Paragraph (version A):
It is also important that the Appraisal Policy was itself obtained
securely.  As such, if Appraisal Policy in a Relying Party or
Verifier can be configured via a network protocol, the ability to
attest to the health of the client providing the Appraisal Policy
needs to be considered.
Paragraph (version B):
To assess the security provided by a particular Appraisal Policy, it
is important to understand the strength of the Root of Trust, e.g.,
whether it is mutable software, or firmware that is read-only after
boot, or immutable hardware/ROM.
Paragraph (version B):
It is also important that the Appraisal Policy was itself obtained
securely.  As such, if Appraisal Policies for a Relying Party or for
a Verifier can be configured via a network protocol, the ability to
create Evidence about the integrity of the entity providing the
Appraisal Policy needs to be considered.