RFC 8555 Proposal to Section 7.5.1

[jeremyhahn]

Summary:
RFC 8555 challenge response proposal

While this is not a Boulder issue per se, I'm not aware of any RCF 8555 specific forums. If there is a more appropriate location for my query, kindly help redirect my concern. I noticed a LetsEncrypt email on the RFC so I thought this might be a good place to start.

Section 7.5.1 of RFC 8555 states the client sends an empty JSON body POST request to the challenge URL to confirm it's ready for validation. This seems, perhaps, overly restrictive, and certainly inefficient for authorization types that are able to produce a valid challenge response at the same time the challenge is accepted, such as the case with a permanent-identifier from a TPM, HSM or other device with attestation capabilities.

You can see this thread for more context:
jeremyhahn/go-trusted-platform#2

Another issue I encountered worth mentioning (but not as important to me):
The base64 encoding scheme in RFC 8555 seems incompatible with the JOSE standard - more specifically, the issue arises because the ACME RFC 8555 expects only the entire protected, payload, and signature fields to be base64url-encoded in the final JOSE object—not each individual element inside them. However, in typical JOSE implementations, each part, like the protected header, is often base64url-encoded before being embedded in the JOSE object. Therefore, ACME expects base64url encoding only on the outermost components, while traditional JOSE implementations may encode internal components as well, causing a mismatch.

This mismatch is inconvenient in modern applications based on JOSE and leads to having to maintain two different libraries for serialization and signing.

The nice thing about standards is there are so many of them :)

[jsha]

Hi @jeremyhahn ! Looks like we successfully got the conversation started on acme@ietf.org, so I'm closing out this issue.