Hi Brian! > -----Original Message----- > From: Brian Sipos <[email protected]> > Sent: Tuesday, July 27, 2021 5:13 PM > To: Roman Danyliw <[email protected]> > Cc: [email protected] > Subject: RE: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04 > > 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.
Thanks for bringing the issue to DTN. We'll wait to see the next steps. > > **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 see this is more complicated than I realized. Thanks for explaining it. I think the current options might be: (1) Roughly what you said above + Make it clear that this document is NOT using the RFC5280 profile and simply reusing the data structures (but not the validation logic). Related to this, and excuse my ignorance about DTN, would it be possible to constrain these non-RFC5280-conforming certificates from appear on the internet with some normative phrasing. Technically, RFC5280 is the _Internet_ PKIX profile. This document goes to great pains to separate the internet portion of the ACME protocol exchange and the validation happening over DTN (which might be considered a "limited domain" as framed by RFC8799). (2) Revise RFC5280. I'm loath to pursue this path unless we really need to. Regards, Roman > 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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
