Authors,
While reviewing this document during AUTH48, please resolve (as necessary)
the following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use onhttps://www.rfc-editor.org/search. -->
2) <!-- [rfced] The sentence below seems to be missing a verb (such as
designed, used, etc.). May we rephrase the sentence as follows to improve
readability?
Original:
The Arm Platform Security Architecture (PSA) is a family of hardware
and firmware security specifications, as well as open-source
reference implementations, to help device makers and chip
manufacturers build best-practice security into products.
Perhaps:
The Arm Platform Security Architecture (PSA) is a family of hardware
and firmware security specifications, as well as open-source
reference implementations, that is designed to help device makers and
chip manufacturers build best-practice security into products.
-->
3) <!-- [rfced] Is the Application domain specified as the security domain
outside the SPE in the definition for NSPE? Please clarify.
Original:
NSPE:
Non Secure Processing Environment, the security domain outside of
the SPE, the Application domain, typically containing the
application firmware, real-time operating systems, applications
and general hardware.
Perhaps:
Non-Secure Processing Environment (NSPE):
The security domain (Application domain) outside of the SPE that
typically contains the application firmware, real-time operating
systems, applications, and general hardware.
-->
4) <!-- [rfced] Is "them" and "it" referring to "PSA claims" in this
sentence?
Original:
The Attesting Environment is responsible for collecting the
information to be represented in PSA claims and to assemble them into
Evidence. It is made of two cooperating components:
Perhaps:
The Attesting Environment is responsible for collecting the
information to be represented in PSA claims and assembling them into
Evidence. PSA claims are made of two cooperating components:
-->
5) <!-- [rfced] May we rephrase the following sentence for clarity?
Original:
It MUST be represented as a string made of
nineteen numeric characters: a thirteen-digit [EAN-13], followed by a
dash "-", followed by the five-digit versioning information described
in [PSA-Cert-Guide].
Perhaps:
It MUST be represented as a string made of
nineteen numeric characters: a thirteen-digit [EAN-13], followed by a
dash "-", followed by the five-digit versioning information described
in [PSA-Cert-Guide].
-->
6) <!-- [rfced] We have updated the following sentence for clarity. Please
review and let us know any objections.
Original:
The following claims are part of the PSA token (and therefore still
Evidence) but aim to help receivers, including relying parties, with
the processing of the received attestation Evidence.
Current:
The following claims are part of the PSA token (and are therefore still
Evidence). However, they aim to help receivers, including Relying
parties, with the processing of the received attestation Evidence.
-->
7) <!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
8) <!-- [rfced] We have updated "certs" in the sentence below to
"certifications" for consistency. The use of "certs" has also been updated
throughout the rest of the document. Please let us know any objections.
Original:
Certified public keys require the manufacturer to run the
certification authority (CA) that issues X.509 certs for the IAKs.
Current:
Certified public keys require the manufacturer to run the
certification authority (CA) that issues X.509 certifications for the
IAKs.
-->
9) <!-- [rfced] To clarify, are the reference values described below
registered with the Verifier? Or are the claims in this profile compared
to reference values in addition to being registered with the Verifier?
Original:
In addition, the Verifier will typically operate a policy where
values of some of the claims in this profile can be compared to
reference values, registered with the Verifier for a given
deployment, in order to confirm that the device is endorsed by the
manufacturer supply chain.
Perhaps:
In addition, the Verifier will typically operate a policy where
values of some of the claims in this profile can be compared to
reference values and registered with the Verifier for a given
deployment in order to confirm that the device is endorsed by the
manufacturer supply chain.
Or:
In addition, the Verifier will typically operate a policy where
values of some of the claims in this profile can be compared to
reference values that are registered with the Verifier for a given
deployment in order to confirm that the device is endorsed by the
manufacturer supply chain.
-->
10) <!-- [rfced] Should "verification key material to the Verifier" be
rewritten as follows for clarity?
Original:
[PSA-Endorsements] defines a protocol based on the [RATS-CoRIM] data
model that can be used to convey PSA Endorsements, Reference Values
and verification key material to the Verifier.
Perhaps:
[PSA-Endorsements] defines a protocol based on the data model
described in [RATS-CoRIM] that can be used to convey PSA Endorsements
and Reference Values, and to verify key material to the Verifier.
-->
11) <!-- [rfced] Reference-related questions:
a) The following reference appears to be a code repository that was last
updated in August 2023. "iat-verifier" only appears on the page as a link;
is the goal to point readers to the iat-verifier tree? Please review.
Currently, we have updated the document as described below to follow the
RFC style guidance (seehttps://www.rfc-editor.org/styleguide/part2/#ref_repo).
We may make more updates depending on the answer to the
question above.
Original:
[IAT-VERIFIER]
Linaro, "iat-verifier", 2023,
<https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/
iat-verifier>.
Current:
[IAT-VERIFIER]
Trusted Firmware, "iat-verifier", commit:
0b49b00195b7733d6fe74e8f42ed4d7b81242801, 18 August
2023,<https://git.trustedfirmware.org/TF-M/tf-m-tools.git/tree/iat-verifier>.
b) Please review the following reference. The URL provided for [PSA]
redirects to the following
link:https://www.arm.com/architecture/security-features.
We found
https://developer.arm.com/documentation/101892/0100/Security-Platform-Security-Architecture?lang=en
(please note that the actual URL contains three hyphens between "/Security"
and "Platform", but XML comments break when more than two hyphens appear
consecutively in a URL). If there are no objections, we will update the
reference as follows.
Original:
[PSA] Arm, "Platform Security Architecture Resources", 2022,
<https://developer.arm.com/architectures/security-
architectures/platform-security-architecture/ documentation>.
Perhaps:
[PSA] Arm, "Security - Platform Security Architecture",
<https://developer.arm.com/architectures/security-
architectures/platform-security-architecture/ documentation>.
c) Note that we have updated the title of the following reference, as the
title of the webpage appears to have changed since 2022. If another page is
preferred, please let us know.
Original:
[PSACertified]
PSA Certified, "PSA Certified IoT Security Framework",
2022,<https://psacertified.org>.
Current:
[PSACertified]
PSA Certified, "Expert IoT Security Framework and
Certification",<https://psacertified.org>.
d) It appears as though the goal is to refer to the most recent I-D prior to deprecation
of the "private use range" values. As such, we have updated the reference to
refer to version -08. Please review and let us know if any updates are needed.
Original:
[PSA-OLD] Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and
T. Fossati, "Arm's Platform Security Architecture (PSA)
Attestation Token", Work in Progress, Internet-Draft,
draft-tschofenig-rats-psa-token-07, 1 February 2021,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
rats-psa-token-07>.
-->
12) <!-- [rfced] We have updated the reference for [STD96] to include entries
for both of the RFCs (9052 and 9338) that comprise the STD. Please review
consider whether the text should specifically refer to RFC 9052 only or if the
current update is acceptable.
Original:
COSE_Sign1 is used for digital signatures and COSE_Mac0 for
MACs, as defined in the COSE specification [STD96].
[STD96] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
Current:
COSE_Sign1 is used for digital signatures and COSE_Mac0 for
MACs as defined in the COSE specification [STD96].
[STD96] Internet Standard 96,
<https://www.rfc-editor.org/info/std96>.
At the time of writing, this STD comprises the following:
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Countersignatures", STD 96, RFC 9338,
DOI 10.17487/RFC9338, December 2022,
<https://www.rfc-editor.org/info/rfc9338>.
Perhaps:
COSE_Sign1 is used for digital signatures and COSE_Mac0 for
MACs as defined in the COSE specification [RFC9052].
-->
13) <!-- [rfced] Please review each artwork element and let us know if any
should be marked as sourcecode (or another element) instead.
In addition, review the updates to sourcecode with type="cddl". If
<sourcecode> is used elsewhere in the document, please consider whether the
type should be set. The current list of preferred values for "type" is
available at
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
If the current list does not contain an applicable type, feel free to
suggest additions for consideration. Note that it is also acceptable
to leave the "type" attribute not set.
-->
14) <!-- [rfced] Terminology
a) We note that <tt> tags are used with a few terms
throughout the document. We also note that these terms also appear
without <tt> tags. Please consider whether updates are needed for
consistency. The pattern of use is unclear to us.
<tt>bootseed</tt> vs. bootseed
<tt>configuration</tt> vs. configuration
<tt>eat_profile</tt> vs. eat_profile
<tt>hardware</tt> vs. hardware
<tt>nonce</tt> vs. nonce
b) Please let us know how we should update the following terms for
consistency throughout the document.
EAT nonce claim vs. nonce claim vs. Nonce claim
Arm's Platform Security Architecture vs. The Arm Platform Security Architecture
Boot Seed vs. bootseed
claims-set vs. claims sets (Appendix A)
PSA-token claims-set vs. PSA claims-set (Appendix A)
-->
15) <!-- [rfced] FYI - We have added expansions for abbreviations upon
first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). The abbreviated
form of each term is used thereafter. Please review each expansion in the
document carefully to ensure correctness.
-->
16) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers. Note that
our script did not flag any words in particular, but this should still be
reviewed as a best practice. -->
Thank you.
RFC Editor
On May 15, 2025, at 4:45 PM,rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/05/15
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP –https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
*rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
*auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9783.xml
https://www.rfc-editor.org/authors/rfc9783.html
https://www.rfc-editor.org/authors/rfc9783.pdf
https://www.rfc-editor.org/authors/rfc9783.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9783-diff.html
https://www.rfc-editor.org/authors/rfc9783-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9783-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9783
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 9783 (draft-tschofenig-rats-psa-token-24)
Title : Arm's Platform Security Architecture (PSA) Attestation Token
Author(s) : H. Tschofenig, S. Frost, M. Brossard, A. Shaw, T. Fossati
WG Chair(s) :
Area Director(s) :
