Subject: [Acme] Re: DNS-ACCOUNT Challenge Update
From: Q Misell <[email-masked]>
To: "Greg T. Wallace" <greg=[email-masked]>
Cc: [email-masked]
Date: Thu, 16 Jan 2025 10:53:39 +0100
List-Id: Automated Certificate Management Environment <acme.ietf.org>

> Instead of just using `base32(SHA-256(<ACCOUNT_URL>)[0:10])`, the ACME
client would specify a `client_id` as a response field in the POST response
to the challenge URL.

There is precedent for this. The (soon to be RFC) draft-ietf-acme-onion
section 3.2 defines responding with additional fields in the challenge.
------------------------------

Any statements contained in this email are personal to the author and are
not necessarily the statements of the company unless specifically stated.
AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace,
Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company
registered in Wales under № 12417574
<https://find-and-update.company-information.service.gov.uk/company/12417574>,
LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876
<https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU
VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №:
522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru
maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca
Digital, is a company registered in Estonia under № 16755226. Estonian VAT
№: EE102625532. Glauca Digital and the Glauca logo are registered
trademarks in the UK, under № UK00003718474 and № UK00003718468,
respectively.

Ar Iau, 16 Ion 2025 am 07:09 Greg T. Wallace <greg=
[email-masked]> ysgrifennodd:

> This could actually be addressed by using something mentioned in RFC 8555 that hasn't been used before. Section 7.5.1 provides in part "The server updates the authorization document by updating its representation of the challenge with the response object provided by the client.  The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. Note that the challenges in this document do not define any response fields, but future specifications might define them.  The server provides a 200 (OK) response with the updated challenge object as its body."
>
> Instead of just using `base32(SHA-256(<ACCOUNT_URL>)[0:10])`, the ACME client would specify a `client_id` as a response field in the POST response to the challenge URL.
>
> e.g.,
>
> POST /acme/chall/prV_B7yEyA4 HTTP/1.1
>    Host: example.com
>    Content-Type: application/jose+json
>
>    {
>      "protected": base64url({
>        "alg": "ES256",
>        "kid": "https://example.com/acme/acct/evOfKhNU60wg",
>        "nonce": "Q_s3MWoqT05TrdkM2MTDcw",
>        "url": "https://example.com/acme/chall/prV_B7yEyA4"
>      }),
>      "payload": base64url({"client_id": "abcde12345"}),
>      "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
>    }
>
> Would result in the ACME Server checking for the DNS name: `_abcde12345._acme-challenge.example.org`
>
> Resource owners (e.g. a business) can agree to a specific client_id with their cloud provider(s) to coordinate things like CNAME delegation. This spec probably should specify the criteria for valid client_id, though it could be as open ended as `_` + as many valid dns characters as someone wants, so long as the subdomain length requirement is met. Maybe something like `_` + 16 to 128 base32 characters (no padding character).
>
> This also makes a little more logical sense because an ACME Client may manage many ACME Accounts (and would redundantly need multiple CNAMEs for one client), or one ACME Account may be present on multiple ACME Clients (and therefore dns name conflicts would still occur since the SHA256 would be the same). Using an ID specific to the client allows one CNAME per client and allows each client to manage its challenges internally to avoid dns name conflicts.
>
> If you go this route, `dns-02` may be a more appropriate challenge type. This would be the same as `dns-01` with added `client_id` field to the challenge and to the dns name.
>
> Because of this, to go even a step further, if the ACME Client does not POST a `client_id` (i.e., it POSTs the empty object `{}`), the current `dns-01` URL would be expected instead (e.g., `_acme-challenge.www.example.org.`). If you take this step, this RFC could actually modify the definition of `dns-01` with full backward compatibility. This prevents the challenge array from growing in size to accommodate a new challenge type, doesn't break existing dns-01 implementations (client or server - a client sending the field to an unsupported server would just have the field ignored and the client would note the field absence in the response from the server; a server not receiving the field would use the current dns-01 behavior as the non-supporting client would already expect), and adds this new functionality. This would also be preferred to adding as dns-02 and eventually retiring dns-01 as acme servers and clients would have to proactively update to the new dns-02 challenge name.
>
>
> As a final note, I know scope was removed from this draft. However, looking forward, `scope` could be added to the response object as well. Again, as a non-breaking change with full backwards compat to existing dns-01.
>
>
>
> On Sun, Dec 1, 2024 at 2:28 PM Jesper Kristensen <[email-masked]> <&lt;[email-masked]&gt;>
> wrote:
>
> > Hi
> >
> > This document provides some nice added flexibility, but I am puzzled why
> > it does not go one step further. While this document allows multiple ACME
> > clients to run independently, it assumes that they are all controlled by
> > the same entity who also sets up the DNS CNAME records. This might work
> > great in a setup with multiple datacenters each needing to run their own
> > ACME client independently, or even multiple clouds assuming the cloud
> > customer is the one running these ACME clients. But I don't think it allows
> > for using multiple clouds when the cloud providers are the ones running the
> > ACME clients, for example for cloud services where the cloud provider
> > terminates the TLS connection for the customer. If a cloud provider were to
> > offer the dns-account-01 challenge to their customers without the same
> > cloud provider also controlling the customer's DNS, the cloud provider
> > would have to ask all their customers to create new CNAME records every
> > time they change what ACME account they use, e.g. when they add support for
> > a new CA. I don't think many cloud providers would accept such a limitation
> > for managing their ACME clients. This additional use case could be
> > supported by letting the client choose the domain label within certain
> > limits, instead of basing it on the ACME account URL. The document says
> > that the binding to account URI is not for integrity so the truncation to
> > 10 bytes is not a problem. But if integrity is not achieved anyway, why
> > then limit it to be coupled with the account URL, and therefore rule out
> > the use case where the entity controlling the DNS and setting up CNAME
> > records is different from the entity running the ACME client and managing
> > certificates? You would need to specify what a valid construction of the
> > domain label would be, and the CA would need to validate that when they
> > validate a challenge if they are no longer fully in control of the label,
> > but that seems to me to be a small price to pay to unlock this additional
> > use case.
> >
> > Den man. 18. nov. 2024 kl. 17.50 skrev Amir Omidi <amir=
> > [email-masked]> <[email-masked]&gt;>:
> >
> >> Hi everyone,
> >>
> >> Based on the feedback received, we've published a new version of the
> >> DNS-ACCOUNT-01 draft (
> >> https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/)
> >> This version has been simplified by removing DNS-02 and the scoping
> >> mechanism, focusing purely on enabling multiple concurrent ACME clients to
> >> authorize the same domain.
> >>
> >> Key changes:
> >>
> >>    - Removed DNS-02 challenge type completely
> >>    - Removed the scoping mechanism (host/wildcard/domain)
> >>    - Simplified DNS record format
> >>    - More focused introduction on the core problem of enabling multiple
> >>    concurrent ACME clients
> >>    - Better explanation of use cases like multi-region deployments
> >>
> >>
> >> We welcome your feedback on these changes.
> >>
> >> Best regards,
> >> Amir Omidi
> >> _______________________________________________
> >> Acme mailing list -- [email-masked]
> >> To unsubscribe send an email to [email-masked]
> >>
> >
>
> _______________________________________________
> Acme mailing list -- [email-masked]
> To unsubscribe send an email to [email-masked]
>