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

[Brian Sipos <[e-mail]>]

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