On Thu, Jan 8, 2026 at 12:12 PM Michael Richardson <[email protected]> wrote:
> > David Benjamin <[email protected]> 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. >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
