Hi Frank, I'm a little confused as to what this draft attempts to achieve; maybe you can help clarify?
My understanding is that this draft attempts to address perceived weaknesses in the ACME protocol relating to proxying. I don't however see the need for this. RFC8555 § 6.2 already provides a binding between the client requesting a certificate and its requests. This can be combined with RFC 8657 Account URI for an even stronger binding between identifier and requesting client. There is a discussion to be had in the wider PKI scope about a CSR not being proof of key possession, however I don't really see what the vulnerability in the context of ACME is. If someone completes all challenges and then requests a certificate for a public key that isn't theirs they don't really achieve anything. Q ------------------------------ 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. On Mon, 25 Nov 2024 at 04:11, Xialiang(Frank, IP Security Standard) <frank.xialiang=40huawei....@dmarc.ietf.org> wrote: > Hi ACME experts, > > We submitted and presented a new ACME paper at the IETF 121st meeting -- > https://datatracker.ietf.org/doc/draft-geng-acme-public-key/. > > > > This draft is about ACME Extension for Public Key Challenges: basically, > we think the current identity validation mechanism of ACME（check the ACME > applicant’s control over the requested identity）needs to consider some > necessary extension in some specific use case (The ACME proxy or ACME > applicant itself is taken over by the adversary and perform the public key > replacement attack, result in the replacement of the public key in the > final CSR message and gain the control of the real applicant’s identity). > So, we propose a new ACME challenge type – ACME public key challenge > (pk-01, 3 types of identifier can be applied with: pk, selfsign-cert and > csr), together with IDP and known public key authentication protocol (i.e., > WebAuthn, Opaque/AKE, non-interactive zero-knowledge (NIZK) discrete > logarithm equality (DLEQ) proof…). Through this extension, the public key > authenticity, consistency and mapping to the identity are all well checked > and protected. > > > > Hopefully, you have noticed this draft~~ > > If no, we are looking forward to your review on this draft, and warmly > welcome your comments on it. > > > > Thanks a lot! > > > > B.R. > > Frank > > > _______________________________________________ > Acme mailing list -- acme@ietf.org > To unsubscribe send an email to acme-le...@ietf.org >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
