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

[Roman Danyliw <[e-mail]>]

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