Why aren't we talking about going to DANE instead? thx ..Tom (mobile)
On Thu, Jul 25, 2024, 3:34 PM Matthew McPherrin <mattm= [email protected]> 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 <[email protected]> > wrote: > >> >> Aaron Gable <[email protected]> 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 <[email protected]>, Sandelman Software Works >> -= IPv6 IoT consulting =- *I*LIKE*TRAINS* >> >> >> >> _______________________________________________ >> Acme mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > RATS 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]
