Thanks Chris and David, Those sound like great changes that will help this document pass through ACME WG review!
This comment caught my eye: > the server only needs to verify that the value in the token matches the value in the order. I'm assuming that's referring to Section 6, Step 5? "Verify Constraints Match: Verify that the "atc" claim "tkvalue" identifier contains the equivalent base64url encoded JWTClaimConstraints or EnhancedJWTClaimConstraints certificate extension string value as the Identifier specified in the original challenge." ? I've been recently re-familiarized with RFC6943 which details all the ways that CVEs hide in the gaps of under-specified equality checking procedures for identifiers, so I want to poke at whether "equivalent base64url ... string value" is tightly-specified enough to prevent a ... umm ... clever implementer from "clever'ing" themselves into a vulnerability, or if the equality check algorithm could be spelled out more explicitly? When talking about comparing two identifiers, I generally expect to see some variant of the text: "Do blah blah to put both identifiers into their canonical form, then perform a byte-by-byte comparison". On Thu, 26 Mar 2026 at 07:48, Chris Wendt <chris= [email protected]> wrote: > Hi ACME WG, > > We were unfortunately unable to attend IETF 125 and wanted to follow up on > list with an update to the document following the discussion at IETF 124 > and subsequent editorial review. > > The updated draft addresses the feedback from the meeting, particularly > Aaron's observation that the ACME wire protocol sections are clear but the > validation description was difficult to review without STIR ecosystem > background. The changes are summarized below. > > Substantive changes: > > The Introduction now includes a short paragraph orienting ACME reviewers > to the STI ecosystem context — noting that this document follows the same > pattern as the TNAuthList profile (RFC 9448) and that the Token Authority > is responsible for the domain-specific semantic validation of > JWTClaimConstraints content governed by RFC 8226 and RFC 9118. > > Section 6 now includes a framing note that explicitly identifies which > validation steps are generic ACME authority token steps and which two steps > are specific to this profile. This should allow ACME reviewers to scope > their review without needing deep familiarity with the STIR certificate > extensions. > > The ASN.1 examples of JWTClaimConstraints structures that were previously > in the normative body of Section 5.5 have been moved to an informative > Appendix A. Section 5.5 now includes a brief paragraph clarifying that the > identifier value is opaque from the ACME server's perspective — the server > only needs to verify that the value in the token matches the value in the > order. The appendix retains the full ASN.1 examples including DER encodings > and base64url values for STI Token Authority and certificate requestor > implementers. > > Editorial changes: > > Fixed broken normative references in the Introduction, corrected a JSON > syntax error in the authorization object example, normalized JSON/JWT > indentation and colon spacing consistently across all code blocks, fixed > the challenge response URL in the protected header example, and added > clarifying notes around the Token Authority account identifier and the flow > back to the ACME challenge URL after token acquisition. > > We believe the document is in good shape for review. Feedback welcome on > list. > > Thanks, > Chris & David > > > > On Mar 26, 2026, at 8:45 AM, [email protected] wrote: > > > > Internet-Draft draft-ietf-acme-authority-token-jwtclaimcon-01.txt is now > > available. It is a work item of the Automated Certificate Management > > Environment (ACME) WG of the IETF. > > > > Title: JWTClaimConstraints profile of ACME Authority Token > > Authors: Chris Wendt > > David Hancock > > Name: draft-ietf-acme-authority-token-jwtclaimcon-01.txt > > Pages: 21 > > Dates: 2026-03-26 > > > > Abstract: > > > > This document defines an authority token profile for the validation > > of JWTClaimConstraints and EnhancedJWTClaimConstraints certificate > > extensions within the Automated Certificate Management Environment > > (ACME) protocol. This profile is based on the Authority Token > > framework and establishes the specific ACME identifier type, > > challenge mechanism, and token format necessary to authorize a client > > to request a certificate containing these constraints. > > > > The IETF datatracker status page for this Internet-Draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-jwtclaimcon/ > > > > There is also an HTMLized version available at: > > > https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-jwtclaimcon-01 > > > > A diff from the previous version is available at: > > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-authority-token-jwtclaimcon-01 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > Acme mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
