Hi Mike, Thanks for your comments, please see our responses inline: 发件人: Mike Ounsworth <Mike.Ounsworth=40entrust....@dmarc.ietf.org> 发送时间: 2024年11月25日 22:20 收件人: Q Misell <q...@as207960.net>; Xialiang(Frank, IP Security Standard) <frank.xiali...@huawei.com> 抄送: acme@ietf.org; draft-geng-acme-public-key.aut...@ietf.org 主题: RE: [EXTERNAL] [Acme] Re: Introducting a new draft about adding a new ACME challenge type: public key challgenge
I have not yet had time to read the draft, but from the description in this email thread, am I to understand that the attack model is an attarker who compromises the ACME client and wants to replace the public key (CSR) with their own, is that correct? In which case, they have the private key, how does a proof-of-possession challenge help? [Frank]: you raise a good question, and we have just clarified in other discussing threads, please take a look there. But for short, what we are doing is not simply a PoP, but supporting public key authentication with IdP (which had the valid public key before) in the ACME challenge phase, and then guarantee the public key consistency between this phase with the final certificate application phase. At first glance, this seems like a solution looking for a problem – IE the last 10 years have given us all these cool new proof techniques, but I’m not yet convinced that adding them to ACME solves a real problem. [Frank]: In addition, I would like to emphasize the benefits of the ACME+saPAKE/Opaque combination, which can realize temporary identity certificates and establish a temporary trust chain relationship with one secret at a time. It is beneficial in cross-domain authentication and authorization. We can elaborate this point in next version draft. B.R. Frank --- Mike Ounsworth From: Q Misell <q=40as207960....@dmarc.ietf.org<mailto:q=40as207960....@dmarc.ietf.org>> Sent: Monday, November 25, 2024 2:39 AM To: Xialiang(Frank, IP Security Standard) <frank.xialiang=40huawei....@dmarc.ietf.org<mailto:frank.xialiang=40huawei....@dmarc.ietf.org>> Cc: acme@ietf.org<mailto:acme@ietf.org>; draft-geng-acme-public-key.aut...@ietf.org<mailto:draft-geng-acme-public-key.aut...@ietf.org> Subject: [EXTERNAL] [Acme] Re: 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 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://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!FJ-Y8qCqXTj2!fnuSP5j_JCZriHzC7GjpcCiikO2HvOWa3_CRL6Qx-aHjpOS6R9t9b1SG8fi9jEBGcwKSKP0ibCbTz0w86HKxzmoZ2lrAFHOyNOds$>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!FJ-Y8qCqXTj2!fnuSP5j_JCZriHzC7GjpcCiikO2HvOWa3_CRL6Qx-aHjpOS6R9t9b1SG8fi9jEBGcwKSKP0ibCbTz0w86HKxzmoZ2lrAFHCPj_75$>. 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-geng-acme-public-key/__;!!FJ-Y8qCqXTj2!fnuSP5j_JCZriHzC7GjpcCiikO2HvOWa3_CRL6Qx-aHjpOS6R9t9b1SG8fi9jEBGcwKSKP0ibCbTz0w86HKxzmoZ2lrAFGz-yjdz$>. 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
