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

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

Small errata of the previous email:

*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*


That is definitely a big one, I'd love to do that. *I wouldn't *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.



On Tue, Jul 14, 2026 at 6:25 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.
>
> 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.
>>>
>>>
>>>

-- 

Fabian V. Thobe

[phone] / [e-mail]

Via Filippo Corridoni 68, 56125 Pisa