Return-Path: X-Original-To: acme@mail2.ietf.org Delivered-To: acme@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 70F55307B38F for ; Tue, 3 Jun 2025 18:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr9LhxxGGAk5 for ; Tue, 3 Jun 2025 18:18:56 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9FB0F307B386 for ; Tue, 3 Jun 2025 18:18:56 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-74267c68c11so4914835b3a.0 for ; Tue, 03 Jun 2025 18:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748999936; x=1749604736; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qT5AGhvPdizwL2QvY/Pk9h5ReAt4NJMwGZp4+p+Uu0U=; b=GjGBoHXCNPICJC2x3v1wGXh6V9ejHCG5AAr0AiwgdNlKOV7VTlhuKlqz6hA1+p7sky 1BJw9xpUSx58XVykpEpkKrC0eDQB34MslNn7shJLyCgFi1dey/kHUGyo0HqzWiZP3bx7 VWofJ0I+Yr1R7TaCe6aWffNV8BrBTyOOPH9FTfn4weSnHo2n5SRAQJ5CDNONEZJSYyEP EDXEK6USBX0Gb/nLYSrpdf4aH+xEpk4bGaheYvNielrDIjrbD9v0NTNeeOEKRYcwfBpv XHWkKiX8aQOq5pcczIHHriocu85x5U9E68kEkrhOuAmEcPzxrhH8Ktx3MaVxl9D0KxV2 WsRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748999936; x=1749604736; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qT5AGhvPdizwL2QvY/Pk9h5ReAt4NJMwGZp4+p+Uu0U=; b=v3BO5O90BbOCkE7yYfjsurWDHdK9DKqPPaVPHa4xC4pcd/06EIhDfgTXnFP/YQhhaW TVS+G+B1qKGzpQnekBFGOianp52uo7UO/xXrhsf4gjuYt5/SzL2Yl94i3uF7wCSaTHpQ L7X3z/twXqo5kt5e2u5OC1r+XOOLxGGV1BJMa8g5r+zju1tksIpplWWl3DZ2fsG9uE9L eJKunpA2O8stJdMDwm2P1A3NHWwVf7Iy06sfFfHyPA5qtktauYeQLazjrTVe/3IZ2wGz 1q5hS7lk57pWgpB1KDprfJCMmxSsgYYePKo2oa175ih1xo8m0Yq367S7Vq6hTzXbVrM2 VswA== X-Forwarded-Encrypted: i=1; AJvYcCXX7UlMnuNQLYAOhR/6rWc2p6exCHAh5SepSuj5TjKzo4Qq9yfpeaDtB7FsSvQh76rIdb8s@ietf.org X-Gm-Message-State: AOJu0Yx52UgJ1XJFO+gkn9awmFxjOmfCKMO8iDHG8q82ri1V9XmRihpW ahhqvbM57nuAOxvmmswLa5P/a3ukUe4nBTh1rSgd1/0oeJADFVzoSbB5FDBhp+/KOAHCgfL4z2Q BsnWRtIdErk17ubgvo7vW0irrM0Sbbyou9Q== X-Gm-Gg: ASbGncugZMfNgS9sanuVfWHErw1iPFJX5ua1kTbYGe4fTq83skdywDuC4ECbPkLSuTn HVK5x+HnJePvyLgIDYkwZjU3SrKUFPPuIenMNQDA8ivkni6CFmY/bpkVG5dMJGsaQn5PSLaMYNN cZbIZfht5XIzG5eH1hG72WQjcKhDkoTB2EFzxnUjiHGQZjI63kQB3nPp19306uSCyc7EM= X-Google-Smtp-Source: AGHT+IHWEaIHDRWmX2zZYfRHsWoQeipp38dox2DetszicPXJ8rUHWFRN13FkcWSMFMWFa8k7pPFZCEqN0CGBEjtQ/Po= X-Received: by 2002:a17:90b:4a10:b0:312:26d9:d5a7 with SMTP id 98e67ed59e1d1-3130cd2b40emr1514936a91.20.1748999935512; Tue, 03 Jun 2025 18:18:55 -0700 (PDT) MIME-Version: 1.0 References: <26CE5291-F039-4BF6-A0CC-DD3CF426E28B@iana.org> In-Reply-To: From: Brian Sipos Date: Tue, 3 Jun 2025 21:18:44 -0400 X-Gm-Features: AX0GCFvYSieTKxIzH6wGnHdJktRcwpL_nbIAbNfgzi9awNb3Ag9NEE3AMlcQkh0 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary="000000000000de51e80636b4c783" Message-ID-Hash: SO6WS2DYFYUI5JJ54REO5DQ3YSNII37Y X-Message-ID-Hash: SO6WS2DYFYUI5JJ54REO5DQ3YSNII37Y X-MailFrom: brian.sipos@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-acme.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: David Dong , "acme@ietf.org" , "rt-comment@iana.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BAcme=5D_Re=3A_=5BIANA_=231417923=5D_expert_review_for_draft-iet?= =?utf-8?q?f-acme-dtnnodeid_=28acme=29?= List-Id: Automated Certificate Management Environment Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000de51e80636b4c783 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Richard Barnes 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 woul= d > 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 fo= rm: > > """ > 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 thi= s > 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 "...containi= ng > 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 ne= ed > to just pick one or make the negotiation mandatory. "Just pick one" woul= d > 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 i= t > more succinct. It should not be normative in any case; what matters is > that the client does something that satisfies the server's mandatory chec= ks. > * 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-bu= ndle-endpoint-id-acme-ide > [2] https://www.rfc-editor.org/rfc/rfc9171.html#name-endpoint-id > > On Thu, May 29, 2025 at 12:16=E2=80=AFAM David Dong = 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 Jun= e 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'l= l >> 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-leave@ietf.org > --000000000000de51e80636b4c783 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Richard,
I agree with the inconsisten= cies or confusions that you have commented on. I am preparing an updated dr= aft to address these comments without changing the required or observable b= ehavior. The validation method has a typo and its challenge hash algorithm = options are mandatory, the CDDL has limited expressiveness about allowed co= mbinations 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 proced= ure 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 Authorizati= on mechanism defined in Section 8.1 of RFC 8555 the "token" part = must contain only base64url characters which disallows an embedded dot &quo= t;." separator. There is no strict reason why this method needs to use= that exact Key Authorization definition but it feels like using an alterna= tive may be inviting its own confusion. Any thoughts about this?
=
Would a new draft revision be appropriate before the IESG te= lechat this week?
I will have a non-datatracker proposed update s= oon.

