Jeremy, > 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.
Does the following Verified erratum already address this concern? https://www.rfc-editor.org/errata/eid5729 ________________________________ From: ilariliusva...@welho.com <ilariliusva...@welho.com> on behalf of Ilari Liusvaara <ilariliusva...@welho.com> Sent: 15 November 2024 10:20 To: acme@ietf.org <acme@ietf.org> Subject: [Acme] Re: RFC 8555 challenge response proposal On Mon, Nov 11, 2024 at 05: 07: 58PM -0500, Jeremy Hahn wrote: > 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 On Mon, Nov 11, 2024 at 05:07:58PM -0500, Jeremy Hahn wrote: > 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? I guess the text is just unclear and means that for the challenges defined in the RFC, payload is empty. Not that all future challenges MUST have empty payload. At least acme-onion has a challenge with non-empty payload. > 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. ACME uses Flattened JWS JSON Serialization Syntax, defined in section 7.2.2. of RFC 7515 (JWS). It is possible to take the "usual" JWS Compact Serialization, and turn it into Flattened JWS JSON Serialization (split the input to its parts and write the parts as field values). -Ilari _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
