Hi Q, Thanks for your pointing out the reference, I have read this section and found that it (external account binding) is another thing about account authenticity and performed in the ACME “Account Management” phase, different from what our draft proposed about public key authenticity and performed in the “Identifier Validation Challenges” phase.
Hopefully my understanding is not wrong~~ B.R. Frank 发件人: Q Misell <q=40as207960....@dmarc.ietf.org> 发送时间: 2024年11月27日 21:34 收件人: Xialiang(Frank, IP Security Standard) <frank.xiali...@huawei.com> 抄送: Richard Barnes <r...@ipv.sx>; Aaron Gable <aa...@letsencrypt.org>; Mike Ounsworth <mike.ounswo...@entrust.com>; IETF ACME <acme@ietf.org>; draft-geng-acme-public-key.auth...@ietf.org 主题: Re: [Acme] 回复: Re: 回复: [EXTERNAL] Re: Introducting a new draft about adding a new ACME challenge type: public key challgenge Frank, External Account Binding refers to RFC8555 § 7.3.4. ________________________________ 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 Wed, 27 Nov 2024 at 09:13, Xialiang(Frank, IP Security Standard) <frank.xialiang=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Hi Richard, Thanks for your comments, see inline: 发件人: Richard Barnes <r...@ipv.sx<mailto:r...@ipv.sx>> 发送时间: 2024年11月26日 23:09 收件人: Aaron Gable <aa...@letsencrypt.org<mailto:aa...@letsencrypt.org>> 抄送: Xialiang(Frank, IP Security Standard) <frank.xiali...@huawei.com<mailto:frank.xiali...@huawei.com>>; Mike Ounsworth <mike.ounswo...@entrust.com<mailto:mike.ounswo...@entrust.com>>; Q Misell <q...@as207960.net<mailto:q...@as207960.net>>; IETF ACME <acme@ietf.org<mailto:acme@ietf.org>>; draft-geng-acme-public-key.auth...@ietf.org<mailto:draft-geng-acme-public-key.auth...@ietf.org> 主题: Re: [Acme] Re: 回复: [EXTERNAL] Re: Introducting a new draft about adding a new ACME challenge type: public key challgenge Looking at this thread and the document, I think there are two plausible objectives here: 1. Restricting issuance to clients that perform some secondary authentication (as the document seems to propose) 2. Removing the CSR from the protocol (as Aaron suggests) A "pubkey" identifier type is the wrong solution for both. Goal (1) can be solved today with external account binding. Build an external thing that does whatever vetting you want on a client, then bind the vetted account to the ACME account. If you wanted to make this a little more automated, you could do something like an OAuth or OpenID integration, but pulling the entire wild world of user authentication into ACME is the wrong answer. [Frank]: Can you clarify more about “external account binding” you mean here? I think our proposal is one of the binding, which is feasible, and more importantly, automated. If there any other external account binding methods have the same effect? Goal (2) is might not an unreasonable idea, but I would be concerned about (a) compatibility impacts with subjects, (b) compatibility impacts with CA back-end APIs, and (c) new cross-protocol risks usage of the certificate subject key pair (signing some JOSE thing as well as being used in TLS, vs. CSR+TLS, which has been done forever). Even if we wanted to do this, then you don't need the whole machinery of ACME challenges. You don't need an extensible set of ways to validate an ECDSA key, you need one, and probably not even one per algorithm -- you could just define a JWS structure that was the moral equivalent of a CSR and have the client attach it to an order. [Frank]: Concur with your concerns. The current ACME 3-phase design is good and provides enough compatibility. B.R. Frank On Tue, Nov 26, 2024 at 9:55 AM Aaron Gable <aaron=40letsencrypt....@dmarc.ietf.org<mailto:40letsencrypt....@dmarc.ietf.org>> wrote: Hi all, I agree that it would be beneficial for the ACME protocol to have a pubKey identifier type, and to have challenges which can be used to prove control over the corresponding private key. However, it seems that I believe this would be useful for entirely different reasons than the authors here, and I am currently unconvinced by the motivations presented here. I believe that a pubKey identifier type is useful for two reasons: 1) it allows the CSR to be removed from the finalize request, as it will no longer be carrying any information that is not already found in other parts of the ACME protocol; and 2) proof-of-possession allows the ACME server to respect keyCompromise revocation requests which are signed by the Subscriber key instead of only accepting those which are signed by the certificate key. It seems that this draft is arguing for the inclusion of a pubKey type and corresponding challenges from a security perspective: that an adversary might replace the CSR in the finalize request and thereby get issuance of a certificate containing a malicious key. I must admit I do not understand this threat model. If the adversary is simply a network adversary between the legitimate Client and Server, then they cannot replace the CSR: the finalize request is signed by the ACME client key and cannot be tampered with without invalidating that signature. If the adversary is on the ACME client host, and has access to the ACME client key, then the game is already lost -- that adversary *is* the Subscriber for all intents and purposes, and has significant latitude: they can change the ACME client key to one the victim doesn't control, they can (generally, based on the architecture of most clients) complete HTTP-01 and DNS-01 challenges, and they can prove possession of any private key they like. So I think that this document needs to be overhauled in two ways: - more clearly motivating the threat model: what exactly is the security issue being solved, and why is it import that it be solved; and - more clearly motivating the solution space: how do proof-of-possession challenges mitigate the threat, and why are this particular set of proposed challenges the best way to do so. Aaron _______________________________________________ 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<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
