Hi David, Thanks for the nudge. This is approved.
Thanks to the authors for making the fixes. --Richard On Fri, Jun 20, 2025 at 10:30 PM David Dong <[email protected]> wrote: > Hi Richard, > > > > Following up on this; could you take a look at the new draft that was > uploaded, addressing your comments? > > > > https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/18/ > > > > Thank you. > > > > Best regards, > > > > David Dong > > IANA Services Sr. Specialist > > > > *From: *David Dong <[email protected]> > *Date: *Friday, June 13, 2025 at 7:02 PM > *To: *Richard Barnes <[email protected]> > *Cc: *"[email protected]" <[email protected]>, "[email protected]" < > [email protected]>, Deb Cooley <[email protected]>, Brian Sipos < > [email protected]> > *Subject: *Re: [Ext] Re: [Acme] Re: [IANA #1417923] expert review for > draft-ietf-acme-dtnnodeid (acme) > > > > Hi Richard, > > > > Following up on this; could you take a look at the new draft that was > uploaded, addressing your comments? > > > > https://datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/18/ > > > > Thank you. > > > > Best regards, > > > > David Dong > > IANA Services Sr. Specialist > > > > *From: *Deb Cooley <[email protected]> > *Date: *Wednesday, June 4, 2025 at 8:12 AM > *To: *Brian Sipos <[email protected]> > *Cc: *Richard Barnes <[email protected]>, David Dong <[email protected]>, " > [email protected]" <[email protected]>, "[email protected]" <[email protected] > > > *Subject: *[Ext] Re: [Acme] Re: [IANA #1417923] expert review for > draft-ietf-acme-dtnnodeid (acme) > > > > Good work. > > > > Med has cleared his discuss. I check Erik Kline's comments, those are > fine too. > > > > Hopefully Richard can find time to take a look, or we will merely wait > until he has time. No worries there. > > > > It is also only Wed midday, still plenty of time for comments (Paul, for > example). So, it isn't done and dusted yet. Just a warning.... > > > > Deb > > > > > > > > On Wed, Jun 4, 2025 at 8:26 AM Brian Sipos <[email protected]> > wrote: > > 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/ > [datatracker.ietf.org] > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/18/__;!!PtGJab4!9hDcYxKBtRH0fxQ0lnhPyHG3qDZMgqHhzr0_TqqdxCElI3dLy1uTJHvLYkk9to4NMxNgllWerk1ap35ieqzA_7EPTWo$> > > > > > > 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 > [ietf.org] > <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-acme-dtnnodeid-17.html*name-bundle-endpoint-id-acme-ide__;Iw!!PtGJab4!9hDcYxKBtRH0fxQ0lnhPyHG3qDZMgqHhzr0_TqqdxCElI3dLy1uTJHvLYkk9to4NMxNgllWerk1ap35ieqzAhUH7cq4$> > > [2] https://www.rfc-editor.org/rfc/rfc9171.html#name-endpoint-id > [rfc-editor.org] > <https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc9171.html*name-endpoint-id__;Iw!!PtGJab4!9hDcYxKBtRH0fxQ0lnhPyHG3qDZMgqHhzr0_TqqdxCElI3dLy1uTJHvLYkk9to4NMxNgllWerk1ap35ieqzAZhMiGH8$> > > > > 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/ > [datatracker.ietf.org] > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-acme-dtnnodeid/__;!!PtGJab4!9hDcYxKBtRH0fxQ0lnhPyHG3qDZMgqHhzr0_TqqdxCElI3dLy1uTJHvLYkk9to4NMxNgllWerk1ap35ieqzAFyS1ryY$> > > > > 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]
