[Acme] Re: ACME and PLANTS

[Seo Suchan <[e-mail]>]

It may be stupid idea but can we use landmark-relative at main finalization (with async finalize) and make a new endpoint for standalone certificate? I fear standalone at old endpoint will cause most (old) client will never patch for landmark-relative at all and use standalone for everything because it works

On 2026년 4월 14일 오전 4시 53분 57초 GMT+09:00, Jacob Hoffman-Andrews <jsha=[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]
>>