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

[Mike Ounsworth <[e-mail]>]

[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.

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.

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.

I did not read the appendices.


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?


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?

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}}"..

2c. You have If "x5u" ... Else if "x5c". I think you need an Else
(neither): fail.

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.


§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.



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?


You could consider adding a glossary, but not necessary.


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."


§ 5.1 -- you might put a note that this section contains the data model,
while the validation rules follow in §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.


§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)?


§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".

"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?


§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.


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).


§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.



§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.

I love the reference to [RFC6943]. That's great.


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]
>