Roman, My replies regarding the other, editorial comments are below with the prefix "BS:". I'll get back to the earlier topics in the other mail thread.
** 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". > > BS: I will add a third paragraph in that section to explain the new ACME identifier and its rationale before using it. > ** 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 > > BS: Will do. > ** 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. > > BS: Will do, this phrasing is more clear. > ** Figure 1. For clarity, it would be helpful to number the arrows between > nodes and also use the corresponding numbers in the narrative text. > > BS: I agree, will add ordinal number hints to each flow. > ** 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. > > BS: Will clarify this. > ** 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. > > BS: I will rephrase to specifically point to RFC5280 as a direct requirement here. > ** 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. > > BS: I added a statement to clarify unique-to-authorization vs. unique-to-challenge: Each authorization can consist of multiple Challenge Bundles (e.g. taking different routes), but they all share the same "token-chal" value. and also the the "token-bundle" paragraph explaining: This ensures that the Key Authorization is bound to the ability to receive the Challenge Bundle and not just have access to the ACME Challenge Object. > ** 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. > > BS: This was more due to taking existing ACME validation methods as examples than any other driving concern. I suspect that is because the client vs. server implementers have different communities of users. ** 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" > > BS: Yes, this is inaccurate and will be corrected. > ** Section 3.4. Typo. s/Each Each/Each/ > > ** Section 3.4. Typo. s/the the/the/ > > BS: Will fix both of these. > ** 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. > > BS: I will add explanatory text here and for the challenge bundle of: The allowed interval starts at the Creation Timestamp and extends for the Lifetime of the Response Bundle. > ** 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? > > BS: Not explicitly; the concept being that the BP node operated by the ACME server would be implicitly trusted (e.g. pre-configured on the ACME client's BP node) and would be BIB-signing its own outgoing bundles. This is similar in concept to the ACME HTTP server having a TLS-purpose certificate chained to a CA trusted by the ACME HTTP client. This doesn't *prohibit *a network from using an integrity gateway in both directions (or using any other variety of extension blocks and exotic BP configs) but doesn't require it. > ** 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. > > BS: Agreed, and I will add a security subsection to clarify this. > ** 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? > > BS: I am adding a few paragraphs for this topic, because most of this communication doesn't need confidentiality but it does need to have positive access control and prevent spoofing.
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
