On Mon, Nov 11, 2024 at 12:38 PM Jeremy Hahn <m...@jeremyhahn.com> wrote:
> 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. > Note that a response to a new-order request can include authorizations that are already in state "valid". I believe clients won't bother to POST to any challenge in an authorization that is already valid. That seems like a good fit for your use case. I'll also say that when designing the protocol we considered that HTTP requests are cheap, and we didn't set out to absolutely minimize them. > 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. > I don't understand this question. Could you rephrase? Possibly with some examples? It sounds like you may be running into an implementation bug somewhere. Or are you describing that it's inefficient to take a a JSON object that contains base64url strings, and then further base64url encode that JSON object?
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
