On Wed, Mar 11, 2026 at 07:24:43AM -0700, Aaron Gable wrote: > > But some PKIs and some CAs within the WebPKI would like to have mechanisms > that actually prove control of the corresponding key pair. For this, we > probably need a signature over a nonce. I see three obvious potential paths > for this: > > - A challenge that can be fulfilled by POSTing a JWS to the challenge URL, > where the JWT contains a CA-provided nonce. This is potentially easier for > an ACME client, but is much less cryptographically sound, as the > certificate key is not expected to be signing JWSes.
A variant would be signing TLS 1.3 signature. Which is cryptographically more sound, and supports more algorithms (except ECDSA/Bitcoin curve). And if the set of algorithms is not enough, then the method discussed below would not work either. > - A challenge that can be fulfilled by the ACME client doing a TLS > handshake using the desired key. This has the advantage of being the most > cryptographically sound: we're using the TLS key to do a TLS handshake, and > TLS already has all of the temporality features built-in with no need for > an additional CA-provided nonce. But of course it has the disadvantage of > being essentially identical to the existing tls-alpn-01 challenge type, > which has the distinction of being the least-used challenge type in > practice. This is largely because it is much more complex to implement than > http-01, but still requires the server to be open to the internet like > http-01. I think this challenge would be simpler than tls-alpn-01 (no need > to build a custom cert with the nonce in an extension), but it would still > require the ACME client to be able to provision a > potentially-never-previously-used key into a webserver without letting any > non-validation traffic get routed to that webserver. What name should be used for that connection? If client can specify the name, that requires a nonce anyway. > But as evidenced by dns-persist-01, we've also been thinking critically > about the security of methods that don't require nonces. In that vein, we > have my current personal favorite potential challenge method: > - A challenge that can be fulfilled by the public key being found in a DNS > TXT record on the domain in question, basically a combination between DANE > and the dns-persist-01 draft. No need for signing over nonces, no need for > open webservers, and not even any need for the ACME client to have DNS API > credentials unless the ACME client wants to rotate the key frequently. Just > put the key (or a hash of the key) in DNS, and then the CA can confirm that > the current DNS controller wants that key to be used. This has all the > advantages of DANE, with none of the "every relying party has to do a bunch > of extra DNS lookups and validations" disadvantages of DANE. What names are queried? All? How are names with this info missing handled? -Ilari _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
