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

["Fabian V. Thobe" <[e-mail]>]

Hey Mike, Hey Corey,

First, thank you very much for your kind review of my initial email. Having
had personal ties to people in countries which would not be considered
free, I am surely more sensitive than the next guy and more sceptical
towards infrastructure around me.


*In general, reuse of authorizations is desirable. For "high security"
environments, clients could proactively deactivate authorizations after
certificate issuance per RFC 8555, section 7.5.2.  So, I think the current
spec and server implementations are sufficient, provided that the server
implements deactivating authorizations.*
*I agree that this is a potential gap in the ACME spec. RFC 8555 allows
revocation requests to be signed by any account that has valid
authorizations for all identifiers in the certificate, but:*

   1.
*There is no language mandating the deactivation of authorizations in the
   course of revocation, and: *
   2. *Revocation requires a certificate to revoke.*

*Additionally, there's no language in section 7.5.2 to invalidate
authorizations across all accounts.*


The fun part is, that I fully agree with you regarding 7.5.2, technically
for ease of implementation though, I believe that the organic way to pass a
cache policy would be with the item it governs > hence with the order to be
subsequently stored with the authorization itself, a simple caching : true
/ false together with the order would basically solve the entire issue.

"identifiers": [
         { "type": "dns", "value": "example.org", "caching" : "false" }
       ],

I feel this would be the most lightweight solution and also go hand in hand
with keeping 8555 as lightweight as possible.

*You don't want to make an API like that un-authenticated because then that
becomes a vector for DoS attacks. *


Good that we all don't want to go that road XD

*But I also see your idea to add a "I lost my account key" feature to ACME
that lets you do a DNS-01 challenge in order to prove ownership and thereby
revoke authorization to any existing ACME accounts (this feels to me
similar to a "I forgot my password" flow). I think that's an interesting
idea worth exploring.*

That is definitely a big one, I'd love to do that. I would like to
invalidate accounts as for the tremendous side effects that could have on
weak client side implementations and unintentional failed renewal. I think
requiring re-authorization is sufficient, but maybe I am missing something.

*Regarding the adoption of authorisation invalidation: *

Right now adoption for authz revocation is spotty:
Certbot: does not allow revocation of authorisation
poshACME: Does fully support it
acme.sh: Does fully support it

Certbot is the tool Let's Encrypt pushes most and has surely the highest
adoption outside of native hosting service integration and does neither
mention caching nor backup of account keys in any section of the
documentation.

*If you want to submit a proposed solution, I suggest you write an
Internet-Draft and submit it to the IETF Datatracker so that the WG has a
draft to review. Potentially, some of the folks on this mailing list might
volunteer to help you write it, if there is enough interest in solving this
problem*


Yes, I'd love to. I think the most pragmatic way would be a "caching" :
"true / false" on the identifier inside the order object. It can be passed
along the chain to create the authorization object.
If more complex solutions are appreciated, I would write a proposal along
the lines of DNS validation based authorization invalidation. I am not sure
if an account recovery is needed, if the authorizations are invalidated.

Thanks to you both, I really appreciated your replies. I am either way
happy to contribute, I do though believe that passing caching boolean down
with the order would be easiest.

On Tue, Jul 14, 2026 at 6:23 PM Fabian V. Thobe <[e-mail]> wrote:

> Hey Mike, Hey Corey,
>
> First, thank you very much for your kind review of my initial email.
> Having had personal ties to people in countries which would not be
> considered free, I am surely more sensitive than the next guy and more
> sceptical towards infrastructure around me.
>
>
> *In general, reuse of authorizations is desirable. For "high security"
> environments, clients could proactively deactivate authorizations after
> certificate issuance per RFC 8555, section 7.5.2.  So, I think the current
> spec and server implementations are sufficient, provided that the server
> implements deactivating authorizations.*
> *I agree that this is a potential gap in the ACME spec. RFC 8555 allows
> revocation requests to be signed by any account that has valid
> authorizations for all identifiers in the certificate, but:*
>
>    1.
> *There is no language mandating the deactivation of authorizations in the
>    course of revocation, and: *
>    2. *Revocation requires a certificate to revoke.*
>
> *Additionally, there's no language in section 7.5.2 to invalidate
> authorizations across all accounts.*
>
>
> The fun part is, that I fully agree with you regarding 7.5.2, technically
> for ease of implementation though, I believe that the organic way to pass a
> cache policy would be with the item it governs > hence with the order to be
> subsequently stored with the authorization itself, a simple caching : true
> / false together with the order would basically solve the entire issue.
>
> "identifiers": [
>          { "type": "dns", "value": "example.org", "caching" : "false" }
>        ],
>
> I feel this would be the most lightweight solution and also go hand in
> hand with keeping 8555 as lightweight as possible.
>
> *You don't want to make an API like that un-authenticated because then
> that becomes a vector for DoS attacks. *
>
>
> Good that we all don't want to go that road XD
>
> *But I also see your idea to add a "I lost my account key" feature to ACME
> that lets you do a DNS-01 challenge in order to prove ownership and thereby
> revoke authorization to any existing ACME accounts (this feels to me
> similar to a "I forgot my password" flow). I think that's an interesting
> idea worth exploring.*
>
> That is definitely a big one, I'd love to do that. I would like to
> invalidate accounts as for the tremendous side effects that could have on
> weak client side implementations and unintentional failed renewal. I think
> requiring re-authorization is sufficient, but maybe I am missing something.
>
> *Regarding the adoption of authorisation invalidation: *
>
> Right now adoption for authz revocation is spotty:
> Certbot: does not allow revocation of authorisation
> poshACME: Does fully support it
> acme.sh: Does fully support it
>
> Certbot is the tool Let's Encrypt pushes most and has surely the highest
> adoption outside of native hosting service integration and does neither
> mention caching nor backup of account keys in any section of the
> documentation.
>
> *If you want to submit a proposed solution, I suggest you write an
> Internet-Draft and submit it to the IETF Datatracker so that the WG has a
> draft to review. Potentially, some of the folks on this mailing list might
> volunteer to help you write it, if there is enough interest in solving this
> problem*
>
>
> Yes, I'd love to. I think the most pragmatic way would be a "caching" :
> "true / false" on the identifier inside the order object. It can be
> passed along the chain to create the authorization object.
> If more complex solutions are appreciated, I would write a proposal along
> the lines of DNS validation based authorization invalidation. I am not sure
> if an account recovery is needed, if the authorizations are invalidated.
>
> Thanks to you both, I really appreciated your replies. I am either way
> happy to contribute, I do though believe that passing caching boolean down
> with the order would be easiest.
>
> Fabian
>
>
> On Tue, Jul 14, 2026 at 3:15 PM Corey Bonnell <[e-mail]> wrote:
>
>> > Introduce a mechanism to explicitly disable authorization caching for
>> DNS-01 challenges (Reference:
>> https://github.com/letsencrypt/boulder/issues/8870)
>>
>> In general, reuse of authorizations is desirable. For "high security"
>> environments, clients could proactively deactivate authorizations after
>> certificate issuance per RFC 8555, section 7.5.2.  So, I think the current
>> spec and server implementations are sufficient, provided that the server
>> implements deactivating authorizations.
>>
>> > 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).
>>
>> I agree that this is a potential gap in the ACME spec. RFC 8555 allows
>> revocation requests to be signed by any account that has valid
>> authorizations for all identifiers in the certificate, but:
>>
>>
>>    1. There is no language mandating the deactivation of authorizations
>>    in the course of revocation, and:
>>    2. Revocation requires a certificate to revoke.
>>
>>
>> Additionally, there's no language in section 7.5.2 to invalidate
>> authorizations across all accounts.
>>
>> Absent a way to invalidate through the ACME protocol, there are some
>> mitigations:
>>
>>
>>    1. Directly contact the CA. WebPKI CAs need to be able to respond to
>>    problem reports within 24 hours.
>>    2. Assuming the WebPKI CA supports RFC 8657 (which all will need to
>>    support in early 2027 thanks to CABF ballot SC-98): set up CAA records with
>>    a short TTL containing the RFC 8657 accounturi parameter and update the
>>    records in the event of account compromise. WebPKI CAs are required to
>>    recheck CAA records every 8 hours or before the TTL elapses (whichever is
>>    greater), so there is a relatively short window for abuse.
>>
>>
>> Thanks,
>> Corey
>>
>> [1]
>> https://cabforum.org/2026/05/13/ballot-sc098v2-process-rfc-8657-caa-parameters/
>>
>> Jul 14, 2026, 04:27 by [e-mail]:
>>
>> 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‑01 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.
>>
>>
>>