Hi Amir, and Ryan
I agree with your comments.
Yes ACME account key needs full lifecycle management(including replace
mechanism).
Maybe my demand can be satisfied by a new challenge type, rather than the
digest form generated based on accountkey.
e.g: design a new challenge type`dns-delegation-01`
And Domain name's challenges API:
POST /acme/authz/PAniVnsZcis HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/evOfKhNU60wg";,
"nonce": "uQpSjlRb4vQVCjVYAyyUWg",
"url": "https://example.com/acme/authz/PAniVnsZcis";
}),
"payload": "",
"signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
}
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://example.com/acme/directory>;rel="index"
{
"status": "pending",
"expires": "2016-01-02T14:09:30Z",
"identifier": {
"type": "dns",
"value": "www.example.org"
},
"challenges": [
{
"type": "http-01",
"url": "https://example.com/acme/chall/prV_B7yEyA4";,
"token": "DGyRejmCefe7v4NfDGDKfA"
},
{
"type": "dns-01",
"url": "https://example.com/acme/chall/Rg5dV14Gh1Q";,
"token": "DGyRejmCefe7v4NfDGDKfA"
},
{
"type": "dns-delegation-01",
"url": "https://example.com/acme/chall/D2zX3m9jfIyE4";,
"token": "DGyRejmCefe7v4NfDGDKfA"
}
]
}
And requires user to create DNS TXT
_acme-challenge_cloudflare.www.example.org 300 TXT keyAuthorization=token
|| '.' || base64url(Thumbprint(accountKey))
And perform challenge(delegation can only be alphanumeric, no special
characters allowed):
POST /acme/chall/D2zX3m9jfIyE4 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/D2zX3m9jfIyE4"; }), "payload": base64url({
"delegation": "cloudflare"
}), "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" }
How about new challenge type like this? But we need a draft a new RFC if it
makes sense.
Thanks
在2025年5月15日星期四 UTC+8 00:13:35<Ryan Hurst> 写道：
> Remember that an ACME account key is just another cryptographic key that
> requires full lifecycle management. This involves keeping it secure,
> rotating it regularly to limit the window an attacker has if it is ever
> compromised, and eventually replacing it with a key using stronger or newer
> algorithms (for example, moving to ML-DSA for post-quantum security). In
> practice, ACME account keys are no more secure than the keys used for TLS
> certificates, since most implementations store them on disk protected only
> by basic filesystem ACLs.
>
> On the positive side, because account keys see fewer operations, they can
> be generated and stored in hardware such as a TPM, which offers stronger
> protection without impacting TLS performance or algorithm choices. This is
> why it makes sense to decouple the domain-control label from the account
> key itself, but the specification must still acknowledge that these keys
> require proper management. Failing to do so would lead to fragile
> implementations and discourage sound key-management practices.
>
> Ryan
>
> On Wed, May 14, 2025 at 9:10 AM Xiaohui Lam <[email protected]> wrote:
>
>> Hi Amir,
>>
>> Thank you for post expanding contents.
>>
>> > I don't doubt this, but most of what we do in this space is planning
>> for worst case scenarios. As ACME is meant to facilitate short-lived
>> credentials, I don't think it would be responsible to build features that
>> rely on long (forever?) lived keys.
>>
>> How do we solve this problem?
>> - Let's encrypt returns account URI:
>> https://acct.acme-v02.letsencrypt.org/acct/tjvsrsls89gu9ssu (Just an
>> example and does not represent the actual content.)
>> - base32(SHA-256(
>> https://acct.acme-v02.letsencrypt.org/acct/tjvsrsls89gu9ssu)[0:9])
>> - GTS returns a different account URI:
>> https://acme-02.pki.google/account/ilctdkn9ifnueocs (Just an example and
>> does not represent the actual content.)
>> - base32(SHA-256(https://acme-02.pki.google/account/ilctdkn9ifnueocs
>> )[0:9])
>>
>> This situation (scenario of Cloudflare's multiple backup certificate) CA
>> requires two different dnshostname, and Cloudflare customers need to create
>> DNS record twice.
>>
>> Is there other way to reduce configuration overhead for users?
>>
>> Thank you.
>> 在2025年5月15日星期四 UTC+8 00:01:57<Amir Omidi> 写道：
>>
>>> > Based on my experience, instances of ACME account key compromise are
>>> extremely rare. I also have full confidence in Cloudflare’s robust security
>>> operations capability - such account key compromises are highly unlikely to
>>> occur internally at Cloudflare.
>>>
>>> I don't doubt this, but most of what we do in this space is planning for
>>> worst case scenarios. As ACME is meant to facilitate short-lived
>>> credentials, I don't think it would be responsible to build features that
>>> rely on long (forever?) lived keys.
>>>
>>> Furthermore, the issue isn't only key compromise. There are many
>>> circumstances why this key might change. For example:
>>>
>>> 1. Regulatory requirements on not having long-lived keys.
>>> 2. There being a runtime problem during generation of this ACME account
>>> key that is discovered in the future.
>>> 3. Moving away from ECC/RSA keys in the future.
>>>
>>> I feel very strongly that we should not be building a feature that takes
>>> a strong dependency on the life of a key, where it doesn't really need to.
>>>
>>> Thanks!
>>>
>>> On Wed, May 14, 2025 at 11:57 AM Xiaohui Lam <[email protected]> wrote:
>>>
>>>> Hi Amir,
>>>>
>>>> Thank you for your response, specially posted here, your concern when
>>>> drafting the RFC.
>>>>
>>>> Based on my experience, instances of ACME account key compromise are
>>>> extremely rare. I also have full confidence in Cloudflare’s robust
>>>> security
>>>> operations capability - such account key compromises are highly unlikely
>>>> to
>>>> occur internally at Cloudflare.
>>>>
>>>> My suggestion is to draft the document to retain both the current
>>>> account URI-generated suffix and add an account key-generated suffix. This
>>>> would allow delegate operators (such as Cloudflare) to implement the
>>>> optimal approach for their customers.
>>>>
>>>> Thank you.
>>>>
>>>> 在2025年5月14日星期三 UTC+8 23:17:12<Amir Omidi> 写道：
>>>>
>>>>> Hi!
>>>>>
>>>>> However, wouldn’t it be more logical to generate this host from the
>>>>> account public key instead?
>>>>>
>>>>>
>>>>> If we think about the entire lifecycle of the ACME account, using the
>>>>> public key makes less sense. The workflow that I’ve imagined for this is
>>>>> as
>>>>> follows:
>>>>>
>>>>> 1. Large provider creates ACME accounts on ACME enabled CAs.
>>>>> 2. Large provider ensures that the CA’s have rate limits in place to
>>>>> allow them to do large number of issuances.
>>>>> 3. Large provider communicates these stable strings to the customer to
>>>>> set as CNAME records for DCV delegation.
>>>>>
>>>>> Now, if we use the public key, these are no longer stable URLs. We
>>>>> effectively have a long lived key, where replacing that key ends up
>>>>> requiring every single customer to change their CNAME records.
>>>>>
>>>>> With the design that is currently in place, we can use
>>>>> https://datatracker.ietf.org/doc/html/rfc8555#section-7.3.5 to
>>>>> rollover the account keys, without causing disruptions to the end users.
>>>>>
>>>>> Hope this answers the inquiry!
>>>>>
>>>>> On May 14, 2025, at 10:42 AM, Xiaohui Lam <[email protected]> wrote:
>>>>>
>>>>> It should be following:
>>>>>
>>>>> - _acme-challenge_cd9dtbvvknxwz1mg.example.org 300 IN CNAME "
>>>>> example.org.googletrustservice.acme-delegate.cloudflare.com", for
>>>>> Google Trust Service
>>>>> - _acme-challenge_on0ikkqoklpbadex.example.org 300 IN CNAME "
>>>>> example.org.letsencrypt.acme-delegate.cloudflare.com", for Let's
>>>>> Encrypt
>>>>>
>>>>> Sorry for my typo
>>>>> 在2025年5月14日星期三 UTC+8 22:39:59<Xiaohui Lam> 写道：
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I came across Cloudflare’s blog (
>>>>>> https://blog.cloudflare.com/zh-cn/introducing-dcv-delegation), which
>>>>>> mentions an RFC draft Automated Certificate Management Environment
>>>>>> (ACME)
>>>>>> DNS Labeled With ACME Account ID Challenge. This draft proposes a new
>>>>>> domain control verification (DCV) method using following DNS record:
>>>>>> _acme-challenge_ujmmovf2vn55tgye.www.example.org 300 IN TXT
>>>>>> "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI"
>>>>>>
>>>>>> Key concern of mine revolves around how the validation domain name is
>>>>>> constructed by prepending the label:
>>>>>> "_acme-challenge" || base32(SHA-256(Account Resource URL)[0:9])
>>>>>> The verification DNS host _acme-challenge_[suffix]'s suffix is
>>>>>> generated from the ACME account URI (account resource URL). However,
>>>>>> wouldn’t it be more logical to generate this host from the account
>>>>>> public
>>>>>> key instead?
>>>>>>
>>>>>> Let’s contextualize this with Cloudflare’s use case: they aim to
>>>>>> allow users to delegate _acme-challenge_[suffix] via CNAME records. If
>>>>>> we
>>>>>> use the account URI to generate the DNS host suffix, and Cloudflare
>>>>>> users
>>>>>> need to enroll certificates from two CAs - such as
>>>>>>
>>>>>> - Let’s Encrypt, and
>>>>>> - Google Trust Service
>>>>>>
>>>>>> Cloudflare will give two CNAME records, e. g:
>>>>>>
>>>>>> - _acme-challenge_cd9dtbvvknxwz1mg.example.org 300 IN CNAME "
>>>>>> example.org.googletrustservice.acme-delegate.cloudflare.com", for
>>>>>> Let's Encrypt
>>>>>> - _acme-challenge_on0ikkqoklpbadex.example.org 300 IN CNAME "
>>>>>> example.org.letsencrypt.acme-delegate.cloudflare.com", for Google
>>>>>> Trust Service
>>>>>>
>>>>>> They would have to create two separate CNAME records (due to
>>>>>> different DNS hosts and values for every CA).
>>>>>>
>>>>>> In contrast, if the DNS host suffix is generated from the account
>>>>>> public key, Cloudflare users would only need to create one CNAME record
>>>>>> for
>>>>>> delegation. This streamlines the process, enhanced security(publickey is
>>>>>> far secure than an url string) and reduces configuration overhead for
>>>>>> users.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "[email protected]" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to [email protected].
>>>>> To view this discussion visit
>>>>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c8a84911-53fa-418f-b742-9109157c1997n%40mozilla.org
>>>>>
>>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c8a84911-53fa-418f-b742-9109157c1997n%40mozilla.org?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>>
>>>>> --
>> You received this message because you are subscribed to the Google Groups
>> "[email protected]" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>>
> To view this discussion visit
>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/7ea62291-2e4c-4500-a4b2-d0d7ed7a43d7n%40mozilla.org
>>
>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/7ea62291-2e4c-4500-a4b2-d0d7ed7a43d7n%40mozilla.org?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/f1d5fabe-c15f-4e4c-abd7-b235d3bf6dbdn%40mozilla.org.
