[Acme] Re: ACME and PLANTS

[Jacob Hoffman-Andrews <[e-mail]>]

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 <[e-mail]>
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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>