[Acme] Re: Two pull requests from me waiting.

[Henry Birge-Lee <[e-mail]>]

Hi Sebastian,

Thanks for opening these up. These are topics we have under discussion and
I plan to discuss these PR with the other authors. I think the points they
address on both topics are valid and worth putting in changes around.

Best,
Henry

On Tue, Jun 2, 2026 at 4:20 PM Sebastian Robin Nielsen <sebastian=
[e-mail]> wrote:

> https://github.com/ietf-wg-acme/draft-ietf-acme-dns-persist/pulls
>
> First one:
>
> This is to change the language in the document. issuer-domain-name is a
> opaque value from client’s point of view.
>
> That means, the client does not make a request, verify or otherwise make
> any connection to the value in the field ”issuer-domain-name”.
>
>
>
> it could be a random hash like ”adf6a97f6a95f85fda5f9d59a98fda59fa6”. It
> would work perfectly still.
>
>
>
> That means, protecting the ”issuer-domain-name” does not give any security
> advantage from the clients point of view.
>
> A compromise of ”issuer-domain-name” would also not give any security
> degradation.
>
> The ”issuer-domain-name” may even be a domain the CA no longer owns (for
> example a legacy domain they no longer renew, but still keep in their CPS
> to keep old dns-persist-01 records working indefinitely).
>
>
>
> Tthe above pull request changes it to ”ACME Directory URL” – which is the
> sensitive resource the CA owns in the ACME world.
>
>
>
> Max Hearnden suggested that a ACME Directory may emit cross-domain URLs in
> its directory – for example a newAccount URL that does not reside at the
> same domain as the Directory.
>
> This newAccount URL could then be independently compromised.
>
>
>
> However, in my opinion, its the CAs responsibility – if they host parts of
> their ACME infrastructure on different domains - to at least perform some
> basic health checking of their sub-resources and shut down the Directory
> URL if any sub-resource is found to be comrpomised. Thus, the important
> thing to keep secure (with DNSSEC and other things) is the ACME Directory
> URL. Thats a URL that is the ”root of trust” for the ACME client, and
> failing to secure that would mean complete takeover of the ACME client.
>
>
>
>
>
> Second one:
>
> Its a variation of my ”pubkey:” idea, but instead of a SPKI hash of the
> pubkey, I chose a JWK thumbprint. In this way, functionality to verify it
> already exist server-side and functionality to generate it, exist
> client-side (in the same functions which generate a JWK thumbprint for use
> in HTTP-01 challenges).
>
> To avoid a CA going foul of the CAB forum rules, I chose to make a rule
> that a CA must invalidate any authorizations that have been validated using
> a pubkey: record, IF a keyChange is made on the account, so if said key
> would be moved to a second account, a pubkey: record doesn’t accidentially
> validate 2 account to issue certificates simultaniously for the same record
> (which is prohibited by the CAB forum since each dns-persist-01 record may
> only link to ONE account).
>
> Client functionality that a client must reject a pubkey: URL emitted from
> a ACME server (as discussed) – I choose to omit, since a pubkey: record is
> SUPPOSED to be generated completely offline.
>
> Clients implementing support for pubkey: records will thus already do the
> calculations offline.
>
>
>
>
>
>
>
> Hope you like the pull requests, and it would be nice if someone in the
> ACME group could take a look on them and see if there is any problems.
>
> the first one should not really be a problem to merge.
>
>
>
>
>
> Best regards, Sebastian Nielsen
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>