Hi all, At the request of this draft's authors, I'm using this thread to provide additional feedback on the updated version of the document ( draft-geng-acme-public-key-01 <https://datatracker.ietf.org/doc/draft-geng-acme-public-key/01/>) which will be presented at IETF 122.
While I appreciate the document updates to address my comments about omitting the CSR, I believe this document is still structurally quite scattered and does not successfully argue its motivation. Regarding the structure, I think the logic would be much clearer if the document were laid out as: 1. Introduction (similar to today) 2. Terminology (BCP 14 boilerplate) 3. The pk Identifier Type (defines the `pk` identifier type; doesn't bother with the "selfsign-cert" and "csr" identifier types, as those are just transport mechanisms for a public key, not things that would be included in a certificate directly) 4. Identifier Validation Challenges 4.1. pk-idp-01 (how to use a third-party identity provider to prove control of the key, as described by the document today in Sections 2 and 5) 5. Changes to the Finalize Request (detailing how an ACME server may allow the CSR to be omitted from a finalize request if a pk identifier has been validated) 6. Security Considerations (absorbing most of the contents of what is currently Section 3 "Security Model") 7. IANA Considerations This layout would more closely match the layout of both RFC 8738 (ACME IP) and RFC 8823 (ACME S/MIME), for ease of readability. This layout would also pave the way for a number of other potential validation challenges to be included. Ideas I've had, which should be thoroughly designed and discussed and likely dismissed, include: 4.2. tls-alpn-01 (how to use the existing tls-alpn-01 challenge, with the additional requirement that the presented certificate contain the requested public key and that the TLS handshake complete successfully) 4.3. pk-tls-01 (a new method similar to the above, but without the acme-tls/1 ALPN protocol and without the acmeIdentifier extension, allowing the applicant to use their currently-valid TLS certificate if they plan to keep using the same key) 4.4. pk-dns-01 (similar to the existing dns-01 challenge, with the change that the server expects to find a hash of the pubkey in the TXT record rather than a key authorization) 4.5. pk-dane-01 (similar to the above, but searching for a TLSA 3 1 X or TLSA 1 1 X record rather than a TXT record) 4.6. pk-jwk-01 (as mentioned by Richard Barnes upthread, use the private key to sign a JWS over the challenge token, and POST it to the challenge URL like the new onion-csr-01 challenge) Regarding the motivation, I believe the core of the motivation is presented in the third and fourth paragraphs of the introduction: > Normally a user has a client for automated applications. And in some specific application scenarios, some users who expect to obtain certificates and allow continuous updates cannot integrate such a client. Such a user might use a proxy as a unified entry point for automated certificate requests. This proxy might be a system or an administrator. Based on the standard ACME application process, the ACME server can communicate with the user and prove the validity of the user's identity through its proxy. However, standard ACME application process does not verify that the public key in the challenge phase and the public key in the CSR are the same when the CSR is submitted. The proxy may be a malicious adversary that substitutes the final CSR and applies for a mismatched certificate. > > Similarly, in non-proxy scenarios the certificate applicant is the ACME client, which may generate other arbitrary public-private key pairs to apply for obtaining mismatched certificates after completing the challenge phase, i.e., the public key of the finally issued certificate does not match with the public key in the challenge phase, which results in a security risk. Unfortunately, I find this reasoning flimsy. Let's take the proposed situation at face value: a fleet of machines have the internet connectivity to complete DCV challenges, but not to run their own ACME clients. Instead, all their outbound ACME requests are handled by a "proxy" which holds the ACME account key and uses it to sign the ACME requests. The argument is that this fleet may not fully trust that proxy, fearing that it could substitute a different CSR (i.e. a different public key) at the finalization step. But allowing those backend clients to prove that they control various pubkeys does nothing to mitigate the threat of this malicious proxy: it can simply modify the new-order requests to include different pubkey identifiers, complete the challenges to prove control over those pubkeys itself, and then still substitute a different CSR at finalize time. The clients gain no assurance that a certificate containing a different pubkey won't be issued by the proxy. If the backend clients don't trust the proxy, they shouldn't be completing DCV challenges on its behalf. Similarly, in the non-proxy case, an applicant which does not trust its ACME client should not complete any DCV challenges on behalf of that client. Remember that, from the ACME server's perspective, the ACME client (i.e. the entity which controls the ACME client's account key) *is* the applicant -- any other machines which may be helping complete DCV challenges are just helpers, not the "real" applicant. If you don't trust your ACME client, you've already lost, because the Server trusts nothing *but* the ACME client. Again, I appreciate the work the authors have done on this draft. I think that the general concept of a pubkey identifier type is a good one, and we should discuss the merits of various challenge types that can be used to verify that the client wants a given key to appear in its certificate and/or that it controls the corresponding private key. I look forward to discussing this further at IETF 122 and into the future. Aaron
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
