[Acme] 回复：Re: RFC 8555 Last Call Draft Change Request

[皮皮猪 <[e-mail]>]

Hi all,


I'd like to share an alternative concept for the account recovery problem being discussed on the list, and to provide context on how our upcoming OPAQUE extension fits into the broader ACME account security landscape.


Observation from IETF 126:
Account security is emerging as a recurring theme in ACME. The ongoing thread on account recovery ("I lost my account key, let me re-do DNS-01/HTTP-01 and kick all keys authorized for that domain") and the adoption of draft-ietf-acme-dns-persist-01 both highlight the need for stronger account-layer security. These recovery needs are more commonly addressed in IdP-centric scenarios.


Beyond the CAA + ACME Account Binding approach, we have been exploring a password-based mechanism using the OPAQUE (OPAQUE Account+ACME pk-01). The motivation is :


1. Key Vaulting and Cross-Device Synchronization
Since RFC 8555, account private key management has been entirely client-side. Users face a real pain point: each device must generate its own key pair and complete certificate issuance independently, and losing the account key means losing management access to all historical certificates.
We address this by leveraging OPAQUE's native export_key for end-to-end encryption of certificate private keys, then storing them in an ACME Key Vault endpoint:
export_key is derived locally on the client — the server never learns it.
On a new device, the user re-authenticates with OPAQUE, re-derives the same export_key, and recovers all stored keys.
The encryption key is cryptographically bound to the password and OPAQUE credentials — only the user who knows the correct password can decrypt the data.
This is the most significant value of this extension: upgrading the ACME account from a lightweight authentication handle to a "digital asset vault" — with encryption keys derived natively from OPAQUE, without introducing additional cryptographic primitives.


2. Account Recovery and Multi-Factor Authentication
RFC 8555 deliberately omitted account recovery. OPAQUE's registration-recovery two-phase model provides a cryptographically secure solution:
Combining OPAQUE password authentication with the standard ACME account key rollover procedure provides a two-factor recovery path.
OPAQUE account authentication is fully compatible with all existing ACME DCV challenge types and extensions. CAs can configure policies that require OPAQUE authentication as an additional factor for specific certificate types,  providing higher assurance.


The OPAQUE approach and the CAA scheme are complementary. OPAQUE provides an end-to-end cryptographic recovery path independent of DNS infrastructure, covering use cases that cannot be addressed by the CAA scheme.


Following the consensus at IETF 125 on draft-geng-acme-public-key, the authors have split that proposal into two distinct drafts. draft-geng-acme-public-key-07 has already been submitted. We are now authoring draft-geng-acme-opaque, which will cover OPAQUE-based account authentication, account recovery, and password-based issuance. We expect to submit it  and welcome further discussion once the draft is available.


Thanks,
Feng Geng


         原始邮件
         
       
发件人：Aaron Gable <aaron=[e-mail]&gt;
发件时间：2026年7月24日 00:15
收件人：Fabian V. Thobe <[e-mail]&gt;
抄送：Acme <[e-mail]&gt;, Mike Ounsworth <[e-mail]&gt;
主题：[Acme] Re: RFC 8555 Last Call Draft Change Request



Having spent more time thinking&nbsp;about this, and discussing it at IETF 126, I've come to the conclusion that I personally think that CAA (RFC 8659) with ACME Account Binding (RFC 8657) is the correct -- and already extant -- solution here.


If an attacker gains authorizations for your domain names, add CAA records binding those domain names to your specific account&nbsp;at the CA(s) of your choice. Then the attacker will no longer be able to use those authorizations to issue certificates.


This has one huge advantage over any possible ACME-based mechanism: it works no matter how many different ACME CAs exist. Any ACME-based in-band mechanism for revoking authorizations would require the rightful domain controller to attempt to revoke authorizations at every&nbsp;possible ACME CA the attacker could have possibly gotten authorizations from. Requiring the defender to reach out to every single ACME CA is untenable. Adding a single CAA record to their DNS is much simpler, and will affect all CAs equally.


It does have one disadvantage: Per current WebPKI requirements (set by the CA/BF), the CA can cache CAA lookup results for up to 8 hours. If the defender retakes control of their domain and adds new CAA records after just 2 hours, they may not become truly effective for another 6 hours. But at least there's still a strictly limited, human-scale period of time during which the defender has to keep an eye out for any new issuance by the attacker. Once those 8 hours have passed, the new CAA records will protect them. And they'll continue to protect them going forward.


Aaron

On Thu, Jul 16, 2026 at 6:47 AM Fabian V. Thobe <[e-mail]&gt; wrote:
Thank you for the beyond warm receival and the many responses on my initial email and questions.&nbsp;
Mike Ounsworth was kind enough to give me some feedback on this for me to participate&nbsp;in an RFC mailing group and&nbsp;
told me to keep it shorter and give it a try to find collaborators to work on a draft.&nbsp;


Proposal for Draft: Make ACME Zero Trust Ready
I think there is a gap in ACME&nbsp;where a domain owner should be able to contact a CA over ACME, perform a proof-of-ownership (DNS-01 or HTTP-01) and then kick any ACME&nbsp;authorisations currently authorized to issue for that domain.&nbsp;
Based on the replies there seems to be a consensus around this topic given the current lack of recovery procedures for a loss of an ACME account key.&nbsp;


Aaron Gable made following suggestion:&nbsp;
&gt; Add a new field to newAuthorization (and maybe newOrder) requests, call&nbsp;it `exclusive: true` for the sake of argument.
&gt; When an `exclusive` authorization moves into the `valid` state, all other `valid` authorizations for the same identifier&nbsp;held by different accounts are moved into the `revoked` state.


I think what Aaron Gable&nbsp;suggests would be a good way and has some benefits:&nbsp;

we wouldn't toy with accounts;&nbsp;

it would resolve the complex recovery processes needed if starting with an account recovery process
Considering also Corey's feedback I would like to offer to work on a Draft and I am looking for collaborators to realize following:&nbsp;

An exclusivity field to invalidate all previous authorizations&nbsp;in validity

An MTC compatible One Time Authorization Flag disallowing future order to be made with the same Authorization
Both requests target to create a situation ACME servers follow a 0 trust spirit of continued revalidation if requested by the Account holder.&nbsp;

Would somebody be willing to work with me on that?




On Wed, Jul 15, 2026 at 8:33 PM Aaron Gable <aaron=[e-mail]&gt; wrote:
Heh, I was planning to bring this up during AoB, so it's great to have it on the agenda.


I think that the simplest approach is something like this:
- Add a new field to newAuthorization (and maybe newOrder) requests, call it `exclusive: true` for the sake of argument.
- When an `exclusive` authorization moves into the `valid` state, all other `valid` authorizations for the same identifier&nbsp;held by different accounts are moved into the `revoked` state.


A slightly more complex version would be to add a new /revoke-authz directory entry, which creates a special kind of Authorization which behaves like I described above. This would have the benefit of being easy to advertise (an ACME server supports it if they list the new endpoint in their directory) and dedicated (no one could write an ACME client which simply marks all&nbsp;new order authorizations as exclusive). This would have the downside of being a bit more work for ACME clients to implement (a whole new endpoint and equivalent of a CLI subcommand as opposed to just a single new boolean).


Note that most CAs simply do not have ways for one Subscriber to prevent a different Subscriber from issuing for the same identifier. This isn't a deficiency in ACME compared to the status quo, but it definitely is a place where ACME can lead the way.


Aaron
 _______________________________________________
 Acme mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 




--

Fabian V. Thobe

[phone] /&nbsp;[e-mail]

Via Filippo Corridoni 68, 56125 Pisa