Thanks for bringing this up, in writing this reply I feel like I'm griping more than I'm coming up with answers, but I agree wholeheartedly that something like this should get added; there are just a lot of details to work through.
It's more complicated than that, even, in that the chains are different not just based on account, but based on whether using an ECDSA or RSA key for the certificate. (I have an E1-allowlisted account, and use it getting both ECDSA-signed-by-E1 and RSA-signed-by-R3 certificates.)
I could imagine a CA with more complicated rules (though I don't know what the "industry standard" is), such as using a 4096-bit RSA intermediate when signing a 4096-bit RSA certificate but only a 2048-bit intermediate when signing a 2048-bit cert. Or maybe just using different intermediates "randomly" at the same time. I know Amazon's CA seems to just pick a random intermediate of theirs as far as I can tell (though that isn't via ACME), and Let's Encrypt has at some point talked about the possibility of using a different intermediate depending on which datacenter is processing the request.
Yes, I think that in order to find out which chains are going to be available for a certificate, one would need to present to the server at least some of the details about it (key type and size, at the very least, though maybe domain names or the like too), and then the server might need to remember which intermediate it "promised" it would use for that client. I'm guessing that it could get really convoluted for some CAs, to make sure that further requests from an account get routed to the same datacenter or whatever in order to get the same options.
And, I think the "type" concept which seems to only have values of "RSA" or "ECDSA" might need to be expanded a bit to include other key properties, and maybe other things like "datacenter" or some concept like that.
Other things that you might want to add, somewhere, somehow, in order to make a client's life easier (though I understand this is drifting at least a bit off topic):
- Which signature/hash methods are allowed for the CSR. (I mean, the industry in general is in for a world of hurt if there ends up being any need to move off of SHA-256, especially if the need is to move quickly. But I'm assuming it will need to go away at some point, and when it does it'd be good if there would be a way for clients to tell what hashes the server will accept before just trying them out.
- If ARI is a thing resembling the current draft, which hash algorithms are allowed for ARI requests.
- Which key lengths and types are supported for certificates.
- Which key lengths and types are supported for account keys.
- Information on applicable rate limits.
- Whether there is support for requesting a specific notBefore or notAfter, and what constraints there are on it. (Or at the very least, some information what the default certificate lifetime is.)
- What CSR extensions (like OCSP Must-Staple) are supported.
- If the directory is for a "staging" environment, and maybe a link to the corresponding staging/live environment from the other. (It's kind of awkward that clients basically hard-code Let's Encrypt's staging server, and use it even when configured to use a different CA for production.)
- Policies on revocation options (like, Let's Encrypt requests revoking for keyCompromise to be by the certificate key only.)
I guess I'm just saying, while I agree more chain information should be exposed, I'd like to add even more things while we're talking about changing things, and maybe present the idea that I'm not even sure that the chain options are the highest priority for stuff that should be added to ACME in order to allow clients to actually just have a Directory URL and go from there.