On Wed, Nov 27, 2024, 08:22 吴攀雨 <wupany...@gmail.com> wrote: > The main focus is on proxy scenarios where the adversary is on the ACME > client and has access to the CSR file of another person's public key, but > does not possess the private key corresponding to the public key of the > certificate. Due to these risks, our proposed draft requires that the > challenge needs to be completed at the final applicant and that the > consistency between that submitted public key and the challenge > interrogation phase be verified at the certificate application phase. >
Sorry, but this doesn't make sense to me. If the adversary is on the ACME client, then it doesn't matter that they don't have access to the keypair that the victim wants to include in the certificate. The adversary can just generate their own keypair, create their own CSR, and complete any proof-of-possession challenges for that key -- because they do in fact possess it. It sounds to me like you're saying that these proof-of-possession challenges would only be able to be completed by someone who controls both the key *and* the domain in question. This raises multiple questions in my mind: - the ACME client does in fact control the domain in question, otherwise it wouldn't be able to complete normal domain control validation -- so what prevents it from being able to complete these proof-of-possession challenges as well? - ACME orders often contain multiple unrelated domains -- which of those domains is the one that gets tied to the key, and how is that communicated between the ACME client and server? - how do the challenge methods described by this draft ensure that an ACME client on a "proxy" is unable to complete them? Thanks, Aaron >
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
