On Mon, Nov 11, 2024 at 03:25:03PM -0500, Jeremy Hahn wrote: > Hello, > > 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.
As note, onion-csr-01 from draft-ietf-acme-onion has nontrivial JSON body. So new challenge methods can have non-empty JSON bodies if there is need for that. I would expect most challenges for keys-as-identifiers (if that gets done) to have such nontrivial bodies. But I would expect most of those to be more about proof-of-possession than attestation. > 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 internal components are encoded regardless, as the protected header is JSON, which can not represent binary data directly. And different forms of signatures in JOSE are just encodings of the same thing: It is possible to take a compact JWS and rewrite it into JSON object. The JOSE signing library I wrote has a type representing a signed JWS (independent of serialization), which has methods to output compact and JSON serializations. The code for both fits into one screenful. -Ilari _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
