Skip to content

Commit

Permalink
Merge pull request #44 from ietf-rats-wg/quick-back-to-back-read
Browse files Browse the repository at this point in the history
Tiny editorial corrections
  • Loading branch information
dthaler authored Nov 29, 2024
2 parents aaaaf4d + fc88bae commit 18fa1d8
Showing 1 changed file with 11 additions and 11 deletions.
22 changes: 11 additions & 11 deletions draft-ietf-rats-endorsements.md
Original file line number Diff line number Diff line change
Expand Up @@ -85,20 +85,20 @@ manner, i.e., a tree.
The state of an Attester also encompasses the combination of static and
dynamic composition (e.g., provisioned and deployed software, firmware, and
micro-code), static and dynamic configuration, and the resulting operational state
of its components at a certain point of time. Thus, a Verifier needs to receive
of its components at a certain point in time. Thus, a Verifier needs to receive
conceptual messages with information about actual state, and information about desired/undesired
states, and an appraisal policy that controls how the two are compared.

Each Attester in general has at least one Attesting Environment and one Target
Environment (e.g., hardware, firmware, Operating System, etc.). Typically, each
Attester has multiple Target Environments, each with their own set of claims (sometimes
called a "claim sets") representing their actual state. Additionally, the number of
called "claim sets") representing their actual state. Additionally, the number of
Target Environments and Attesting Environments that are components of an Attester are not limited.

"Actual state" is a group of claim sets about the actual state of the Attester at a
given point in time. Each claim set holds claims about a specific Target Environment
that is essential to determining trustworthiness. Generally speaking, each claim
has a name (typically referred to as label and occasionally referred to as a key, code-point, or some other ID)
has a name (typically referred to as a label, and occasionally referred to as a key or code-point)
and a singleton value, being a value collected from a Target Environment of a specific Attester at a given point
in time. Some claims may inherently have multiple values, such as a list of
files in a given location on the device, but in the context of this document such
Expand Down Expand Up @@ -191,7 +191,7 @@ state if a condition is met.
A claim is conditional if
it only applies if other actual state matches Reference Values, according to some
matching policy.
For example an Endorser for a given CPU might provide additional
For example, an Endorser for a given CPU might provide additional
information about what the CPU supports based on current firmware configuration
state, or an Endorser might provide additional information that if the
serial number is in a given range, then a specific security guarantee is present.
Expand All @@ -204,7 +204,7 @@ Verifier policies around matching actual state against
reference state are normally expressed in Appraisal Policy for Evidence.
Similarly, reference state is normally expressed in the Reference Values
conceptual message. Such policies allow a Verifier and Relying Parties to make
their decisions about trustworthiness of an Attester.
their decisions about the trustworthiness of an Attester.

The use of conditionally endorsed values, however, is different in that
a matching policy is not about trustworthiness (and hence not "appraisal" per se)
Expand Down Expand Up @@ -267,7 +267,7 @@ of the Endorsement itself (e.g., using a certificate lifetime) is provided.
{{Section 8.1 of RFC9334}} discusses timeliness of claims in Evidence. When
additional static claims are provided in Endorsements, no additional steps
are needed for timeliness of those claims since they are static rather than
dynamically varying by time. Once timeliness of Evidence is verified,
dynamically varying over time. Once timeliness of Evidence is verified,
any matching conditionally endorsed values can be applied.

If Endorsements ever carry dynamic claims in the future (e.g., whether
Expand All @@ -278,7 +278,7 @@ and would be the responsibility of specific protocol documents. See

# Multiple Endorsements {#multiple-endorsements}

Figure {{input}} showed an example with an Endorsement at layer 0, such as
{{input}} shows an example with an Endorsement at layer 0, such as
a hardware manufacturer providing claims about the hardware. However, the
same could be done at other layers in addition. For example, an OS vendor
might provide additional static claims about the OS software it provides,
Expand Down Expand Up @@ -329,7 +329,7 @@ Attester -------------------------------------------'
{: #multiple artwork-align="center" title="Multiple Endorsements"}

When Target Environments from different vendors each have their own
Endorser, it is important that a Verifier be able to distinguish
Endorser, a Verifier must be able to distinguish
which Endorser is allowed to provide an Endorsement about which
Target Environment. For example, the OS Endorser might be trusted to
provide additional claims about the OS, but not about the hardware.
Expand Down Expand Up @@ -377,11 +377,11 @@ and a very simple (by comparison) Appraisal Policy for Evidence and desired stat
a required trust anchor that Evidence must be signed with and little else).

Using the same message format for Evidence, Endorsements, and (later) Attestation Results received
from the later Verifier, can provide a code size savings due to having only a single parser
from the later Verifier, can provide code size savings due to having only a single parser
in this limited case.

Similarly, an embedded constrained Verifier can choose to not support conditionally
endorsed values, in order to avoid complexity introduced by such.
endorsed values, in order to avoid the complexity introduced by such.

# Security Considerations

Expand All @@ -391,7 +391,7 @@ storing a trust anchor for the Endorser. The binding from an Endorsement to
a given Target Environment is done as discussed in {{endorsing-keys}} of this document.

{{RFC9334}} (especially Section 3.2 and Section 12) also discusses security considerations
around the attestation of layers, and around sources of appraisal policies.
around the attestation of layers, and sources of appraisal policies.
{{endorsing-keys}} of this document covers additional considerations in these areas,
and {{formats-security}} covers additional considerations around Endorsement formats.

Expand Down

0 comments on commit 18fa1d8

Please sign in to comment.