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 <brian.sipos+i...@gmail.com>
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 <r...@ipv.sx> 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 <david.d...@iana.org> 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 -- acme@ietf.org
>> To unsubscribe send an email to acme-le...@ietf.org
>>
>
_______________________________________________
Acme mailing list -- acme@ietf.org
To unsubscribe send an email to acme-le...@ietf.org
