This will be almost scribble like, so it may hard to read.
add onion identifier -
chllenges ::
http/tls-alpn (both over tor network)
dns challenge can’t be used
new csr based challenge (LE want to use it because it doesn’t need tor daemon running on VA), but are we send json payload to VA backend from WFE.
from pebble wte updateChallenge function.
// In strict mode we reject any challenge POST with a body other than {}.
// This matches RFC 8555 Section 7.5.1 and the ACME challenge types that
// Pebble has implemented. Per ACME errata 5729[0] it may not be true for
// extensions to ACME that add new challenge types.
Boulder will need a new column for this csr data saved at challange object: will it able to work on production without massive downtime?
signing would be same as before (except the need to set SNI as dns, not maked up onion identifier obviously
We could just send the CSR directly to the RA, that will check with the VA that it contains the signed keyAuthz, update the challenge status, and then just discard the CSR.
I realize that the example is for signing, but since it calls x509.ParseCertificateRequest on the DER-form of the CSR, we know it can handle reading and validating it also.