Hi!
I conducted an AD review of draft-ietf-acme-dtnnodeid-04. Thanks for all of
the work on this extension to support DTN. My feedback is as follows:
** This document proposes an update to draft-ietf-dtn-bpbis.
-- Editorially, if that's the case, the document header has a typo of
"-ietf-dtn-bpbis". The abstract should explicitly state that what document is
being updated and how.
-- On the process side, this arrangement is rather unusual. No quarrels with
the substance of the update which will improve extensibility. However, this
particular document has experimental status and the document being updated
(draft-ietf-dtn-bpbis) is proposed standard (PS). Having a lower maturity
document updating one of higher status is my concern -- "experiments fail".
Was this issue considered? Discussed with the DTN WG? I'll note that
draft-ietf-dtn-bpbis has not yet been published (although it is in the late
state of the RFCEd queue). Could the changes just be added there directly?
**I need a little help on DTN addressing. The text notes that that the intent
is to issue certificates with DTN Node IDs as a URI in subjectAltName.
(a) From the ABNF in Section 4.2.5.1.1 of draft-ietf-dtn-bpbis-31 of the dtn
schema says:
dtn-uri = "dtn:" ("none" / dtn-hier-part)
dtn-hier-part = "//" node-name name-delim demux ; a path-rootless
node-name = 1*(ALPHA/DIGIT/"-"/"."/"_") reg-name
name-delim = "/"
demux = *VCHAR
(b) The dtn schema does have circumstances where there is an authority part to
the URI. The definition of reg-name in Section 3.2.2 of RFC3986 seems to
suggest sufficient flexibility such that it would not represent a name valid
(at least in syntax) in the DNS
(c) Section of 4.2.1.6 of RFC5280 says the following about URIs in the SAN:
URIs that
include an authority ([RFC3986], Section 3.2) MUST include a fully
qualified domain name or IP address as the host.
Given the constraint of (c) and the flexibility afforded with the definition of
a node ID in (a)+(b), will DTN Node IDs always satisfy the requirement from (c)
to be FQDN? Is language needed to ensure that (likely in a few places in the
document)?
** Section 1. Editorial. The paragraph starting with "Once an ACME server
validates ..." jumps immediately into discussion a "uri" without explicitly
describing it. The text also transitions from the previous paragraph talking
DTN Node Ids being URIs and now talking about "uri". I would have appreciate a
bit more hand-holding use the ACME terminology of a new "identifier type" and
the need for a new DTN specific "challenge type".
** Section 1.
This document also updates BPv7 to explicitly use the IANA
administrative record type registry in Section 6.
Please explicitly cite a reference to BPv7
** Section 1.2.
When a ACME client requests a pre-authorization or an order with a
"uri" having one of the DTN Node ID schemes, the ACME server offers a
challenge type to validate that Node ID.
As noted in section 1, please explicitly state that what a "uri" is - a new
ACME identifier type. I would recommend:
When a ACME client requests a pre-authorization or an order with a "uri"
identifier type with a value being one of the DTN Node ID schemes, the ACME
server offers an "dtn-nodeid-01" challenge type to validate that Node ID.
** Figure 1. For clarity, it would be helpful to number the arrows between
nodes and also use the corresponding numbers in the narrative text.
** Section 1.3. The explicit guidance on extracting the CDDL from the XML is
very useful. Thanks for including it.
** Section 1.4. Per the definition of "Challenge Bundle", shouldn't text
clarify that it's the BP agent of the ACME server? The Response Bundle
helpfully makes that distinction.
OLD
It is a Bundle created by the ACME
server to challenge a Node ID claim.
NEW
It is a Bundle created by the BP agent managed by the ACME
server to challenge a Node ID claim.
** Section 2.
Identifiers of type "uri" in certificate requests MUST appear in an
extensionRequest attribute [RFC2985] containing a subjectAltName
extension of type uniformResourceIdentifier having a value consistent
with the requirements of [RFC3986]. Because the
uniformResourceIdentifier is encoded as an IA5String it SHALL be
treated as being in the percent-encoded form of Section 2.1 of
[RFC3986].
Section 1 invokes the use of the PKIX profile [RFC5280]. The above described
guidance is only part of the constraints on using a SAN on the URI. Section
4.2.1.6 of [RFC5280] covers the rest.
** Section 3.
"token-chal" This token is unique to, and constant for, each ACME
authorization.
This sentence reads to me as saying inconsistent things - "unique to ... each
ACME authorization" suggests that each authorization gets a different token.
"... and constant for each ACME authorization" seems to suggest is the same
token across all ACME authorizations. That doesn't seem right.
** Section 3. Editorially. I found the validation process being described as
two separate lists of action, one for the client and one from the server,
instead of interleaving them hard to follow. However, I yield to the WG on
this one.
** Section 3.3.
Source Node ID: The Source Node ID SHALL indicate the Node ID of the
ACME server performing the challenge.
Is it the "Node ID of the ACME server" or the "Node ID of the BP agent of the
ACME server"
** Section 3.4. Typo. s/Each Each/Each/
** Section 3.4. Typo. s/the the/the/
** Section 3.4.1.
* The Response Bundle was received within the time interval allowed
for the challenge.
It would be helpful to state if this check based is based on the Creation Time
and Lifetime fields.
** Section 4. The text here is generic describing the functionality of the
gateway. Figure 1 presented an architecture where only the Response Bundle
would pass through the integrity gateway. Is it envisioned that the Challenge
Bundle could use it as well?
** Section 8. It would be worth repeating that the Security Considerations of
draft-ietf-dtn-bpbis apply to the BP-to-BP agent communication. Likewise, that
RFC8555 applies to the ACME client/server communication.
** Section 8. Section 1.1 states that the communication between the ACME
client and ACME server and their respective BP agents is out of scope.
However, the integrity of the entire ACME issuance process rests on security of
this communication. Can the risks of and considerations for that communication
please be documented?
Regards,
Roman
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
