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: [email protected] <[email protected]> För zandoodle Skickat: den 7 april 2026 00:42 Till: [email protected] Ä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 -- [email protected] To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
