Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarify that SW components can be both code and config #74

Merged
merged 3 commits into from
Feb 9, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 20 additions & 16 deletions draft-tschofenig-rats-psa-token.md
Original file line number Diff line number Diff line change
Expand Up @@ -190,6 +190,7 @@ Model documentation {{PSA-SM}}.

## Glossary

{: vspace="0"}
RoT:
: Root of Trust, the minimal set of software, hardware and data that has to be
implicitly trusted in the platform - there is no software or hardware at a
Expand All @@ -214,7 +215,7 @@ Environment (REE), or "normal world".)
# PSA Attester Model

{{fig-psa-attester}} outlines the structure of the PSA Attester according to
the conceptual model described in {{Section 3.1 of I-D.ietf-rats-architecture}}.
the conceptual model described in {{Section 3.1 of RFC9334}}.

~~~ aasvg
{::include art/psa-attester.ascii-art}
Expand Down Expand Up @@ -419,21 +420,22 @@ If present, it MUST be between 8 and 32 bytes.
{: #sec-sw-components }

The Software Components claim is a list of software components that includes
all the software loaded by the PSA RoT. This claim SHALL be included in
attestation tokens produced by an implementation conformant with {{PSA-SM}}.
all the software (both code and configuration) loaded by the PSA RoT. This
claim MUST be included in attestation tokens produced by an implementation
conformant with {{PSA-SM}}.

Each entry in the Software Components list describes one software component
using the attributes described in the following subsections. Unless explicitly
stated, the presence of an attribute is OPTIONAL.

Note that, as described in {{?I-D.ietf-rats-architecture}}, a relying party
will typically see the result of the verification process from the Verifier in
form of an attestation result, rather than the "naked" PSA token from the
attesting endpoint. Therefore, a relying party is not expected to understand
the Software Components claim. Instead, it is for the Verifier to check this
claim against the available endorsements and provide an answer in form of an
"high level" attestation result, which may or may not include the original
Software Components claim.
Note that, as described in {{?RFC9334}}, a relying party will typically see the
result of the verification process from the Verifier in form of an attestation
result, rather than the "naked" PSA token from the attesting endpoint.
Therefore, a relying party is not expected to understand the Software
Components claim. Instead, it is for the Verifier to check this claim against
the available endorsements and provide an answer in form of an "high level"
attestation result, which may or may not include the original Software
Components claim.

~~~
{::include cddl/psa-software-components.cddl}
Expand All @@ -444,14 +446,17 @@ Software Components claim.
The Measurement Type attribute (key=1) is short string representing the role of
this software component.

The following measurement types MAY be used:
The following measurement types MAY be used for code measurements:

* "BL": a Boot Loader
* "PRoT": a component of the PSA Root of Trust
* "ARoT": a component of the Application Root of Trust
* "App": a component of the NSPE application
* "TS": a component of a Trusted Subsystem

The same labels with a "-config" postfix (e.g., "PRoT-config") MAY be used for
configuration measurements.

#### Measurement Value

The Measurement Value attribute (key=2) represents a hash of the invariant
Expand Down Expand Up @@ -591,10 +596,9 @@ type defined in {{sec-iana-media-types}} or the CoAP Content-Format defined in
# Freshness Model

The PSA Token supports the freshness models for attestation Evidence based on
nonces and epoch handles (Section 10.2 and 10.3 of
{{?I-D.ietf-rats-architecture}}) using the `nonce` claim to convey the nonce or
epoch handle supplied by the Verifier. No further assumption on the specific
remote attestation protocol is made.
nonces and epoch handles ({{Section 10.2 and Section 10.3 of ?RFC9334}}) using
the `nonce` claim to convey the nonce or epoch handle supplied by the Verifier.
No further assumption on the specific remote attestation protocol is made.

# Collated CDDL

Expand Down