What follow are all of the reasonable approaches that have occurred to me,
presented in order from least to most desirable in my personal opinion:
1) Add a new field to the Order object, so that a finalized MTC order can
have both a "certificate" URL and a "landmarkCertificate" URL or something
like that. This is simple, and makes it very clear to the client that only
one of the two expected certificates has been issued so far. But it may
cause breakage in clients that don't like unexpected fields when parsing
JSON objects, and it feels overly-specific: why should the entire ACME
protocol have to know about landmark certificates, even when deployed in
private PKIs that aren't using MTC?
2) Replace the original contents of the certificate URL (a standalone
certificate) with different contents (a landmark certificate) when the
landmark certificate becomes available. This is similar to ACME STAR's
approach (RFC 8739), where the contents of the "star-certificate" URL are
periodically updated by the CA under the assumption that the client will
poll that URL. But that RFC decided to create a new Order field
("star-certificate") rather than overload the semantics of the existing
certificate field, so we probably don't want to go back on that decision.
And there is no simple way to communicate to the client when the contents
will be replaced (note that ACME STAR does this with a whole new sub-object
on the Order).
3) When the landmark certificate becomes available, add a new `link
rel=alternate` to the certificate resource, indicating that an alternate
version of the certificate is now available. This is nice and simple, but
still gives the server no way to communicate when the landmark cert will be
available.
4) When the standalone cert is first downloaded, *immediately* include a
`link rel=alternate` pointing to a different URL where the landmark cert
will be served. When that URL is accessed, respond with a reasonable status
code and include a Retry-After header indicating when the landmark cert
will be available. Then the client can just retry that URL at the indicated
time to get the landmark cert.
This fourth idea is what we've discussed in the past, and is what is
described in the current MTC draft. I include the other options here to
show that they've been considered, and to illustrate why I believe they are
inferior to the current proposal.
Aaron
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]
