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 -- [email protected]
To unsubscribe send an email to [email protected]
