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

[Brian Sipos <[e-mail]>]

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 <[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]> 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]>
>> 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]> 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 <[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 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 -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>> _______________________________________________
>> Acme mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>