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

[Brian Sipos <[e-mail]>]

Roman,
Thank you for this thorough review. I want to address the more
procedural/structural points first; the ones which have implications outside of
just this document.

> 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?

BS: I did bring this up in the DTN WG earlier and the BPbis authors were fine
with the update itself, which didn't require BPbis document changes, but I
understand the concern about the different document status levels. I have
brought this new concern up in the DTN WG with options of either a late AUTH48
edit or a separate small Proposed Standard document from the DTN WG. The change
really is not specific to this ACME document but related only to this being the
first new administrative record type for BPv7.

> **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.
> ...
> 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)?

BS: This is a good catch regarding conformance to RFC 5280, and unfortunately
represents a subtle logical conflict with this and another document [1].
Although Section 4.2.1.6 of RFC 5280 states this requirement about the URI
authority part it makes no other use of this authority restriction, and although
RFC 6125 does define a URI-ID which has matching logic based on the authority
part the certificate profile shared by DTN TCPCLv4 [1] and this document
explictly avoid using URI-ID in favor of the matching logic defined in [1] for
NODE-ID.
So while a "dtn" scheme URI contains an authority part which I believe meets the
intent of the RFC 5280 restriction (a unique and unambiguous name/address) it
does not meet the letter-of-the-law in that document. The dtn scheme is already
in use and has been for many years; although it resembles a URN in semantics it
does use a URL syntax which may be more of an historical accident than a design
decision (as the "ipn" scheme does not use the URL authority syntax).
Do you think that explicitly calling this out in this document and in [1] are an
acceptable way to avoid this logical issue? Meaning any CSR or certificate
handler for DTN must be aware to ignore that specific RFC 5280 requriement.

I think all of your other comments are sensible and I will respond to them
separately.
Thank you,
Brian S.

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-26#section-4.4.2