[Acme] Re: Potential issues with dns-persist-01

[Sebastian Robin Nielsen <[e-mail]>]

another thing that warrants using the "accounturi" parameter (by creating a new pubkey:<sha256 of pubkey>) instead of using a new "accountkey" parameter, is to avoid needing a CAB/F rules change.

The CAB/F rules change says that "accounturi" should be a unique value identitying an account. If this value consist of the account URL itself, or is the public key of the account, doesn't really matter.
Since each account must have a unique public key, a public key is as much "unique value identitying an account" as the account URI itself.

(and in same way, account URI can be resolved into a public key, and a public key can be resolved into an account).

And since the CAB/F rules apply when the check is done, it doesn't really matter if the record was created prior to account creation, since once the account is created, there is a link between the _validation-persist record and the account exist - when the check is made.

The RFC 8657 mentions a CA must use a account URI that doesn't create ambiguity between accounts at different CA's.
This is obviously to prevent accounts belongning to different people to "gain access" to issue for a domain.

If the same pubkey is used for two accounts on two different CA's that share the same caaIdentities, the accounts can be considered belongning to the same entity.

Here is the extract from the ruling:


3.2.2.4.22 DNS TXT Record with Persistent Value 
Confirming the Applicant’s control over a FQDN by verifying the presence of a 
Persistent DCV TXT Record identifying the Applicant. The record MUST be placed at 
the “_validation-persist” label prepended to the Authorization Domain Name 
being validated (i.e., “_validation-persist.[Authorization Domain Name]”). For 
this method, the CA MUST NOT use the FQDN returned from a DNS CNAME lookup as 
the FQDN for the purposes of domain validation. This prohibition overrides the 
Authorization Domain Name definition. CNAME records MAY be followed when 
resolving the Persistent DCV TXT Record. 
The CA MUST confirm the Persistent DCV TXT Record’s RDATA value fulfills the 
following requirements: 
1. The RDATA value MUST conform to the issue-value syntax as defined in RFC 8659, 
Section 4.2; and 
2. The issuer-domain-name value MUST be an Issuer Domain Name disclosed by the 
CA in Section 4.2 of the CA’s Certificate Policy and/or Certification Practices Statement; 
and 
3. The issue-value MUST contain an accounturi parameter, where the parameter 
value is a unique URI (as described by RFC 8657, Section 3) identifying the account of 
the Applicant which requested validation for this FQDN; and 
4. The issue-value MAY contain a persistUntil parameter. If present, the 
parameter value MUST be a base-10 encoded integer representing a UNIX timestamp 
(the number of seconds since 1970-01-01T00:00:00Z ignoring leap seconds); and 
5. The issue-value MAY contain additional parameters. CAs MUST ignore any 
unknown parameter keys. 
*** REST OF RULE ABOUT  PERSISTUNTIL OMITTED ***


Best regards, Sebastian Nielsen


-----Ursprungligt meddelande-----
Från: [e-mail] <[e-mail]> För zandoodle
Skickat: den 7 april 2026 00:42
Till: [e-mail]
Ämne: [Acme] Re: Potential issues with dns-persist-01

I'm not sure why the accounturi parameter needs to be used for this 
change given that existing implementations don't support pubkey URIs and 
therefore it would be backwards incompatible anyway. Using a separate 
parameter would eliminate issues due to lax URI validation.

Thanks - Max

On 06/04/2026 23:16, Sebastian Robin Nielsen wrote:
> Thats not what I proposed. I proposed that the client computes his pubkey:<sha256 of pubkey> offline before even touching the ACME server.
> Thats the whole point of the proposed change. You could calculate and provision the _validation-persist record even before you have installed a network card in the server.
>
> The standard could have a explicit rule that if the server sends a pubkey: in any "accounturi" parameter, either at account creation, or inside challenge object, the client SHOULD ignore them and always use a self-calculated value for accounturi=pubkey:<sha256 of pubkey> in the _validation-persist record to provision.
>
> If the client wishes to use key rollover, they could either update the record for each rollover, or use the normal accounturi construction.
> So there is tradeoff, either you trust your server to be able to keep your account key a secret, and never need to "rollover", thus you use the accounturi=pubkey:<sha256 of pubkey> construction - gaining protection against online attacks.
> Or you choose to rollover, but then you use the normal accounturi system, because you don't trust your server to keep your account private key a secret.
>
> The standard must of course explicitly specify that a pubkey: parameter is never acceptable in a "kid" parameter either.
> The pubkey: parameter is only permitted inside the _validation-persist record.

_______________________________________________
Acme mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]