Is the primary reason for this so we don’t have to have the user specify multiple DNS records? If so I don’t think this added complexity makes sense here.
On Wed, May 14, 2025 at 12:32 Xiaohui Lam <[email protected]> wrote: > 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/CAOG%3DJU%2BxOsriCYiwuxS8bUjGO5cmP5rAb-Ljd46XYOArQOYQgQ%40mail.gmail.com.
