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]
