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
<jesperm...@gmail.com> <<jesperm...@gmail.com>>
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=
> 40aaomidi....@dmarc.ietf.org> <40aaomidi....@dmarc.ietf.org>>:
>
>> 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 -- 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
