Hi Aaron, Thank you so much for your comment, see inline: ----------------------------------------------------------------- 2024年11月27日 05:50，Aaron Gable <aa...@letsencrypt.org> 写道： 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. [ wupanyu] In my understanding, the TLS-ALPN-01 challenge is mainly used to verify domain control, and the key Authorization during the challenge is derived from the fingerprint of the account key, indirectly proving the client's control over the account key. But in fact there is no way to solve the public key substitution attack at the final certificate request stage. As for streamlining the CSR process, it's an interesting point that can be discussed together indeed! 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
