[Acme] Re: WG Last Call: draft-ietf-acme-authority-token-jwtclaimcon-03 (Ends 2026-07-25)

[Mike Ounsworth <[e-mail]>]

Hi Chris,

-06 looks good to me. Thanks for working through my (rather large) review!

I will advance this past WGLC.

On Mon, 7 Sept 2026 at 13:44, Chris Wendt <[e-mail]> wrote:

>
> Darn :)
>
> Submitted -06 to fix it in two places actually.  the step 2 fix you
> suggested and in Section 7 there was a similar certificate mis-reference i
> fixed as well.
>
> Thanks Russ.
>
>
> On Sep 6, 2026, at 1:02 PM, Russ Housley <[e-mail]> wrote:
>
> Chris:
>
> The document says: he Authority Token MUST be signed by a certificate...
>
> Private keys are used to sign objects.  The public key in a certificate is
> used to validate a signature on an object.
>
> Please reword.
>
> Russ
>
>
> On Sep 5, 2026, at 8:14 AM, Chris Wendt <[e-mail]> wrote:
>
> Hi Mike,
>
> Thank you very much for the very comprehensive review.  I’ve created a new
> -05 and corresponding responses inline:
>
> On Sep 2, 2026, at 2:19 PM, Mike Ounsworth <[e-mail]>
> wrote:
>
> [Chair hat on]
> Russ gave a WGLC review from a STIR perspective, and that's great.
> I have been waiting for someone to provide a technical review of the
> implementability from an ACME Client / ACME Server perspective. Since
> nobody has, and it is high-time that we advance this document, I have done
> a review myself. Please take this as you would any other WGLC comments. If
> you feel that these comments do not need to be acted on, then ok.
>
>
> [Chair hat off]
>
>
> GENERAL:
>
> I find the intro is well-written and nicely frames what parts of this
> document are ACME and what are STIR. Well done.
>
> I find that the ACME json payloads are well specified.
>
>
> [cw] Thanks!
>
>
> I find that the target audience of the document is unclear, which makes it
> a bit hard to read because I'm never sure which sections would apply to an
> implementer of an ACME Client / Server, or to an implementer of a Token
> Authority, or both. As an ACME WG document, I expect that the target
> audience is limited to implementers of ACME Clients and Servers, but then
> you do things like explain the token structure in great detail, and then
> say "But ACME Clients and Servers MUST treat this as an opaque byte string,
> MUST NOT parse it, and MUST perform an octet-by-octet match against
> new-order". Ok, so then what was the point of explaining the structure? I
> found that this (apparent) excess of information made the document
> confusing to read from the perspective of an ACME implementer.
> I suggest that the target audience be clearly stated, and the document
> reviewed to remove content not relevant to that audience.
>
>
> [cw] Agreed the document never said who each part is for. -05 adds a
> paragraph at the end of the Introduction. The normative requirements are
> for ACME client and server implementers (the identifier type, the challenge
> and token exchange, the token structure, and the Section 6 validation
> rules), and to the ACME client and server the JWTClaimConstraints value is
> an opaque octet string, transported, compared octet-by-octet, and never
> parsed.
> The paragraph marks the internal structure of that value (Section 5.4, the
> appendix) as informative background for Token Authority implementers. That
> material is in the document because Russ asked for it from the STIR side;
> the audience paragraph is there so an ACME implementer can skip it. I kept
> it for that reason rather than cutting it.
>
>
> Section 6 is the actual good stuff: those are the rules for correctly
> implementing an ACME Server. Really, this and the JSON blobs are the only
> normative parts of the document. The whole security model of the document
> rests on Section 6, so I took a detailed pass and am pointing out a number
> of places that these rules could use tightening up.
>
>
> [cw] Agreed, and that's where most of the -05 changes are.
>
>
> I did not read the appendices.
>
>
> [cw] For reference, the appendix examples were corrected in -04 following
> Russ's review (the ASN.1 encodings had bugs); no ACME-implementer content
> there.
>
>
> ISSUES:
>
>
> §6
>
> Error handling: you say at the bottom of this section:
> "If any step of the validation process fails, the "status" in the
> challenge object MUST be set to "invalid".
> And I guess that does specify error handling, but it feels incomplete. Is
> the Server supposed to communicate anything back to the Client (if so,
> which error code?), or fail silently? Is it communicating the same thing
> for all 7 types of failures, or do you want to specify more specific error
> codes? Is the client supposed to take any action(s) based on these error
> codes?
>
>
> [cw] -05 changes the failure sentence. The server sets status to "invalid"
> and SHOULD include an "error" field with an ACME problem document (RFC 8555
> Section 6.7), unauthorized being the generally-appropriate type, and the
> client handles the failed authorization per RFC 8555. I did not give each
> of the seven failures its own code; they all reduce to "this token does not
> authorize this order."
>
>
>
> 2a. I expected this to say that if a "token-authority" was included in the
> challenge, then this MUST also match". ... otherwise what's the point of
> the "token-authority"? The fact that "token-authority" is not mentioned
> anywhere in §6 is a bit confusing. What's it for then?
>
>
> [cw] "token-authority" (Section 4) is the optional URL the ACME server
> points the client at to fetch the token. It's a client-side hint used
> during token acquisition, not a validation input. In practice the returned
> token is signed by a certificate whose root corresponds to that
> token-authority, so the acquisition URL and the trust anchor line up, and
> §6 establishes trust through that issuer certificate in x5u/x5c (step 2)
> rather than by matching token-authority, which is why 9447 left the
> parameter optional.
>
>
> 2b. I think "trusted issuer" is carrying a lot of weight in this sentence,
> and that should be made explicit. I think it's implied that the ACME Server
> needs to be pre-configured with some trust relationship to that Token
> Authority (name, pub key, root of the x5c chain, something). I think that
> should be called out explicitly here. Also, presumably not just any random
> X.509 cert will do; presumably the signer of the Authority Token needs to
> have all the right EKUs, extensions, whatever to actually be a valid Token
> Authority. Presumably the ACME server needs to check this, or the whole
> security model falls apart? I suggest a sentence of the form "This
> certificate needs to represent a valid Token Authority as per {{Section Y
> of RFCXXXX}}"..
>
>
> [cw]  Agreed. RFC 9447 assumes a preexisting CA<–>Token Authority trust
> relationship and specifies no mechanism; RFC 9448 uses the same "trusted
> issuer for the ecosystem" wording. -05 rewrites step 2: the token MUST be
> signed by a certificate the ACME server is configured to trust as an
> Authority Token issuer for the ecosystem, with the trust anchors and any
> certificate requirements coming from the deploying ecosystem (STIR
> governance), out of scope here.
>
> On the EKU: I think it's a reasonable suggestion, however it doesn't
> belong in this profile alone. Every Authority Token profile, TNAuthList
> (RFC 9448), this one, and future ones, sign tokens with a Token Authority
> certificate, so defining it here would only cover JWTClaimConstraints only
> and diverge from deployed 9448.  We can consider it as an extension to 9447
> perhaps in the future, but would prefer to not force it here.
>
>
> 2c. You have If "x5u" ... Else if "x5c". I think you need an Else
> (neither): fail.
>
>
> [cw] Fixed. Step 2 now fails if neither is present or the certificate is
> not trusted.
>
>
> 6. "(e.g., verify that the token has not expired using the "exp" claim)"
> Remember that section 5 is only the data model and contains no validation
> rules, so I'm not comfortable with a security check that this document's
> whole security model hing on being specified as a "do all the things, you
> know what they are". I think that all of the checks that the ACME Server
> MUST do need to be laid out explicitly here.
>
> This is the first time in the document that you are mentioning that the
> ACME Server needs to check the "exp" claim against its local system clock.
> Is there extra specification required here, like ensuring that the ACME
> server has an accurate clock, or accounting for clock skew? That seems like
> a pretty important thing to be introducing for the first time in a
> non-normative "e.g." block.
>
> What else is covered by that "e.g."? Those need to be listed out
> explicitly, with concrete verification rules.
>
>
> [cw]  Agreed the "e.g." was too loose for a security-critical check. -05
> makes it more explicit, verify exp is present and not expired against the
> server's current time, MAY allow small clock skew per local policy, verify
> jti is present, and fail on absent/expired exp or absent jti. Those are the
> only "remaining claims" in the profile.
>
>
>
> §7 If I'm understanding this correctly, then in might be worth adding "The
> CA MUST ensure that this x5u URL remains live until the expiry of the
> certificate". I'm not a great expert in the JWT x5u claim, but if there are
> any other requirements in order for the JWT parser to be able to use that
> x5c successfully, then those might be worth dragging in here too.
>
>
>
> [cw] Added, as a SHOULD, the CA SHOULD keep the URL retrievable as long as
> relying parties may need it, at least until the certificate expires.
>
>
> NITS:
>
> Section 1:
>
> "This profile facilitates proper delegation and authorization for entities
> requesting certificates under ACME and similar frameworks."
> This is maybe more of a curiosity question, but what is mean by "... and
> similar frameworks"? Are there other (non-ACME) protocols that you expect
> to normatively reference this draft?
>
>
> [cw]  Removed. "and similar frameworks" the intent was that US STIR
> implementations don't have a MUST to support ACME, but they do rely on
> Authority Tokens even when certificates are issued by alternative protocols
> or methods, so "and similar frameworks" was acknowledging that the
> Authority Token authorization defined here can be used outside ACME. This
> document only specifies the ACME profile, so those cases are out of scope
> for it, which is why I removed the phrase. Separately, other STIR documents
> such as Vesper will normatively reference this one and consume the
> authorization it defines.
>
>
> You could consider adding a glossary, but not necessary.
>
>
> [cw] skipped for now
>
>
> Section 4:
> "If the "token-authority" parameter is not present, the ACME client MUST
> identify the Token Authority based on locally configured information or
> local policies."
> I'm not sure that MUST is doing anything. As a test, if you deleted that
> sentence and left it unspecified, would anything change in terms of interop?
> Maybe instead:
> "If the "token-authority" parameter is not present, then this assumes that
> the ACME client has been configured out-of-band with this information."
>
>
> [cw] Reworded to your version and dropped the MUST. Also added a sentence
> that the parameter is advisory to the client and the server doesn't use it
> (the 2a point).
>
>
> § 5.1 -- you might put a note that this section contains the data model,
> while the validation rules follow in §6.
>
>
> [cw] Added — Section 5 is the data model, validation is Section 6.
>
>
> §5.5:
> "a base64url-encoded DER representation of a JWTClaimConstraints or
> EnhancedJWTClaimConstraints ASN.1 object as defined in [RFC8226] and
> [RFC9118]. From the ACME server's perspective this value is opaque:
> validation step 5 in Section 6 requires only that the value in the token is
> octet-by-octet identical to the value in the order. The semantic content of
> the extension — which claims are permitted or excluded, and for which
> telephone numbers — is a STIR ecosystem concern governed by [RFC8226] and
> [RFC9118], and is validated by the Token Authority prior to token issuance
> (see Section 5.3). In particular, the ACME server does not parse or
> cross-check the JWTClaimConstraints and TNAuthList extensions for mutual
> consistency:"
>
> This paragraph is basically the core of the draft. This parahraph could be
> way higher up, like this paragraph could be almost the entirety of the
> Intro.
>
>
> [cw] Took the core of it into the Introduction (the audience paragraph
> with opaque octet string, octet-by-octet, never parsed). Left the fuller
> version in 5.5 where the TNAuthList interaction should have it.
>
>
> §5.4 defines quite nicely what is meant by "a subset of its own
> authority". I was expecting that section to end with the rules for
> determining when a set of {mustInclude, permittedValues, mustExclude} are a
> subset of another, so that the ACME server can enforce that. But instead I
> found:
> "The ACME server then compares the token value to the new-order identifier
> value octet-by-octet (Section 6, step 5) and does not parse or interpret
> the ASN.1 content."
> So then, what's the point of including this detail in this ACME document
> if neither the ACME Client or Server needs to process it (and, in fact is
> forbidden from doing so)?
>
>
> [cw] Same answer as the target-audience point, it's there for the Token
> Authority implementer and based on Russ's review, and the audience
> paragraph now says the ACME server doesn't process it. Kept, labeled
> informative.
>
>
> §5.5
> "The ACME new-order request may include multiple identifiers"
> "a certificate order may require two Authority Token identifier types"
> "Other Authority Token types may be introduced in future Authority Token
> profile specifications"
> I suggest either "MAY" or "can".
>
>
> [cw] Changed the three lowercase "may"s to "can".
>
>
> "The TNAuthList Authority Token authorizes the token holder to obtain
> certificates containing a TNAuthList extension whose scope is less than or
> equal to the scope of the TNAuthList identifier in the token."
> Almost a curiosity question, but is checking and enforcing that the job of
> the Token Authority, or the ACME Server? That sortof goes back to my
> confusion about why §5.4 contains so much detail to then end with
> "octet-by-octet match against the new-order". If this is out-of-scope for
> ACME Clients and Servers, then maybe you could remove this without
> materially changing the document?
>
>
> [cw] It's the Token Authority's job, not the ACME server's meant to be
> informative context. The audience note now frames it that way, so I left it
> in.
>
>
> §5.5.1 -- example of a new-order with both a "TNAuthList" and a
> "JWTClaimConstraints". But can you have more than one of each? Is that
> specifically forbidden somewhere in this doc? Is that forbidden by RFC8555?
> That's probably worth mentioning either way.
>
>
> [cw] -05 adds that a new-order request contains at most one
> JWTClaimConstraints identifier and at most one TNAuthList identifier.
>
>
> 7. "matches the account key of the client"
> Just to be super clear, I could say "ACME account key as defined in
> {{Section 8.2 of RFC8555}}". I honestly got this far in the document
> thinking that this was a fingerprint that needed to match the CSR (though,
> going back, I see that §5.1.4 was clear about this, I just skimmed over it).
>
>
> [cw] Added a reference to the ACME account key in RFC 8555. One note:
> Section 8.2 is "Retrying Challenges”, the account key is the account object
> (Section 7.1.2). I referenced 8555 generally.
>
>
> §6
> "Steps 1 through 3 and steps 6 through 8 are general ACME authority token
> validation steps applicable to any Authority Token profile."
> Just to be clear, that applicable to any STIR Authority Token profile,
> still not generic ACME behaviour? I would throw the word STIR or something
> into that sentence.
>
>
> [cw] Changed to "any STIR Authority Token profile," and noted it mirrors
> the TNAuthList validation in RFC 9448.
>
>
>
> §8
> "The creation, transport, and any storage of this token MUST follow the
> strictest of security best practices"
> That is a completely empty MUST in that it doesn't tell me anything
> actionable as an implementer. Like, a MUST should generally be something
> that I could write tests for and easily check if an implementation is in
> compliance or not. Do you have a BCP or RFC that you can point at? "MUST
> ... best practices according to [Thing]"? If not, I would remove the
> normative MUST from this sentence.
>
>
> [cw] Reworded. Dropped "strictest of security best practices," pointed at
> RFC 8725 (JWT BCP) and the RFC 9447 security considerations, and kept the
> MUST only on the encrypted transport already required by the document.
>
>
> I love the reference to [RFC6943]. That's great.
>
>
> [cw] Thanks!
>
>
>
> On Wed, 2 Sept 2026 at 07:49, Chris Wendt <[e-mail]> wrote:
>
>> Hi ACME chairs,
>>
>> Just wanted to check in to see if we have satisfied the WG Last Call
>> review and can proceed forward?
>>
>> Thanks!
>>
>> -Chris
>>
>> On Jul 26, 2026, at 3:20 AM, Russ Housley <[e-mail]> wrote:
>>
>> My comments are resolved.
>>
>> Russ
>>
>> On Jul 25, 2026, at 10:13 AM, Chris Wendt <[e-mail]> wrote:
>>
>> Hi all,
>>
>> I've posted -04.
>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-jwtclaimcon-04
>>
>> Summary of the changes:
>>
>> Addressing Russ Housley's review of Section 5.4:
>>
>> Expanded "Scope of the JWTClaimConstraints" to describe the constraint
>> components
>>
>> - mustInclude (claim names that MUST be present)
>> - permittedValues (the values a given claim is permitted to take)
>> - mustExclude (claim names that MUST NOT appear, available only in
>> EnhancedJWTClaimConstraints per RFC 9118)
>>
>> and noted that the enhanced form with mustExclude is only needed when the
>> optional ("extended") claims must be constrained.
>>
>> Based on my discussion with Russ I also made the sure the model is
>> explicit that the Token Authority validates the requested
>> JWTClaimConstraints value against what the requester is authorized to
>> include, explicitly equal or a subset of that (not a superset) and places
>> that validated ASN.1 value in the token. Then it’s clear that the ACME
>> server then only compares the token value to the new-order identifier
>> octet-by-octet and never need to evaluate or parse the ASN.1.
>>
>> Two bonus updates:
>>
>> Example 3: added a clearer description of constraining the "orig" claim
>> to a specific set of telephone numbers, along with a note in Section 5.5 on
>> why the CA does not need to cross-check the JWTClaimConstraints against the
>> TNAuthList: an inconsistent pair simply fails PASSporT verification for all
>> calls, so authority and accountability stay with the CSR requester to make
>> sure they apply both Authority Tokens correctly as a pair.
>>
>> I rechecked and fixed the appendix example values to conform to the RFC
>> 9118 ASN.1: mustExclude values are now wrapped in the required SEQUENCE,
>> and permittedValues entries covering more than one claim are now encoded as
>> one JWTClaimValues per claim.
>> The DER hex, base64url, and byte counts were regenerated based on that.
>>
>> Comments welcome, but hopefully that satisfies the WGLC end date today.
>>
>> Thanks and good to see everyone this past week.
>>
>> -Chris
>>
>> On Jul 23, 2026, at 10:11 AM, Chris Wendt <[e-mail]> wrote:
>>
>> Thanks Russ for the review.
>>
>> I agree with that comment and will address it.
>>
>> -Chris
>>
>> On Jul 23, 2026, at 2:52 PM, Russ Housley <[e-mail]> wrote:
>>
>> I have read the document, and I support publication, but I think a
>> shortcoming needs to be addressed before it is passed to the IESG.
>>
>> Section 5.4 says:
>>
>> Because this specification involves the JWTClaimConstraints and
>> EnhancedJWTClaimConstraints extensions, the client MAY request an Authority
>> Token with some subset of its own authority as the JWTClaimConstraints
>> provided in the "tkvalue" element of the "atc" JSON object.
>> JWTClaimConstraints can be constructed to define a limited scope of claims
>> and claim values the client has authority over.
>>
>>
>> This is correct, but I think a few more details are needed.
>>
>> JWTClaimConstraints specifies claim names that must be included
>> (mustInclude) and it specifies values that are allowed in particular claims
>> (permittedValues). All of the mustInclude need to be in the token.  Each
>> value in the token need to be in the pmittedValues. In this way, the token
>> satisfies the constraints, and a particular certificate can be issued that
>> is a subset of those authorizations.
>>
>> The structure for EnhancedJWTClaimConstraints is a bit more complex.  It
>> also has claim names that MUST NOT appear (mustExclude). I would expect all
>> of these to be in the token.
>>
>> Russ
>>
>> On Jul 2, 2026, at 6:03 PM, Mike Ounsworth via Datatracker <
>> [e-mail]> wrote:
>>
>> This message starts a WG Last Call for:
>> draft-ietf-acme-authority-token-jwtclaimcon-03
>>
>> This Working Group Last Call ends on 2026-07-25
>>
>> 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.
>>
>> File can be retrieved from:
>>
>> https://www.ietf.org/archive/id/draft-ietf-acme-authority-token-jwtclaimcon-03.txt
>>
>> Please review and indicate your support or objection to proceed with the
>> publication of this document by replying to this email keeping
>> [e-mail]
>> in copy. Objections should be explained and suggestions to resolve them
>> are
>> highly appreciated.
>>
>> Authors, and WG participants in general, are reminded of the Intellectual
>> Property Rights (IPR) disclosure obligations described in BCP 79 [1].
>> Appropriate IPR disclosures required for full conformance with the
>> provisions
>> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
>> Sanctions available for application to violators of IETF IPR Policy can be
>> found at [3].
>>
>> Thank you.
>>
>> [1] https://datatracker.ietf.org/doc/bcp78/
>> [2] https://datatracker.ietf.org/doc/bcp79/
>> [3] https://datatracker.ietf.org/doc/rfc6701/
>>
>> 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-03
>>
>> A diff from the previous version is available at:
>>
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-acme-authority-token-jwtclaimcon-03
>>
>> _______________________________________________
>> Acme mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>>
>>
>> _______________________________________________
>> Acme mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>>
>>
>> _______________________________________________
>> Acme mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> Acme mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>