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

[Michael Paoli <[e-mail]>]

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