On Thu, Jul 24, 2025 at 11:52 AM Carl Wallace <[email protected]> wrote:
> > > > > *From: *Kathleen Moriarty <[email protected]> > *Date: *Thursday, July 24, 2025 at 5:31 AM > *To: *Q Misell <[email protected]> > *Cc: *<[email protected]>, Michael Richardson <[email protected]>, > Mike Ounsworth <[email protected]>, IETF ACME <[email protected]> > *Subject: *[Acme] Re: Personal review of draft-ietf-acme-client > > > > There’s no way to add this to SCEP formally and EST relies on LaMPS, which > is already backlogged. > > > > [CW] Re: SCEP, I get your earlier point that using SCEP in new protocols > is discouraged but SCEP is widely used and in some cases a minor tweak to > SCEP makes more sense than replacing the certificate management protocol > entirely. I do not follow your point above that one cannot add attestation > support to SCEP. I’ve worked with an implementation that’s been > provisioning certificates via a SCEP that was augmented with attestation > information for ~8 years or so. The mechanism in > draft-ietf-lamps-csr-attestation should work with SCEP as well. FWIW, I’m > not against adoption, but let’s not try to cast ACME as the sole option. > FYI - the draft is already adopted. There were a good number of reviews between meetings and several who said they planned to implement in the meeting. This discussion should be one to add to the in-person and not replace it per typical IETF procedures. > > > I’m not sure why this has to go through adoption calls every single time > it’s presented despite support. I don’t see that in other working groups or > with other drafts. > > > > -Kathleen > > > > Sent from my mobile device > > > > On Jul 24, 2025, at 11:26 AM, Q Misell <[email protected]> > wrote: > > > > 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] > > _______________________________________________ Acme mailing list -- > [email protected] To unsubscribe send an email to [email protected] > -- Best regards, Kathleen
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
