My personal goal is actually not to replace the CSR with "some kind of new ACME-native CSR-like thing". In my opinion, we already have an ACME-native CSR-like thing: the new-order request. It carries almost all of the information necessary to construct the certificate: the SANs, the profile, the validity interval. With the addition of a public key identifier type, we'll close the last gap between a new-order request and a CSR.
Some people might object to this characterization, because a CSR also carries a signature from the public key in question, while the new-order request does not. While true, that distinction doesn't actually matter, because the signature in the CSR is not proof of key possession. The CSR does not contain any nonces or other ephemeral data; it is evidence that *someone* at *some time* wanted this key and these domains to be associated, but not at all proof that the domain controller wants that association *now*. For some PKIs, that's totally fine. The CA/BF Baseline Requirements do not require any sort of proof of control or proof of possession for the public key in the cert. So one can imagine a variety of ACME challenges for the pubkey identifier type that don't require proof of possession: - No challenge at all; all pubkey identifiers are associated with Authorizations that are immediately in the Valid state. - A challenge that can be fulfilled by POSTing a CSR to the challenge URL, just like a client today POSTs a CSR to the finalize URL. 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 CSR to the challenge URL, where that CSR contains a custom extension which contains a CA-provided nonce. This has the upside of being cryptographically sound -- there are plenty of domain separators in a CSR, and we already expect TLS keys to be able to self-sign CSRs -- but has the downside of still requiring the client to construct a CSR and the server to parse and validate one. The one real advantage here is that the CSR construction and parsing wouldn't need to worry about any of the *other* aspects of the CSR, like SANs or EKUs. - 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 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. 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. Anyway, some or all of these are the things that I would like to have considered as potential challenge types to accompany the pubkey identifier type. Let me know if there are any ideas I've missed, or if you think any of these should be dismissed out-of-hand as obviously bad or insecure. Aaron On Wed, Mar 11, 2026 at 6:36 AM Mike Ounsworth <[email protected]> wrote: > [chair hat off] > > Ilari You do make a good point that if you're trying to enroll a > certificate with a subject key on some crazy algorithm that is not > registered in JWS, then you'll have a problem. > > On the other hand, the whole objective here is to remove the ASN.1-based > CSR from ACME so that ACME implementations don't need an ASN.1 parser and > replace it with "some kind of new ACME-native CSR-like thing". To this > effect, I think that some hacked together TLS 1.3 format + X.509 > signatureAlgorithm + X.509 signatureValue is not an improvement in terms of > _removing_ implementation complexity. > > On Wed, 11 Mar 2026 at 07:22, Ilari Liusvaara <[email protected]> > wrote: > >> On Wed, Mar 11, 2026 at 06:18:23PM +0900, Seo Suchan wrote: >> > I suggested jws because ACME already based on JWT >> > messages signed by account key, so it doesn't >> > bring anything new to the table. If Eve is able to >> > forge acme message we are toasted anyway >> >> This is certificate key, not account key. The only place where ACME >> currently uses JWS for certificate key is revoke-by-private-key. >> >> ... Which has an issue that if certificate key is something that is >> not supported by JWS, then it can not be revoked by private key. >> >> And using JWS here would similarly have an issue that it does not >> support signature keys that are not supported by JWS (but are supported >> by some other protocol the keys are for). >> >> >> >> >> -Ilari >> >> _______________________________________________ >> Acme mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
