All, thank you for patience and apologies for being so close to the telechat date. But a -18 is now posted [1] that should address all critical feedback from Richard and Mohamed.
There were a couple of style comments from Richard which I believe are valid but would affect the JSON object keys and Key Authorization structure so I have not made changes. These may be considered as feedback related to the experimental nature of this document and deferred to a future validation version. I don't feel strongly as to whether or not any more changes are needed, only erring on the side of not making technical changes. Brian S. [1] https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/18/ On Wed, Jun 4, 2025 at 5:57 AM Deb Cooley <[email protected]> wrote: > Brian, > > Go ahead and issue a new draft when you have these changes (and any > changes necessary from Med's discuss). I won't file a discuss, but I also > won't progress the draft until IANA is happy with it. > > If you can clear the IANA hurdle before Thursday morning, it will be > easier. (possibly too much pressure on Richard, but at least a new draft > will help) > > As for Med's discuss, reply to address his discuss comments and non > discuss comments, making changes where you believe they should be made, and > justifying no change where you think that is a better option. If it needs > to be two updates to the draft (the first for IANA and the second for Med > and others) that is fine. > > Deb > > On Wed, Jun 4, 2025 at 3:55 AM Richard Barnes <[email protected]> wrote: > >> If you have fixes cued up, I would suggest going ahead and issuing a new >> draft. If I were an AD reviewing this, I would put a DISCUSS on it on the >> grounds of it not being clearly enough specified :) >> >> On Wed, Jun 4, 2025 at 3:18 AM Brian Sipos <[email protected]> >> wrote: >> >>> Richard, >>> I agree with the inconsistencies or confusions that you have commented >>> on. I am preparing an updated draft to address these comments without >>> changing the required or observable behavior. The validation method has a >>> typo and its challenge hash algorithm options are mandatory, the CDDL has >>> limited expressiveness about allowed combinations of items. >>> >>> The JSON object keys (dashed-name vs camelCase) I don't have strong >>> feelings about and this would be a change to the ACME side of the >>> validation method but I will try to stick with convention while being >>> understandable in correlating names. >>> >>> I agree that the list of client procedure and server procedure steps >>> should be informative and just combine existing ACME requirements. I will >>> move normative statements out of those lists. >>> >>> On the topic of the concatenation scheme, to reuse the Key Authorization >>> mechanism defined in Section 8.1 of RFC 8555 the "token" part must contain >>> only base64url characters which disallows an embedded dot "." separator. >>> There is no strict reason why this method needs to use that exact Key >>> Authorization definition but it feels like using an alternative may be >>> inviting its own confusion. Any thoughts about this? >>> >>> Would a new draft revision be appropriate before the IESG telechat this >>> week? >>> I will have a non-datatracker proposed update soon. >>> >>> Brian S. >>> >>> On Thu, May 29, 2025 at 11:12 AM Richard Barnes <[email protected]> wrote: >>> >>>> Hi David and ACME folks, >>>> >>>> This specification isn't quite sufficient, on either front. >>>> >>>> # Identifier type >>>> >>>> The document does not actually specify what goes in the "value" field >>>> of the identifier. The reference listed in the IANA registration is to >>>> this document and the generic URL specification. The latter is unhelpful >>>> and should be removed. For the former, I assume the reference is to >>>> Section 2 [1], but that section doesn't say what goes in the "value" >>>> field. I would expect there to be some reference to the Endpoint ID >>>> specification in RFC 9171 [2]. Basically what's missing here is a sentence >>>> of the following form: >>>> >>>> """ >>>> The `value` field of the ACME identifier object of type `bundleEID` >>>> MUST be a URI of the form specified in {{Section 4.2.5.1 of RFC9171}}. >>>> """ >>>> >>>> As an aside, the text starting " Identifiers of type "bundleEID" in >>>> certificate requests SHALL appear in an extensionRequest attribute..." >>>> doesn't make any sense here. This isn't an ACME field. If you mean that >>>> the CSR submitted in order finalization should also contain an >>>> extensionRequest (in addition to the identifier being used in ACME in this >>>> form), say that. >>>> >>>> # Validation method >>>> >>>> This section is more complete, but the hash algorithm selection is >>>> under-specified. The bundle description in Section 3.3 says "...containing >>>> two pairs" and then lists three mandatory pairs, and the CDDL in Appendix A >>>> has the hash algorithm negotiation as syntactically optional. The >>>> mechanism doesn't work without a defined hash algorithm, so either you need >>>> to just pick one or make the negotiation mandatory. "Just pick one" would >>>> be my suggestion -- you already have validation methods as a way to do >>>> negotiation, and hash algorithms don't change that often. You're reliant >>>> on SHA-256 anyway, by way of the keyAuthorization construction. >>>> >>>> Comments: >>>> * Nit: "token-chal", "token-bundle", and "id-chal" are inconsistent >>>> with the field camel case naming convention in ACME. "challengeToken", >>>> "bundleToken", and "id" would be more consistent. >>>> * In the list of client actions, (1), (2), (4), and (8) are just >>>> "follow the normal ACME process". You could probably remove this list, or >>>> make it more succinct. It should not be normative in any case; what >>>> matters is that the client does something that satisfies the server's >>>> mandatory checks. >>>> * The concatenation scheme here risks confusion between two >>>> challenges. Better to separate them, e.g., with a "." character. >>>> * The "request object" and "response object" are incorrectly named -- >>>> they're backwards. >>>> * The "request object" is actually the challenge object, which is >>>> delivered in an HTTP response >>>> * The "response object" is the object that is included in a POST >>>> request by the client in order to select the challenge >>>> >>>> Cheers, >>>> --Richard >>>> >>>> [1] >>>> https://www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-17.html#name-bundle-endpoint-id-acme-ide >>>> [2] https://www.rfc-editor.org/rfc/rfc9171.html#name-endpoint-id >>>> >>>> On Thu, May 29, 2025 at 12:16 AM David Dong <[email protected]> >>>> wrote: >>>> >>>>> Dear Richard Barnes (cc: acme WG), >>>>> >>>>> >>>>> >>>>> Following up; as the designated expert for the ACME Identifier Types >>>>> and ACME Validation Methods registries, can you review the proposed >>>>> registrations in draft-ietf-acme-dtnnodeid-17 for us? This is on the June >>>>> 5 >>>>> th telechat agenda. >>>>> >>>>> >>>>> >>>>> Please see: >>>>> >>>>> >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/ >>>>> >>>>> >>>>> >>>>> The due date was May 12. >>>>> >>>>> >>>>> >>>>> If this is OK, when the IESG approves the document for publication, >>>>> we'll make the registrations at: >>>>> >>>>> >>>>> >>>>> https://www.iana.org/assignments/acme/ >>>>> >>>>> >>>>> >>>>> With thanks, >>>>> >>>>> >>>>> >>>>> David Dong >>>>> >>>>> IANA Services Sr. Specialist >>>>> >>>> _______________________________________________ >>>> Acme mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> _______________________________________________ >> Acme mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
