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: [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]
