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. 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. 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
