[Acme] Re: Call for adoption: draft-davidben-acme-profile-sets-00 (Ends 2026-01-21)

[David Benjamin <[e-mail]>]

On Thu, Jan 8, 2026 at 12:12 PM Michael Richardson <[e-mail]>
wrote:

>
> David Benjamin <davidben=[e-mail]> wrote:
>     > For folks who missed it, I talked a bit about the motivation in both
> the
>     > draft and 124, so here are the links to what happened in 124. This
> is a
>     > pretty tiny mechanism, so there's not a lot to skim through there:
>     >
> https://datatracker.ietf.org/meeting/124/materials/slides-124-acme-acme-profile-sets-00
>
> I looked again at the slides.
> The motivation is good.  I think some of the context is wrong,... like if
> "Old Clients" live forever, then they aren't going to get new certificates.
>
> Maybe you don't mean old ACME clients, but old TLS clients?
> (PS: they also don't do TLS 1.3, often not TLS 1.1.  Try connecting to a
> 2010-era BMC.)
>

Er, yes, sorry, those were referring to older TLS clients, or whoever the
relying party was. Those slides were presented in the context of how to run
a TLS server, but it did make the slides harder to read without the voice
track. :-(

I can't fix the slides after the fact, but if you prepend "Running a TLS
server is easy, right?" to the first slide, I think it then flows. (And of
course there's an analogous situation for any authenticating/relying party
pair when there's a wide range of relying parties. The draft itself is
hopefully written with more precise and general language.)


> I don't think ACME Profile Sets completely solves the problem described in
> the slides.   We need more.  Maybe a connection to RFC9908 (just issued,
> but
> not announced yet.. weird)... a CSR/CSR-attributes redo in JSON/JOSE/COSE
> could be part of an RFC7030bis.  Worth further discussion, I hope.
>

The aim is to specifically solve the case where the subject information in
all the variants is the same, as that seems to be where this kind of
automation most naturally fits. It's true there are a bunch of other, more
complex, cases where folks might need multiple certificates. Those seem
hard to automate because they require the ACME client to have knowledge of
the variations, but happy to be proven wrong. :-)

Not to say those aren't also interesting problems, but this subset seems
both useful, fairly easily achievable, and fit within a clear "subject
decisions vs PKI decisions" model, so that seemed a good place to draw a
box.


>     > But older relying parties still have the old behavior, and ACME
> clients
>
> Yes, older relying, or corresponding parties.
>