[I am speaking as ACME Chair] We may have a disagreement about whether ACME or EST is better suited to this use case, but attacking the other person's level of understanding is not ok.
@Richard - If ZoTrus runs an ACME server, and you wish to see draft-ietf-acme-client progress, would you be willing to join Kathleen Moriarty as an author to help with editing the draft? Also, I don't know if the ZoTrus ACME server is publicly available on the internet, but it would be helpful (although technically not required for RFC publication) if you could implement the draft for your client - server environment and give a presentation at the next IETF about what you learned -- IE does the text of the draft as it is written now do what you need, or does the text needs to be adjusted based on what you learn while implementing it? On Sun, 27 Jul 2025 at 21:11, <[email protected]> wrote: > Yes，everyone should be polite. > > > > Best Regards > > Richard Wang > > > > *From:* Deb Cooley <[email protected]> > *Sent:* Sunday, July 27, 2025 5:50 PM > *To:* [email protected] > *Cc:* Michael Richardson <[email protected]>; IETF ACME <[email protected] > > > *Subject:* [Acme] Re: Personal review of draft-ietf-acme-client > > > > This is a warning that we need to be polite. > > > > What Michael means is that acme and est do not serve the same purpose. > They are not interchangeable. Please be sure you understand which protocol > fits your needs best. If you are attempting to register devices, then est > may be better for you. > > > > There is, in fact, a draft called acme integrations which is sitting in > the editors queue which gives a way to stitch acme and est together. > Sadly that draft is still waiting for other drafts to progress (looking at > you MCR). > > > > If you need some of the challenges in the current acme client draft, will > you agree to help to author? review? review other acme drafts? > > > > Deb > > Sec AD > > > > On Sat, Jul 26, 2025 at 5:06 AM <[email protected]> wrote: > > The facility is the worldwide ACME provider, not just Let's Encrypt. > > ZoTrus is an ACME provider, just need to add difference challenge, then we > can provide other type certificate automation except TLS/SSL certificate. > > This word is also suitable for you "Please make sure you understand this > deeply, or you will be very disappointed." > > Richard > > > -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: Friday, July 25, 2025 9:56 PM > To: [email protected]; 'IETF ACME' <[email protected]> > Subject: Re: [Acme] Re: Personal review of draft-ietf-acme-client > > > <[email protected]> wrote: > > I mean ACME is already widely deployed in TLS/SSL certificate, it > > issued more 20B certificates now. > > Not really relevant. It has issued no client certificates. > (At least, none intended for that use, even if some are used that way) > > > So we can use the worldwide ACME facility for other type certificate > > automation, just need to add challenge type, this is EST don’t have. > > By this, perhaps you mean the LetsEncrypt infrastructure, (and the certbot > client). > This infrastructure is not useable for client certificates **as is** Could > it be changed? Of course: write LE a big enough checque. > > I'm sorry about this. I wish it could sing *and* dance. > So, it's not going to help with this. > Please make sure you understand this deeply, or you will be very > disappointed. > > -- > 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] > > _______________________________________________ > 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]
