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

[Mike Ounsworth <[e-mail]>]

I have added this item to the agenda for next week under

## New Business
...
* New mechanism for “I lost my account key, let me re-do DNS-01 / HTTP-01
and then kick all keys currently authorized against that domain” (see
discussion on-list titled “RFC 8555 Last Call Draft Change Request”)

That said, by all means please continue discussing on-list.

On Tue, 14 Jul 2026 at 21:35, Michael Paoli <michael.paoli=
[e-mail]> wrote:

> I think Fabian ("Fabian V. Thobe" <[e-mail]>) raises excellent
> point(s).
>
> I think I'll mostly limit myself to matters on / raised by, or (quite)
> close to:
> RFC 8555 Section 7.5.2 Deactivating an Authorization
> https://www.rfc-editor.org/rfc/rfc8555.html#section-7.5.2
>
> And please pardon my at least partial ignorance on these matters, I
> certainly won't know all the relevant technical details, but hopefully
> at least "enough" of what may generally be relevant.
> I arrived here via a relatively indirect means, notably via
> a bug in certbot:
> https://github.com/certbot/certbot/issues/10494
> which in many cases didn't handle
> RFC 8555 Section 7.5.2 Deactivating an Authorization
> properly, at least relative to certbot's documentation (but in
> some other (special) cases it did work as documented).
> There was also a longer discussion that lead up to isolating that bug in
> certbot, see, e.g.:
>
> https://community.letsencrypt.org/t/certbot-deactivate-authorization-s-rfc8555-section-7-5-2/243041/22
> etc.
>
> To Fabian's point(s), and related, regarding:
> RFC 8555 Section 7.5.2 Deactivating an Authorization
> I think that, at least in theory, the DNS domain owner ought have means
> to deactivate an authorization, even if they don't or no longer have
> access to the currently required key.  Now, as to whether or not that
> would be highly feasible, and/or other mitigating controls and
> (possible) adjustments ought be made to RFC 8555, or if it would be most
> practical or needed to have changes and/or additions to other RFC(s),
> and/or other standards, and perhaps even warranting or necessitating
> some coordination, is also another question/matter to be considered.
>
> In any case, I can think of many scenarios where at least some changes
> ought be made to the existing.  E.g., let's say, at least
> hypothetically:
>
> For a given domain, let's say we have owners of the
> domain, in chronological sequence: OLDOLD, OLD, NEW.  We can even
> further say, OLDOLD and NEW happen to be same legitimate owner.  But
> between, OLD somehow managed to hijack the domain from registrar, and to
> Certificate Authorities (CAs), RFCs, etc. OLD appeared legitimate, but
> legally etc. OLD was not.  Let's further say, while OLD had control,
> there were hundreds of generally widely trusted CAs, and half or more
> well supported ACME and RFC8555, and during that time, OLD created new
> accounts on Let's Encrypt (LE) and other ACME supporting CAs, and
> obtained hundreds to thousands or more trusted CA issued certs for
> domain, sub-domains thereof, and including wildcards, etc., and used ACME
> for all of those, and DNS validation at that time, so now those
> authorizations have been cached by these various CAs for up to 30 days
> (I believe that's the max in RFC8555).  Anyway, subsequently, NEW
> regains control, but now they've quite the mess to deal with.  Not only
> many certs they want to have revoked but also issues with
> RFC 8555 Section 7.5.2 Deactivating an Authorization
> as with those cached, OLD could still continue to obtain trusted CA
> certs via ACME - and of course NEW wants to prevent all such attempts.
>
> Slightly different but similar scenario to the above.  The ownership of
> the domain never changed.  But some bad actor person(s), e.g. employed
> by domain owner, exceeded their authority, and likewise requested and
> obtained many trusted CA certs from many CAs via ACME.  The domain owner
> subsequently terminated those bad actors from their employ, but
> meantime, those bad actors ran off to countries lacking extradition
> treaties, sold keys via the Dark Web, and now very bad actors can
> continue to get trusted CA certs from ACME CAs for up to 30 days.
>
> So, I think probably two cases/areas need to be addressed to
> fix/mitigate those types of risks, or any where legitimate owner needs
> revoke authorization without having access to key.
>
> First case, where owner has all the relevant information, notably what
> authorization(s) are cached out there with what CA(s), having control of
> domain and being able to effectively prove that (though means matching
> or quite similar to ACME), they should have means to deactivate such
> authorizations.  And it should be doable in quite timely manner, e.g.
> API, and I'm thinking hopefully/probably as minor extension to existing
> ACME / RFC8555 ?  Or maybe that need/ought go in a separate RFC (e.g.
> depending how extensive needed changes may be, etc.).
>
> Second case, and more generally.  E.g., depending what bad actor(s) /
> OLD may have done, with domain, how many sub-domains, and including with
> wildcards, and across how many trusted CAs, it may not be feasible for
> legitimate owner to determine the full extent of the issue and be able
> to track down and revoke all those cached authorizations.  I was
> thinking CA transparency logs might be used to track those down - but
> not necessarily.  E.g. if bad actors go through part of ACME, and get
> authorizations, and those were cached, but don't proceed through to cert
> issuance, there may be nothing in the transparency logs to indicate such
> had happened (not sure I've got that fully right, but I'm guestimating
> there aren't CA required public logs of all the granted authorizations
> and their expirations?  And presuming that's not there, probably
> wouldn't want to burden all ACME CAs with adding such).
> So, perhaps to best address, not a 100% fix (revocation), but rather
> mitigating control, and much simpler and more feasible.
> At present, the caching is up to 30 days.  What if that max was reduced
> to something in the range of 7 days to an hour?  I'm thinking any
> shorter would probably be too short, as there are good legitimate
> reasons for caching - e.g. for those that have to do (semi-)manual
> operations to get the authorizations, don't want to have to unduly
> burden them with having to repeat that too frequently.  And I'm thinking
> for potential high/low ends to potentially consider for the max,
> on the shorter side, I was thinking DNS TLD NS delegating authority
> TTLs, e.g. shortest I'm aware of that's much used is org. of 3600 (and
> longest, e.g. com. (and others) of 2 days).  And on the high end,
> perhaps as long as LE's present shorter-term issued certs and ACME
> authorization cache duration, which I believe is 7 days.  Though I think
> I'd probably advocate for something in the range between one hour and
> two days.  I think 7 days is probably rather excessive for good
> mitigation, and I don't know that there are really that many use cases
> with good strong justification for having authorizations cached beyond
> 2 days (let alone beyond 7 days).
> There would also be matter of (effective) enforcement, notably changing
> from the existing.  Updating RFC8555 itself I don't think would fully
> cover it - probably some coordination needed on the standards for what
> allows CAs to become and remain trusted CAs.  So, perhaps RFC8555 would
> be changed from MUST ... 30 days (or however it's worded on the
> duration presently), to a new max - call it T (somewhere between, e.g.
> one hour and two days), and changing RFC8555 to
> MUST not exceed 30 days, SHOULD not exceed T, and as of
> YYYY-MM-DDT00:00Z and thereafter MUST not exceed T.  And then the
> particular YYYY-MM-DDT00:00Z could be coordinated with the trusted CA
> standards requirements.  And future revisions of RFC8555 after
> YYYY-MM-DDT00:00Z could simplify that by just dropping the 30 day bit,
> change the SHOULD to MUST, and drop the YYYY-MM-DDT00:00Z bit.
> And ... not quite mitigating controls:
> These mostly suffer the close the barn door after the horse has gotten
> out problem, or in other words, aren't useful retroactively.
> E.g. if means were added to do request with a shorter caching max,
> that doesn't help on deactivating earlier requests that had long (up to
> 30 days) cached authorizations that are still active.  One may need to
> revoke much sooner, or at least have mitigating controls expire such
> caches much sooner than 30 days.
> Likewise CAA DNS records, those aren't useful to retroactively address
> the issue, and even if the RFC(s) were changed to have CAA record
> (optionally?) apply retroactively, that still has little granularity.
> E.g. domain owner might have hundreds of thousands or more certs under
> their domain that are legit, but bad actors may have gotten
> authorizations cached for key(s) they control for (hundreds of)
> thousands or more for domain, and sub-domains thereof (including
> wildcards), and legitimate owner may need means to deactivate those
> cached activations from bad actors, or at least short of that -
> mitigating control, have them expire in relatively short period of time,
> while not disturbing those that are legitimate.
> And both those fully legitimate, and those cached by bad actor activity,
> could all be under same CA, so again, CAA DNS record wouldn't have the
> granularity to deal with that on separating them out, and I don't think
> major extensions to definition of CAA DNS record and/or adding other DNS
> record types to deal with the situation would likely be the best way(s)
> to go for mitigating controls.
>
> So, I'm curious, what, if any, very much really needed cases exist for
> the existing caching going beyond 2 days, or even 7 days?  If there's
> (next to) nothing there, perhaps simplest major step would be
> mitigating control on dropping that max down to something between an
> hour and 2 days.
>
> But as for how to feasibly allow any legit domain owner to revoke from
> cache, without key, and perhaps without even having advanced knowledge
> of all the cached authorizations across all the trusted CAs (e.g. many
> created by bad actors), I don't know that there's any relatively clean
> simple enough feasible way to handle those more general cases.  But lots
> more brains on this list, etc., than mine alone, so maybe some have
> great ideas how that could be highly feasibly achieved.
>
> But in any case, I think at least mitigating control, working on
> dropping the max. caching time is likely simplest and most feasible,
> and though it wouldn't 100% cover the issue, it may be "good enough" to
> cover, or at least well help, for most cases (e.g. turn an up to 30 day
> problem into a less than 2 day problem).
>
> references/excerpts:
>
> > From: "Fabian V. Thobe" <[e-mail]>
> > Date: Tue, 14 Jul 2026 10:25:45 +0200
> > Message-ID: <
> [e-mail]>
> > To: [e-mail]
> > CC: [e-mail], [e-mail]
> > Subject: [Acme] RFC 8555 Last Call Draft Change Request
> > Archived-At: <
> https://mailarchive.ietf.org/arch/msg/acme/tpvOoBqHcEhSoPP-C0UaBtERgeY>
> >
> > Dear RFC8555 Committee,
> >
> > In cc: Alexis Hancock from EFF as some content involves also Certbot
> >
> > *TL;DR *
> > A mechanism for authorization invalidation independent of the account key
> > appears necessary to ensure that domain ownership, and not a historical
> > authorization state, remains the ultimate source of trust.
> >
> > *Background*
> > While working on improvements to the DNS Route53 plugin for Certbot
> (Certbot
> > PR #10729 <https://github.com/certbot/certbot/pull/10729>) to better
> meet
> > the security requirements of a European government entity, we identified
> a
> > potentially critical issue related to cached DNS-01 authorizations.
> > Specifically,
> > we observed during the PR related manual testing that certificate
> issuance
> > remained possible even after the certbot DNS credentials had been revoked
> > upon credential change. While we initially suspected a regression related
> > to previously used AWS credentials, further investigation revealed that
> the
> > root cause lies in RFC8555 mandated procedures handling of DNS
> > authorizations.
> >
> > *Relevant Sections of RFC 8555*
> >
> > *7.5.2. Deactivating an Authorization*
> > The server must verify that deactivation requests are signed by the
> account
> > key corresponding to the authorization.
> >
> > *7.3.6. Account Deactivation*
> > Similarly, account deactivation requires a valid signature from the
> account
> > key.
> >
> > *In both cases, the ability to revoke or deactivate authorizations is
> > strictly tied to possession of the account key.*
> >
> > *Threat Analysis*
> >
> > *High-Level Concern*
> >
> > The current model creates a situation in which DNS-01 authorizations may
> > remain valid even when DNS credentials are revoked and the account key is
> > no longer accessible for a lack of re-authorization. If a legitimate
> owner
> > loses control of the account key, whether through compromise or
> operational
> > loss, there is no reliable mechanism to invalidate existing
> authorizations.
> >
> > This creates a scenario where a malicious actor in possession of the
> > account key can continue issuing certificates without the knowledge or
> > consent of the legitimate domain owner.
> > Hereby the fact that Let's Encrypt clearly democratized encryption with
> > valid certificates is of high importance: systems in subpar environments
> or
> > environments subject to financial constraints regarding the procurement
> are
> > much more vulnerable than large enterprises or organizations. Especially
> in
> > the highly open source dependent political NGO sector I see significant
> > risks as the infrastructure owner might be a malicious actor allowing
> > various "men in the middle" scenarios.
> >
> > A mechanism for authorization invalidation independent of the account key
> > appears necessary *to ensure that domain ownership, and not historical
> > authorization state, remains the ultimate source of trust*.
> >
> > *Observed Risk Scenarios*
> >
> > Several already observed risk scenarios emerged:
> >
> >    - Lack of recoverable or uncompromised physical infrastructure after
> >    ransomware incidents makes the account keys irrecoverable;
> >    - Preference for full system rebuilds over restoration due to
> >    uncertainty about compromise timelines;
> >    - Missing or incomplete secret management practices;
> >    - Operational pressure leading to deviations from established recovery
> >    procedures
> >
> > In these scenarios, loss of the ACME account key is a realistic and,
> maybe
> > even already a  recurring outcome.
> >
> > *Expanded Risk Considerations*
> >
> > Additional risks arise in environments where DNS infrastructure itself
> may
> > be compromised or controlled by malicious actors, including:
> >
> >    - Man-in-the-middle attacks via compromised DNS resolution chains
> >    - Centralized or state-controlled infrastructure introducing systemic
> >    risks
> >    - Limited infrastructure diversity in certain regions
> >
> > In such cases, cached authorizations amplify the attack surface by
> allowing
> > continued certificate issuance independent of current DNS control.
> >
> > *Proposed Mitigations*
> >
> >    1. *Lightweight Option: No-Cache Mechanism for DNS-01*
> >    Introduce a mechanism to explicitly disable authorization caching for
> >    DNS-01 challenges.
> >    (Reference: https://github.com/letsencrypt/boulder/issues/8870)
> >    2.
> >
> >    *Break-Glass Recovery via Proof of Ownership*
> >    Introduce a recovery mechanism allowing domain owners to invalidate
> all
> >    existing authorizations (not the account) through a fresh
> >    proof-of-ownership challenge (e.g., DNS-based).
> >
> >    This would:
> >    - Provide a recovery path in case of account key loss
> >       - Prioritize domain ownership verification over authorization
> >       persistence
> >       - Align with the core purpose of certificates: authentication, not
> >       just encryption
> >
> > *Additional notes regarding awareness*
> >
> > In discussions with peers across banking, healthcare, public sector, and
> > commercial environments (many operating under ISO 27001 or similar
> > frameworks), a lack of awareness regarding cached issues become apparent
> > (despite all of us using Let's Encrypt in private or professional
> > settings). Notably, none of the professionals consulted were aware that
> > DNS-01 authorizations are cached in a way that allows continued
> certificate
> > issuance after DNS credentials are revoked. There is also no clear
> > indication of this behavior in common tooling.
> >
> > As a result all of us assumed that:
> >
> >    - Revoking DNS credentials is widely assumed to fully mitigate risk
> >    - No standard procedures were required for responding to account key
> loss
> >
> > Given that the tooling does not surface or warn about cached
> > authorizations, there might also be a problem regarding the value of
> > account keys. To be honest among 9 people, two of us even had a false
> risk
> > assessment in the ISO 27001 assessments, in one case fully audited by a
> > market leading entity. There might be a disconnect between what's
> > documented at Let's Encrypt and what effectively reaches the community as
> > literally there's no section neither about risks nor backup in the
> Certbot
> > documentation, the discovery of the non-ephemeral nature of
> authorizations
> > requires research, this is also reflected in the answers of AI agents
> (see
> > below), all major AIs apart from Claude responded wrongly. An issue and
> > offering to fix at least some oddities of certbot behaviour was not
> > favourably received (https://github.com/certbot/certbot/issues/10731)
> >
> > As outlined above, the current ACME model prioritizes usability and
> > automation but does not fully address scenarios involving loss of account
> > keys. Given the widespread adoption of ACME and the increasing reliance
> on
> > short-lived certificates, this gap presents a meaningful security risk
> > undermining the efforts to shorten certificate lifetime for security as
> any
> > effort is undermined by the malicious can simply order a new certificate
> > with obtained account keys.
> >
> > I would be happy to provide a more detailed proposal, including draft
> > specification language and an expanded threat analysis, if that would be
> > helpful.
> > Attachments
> >
> > *Boulder Issue:*
> > Feature Request: Add an opt-in mechanism to disable DNS-01 authorization
> > reuse (--no-cache) for one Time DNS-01 Challenge Usage
> >  #8870
> > https://github.com/letsencrypt/boulder/issues/8870
> >
> > *Certbot PR *
> > dns-route53: cerbot credentials.ini file support + fix duplicate TXT
> record
> > on apex/wildcard
> > #10729
> > https://github.com/certbot/certbot/pull/10729
> >
> > *Certbot Issue *[Bug]: Invalid / Revoked credentials allow renewal due to
> > lack of revalidation of credentials and continued use of DNS-01 Auth
> >  #10731
> > https://github.com/certbot/certbot/issues/10731
> >
> > *Example Observation*
> >
> > A Certbot renewal executed with invalid DNS credentials still succeeded,
> > without indicating that cached authorizations were used:
> >
> > (venv) zeus@mi-certbot-staging:~/certbot$ sudo venv/bin/certbot
> certonly \
> > --dns-cloudflare -d "*.domain.com" --dns-cloudflare-credentials \
> > ~/cfinvalid --staging
> > [...]
> > Renewing an existing certificate for *.domain.com
> > Successfully received certificate.
> > Certificate is saved at: /etc/letsencrypt/live/domain.com/fullchain.pem
> >
> > *Generative AI answers to the question:are dns challenges on certbot
> remade
> > on every renewal?*
> >
> >    1. *Gemini*
> >    Unconditional Yes
> >    Yes, DNS challenges are remade on every single renewal. Every time
> >    Certbot attempts to renew a certificate, it initiates a fresh "order"
> with
> >    the Certificate Authority (such as Let's Encrypt). This order
> generates a
> >    brand-new, completely randomized token.
> >
> >    2. *Co-Pilot *
> >    Unconditional Yes
> >    "Yes - DNS challenges are recreated every time Certbot renews your
> >    certificate, unless your DNS plugin/provider supports persistent TXT
> >    records (almost none do). Certbot must prove domain control again at
> each
> >    renewal, so it generates a new TXT value for _
> >    acme-challenge.yourdomain.com every time."
> >
> >    3. *ChatGPT*
> >    Unconditional Yes
> >    "Yes. If you're using a DNS-01 challenge with Certbot, the challenge
> is
> >    generated fresh for every certificate issuance and every renewal."
> >
> >    4. *Claude*
> >    Correct Answer
> >    Not automatically, no - it depends on the ACME server's authorization
> >    caching, not on certbot itself.
> >
> > Fabian V. Thobe
> >
> > [phone] / [e-mail]
> >
> > Via Filippo Corridoni 68, 56125 Pisa
>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>