Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!--[rfced] Please note that the title of the document has been updated as
follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide"). Please review and confirm that this is how you would like
"BRSKI-AE" to be expanded both in the title and throughout the rest of
this document.
Original:
BRSKI-AE: Alternative Enrollment Protocols in BRSKI
Current:
BRSKI-AE: Bootstrapping Remote Secure Key Infrastructure with Alternative
Enrollment
-->
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
3) <!-- [rfced] We have updated the text below to improve readability. Please
review to ensure these changes do not alter your intended meaning.
Original:
It uses them to authenticate itself to the
Manufacturer Authorized Signing Authority (MASA, [RFC8995]), and
to the registrar, which is the access point of the target domain,
and to possibly further components of the domain where it will be
operated.
Current:
It uses them to authenticate itself to the
Manufacturer Authorized Signing Authority (MASA) [RFC8995] and the
registrar (which is the access point of the target domain) and to
possibly further components of the domain where it will be
operated.
-->
4) <!-- [rfced] Please review the following questions and changes regarding the
terminology list in Section 2:
a.) FYI - We have updated some list items to have a 1:1 relationship between
abbreviation and expansion. Please carefully review these changes and let us
know of any objections.
b.) As this list contains a mixture of definitions and abbreviations, may we
separate these items into two separate lists for readability?
c.) We note that several abbreviations appear in this document that are not
included in the terminology list in Section 2 (see some examples
below). Please review and let us know if these or any other terms should be
added.
(Note that we have already added a list item for Certification Authority (CA)
as this abbreviation appears in other definitions in this list.)
Key Encapsulation Mechanism (KEM)
Certificate Request Message Format (CRMF)
Simple Certificate Enrolment Protocol (SCEP)
Certificate Management over CMS (CMC)
Autonomic Control Plane (ACP)
-->
5) <!-- [rfced] May we clarify the content in the parenthetical text below?
Original:
Binding a certificate signing request (CSR) to an existing
authenticated credential (the BRSKI context, the IDevID certificate)
enables proof of origin...
Perhaps:
Binding a Certificate Signing Request (CSR) to an existing
authenticated credential (such as the BRSKI context or the IDevID
certificate)
enables proof of origin...
-->
6) <!-- [rfced] FYI - For ease of the reader, we have broken up the following
sentences below into two. Please let us know any objections.
Original:
What the registrar needs to do is to authenticate and pre-authorize the
pledge and to indicate this to the (second) RA by signing the forwarded
certification request with its private key and a related certificate
that has the id-kp- cmcRA extended key usage attribute.
...
It will recognize whether the protocol
it uses and the specific request it wants to perform are understood
and supported by the domain registrar by sending the request to the
respective endpoint according to the above addressing scheme and then
evaluating the HTTP status code of the response.
Current:
What the registrar needs to do is authenticate and pre-authorize the
pledge and indicate this to the (second) RA. This is done by signing the
forwarded certification request with its private key and a related
certificate
that has the id-kp-cmcRA extended key usage attribute.
...
It will recognize whether the protocol
it uses and the specific request it wants to perform are understood
and supported by the domain registrar. This is done by sending the
request to the respective endpoint according to the above addressing
scheme and then evaluating the HTTP status code of the response.
-->
7) <!--[rfced] To avoid the awkward hyphenation of "PKCS #10-formatted CSRs",
may we update the text as follows?
Original:
[RFC7030], Section 2.5 sketches wrapping PKCS #10-formatted CSRs
with a Full PKI Request message sent to the "/fullcmc" endpoint.
Perhaps:
[RFC7030], Section 2.5 sketches wrapping CSRs formatted per PKCS #10
with a Full PKI Request message sent to the "/fullcmc" endpoint.
-->
8) <!-- [rfced] We note the use of "FullCMCRequest" in the following sentence;
however, RFC 7030 uses the term "Full CMC Request". May we update this
instance for consistency with RFC 7030?
Original:
The proof of identity can be provided as part of a FullCMCRequest, based on
CMS [RFC5652] and signed with an existing IDevID secret.
Perhaps:
The proof of identity can be provided as part of a Full CMC Request based on
CMS [RFC5652] and signed with an existing IDevID secret.
-->
9) <!-- [rfced] In the sentence below, may we update "follows" for clarity?
Original:
Note: From the definition of the interaction with the MASA in
[RFC8995], Section 5 follows that it may be synchronous (using
voucher request with nonces) or asynchronous (using nonceless
voucher requests).
Perhaps:
Note: From the definition of the interaction with the MASA in
Section 5 of [RFC8995], it may be synchronous (using
voucher requests with nonces) or asynchronous (using nonceless
voucher requests).
-->
10) <!-- [rfced] How may we clarify what "as not already done" and "it" refer to
in the text below?
Original:
* RA: performs centralized certificate management functions as a
public-key infrastructure for the domain operator. As far as not
already done by the domain registrar, it performs the final
validation and authorization of certification requests.
Perhaps:
* RA: This performs centralized certificate management functions as a
public-key infrastructure for the domain operator. As far as what is
not already done by the domain registrar, the RA performs the final
validation and authorization of certification requests.
-->
11) <!-- [rfced] Throughout this document, we note that RFCs 8895 and 9483 are
often referred to with shortened titles or nicknames such as "BRSKI" and
"LCMPP", respectively.
For clarity, because these names also represent protocols, we plan to update
these document nicknames to just their RFC number (in order to help the reader
distinguish between the RFC itself and the protocol). Please see some examples
below and let us know any objections.
Originals:
In this document, references to CMP follow the Lightweight CMP
Profile (LCMPP) [RFC9483] rather than [RFC4210] and [RFC9480], as the
subset of CMP defined in LCMPP sufficiently meets the required
functionality.
* MASA: functionality as described in BRSKI [RFC8995]. The voucher
exchange with the MASA via the domain registrar is performed as
described in BRSKI.
* Ownership tracker: This is as defined in BRSKI.
Perhaps:
In this document, references to CMP follow [RFC9483] rather than
[RFC4210] and [RFC9480], as the subset of CMP defined in [RFC9483]
sufficiently meets the required functionality.
* MASA: This has the functionality as described in [RFC8995].
The voucher exchange with the MASA via the domain registrar is
performed as described in [RFC8995].
* Ownership Tracker: This is as defined in [RFC8995].
-->
12) <!-- [rfced] In Section 4.1, should "Discovery phase" and "Identification
phase"
be updated to "Discover phase" and "Identity phase", respectively, to better
match the figure from Section 2.1 of RFC 8995?
Original:
Based on the diagram in BRSKI [RFC8995], Section 2.1 and the
architectural changes, the original protocol flow is divided into
several phases showing commonalities and differences to the original
approach as follows.
* Discovery phase: mostly as in BRSKI step (1). For details see
Section 4.2.1.
* Identification phase: same as in BRSKI step (2).
Perhaps:
Based on the diagram in [RFC8995], Section 2.1 and the
architectural changes, the original protocol flow is divided into
several phases showing commonalities and differences to the original
approach as follows.
* Discover phase: This is mostly as in step (1) of [RFC8995]. For
details see Section 4.2.1.
* Identity phase: This is the same as in step (2) of [RFC8995].
-->
13) <!--[rfced] To improve the readability of the following sentence, may we
update
it as follows?
Original:
For transporting the certificate enrollment request and response
messages, the (D)TLS channel established between pledge and
registrar is REQUIRED to use.
Perhaps:
It is REQUIRED to use the (D)TLS channel established between the
pledge and registrar to transport the certificate enrollment request
and response messages.
-->
14) <!-- [rfced] Should "options applicable" be updated to "applicable options"
in the text below?
Original:
Section 5 discusses selected suitable enrollment protocols and options
applicable.
Perhaps:
Section 5 discusses selected suitable enrollment protocols and applicable
options.
-->
15) <!-- [rfced] As this sentence begins Section 4.2.4, may we clarify what
"This" refers to?
Additionally, may we make a similar update in Appendix A.5?
Original:
4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment
This replaces the EST integration for PKI bootstrapping described in
[RFC8995], Section 5.9 (while [RFC8995], Section 5.9.4 remains as the
final phase, see below).
...
A.5. Infrastructure Isolation Policy
This refers to any case in which network infrastructure is normally
isolated from the Internet as a matter of policy, most likely for
security reasons.
Perhaps:
4.2.4. Pledge - Registrar - RA/CA Certificate Enrollment
RA/CA certificate enrollment replaces the EST integration for PKI
bootstrapping described in Section 5.9 of [RFC8995] (while Section 5.9.4
of [RFC8995] remains as the final phase; see below).
...
A.5. Infrastructure Isolation Policy
The infrastructure isolation policy refers to any case in which...
-->
16) <!-- [rfced] To improve readability, may we update the list below as
follows?
Original:
They include the application scenario, the capabilities of the registrar
and of the local RA possibly co-located with the registrar, the enrollment
protocol being used, and the specific contents of the request.
Perhaps:
They include the application scenario, the capabilities of the registrar,
the capabilities of the local RA possibly co-located with the registrar,
the enrollment protocol being used, and the specific contents of the
request.
-->
17) <!--[rfced] Should the following artwork element be reformatted as
a bulleted list, per text from the preceding paragraph?
Original:
The following list of endpoints provides an illustrative example of a
domain registrar supporting several options for EST as well as for
CMP to be used in BRSKI-AE.
...
/.well-known/brski/voucherrequest
/.well-known/brski/voucher_status
/.well-known/brski/enrollstatus
/.well-known/est/cacerts
/.well-known/est/csrattrs
/.well-known/est/fullcmc
/.well-known/cmp/getcacerts
/.well-known/cmp/getcertreqtemplate
/.well-known/cmp/initialization
/.well-known/cmp/pkcs10
-->
18) <!-- [rfced] Formatting and XML:
a.) There are several author comments present in the XML. Please
review and confirm that none of these comments still need to be
addressed. Note that the comments will be deleted prior to
publication.
b.) 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).
c.) We note the following different uses regarding this document's use of <tt>
styling and quotation marks. In the HTML and PDF outputs, the text enclosed in
<tt> is output in fixed-width font. In the txt output, there are no changes to
the font. Please review carefully and let us know if any updates should be made
for consistency:
the <tt>caPubs</tt> field
the acp-node-name field (no quotes or <tt> styling)
<tt>"brski-reg-cmp"</tt>
brski-reg-cmp (no quotes or <tt> styling)
<tt>"brski-registrar"</tt>
<tt>"/.well-known/est/simpleenroll"</tt>
<tt>"/.well-known/<enrollment-protocol>/<request>"</tt>
<tt>"/fullcmc"</tt> endpoint
<tt>"/simpleenroll"</tt> endpoint
'<tt>est</tt>'
'<tt>cmp</tt>'
<tt><enrollment-protocol></tt>
<tt><request></tt>
The label <tt>[OPTIONAL forwarding]</tt>
'renewal' option
"tls-unique" value
the tls-unique value (no quotes)
-->
19) <!-- [rfced] Abbreviations:
a.) FYI - We have updated the expansion of LDevID throughout the document
as follows. Please review and let us know of any objections.
Original:
Locally significant Device IDentifier (LDevID)
Current:
Local Device Identifier (LDevID)
b.) We note the following expanded forms of "PKI" are used after the
abbreviation is introduced. May we update these instances below to the
abbreviation?
Public-Key Infrastructure
public-key infrastructure
c.) May we update instances of "local RA" to the abbreviation "LRA"?
d.) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Autonomic Control Plane (ACP)
Certificate Management over CMS (CMC)
Cryptographic Message Syntax (CMS)
Constrained Application Protocol (CoAP)
Simple Certificate Enrollment Protocol (SCEP)
-->
20) <!-- [rfced] Please review the following changes and questions we have
regarding the References section:
a.) [UNISIG-Subset-137]
The provided URL returns the message: "The requested page could not be found."
We found the following URL from the European Union Agency for Railways (ERA)
website, which matches the specification described in this reference, but it
is a more up-to-date version from May 2023. Would you like to use this version
and URL instead?
<https://www.era.europa.eu/system/files/2023-09/index083_-_SUBSET-137_v400.pdf>
Current:
[UNISIG-Subset-137]
UNISIG, "ERTMS/ETCS On-line Key Management FFFIS", Subset-
137, Version 1.0.0, December 2015,
<https://www.era.europa.eu/sites/default/files/filesystem/
ertms/ccs_tsi_annex_a_-_mandatory_specifications/
set_of_specifications_3_etcs_b3_r2_gsm-r_b1/index083_-
_subset-137_v100.pdf>.
b.) [BRSKI-AE-OVERVIEW]
FYI - We have removed the text below from the <annotation> element in this
reference. If you would like to include this note, we recommend placing it in
the document where this reference is cited (rather than in the references
section).
"Graphics on slide 4 of the status update on the BRSKI-AE draft 04 at IETF
116."
c.) [IEC-62351-9]
Would you like to update to the newest version of this reference? The cited
version of this reference has been withdrawn. In addition, this version of the
document references the SCEP Internet-Draft rather than RFC 8894 (SCEP). RFC
8894 is cited in the 2023 version.
Current:
[IEC-62351-9]
International Electrotechnical Commission, "Power systems
management and associated information exchange - Data and
communications security - Part 9: Cyber security key
management for power system equipment", IEC 62351-9:2017,
May 2017, <https://webstore.iec.ch/en/publication/30287>.
-->
21) <!-- [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/kf/ap
On Feb 10, 2025, at 3:04 PM, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/02/10
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/rfc9733.xml
https://www.rfc-editor.org/authors/rfc9733.html
https://www.rfc-editor.org/authors/rfc9733.pdf
https://www.rfc-editor.org/authors/rfc9733.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9733-diff.html
https://www.rfc-editor.org/authors/rfc9733-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9733-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9733
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9733 (draft-ietf-anima-brski-ae-13)
Title : BRSKI-AE: Alternative Enrollment Protocols in BRSKI
Author(s) : D. von Oheimb, S. Fries, H. Brockhaus
WG Chair(s) : Toerless Eckert, Sheng Jiang
Area Director(s) : Warren Kumari, Mahesh Jethanandani
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
