Hi Michael, Thanks for taking a look and appreciate the feedback, few responses inline:
> On Jul 9, 2025, at 7:02 PM, Michael Richardson <[email protected]> wrote: > > > Chris Wendt <[email protected] <mailto:[email protected]>> wrote: >> We did a few more detailed updates to this draft to include specific >> examples. We also would like to get specific feedback from the ACME >> experts on the use of multiple challenges to address multiple >> certificate extensions. > > My reading of the ACME RFC is that as understood today, the client gets to > pick which of many challenges it satisfies. That the *challenge* establishes > authority by the client/requester over a specific name. I've found people to > speak at cross-purposes, thinking there is understanding when there isn't. > I think that there are other ways to construct this, but I can't tell what > path you've gone done yet. > > If you want multiple challenges satisfied, then the construction is different > than what many imagine it would be. Reading your document, I see that you > have a new identitifer, the JWTClaimConstraints. Does this go into the SAN? Both TNAuthList and JWTClaimConstraints are separate certificate extensions for different but related purposes, but the authority token used to validate a challenge comes from in many cases different authoritative parties (e.g. telephone number vs Rich Call Data about the entity that is assigned that number). So, if there is a certificate requested with both extensions, we want there to be corresponding challenges to allow the CA to validate the information in each extension separately. So, we just want to validate whether having multiple challenges corresponding to the validation of different extensions is a proper use of the challenge mechanism as defined. > > I haven't read your document in great detail yet. > I didn't see anything about what the resulting certificate is supposed to > look like. In general, I think ACME reviewers will need some ColesNotes on > 8226, 9118, 8225 and 8224. Introduction paragraph two is a pretty dense set > of references. > I'm not sure which document to start with :-) RFC8226 is really the core spec that defines both TNAuthList and JWTClaimConstraint certificate extensions In any case, I do take your point and will definitely try to make sure the context is able to be understood by the reader to focus on 8226 in terms of the core extensions we are trying to support. > > I think that the pointer to 9060 should be earlier. ("Don't bury the lead", > which Deb repeats to me regularly, to great effect) > I think that the WHOLE POINT of this effort might be to mint these delegation > certificates? Yes and no, delegate certificates/RFC9060 may likely in practice will be the certificates that end up utilizing TNAuthList + JWTClaimConstraints, but technically that is not strictly true and can be generic to all RFC8226 certificates. > > >> -Chris > >> A new version of Internet-Draft >> draft-wendt-acme-authority-token-jwtclaimcon-03.txt has been >> successfully submitted by Chris Wendt and posted to the IETF >> repository. > >> Name: draft-wendt-acme-authority-token-jwtclaimcon Revision: 03 Title: >> JWTClaimConstraints profile of ACME Authority Token Date: 2025-07-07 >> Group: Individual Submission Pages: 21 URL: >> https://www.ietf.org/archive/id/draft-wendt-acme-authority-token-jwtclaimcon-03.txt >> Status: >> https://datatracker.ietf.org/doc/draft-wendt-acme-authority-token-jwtclaimcon/ >> HTMLized: >> https://datatracker.ietf.org/doc/html/draft-wendt-acme-authority-token-jwtclaimcon >> Diff: >> https://author-tools.ietf.org/iddiff?url2=draft-wendt-acme-authority-token-jwtclaimcon-03 > >> Abstract: > >> This document defines an authority token profile for handling the >> validation of JWTClaimConstraints and EnhancedJWTClaimConstraints. >> This profile follows the model established in Authority Token for the >> validation of TNAuthList but is specifically tailored for the >> JWTClaimConstraints certificate extensions. The profile enables >> validation and challenge processes necessary to support certificates >> containing both TNAuthList and JWTClaimConstraints, particularly in the >> context of Secure Telephone Identity (STI). > > >>> On Jun 13, 2025, at 8:01 AM, Chris Wendt <[email protected] >>> <mailto:[email protected]>> >>> wrote: >>> >>> Hi ACME WG, >>> >>> We have updated the draft related to stir use of authority token >>> specific to JWTClaimConstraints in ACME. I presented this at the last >>> ACME IETF122 meeting and got some support, but also presented it at >>> the STIR WG meeting and got good support there and will continue to >>> keep the experts in the STIR wg in the loop of this document. >>> >>> I would like to ask the working group to consider WG adoption. Like I >>> mentioned, I think this is a straight forward profile document that is >>> likely mostly complete for authority token and follows the same >>> pattern as TNAuthList for the other RFC8226 defined certificate >>> extension JWTClaimConstraints. >>> >>> Chairs, would appreciate your support for asking for Working Group >>> adoption. >>> >>> Thanks! >>> >>> -Chris >>> >>>> Begin forwarded message: >>>> >>>> From: [email protected] Subject: New Version Notification for >>>> draft-wendt-acme-authority-token-jwtclaimcon-01.txt Date: June 13, >>>> 2025 at 8:38:08 AM EDT To: "Chris Wendt" <[email protected]>, >>>> "David Hancock" <[email protected]> >>>> >>>> A new version of Internet-Draft >>>> draft-wendt-acme-authority-token-jwtclaimcon-01.txt has been >>>> successfully submitted by Chris Wendt and posted to the IETF >>>> repository. >>>> >>>> Name: draft-wendt-acme-authority-token-jwtclaimcon Revision: 01 >>>> Title: JWTClaimConstraints profile of ACME Authority Token Date: >>>> 2025-06-13 Group: Individual Submission Pages: 16 URL: >>>> https://www.ietf.org/archive/id/draft-wendt-acme-authority-token-jwtclaimcon-01.txt >>>> Status: >>>> https://datatracker.ietf.org/doc/draft-wendt-acme-authority-token-jwtclaimcon/ >>>> HTMLized: >>>> https://datatracker.ietf.org/doc/html/draft-wendt-acme-authority-token-jwtclaimcon >>>> Diff: >>>> https://author-tools.ietf.org/iddiff?url2=draft-wendt-acme-authority-token-jwtclaimcon-01 >>>> >>>> Abstract: >>>> >>>> This document defines an authority token profile for handling the >>>> validation of JWTClaimConstraints and EnhancedJWTClaimConstraints. >>>> This profile follows the model established in Authority Token for the >>>> validation of TNAuthList but is specifically tailored for the >>>> JWTClaimConstraints certificate extensions. The profile enables >>>> validation and challenge processes necessary to support certificates >>>> containing both TNAuthList and JWTClaimConstraints, particularly in >>>> the context of Secure Telephone Identity (STI). >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>>> >>> >>> _______________________________________________ Acme mailing list -- >>> [email protected] To unsubscribe send an email to [email protected] > > >> ---------------------------------------------------- >> Alternatives: > >> ---------------------------------------------------- >> _______________________________________________ Acme mailing list -- >> [email protected] <mailto:[email protected]> To unsubscribe send an email to >> [email protected] <mailto:[email protected]> > > -- > Michael Richardson <[email protected] <mailto:[email protected]>> . > o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
