On Tue, Nov 26, 2024, 07:09 Richard Barnes <r...@ipv.sx> wrote: > > 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. >
I've always imagined the pubKey proof of possession challenge as being very similar to the TLS-ALPN-01 challenge: do a successful TLS handshake while presenting a (self-signed, or previously-issued) certificate, and that proves you control the corresponding private key using only well-vetted protocols that already support many different key types. This avoids the need to worry about using the same key to sign various different kinds of objects. And I don't think there are CA compatibility impacts -- a CA would have the option of ignoring the finalize CSR (and not requiring their clients to present one) if the client had supplied a pubkey identifier in the new-order request and completed a challenge for it. But regardless, that's a rabbit hole that seems orthogonal to the motivations of this draft. Aaron
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
