"If you don't have a hammer, but you do have a mallet, the mallet may also drive nails."
Short recap of how I think we got here talking about hammers and mallets.
1] I wrote in the Trust Architecture & Cert Mgmt (companion to ATIS-1000080) which included a new way to issue ALIII Authorization Tokens (AATs) which avoids using ACME.
2] Alec noted ACME's automated domain validation mechanisms are especially valuable for issuing short-lived certificates. (He also noted existing code libraries, etc, built on ACME and RFC 9448.)
3] David's contribution using SHAKEN's TNAuthList SPC Token issuance based on RFC 9448 addresses the lack of an ACME-enabled DNS domain validation automation for ALIII Authorization Token (AAT) issuance.
While I agree with the direction of David's contribution, I don't like it because it isn't a PKI best practice approach.
To avoid re-using SHAKEN's TNAuthList SPC Token, I suggested in yesterday's IP-NNI meeting that "we" take on developing the ALIII companion to RFC 9448 "TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token".
3 of the 4 authors of RFC 9448 were David Hancock, Chris Wendt, and Mary Barnes (Jon Peterson being the 4th), and even with Mary's retirement, I think we have enough resources to accomplish the task.
I agree with Richard Shockey's observation IETF does mostly profile so developing the ALIII-companion to RFC 9448 makes sense to me, but you and Richard are also convinced ALIII specifications are required by EOY 2026, so David's contribution is an attempt to hasten the specification development process by re-using the SHAKEN mallet instead of developing an ALIII hammer.
CAUTION: This email has originated outside of Numeracle. Please do not click on any links or open any attachments unless you can confirm the sender and you know the content is safe.
"If all you have is a hammer, I guess that makes everything look like a nail" Martin C Dolly AT&T Expert Member of Technical Staff ...