Hi Q, Thanks for your comments, see our responses inline: 发件人: Q Misell <q=40as207960....@dmarc.ietf.org> 发送时间: 2024年11月25日 16:39 收件人: Xialiang(Frank, IP Security Standard) <frank.xiali...@huawei.com> 抄送: acme@ietf.org; draft-geng-acme-public-key.aut...@ietf.org 主题: Re: [Acme] Introducting a new draft about adding a new ACME challenge type: public key challgenge
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. [Frank]: This draft aims to verify that the ACME client has the control of the private key corresponding to the public key in the final CSR request and eliminates the risk of public key replacement attack. This is not only for the proxying case, but also for the ACME client case. In both cases, the adversary may replace the public key in the final phase. RFC8555 § 6.2 already provides a binding between the client requesting a certificate and its requests. [Frank]: In section 6.2 of RFC 8555, the public key authentication is for the ACME account registration phase, but the authenticity and consistency of the public key in the final certificate application phase are not guaranteed. This is the problem our draft aims to solve. This can be combined with RFC 8657 Account URI for an even stronger binding between identifier and requesting client. [Frank]: The CAA record extension defined in RFC8657 is like the white list mechanism specifically for the domain name certificate issuance case. There is still a need to do more incremental design like our draft to ensure that the final certificate application phase issued certificate is securely bound to the ACME challenge phase validated public key. In addition, CAA records cannot solve the problem of issuing certificates to terminals, which is the case our draft is mainly focused on. 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. [Frank]: There is a risk of public key substitution due to the decoupled design of the ACME (RFC8555) three phases, which splits the phases but does not strongly correlate the public key among these phases. Our draft’s main concern is the risk of an adversary gaining access to real client's CSR and thus its certificate in the final certificate application phase. If someone completes all challenges and then requests a certificate for a public key that isn't theirs they don't really achieve anything. [Frank]: An example is like: when the client applies for a certificate for the legitimate user A, the adversary replaces the public key of A with its own public key, thus obtaining the certificate and the access right of legitimate user A. B.R. Frank 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<mailto: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<mailto:acme@ietf.org> To unsubscribe send an email to acme-le...@ietf.org<mailto:acme-le...@ietf.org>
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
