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

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

since the accounturi is mandatory, it makes more sense to be able to *REPLACE* accounturi with the pubkey (accounturi=pubkey:<sha256 of pubkey>) instead of having to provision both.
It makes it possible to provision the record before the account is even created.

Adding a accountkey= parameter, would require the client to provision both (accounturi AND accountkey) making accountkey only a optional "restriction", not a "replacement".
Thus losing the advantage of being able to provision the record before even touching ACME server.

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]