Brian S.

On Thu, M= ay 29, 2025 at 11:12=E2=80=AFAM Richard Barnes <rlb@ipv.sx> wrote:
Hi David and ACME folks,
This specification isn't quite sufficient, on either front= .

# Identifier type

The d= ocument does not actually specify what goes in the "value" field = of the identifier.=C2=A0 The reference listed in the IANA registration is t= o this document and the generic URL specification.=C2=A0 The latter is unhe= lpful and should be removed.=C2=A0 For the former, I assume the reference i= s to Section 2 [1], but that section doesn't say what goes in the "= ;value" field.=C2=A0 I would expect there to be some reference to the = Endpoint ID specification in RFC 9171 [2]. Basically what's missing her= e 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 RFC9= 171}}.
"""

As an aside, t= he text starting " Identifiers of type "bundleEID" in certificate requests SHA= LL appear in an extensionRequest attribute..." doesn't make= any sense here.=C2=A0 This isn't an ACME field.=C2=A0 If you mean that= the CSR submitted in order finalization should also contain an extensionRe= quest (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-s= pecified.=C2=A0 The bundle description in Section 3.3 says "...contain= ing two pairs" and then lists three mandatory pairs, and the CDDL in A= ppendix A has the hash algorithm negotiation as syntactically optional.=C2= =A0 The mechanism doesn't work without a defined hash algorithm, so eit= her you need to just pick one or make the negotiation mandatory.=C2=A0 &quo= t;Just pick one" would be my suggestion -- you already have validation= methods as a way to do negotiation, and hash algorithms don't change t= hat often.=C2=A0 You're reliant on SHA-256 anyway, by way of the keyAut= horization construction.

Comments:
* Nit= : "token-chal", "token-bundle", and "id-chal"= are inconsistent with the field camel case naming convention in ACME.=C2= =A0 "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".=C2= =A0 You could probably remove this list, or make it more succinct.=C2=A0 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.=C2=A0 Be= tter to separate them, e.g., with a "." character.
* Th= e "request object" and "response object" are incorrectl= y named -- they're backwards.
=C2=A0 =C2=A0 * The "reque= st object" is actually the challenge object, which is delivered in an = HTTP response
=C2=A0 =C2=A0 * The "response object" is = the object that is included in a POST request by the client in order to sel= ect the challenge

Cheers,
On Thu, = May 29, 2025 at 12:16=E2=80=AFAM David Dong <david.dong@iana.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Dear Richard Barnes (cc: acme WG),=

=C2=A0

Following up; as the designated expert for the ACME Ide= ntifier Types and ACME Validation Methods registries, can you review the pr= oposed registrations in draft-ietf-acme-dtnnodeid-17 for us? This is on the June 5th telechat agenda.<= /span>

=C2=A0

Please see:

=C2=A0

https://datatracker.ietf.org/doc/draft-i= etf-acme-dtnnodeid/

=C2=A0

The due date was May 12.

=C2=A0

If this is OK, when the IESG approves the document for = publication, we'll make the registrations at:

=C2=A0

https://www.iana.org/assignments/acme/

=C2=A0

With thanks,

=C2=A0

David Dong

IANA Services Sr. Specialist

_______________________________________________
Acme mailing list -- acm= e@ietf.org
To unsubscribe send an email to acme-leave@ietf.org
--000000000000de51e80636b4c783--