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> wrote: > Hi Richard, > > Thanks for your comments, see inline: > > > > *发件人:* Richard Barnes <r...@ipv.sx> > *发送时间:* 2024年11月26日 23:09 > *收件人:* Aaron Gable <aa...@letsencrypt.org> > *抄送:* Xialiang(Frank, IP Security Standard) <frank.xiali...@huawei.com>; > Mike Ounsworth <mike.ounswo...@entrust.com>; Q Misell <q...@as207960.net>; > 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 > > > > 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> 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 > 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 >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
