I don't quite follow your argument. ACME is not widely deployed for what you want to achieve either. ------------------------------
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. Ar Iau, 24 Gorff 2025 am 11:16 <[email protected]> ysgrifennodd: > OK, forget Grok. > > And again, *EST* is NOT the worldwide deployed standard, ACME is. This > draft use the mature ACME facility to realize other certificate automation, > this is the easy way than any other standard. > > > > > > Best Regards > > Richard Wang > > > > *From:* Q Misell <[email protected]> > *Sent:* Thursday, July 24, 2025 3:34 PM > *To:* [email protected] > *Cc:* Michael Richardson <[email protected]>; Mike Ounsworth > <[email protected]>; IETF ACME <[email protected]> > *Subject:* [Acme] Re: Personal review of draft-ietf-acme-client > > > > > Grok told me that "EST Server Scenario: An enterprise with an internal > CA uses an EST server to issue certificates for IoT devices", but we need > ACME for public CA to issue publicly trusted certificate. > > > > Not to constantly relitigate the value of LLMs, but what Grok has > hallucinated here is not what EST can do, but rather what it has > traditionally been used for. There is nothing to say it can't be used in a > different context to how it is most commonly used. > ------------------------------ > > Any statements contained in this email are personal to the author and are > not necessarily the statements of the company unless specifically stated. > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company > registered in Wales under № 12417574 > <https://find-and-update.company-information.service.gov.uk/company/12417574>, > LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 > <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. > EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: > 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru > maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca > Digital, is a company registered in Estonia under № 16755226. Estonian > VAT №: EE102625532. Glauca Digital and the Glauca logo are registered > trademarks in the UK, under № UK00003718474 and № UK00003718468, > respectively. > > > > > > Ar Iau, 24 Gorff 2025 am 03:26 <[email protected]> ysgrifennodd: > > Hi Mike, > > I checked EST: https://www.rfc-editor.org/rfc/rfc7030 that released on > 2013, > early than RFC8555. > Let me try to explain why not EST but ACME: > (1) the most important reason is ACME is widely used worldwide, EST not; > (2) Grok told me that "EST Server Scenario: An enterprise with an internal > CA uses an EST server to issue certificates for IoT devices", but we need > ACME for public CA to issue publicly trusted certificate. > (3) This draft is just add more challenge type to ACME facility that widely > used, then all type certificates support automation, this is the easy way > for certificate automation then EST. > > So I strongly recommend use ACME, not EST. And we need this draft for > client > certificate including code signing certificate and document signing > certificate, thanks. > > > Best Regards > > Richard Wang > > -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: Wednesday, July 23, 2025 7:57 PM > To: [email protected] > Cc: 'Mike Ounsworth' <[email protected]>; 'IETF > ACME' <[email protected]> > Subject: Re: [Acme] Re: Personal review of draft-ietf-acme-client > > > <[email protected]> wrote: > > This RFC draft is for Client Certificate including Client > Authentication > > Certificate, code signing certificate and document signing > certificate, so > > all type certificates that CA issued support ACME, this is a VERY > necessary > > standard that the industrial need. > > Can you speculate as to why EST is not being used? > > -- > 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]
