[Acme] Re: Introducting a new draft about adding a new ACME challenge type: public key challgenge

[Aaron Gable <[e-mail]>]

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