Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04

[Roman Danyliw <[e-mail]>]

Hi Brian!

Thanks for all of the changes in -05 and -06 to address the feedback below, and the coordinated discussion in the DTN working group.  Please consider all of the -04 feedback resolved but this one remaining change. 

One more edit needs to be made in the change from using uri to bundleEID as the ACME identifier type.  The IANA registrations in Sections 8.1 and 8.2 still refer to "uri" as the type, when in should be "bundleEID".

-- Section 8.1, substitute the label as follows: s/uri/bundleEID/

-- Section 8.2, substitute the identifier type as follows: s/uri/bundleEID/

Regards,
Roman


> -----Original Message-----
> From: Acme <[e-mail]> On Behalf Of Roman Danyliw
> Sent: Friday, July 23, 2021 3:15 PM
> To: [e-mail]
> Subject: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme