On Fri, Mar 13, 2026 at 01:53:09AM +0800, David Benjamin wrote: > > 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
I presume the logical ACME server used and profile (if any) in order creation determines if order will result MTC or traditional X.509 certificate? Also, using different content-type does not seem necessary. The properties can be included as PEM member of new type. Any client that can install MTC certificate can parse such member. Then, that idea of how to distribute landmark certificates is not going to work, because it is far too difficult for clients to implement (due to asynchronous issuance). I suppose the easiest method of dealing with distribution of landmark certificates is unauthenticated GET from somewhere... > 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. ACME is not suited for delivering the landmark one due to too high latency. > 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.) Multiple orders would be a major mess. And "processing" status also has to be relatively quick, as ACME clients can not deal with high latency there. -Ilari _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
