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 <[email protected]> 작성함: >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]
