An attestation authorization still needs to be verified with a challenge, so setting it to valid in the new-order request does not seem like it would work. I think what's best for device attestation is the ability to send the attestation / challenge response at the same time the challenge is accepted, instead of an empty payload. Is there a reason why the RFC strictly requires an empty payload here instead of offering the flexibility of sending a payload, and the ability to resolve the challenge synchronously at the same time it's accepted?
Regarding the JOSE object, I'm saying that the ACME JWS serialization is different from the JOSE standard, so that means having to maintain an ACME specific JWS serialization and signing library in addition to code following JOSE standards. On Mon, Nov 11, 2024 at 4:36 PM Jacob Hoffman-Andrews <j...@letsencrypt.org> wrote: > 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
