I've drafted another approach to the integration here: https://github.com/ietf-plants-wg/merkle-tree-certs/pull/207. Copying the pull request description:
An ACME client polls landmarkURL (which may be shared across many certificates) to determine when a landmark-relative certificate is possible. Once a landmark-relative certificate is possible, the ACME client POSTs to newRelativeCertificate (from the directory). Advantages: - No new states in the Order state machine. - No new polling semantics for certificate download URLs. - CAs do no extra work for clients that don't want relative certificates (or: clients can defer getting relative certificates until they see that traffic justifies it). - Order lifetime does not depend on landmarking period. - All HTTP requests are expected to serve 200 in the happy case. - The new field in the directory serves as a signal that the ACME server supports Merkle Tree Certificates. Disadvantages: - ACME clients will tend to rush in and request relative certificates as soon as a landmark is minted. Options: - CA returns 503 if load is too high and clients backoff and retry. - Some mechanism for clients to decide how long to wait after a landmark is minted before requesting a relative certificate. Perhaps interpolation based on size of landmarks? Keeping list context together: David Benjamin recently proposed a different approach, based on continued polling of order objects after the standalone certificate is issued: https://github.com/ietf-plants-wg/merkle-tree-certs/pull/203. This was in response to some good points about HTTP statuses made by Watson Ladd on the plants@ list: https://mailarchive.ietf.org/arch/msg/plants/_vf4hEt9g4n6CdriRrtZO5ZGwOA/ On Thu, Mar 12, 2026 at 10:53 AM David Benjamin <[email protected]> wrote: > Hi ACME folks, > > (I wasn’t sure about cross-posting etiquette, so I haven't CC'd plants@ > here. Rather, I’ll point plants@ to this thread shortly. Figure it’s > always easier to merge threads than to split them.) > > For folks who haven’t been following, we have a new PLANTS > <https://datatracker.ietf.org/group/plants/about/> WG! It’s definitely > not just an excuse to make plant puns. The WG recently adopted Merkle > Tree Certificates > <https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/> > (MTC) as a starting point. This is all quite early (and obviously I’m > just speaking for myself and not the group), but there is some overlap with > ACME and I figure it's better to start conversations sooner than later. > > The draft has an initial pass at how to put them together here. Happily, > it seems ACME is already rich enough to express what MTC needs, with > fairly minimal additions/guidance: > > > https://www.ietf.org/archive/id/draft-ietf-plants-merkle-tree-certs-02.html#name-acme-extensions > > Some context: > > These slides > <https://datatracker.ietf.org/meeting/124/materials/slides-124-plants-solution-space-and-dispatched-work-00> > from the BoF are a good starting point for how MTC works. The ACME > interaction is that, for each certificate request, an MTC CA returns two > certificates: a “standalone certificate” (large, immediate, generally > usable) and a “landmark certificate” (small, delayed, not generally usable, > optional). The CA... > > 1. Validates the certificate request. > 2. Appends the information to a log, signs it, etc. This step constitutes > issuance. > 3. Constructs a standalone certificate that serves as proof of this > issuance. > 4. Waits some time (hours) for a “landmark” to be allocated. > 5. Constructs a landmark certificate that serves as an alternate proof of > this same issuance. > > MTC wants a way to configure ACME to deliver both certificates (one > immediately and one that the ACME client can optionally retrieve later, > after some delay), along with any metadata needed for the TLS server (etc) > to select between the two. > > The current proposal is to use ACME's existing alternate URLs feature, > modeling the delay with the HTTP Retry-After header from RFC 9110. (Another > option is to make multiple orders. That would let us model the delay with > the "processing" status, but since it’s one validation and issuance event, > one order + alternate URLs seemed a better fit.) > > Thoughts? Is this a good approach to using ACME? > > David > > PS: This is not directly part of the Profile Sets proposal. I’m quite > behind on my inbox and need to follow-up on that! :-) For MTC, the two > certs correspond to one issuance event and are renewed together, so I think > we want only one order. Though the problem space is definitely related and > perhaps my initial guess at one or both was wrong! > _______________________________________________ > 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]
