[Acme] Re: [Ext] Re: Re: [IANA #1417923] expert review for draft-ietf-acme-dtnnodeid (acme)

[David Dong <[e-mail]>]

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 <[e-mail]>
Date: Wednesday, June 4, 2025 at 8:12 AM
To: Brian Sipos <[e-mail]>
Cc: Richard Barnes <[e-mail]>, David Dong <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 5th 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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Acme mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>