Hi Aaron, Thank you very much for your comments, see inline: ---------------------------------------------------------------------------- 2024年11月26日 22:54，Aaron Gable <aa...@letsencrypt.org> 写道： 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 [wupanyu] We also recognize the possibility of streamlining the CSR application process and do not deny and oppose the possible beneficial benefits that would result. However, it is also recognized that this might break the decoupled structure of ACME and introduce a lot of compatibility issues, which of course is well worth the ongoing discussion that can take place. 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. [wupanyu] Thanks for your perspective. Proof-of-possession can indeed be used to determine whether a subscriber possesses the subscriber’s private key when revoking a certificate, thus accomplishing a more reliable revocation. This is a very useful point~ 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. [wupanyu] For security threat modeling, we are currently considering the latter as you say. 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. The adversary has the client's key and the CSR file for someone else's certificate, but the one who passes the validation in the challenge interrogation phase is not the applicant who applied for the public key arbitrarily in the final phase, and thus the certificate cannot be issued for him or her. I hope my description is clear enough~ 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
