Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the source file.
1) <!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
2) <!--[rfced] In the following, is the meaning between ACME client and
server pairs themselves as well as between BP agents themselves?
Or was it intended to be both within ACME client/servers and
between ACME client/servers and BP agents? Note: used a single
hyphen in the "Original" below for this XML comment.
Original:
* Mechanisms for communication between ACME client or ACME server
and their associated BP agent(s). This document only describes
exchanges between ACME client-server pairs and between their BP
agents.
-->
3) <!--[rfced] Looking at Figure 1, please let us know if the following
suggested clarification captures your intended meaning for this
sentence.
Original:
There is nothing in this protocol which requires network-topological
co-location of either the ACME client or ACME server with their
associated BP agent.
Perhaps:
There is nothing in this protocol that requires network-topological
co-location of either the ACME client or ACME server with their
respective associated BP agents.
-->
4) <!--[rfced] How may we update this text to clarify?
Original:
Because this is an ACME document, the following DTN Bundle Protocol
terms are defined here to clarify how they are used by this ACME
identifier type and validation mechanism.
Perhaps A:
Because this document is about ACME, the following DTN Bundle Protocol
terms are defined here to clarify how they are used by this ACME
identifier type and validation mechanism.
Perhaps B:
Because this is a document produced by the ACME WG, the following DTN
Bundle Protocol terms are defined here to clarify how they are used by
this ACME identifier type and validation mechanism.
-->
5) <!--[rfced] This sentence is a bit difficult to follow. Does the
suggested text correctly capture your intent?
Original:
One possible scenario for this would be an issuing CA and an ACME
server on the edge of a BP transit network operated by one agency,
which is accessed via edge routers operated by a second agency, used
by edge nodes known to and trusted by the second agency but not the
first.
Perhaps:
One possible scenario for this would be an issuing CA and an ACME
server on the edge of a BP transit network operated by an agency.
This agency is accessed via edge routers operated by a second agency.
The second agency is used by edge nodes it knows and trusts, but that
are not known or trusted by the first agency.
-->
6) <!--[rfced] Is there another way to say "PKIX other name form"? Is
the meaning "PKIX naming scheme" or "PKIX equivalent of
BundleEID"?
Original:
While the PKIX other name form of BundleEID can hold any Endpoint ID
value, the certificate profile used by [RFC9174] and supported by
this ACME validation method in Section 3 requires that the value hold
a Node ID (Section 1.4).
-->
7) <!--[rfced] Does the following correctly capture your intent?
Original:
This typically is limited to an Administrative Endpoint ID (Section
1.4), but there is no prohibition on the administrative element of a
BP node from receiving administrative records for, and sending records
from, other Node IDs in order to support this validation method.
Perhaps:
Typically, this is limited to an Administrative Endpoint ID (Section
1.4). However, the administrative element of a BP node is not
prohibited from receiving administrative records for, or sending
records from, other Node IDs in order to support this validation
method.
-->
8) <!--[rfced] Is the meaning of "meeting" "matching?
Original:
* The challenge payload contains a token-bundle meeting the
definition in Section 3.3.
Perhaps:
* The challenge payload contains a token-bundle matching the
definition in Section 3.3.
-->
9) <!--[rfced] Should any citation information be included for IP-ID in
this sentence?
Original:
A single bundle security CSR MAY contain a mixed set of SAN
identifiers, including combinations of IP-ID, DNS-ID [RFC9525] and
NODE-ID [RFC9174] types.
-->
10) <!--[rfced] Is there a way to reduce the redundancy of "path" in this
sentence?
Original:
Another way to mitigate single-path on-path attacks is to attempt
validation of the same Node ID from multiple sources or via multiple
bundle routing paths, as defined in Section 3.5
-->
11) <!--[rfced] Should "it" be "them" (i.e., the Key Authorization and the
cryptographic digest)?
Original:
Ultimately, the point of the ACME bundle exchange is to derive a Key
Authorization and its cryptographic digest and communicate it back to
the ACME server for validation, so the uniqueness of the Key
Authorization directly determines the scope of replay validity.
Perhaps:
Ultimately, the point of the ACME bundle exchange is to derive a Key
Authorization and its cryptographic digest and communicate them back to
the ACME server for validation, so the uniqueness of the Key
Authorization directly determines the scope of replay validity.
-->
12) <!--[rfced] We had the following questions/comments related to abbreviation
use throughout the document:
a) 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.
b) Note that we will update to use the abbreviation in lieu of the
expansion on subsequent uses in accordance with
https://www.rfc-editor.org/styleguide/part2/#exp_abbrev for the
following.
BP
EID
-->
13) <!--[rfced] We had the following questions related to terminology use
throughout the document:
a) The following forms appeared with different capping schemes.
Please let us know if/how they should be made consistent.
Bundle vs. bundle
Challenge Bundle vs. challenge bundle
Response Bundle vs. response bundle
BP Agent vs. BP agent
BP Node vs. BP node
Challenge Object vs. challenge object vs. Challenge object
Security Source vs. security source
Lifetime vs. lifetime
Key Authorization vs. key authorization
b) We see the following similar terms. Please let us know if/how they
may be made consistent:
BundleEID vs. Bundle EID vs. Bundle Endpoint ID
ACME Identifier type "bundleEID" vs. identifiers of type "bundleEID"
vs. "bundleEID" identifier type vs. identifier type "bundleEID"
-->
14) <!-- [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.
-->
15) <!-- [rfced] The terms enclosed in <tt> in the xml version of this document
are listed below.
Please review to ensure the usage of <tt> is correct and consistent.
Let us know if any updates are needed.
<tt>BundleEID</tt>
<tt>extensionRequest</tt>
<tt>id-chal</tt>
<tt>id-kp-bundleSecurity</tt>
<tt>id-on-bundleEID</tt>
<tt>otherName</tt>
<tt>subjectAltName</tt>
<tt>token-bundle</tt>
<tt>token-chal</tt>
-->
16) <!--[rfced] Please review the use of citation tags throughout the
document: some are read as part of the sentence while others are
not syntactically relevant.
Please see https://www.rfc-editor.org/styleguide/part2/#citation_usage
for further information/guidance.-->
Thank you.
Megan Ferguson
RFC Production Center
*****IMPORTANT*****
Updated 2025/11/03
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
* [email protected] (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).
* [email protected], 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,
[email protected] 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/rfc9891.xml
https://www.rfc-editor.org/authors/rfc9891.html
https://www.rfc-editor.org/authors/rfc9891.pdf
https://www.rfc-editor.org/authors/rfc9891.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9891-diff.html
https://www.rfc-editor.org/authors/rfc9891-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9891-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9891
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9891 (draft-ietf-acme-dtnnodeid-18)
Title : Automated Certificate Management Environment (ACME)
Delay-Tolerant Networking (DTN) Node ID Validation Extension
Author(s) : B. Sipos
WG Chair(s) : Yoav Nir, Mike Ounsworth
Area Director(s) : Deb Cooley, Paul Wouters
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
