Yes, we actually considered the "have the protocol transmit all of the required math values in a decent form and get an x.509 cert back" version, but some people who were interested in using Let's Encrypt were apparently very keen on being able to use an existing external CSR. So that became mandatory in order not to have two totally separate code paths for X.509-based requests and non-X.509-based requests.

An argument for this is that it makes it theoretically possible for devices that have no knowledge of anything about PKI since the year 2000, and/or no additional programmability, to use Let's Encrypt certs (obtained on their behalf by an external client application). I have, in fact, subsequently gotten something like that to work as a consultant.

▲

mschuster91 2 days ago | parent [-]

Yikes. Guessed as much. Thanks for your explanation.

As for oooold devices - doesn't LetsEncrypt demand key lengths and hash algorithms nowadays that simply weren't implemented back then?

	▲	schoen a day ago \| parent [-]
		Yes, I guess 2000 would actually be an exaggeration these days, as you can't use SHA-1 or 1024-bit RSA subject keys. So you could maintain compatibility with oold devices, but not with oooold devices.