On Wed, Jul 24, 2024 at 01:05:45PM -0700, Aaron Gable wrote: > > For example, I hope to introduce a proposal for a "pubkey" identifier type, > so that TLS ACME clients can submit their pubkey at newOrder time. This > would remove the last field that the ACME CA truly relies on the CSR for, > allowing ACME Servers to ignore the CSR entirely if they so wished. It also > has the added benefit of letting clients prove that they control the > corresponding private key (by fulfilling an ACME Challenge for the pubkey > identifier, e.g. by conducting a TLS handshake with that key), which the > current CSR transmission mechanism does not do.
This could be combined with order autofinalize: Instead becoming ready, order will directly enter processing. This saves from dealing with CSR at all. And I presume that depending on ACME server policies, the ACME server is allowed to skip challenge on the pubkey identifier. There are systems that do not accept external keys, and transporting keys not the best practice regardless. And for TLS handshake as PoP, the ACME server would handshake with what? For actual PoP, one way would be to sign a challenge using TLS 1.3 compatible (e.g., JWS is not cryptographically kosher here) signature using the private key. -Ilari _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
