Re whether to make a separate document or just a section in MTC, I guess that depends on the size of the change. (And what folks want.) If we end up with a design something like the current section, I suspect a separate document is just a ton of busywork, and we can just squirrel it away into the MTC draft. If we decide something substantial is needed, maybe it's worth looking at a separate document. But let's sort out the right design first. :-)
I'd certainly lean towards smaller changes over big ones. That seems generally easier for folks to adopt. There seems to be a pretty good analogy to the existing alternate chains thing. The server MAY provide one or more link relation header fields [RFC8288] with relation "alternate". Each such field SHOULD express an alternative certificate chain starting with the same end-entity certificate. This can be used to express paths to various trust anchors. Clients can fetch these alternates and use their own heuristics to decide which is optimal. Different paths to the same leaf certificate are acceptable to different relying parties, depending on what they trust, but ultimately describe the same issuance event. Similarly, standalone and landmark certificates ultimately describe the same issuance event (thus one order), but different relying parties will accept different of these. And then the trust anchor IDs machinery replaces the heuristics with something well-defined. The only new thing is that one alternate takes some time to become available, hence the Retry-After idea. (Not necessarily the only or best way to spell this, but that was some of the thinking behind this particular idea. Aaron posted a more complete list of other options. This one feels the most natural to me.) David On Fri, Mar 13, 2026 at 2:11 PM Michael Richardson <[email protected]> wrote: > > Mike Ounsworth <[email protected]> wrote: > > Thanks for the discussion. Stepping back a bit, I think there are two > > possible outcomes of the interaction between MTC and ACME: either a > > draft-mtc-acme-00 is needed, or it's not. Given that this still seems > > Yes, we need a document to collect options/discussion. > (Ask me in 12-ish days if I want to volunteer to start it) > > > in the "Large design space, needs to be narrowed down" stage, and > that the > > right experts already seem to be engaged, I'm inclined to not put > this on > > the ACME agenda this go-around but please keep discussion on the > list. Is > > that reasonable? > > I think that's exactly the right thing right now. > > 1. Sometime in early May, decide if a (joint) virtual-interim meeting > would help. > 2. Make sure IETF126's conflict lists ACME<->PLANTS<->LAMPS as conflicts. > 3. EST will need to solve the same problem. It may be similiar, or > completely different. > > I think David wrote: > >> Then the server operator would glue it all together by arranging > for the > >> ACME client to run on a cron job. And since that cron job both has > access > >> to authentication and ACME state, the fact that ACME authenticates > all its > >> URLs is not a huge deal. A separate unauthenticated URL would > suggest a > >> world where the server operator has a *separate* scheduled job > that's > >> have the ACME account key, but does have read/write access to > certificate > >> state. I assumed that doesn't currently exist and we may as well > piggy-back > >> off the existing job schedulingn. > > My understanding is that some operators of many tenanted web-hosting > systems > run their ACME client on a management system. This discussion previously > informed the design of the renewal-info (RFC9773). > > -- > Michael Richardson <[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] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
