The CSR contains a public key which is a large object when compared to other objects the ACME CA needs to store during the ACMEv2 issuance flow. If you accept that up front and the client never bothers to actually authorize the domain or finalize the order, or if one part of the authorization fails, then you’ve wasted disk space and performed inefficient operations.
Unfortunately you're too late to provide input into RFC 8555's design. It's set in stone with the exception of errata.
I recommend that if you have thoughts on extensions or changes to the ACME protocol that could be specified in additional add-on RFCs you should propose them in the IETF working group on the mailing list.
If I remember correctly, this order was intentionally changed between ACMEv1 (the pre-standardization draft version) and ACMEv2 (the standardized version), so probably there is a history of discussion about this issue and the rationale for it in the IETF process. (If so, that would also make it harder to change in the future, because the current version represents an intentional decision after a debate.) @jsha, do you happen to have a reference to when or how this discussion occurred?
In that case conceivably ACME could be extended to support another option for other CA adopters, but it might be very difficult in terms of client compatibility because, by default, ACME client software would not understand how to use that extension. It would probably be a lot of work to get client-side implementations to add it, since there are quite a few developed independently and most of them currently use the RFC 8555 method as published. In order to retain compatibility, the extension would presumably need to allow fall-back to the standardized method if the client didn’t support it, which might not satisfy CAs that want the other order.
Thanks to @cpu for the link! As @Phil mentioned, we specifically introduced this flow because we wanted to minimize the amount of state required for abandoned orders.
I believe that at the time we asked other potential implementers to come forward if the CSR-last flow would cause any problems. We didn’t get much feedback, but what we did get seemed to indicate it wouldn’t be a problem.
I’m sorry that the CSR-last flow introduces more work to integrate with your existing CA software, but I think you will find that if you take the time to make the changes, they will be worthwhile!
Original CA seems have the capability to implement, just need to re-audit after it.
Reseller can’t until CA support CSR-last.
Why we need to think about reseller? There’re some certificate authorities haven’t update their infrastructure softwares for decades, Their only hope to get ACME supports seems that maybe some 3rd helpful reseller build it for them.
That’s a good point! It does seem like it’s hard to fully implement ACME at the reseller level, without support from the CA.
Here’s a thought: Does your CA partner keep validation information around for a certain amount of time? Could you submit a dummy CSR in order to trigger validation, then throw away the results, and perform real issuance using an ACME CSR? Note that you would need to be sure that the CA wouldn’t actually issue a certificate based on the dummy CSR, since that would mean that you as a reseller were in posession of a private key for the certificate (which is a bad idea because it increases the severity of breaches).