[chair-hat-off] The usecase for draft-ietf-acme-profiles is clear to me: the ACME Server can advertise the different "products" that it offers, And the Client can say "I'd like to order a TLS_Server_and_TLS_Client cert please", or "I'd like to order a QWAC cert please" or "I'd like to order an S/MIME cert, please". That's like, "How was that not in the base RFC8555??".
draft-davidben-acme-profile-sets, I'm a much less clear on what it's doing and why. The minutes from 124 were a little sparse on the discussion about this draft [1], but my recollection is that the room shared my uncertainty about what this draft is trying to accomplish. The operative sentence in the draft seems to be this one: "If configured with a profile set, the ACME Client SHOULD request certificates from each profile in the profile set, creating independent, parallel orders for each." So a profile-set is a collection of profiles offered by the same ACME Server (which usually means from the same CA operator) where the ACME Server expects ... or, I guess, actually is recommending ... that clients will want one cert from each profile. I can imagine some usefulness when the CA is rolling over to a new algorithm (PQ) and you're recommending that Client get both an RSA and ML-DSA version of every cert, or if the new default cert profile is adding some crazy new OID that will cause old clients to explode. So this is a mechanism to deal with some kind of CA migration event? Does it have usefulness in steady state; like does the CA want to use profile-sets to offer "packages" like "S/MIME + TLS_Client"? But since the mechanism described in the -00 draft still requires the Client to create independent newOrders, is this really adding value there? If the client needs both a S/MIME and a TLS_Client, does it really need the ACME Server to list that as a package? Or is the underlying assumption that over the next decade, the CA landscape is going to be changing so much that CA Migration Events will be a kind of steady state? I'm with Tim Hollebeek that profile-sets feels like the kind of thing that's gonna be more complex than it looks on the surface; for example, in the PQ Migration usecase it's not just that the Client will fire the same CSR at both the "RSA" and "ML-DSA" cert profiles; it actually needs to create separate RSA and ML-DSA keys / CSRs. Or S/MIME and TLS_Client certs may have different sets of SANs (email vs domain userid). I'm not convinced that the currently-proposed mechanism -- which at its core is human-readable profile descriptions -- is rich enough to fully automate that successfully. So I'm not convinced that this draft is meaningfully solving a meaningful problem, unless there's some killer usecase for this that I'm not seeing. [1]: https://datatracker.ietf.org/doc/minutes-124-acme-202511041930/#draft-davidben-acme-profile-sets---david-benjamin On Wed, 7 Jan 2026 at 15:42, Sven A Rajala <[email protected]> wrote: > > To break the ice, what is the contention about? Sadly I missed the F2F > meeting 124 and I didn’t see any traffic on the mailing list. > > Kindly, > > Sven Rajala > > International PKI Man of Mystery > > > > M: +1 540 687 0761 > > [email protected] > > > > From: Mike Ounsworth via Datatracker <[email protected]> > Date: Wednesday, 2026 January 7 at 16:13 > To: [email protected] <[email protected]>, [email protected] > <[email protected]>, [email protected] > <[email protected]> > Subject: [Acme] Call for adoption: draft-davidben-acme-profile-sets-00 (Ends > 2026-01-21) > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > > > This message starts a acme WG Call for Adoption of: > draft-davidben-acme-profile-sets-00 > > This Working Group Call for Adoption ends on 2026-01-21 > > Chair note: > This is the last of the documents that asked for adoption at 124. > This one was also the most contentious, so instead of the usual "I support > adoption", I would like to see proponents of this draft explain what problem > they are facing in their production environments, and why this draft is the > right solution. > > > Abstract: > This document defines how an ACME Server may indicate collections of > related certificate profiles to ACME Clients. > > Please reply to this message and indicate whether or not you support adoption > of this Internet-Draft by the acme WG. Comments to explain your preference > are greatly appreciated. Please reply to all recipients of this message and > include this message in your response. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp78/__;!!BjbSd3t9V7AnTp3tuV-82YaK!yLjUmHGEjVW1wPI3RIrs-wFjAgT0SwhSnrC6jUNS7zcp_dnBziKhjEGoObf1BfTCKd_vrsBkLxkq33Hn5mw$ > [2] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/__;!!BjbSd3t9V7AnTp3tuV-82YaK!yLjUmHGEjVW1wPI3RIrs-wFjAgT0SwhSnrC6jUNS7zcp_dnBziKhjEGoObf1BfTCKd_vrsBkLxkqKrhPGZ4$ > [3] > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701/__;!!BjbSd3t9V7AnTp3tuV-82YaK!yLjUmHGEjVW1wPI3RIrs-wFjAgT0SwhSnrC6jUNS7zcp_dnBziKhjEGoObf1BfTCKd_vrsBkLxkq9sTZf6E$ > > The IETF datatracker status page for this Internet-Draft is: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-davidben-acme-profile-sets/__;!!BjbSd3t9V7AnTp3tuV-82YaK!yLjUmHGEjVW1wPI3RIrs-wFjAgT0SwhSnrC6jUNS7zcp_dnBziKhjEGoObf1BfTCKd_vrsBkLxkqW50-2Gw$ > > There is also an HTML version available at: > https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-davidben-acme-profile-sets-00.html__;!!BjbSd3t9V7AnTp3tuV-82YaK!yLjUmHGEjVW1wPI3RIrs-wFjAgT0SwhSnrC6jUNS7zcp_dnBziKhjEGoObf1BfTCKd_vrsBkLxkqqgSwOX4$ > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
