My primary concern with "moving beyond the CSR" is that it's a defacto standard which is widely supported today, so we should make sure that (at least for the most part), an ACME client can still take a CSR and transform it into whatever public key format is required. But if the ACME client doesn't have access to the webserver private key, completing some different PoP is going to be challenging.
It seems most of the trouble adopting ACME today is in more "appliance" type contexts, where CSR interoperability is a big win. So I think we need to be cautious about simplifying ACME in a way that harms its adoption, even if it is overall simplified. On Wed, Jul 24, 2024 at 7:17 PM Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Aaron Gable <aa...@letsencrypt.org> 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. > > I'm all for moving beyond the CSR! > I think having something that can be used in ACME and also in other > enrolling > protocols would be useful though. > > RFC7030bis has been talked about. > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > > > _______________________________________________ > Acme mailing list -- acme@ietf.org > To unsubscribe send an email to acme-le...@ietf.org >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
