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/ > > > 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]
