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

[Russ Housley <[e-mail]>]

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]