Why aren't we talking about going to DANE instead? thx ..Tom (mobile)
On Thu, Jul 25, 2024, 3:34 PM Matthew McPherrin <mattm= 40letsencrypt....@dmarc.ietf.org> wrote: > 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 >> > _______________________________________________ > RATS mailing list -- r...@ietf.org > To unsubscribe send an email to rats-le...@ietf.org >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
