[Acme] Re: ACME and PLANTS

[David Benjamin <[e-mail]>]

On Fri, Mar 13, 2026 at 4:10 AM Ilari Liusvaara <[e-mail]>
wrote:

> 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?
>

Yup. You can think of MTCs as "just" a very funny signature scheme for
signing certificates. So it's all flavors of picking which CA instance to
respond with, whether a MTC CA instance vs a traditional CA instance, or a
PQ CA instance vs an ECDSA CA instance.


> 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.
>

RFC 8555 describes a subset of general PEM, even if practically everyone
will run it through a general, permissive PEM parser.
https://www.rfc-editor.org/rfc/rfc8555.html#section-9.1

The text reads to me as being inextensible ("A file of this type contains
one or more certificates encoded with the PEM textual encoding"), which
suggests a new MIME type would be prudent. But if I'm misreading and
application/pem-certificate-chain is actually meant to be extensible, we
can flip that around. Whatever folks prefer.


> 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...
>

Hmm. I'm somewhat unclear on why saving one URL to resume later, vs saving
another URL to resume later, would be more difficult to implement for an
ACME client, but I'm sure my mental model is incorrect. Is it because of
the need to authenticate download URLs? (Very, very, very) naively, I
assumed the ACME client would wake up, look at whatever its current state
is and decide...
- Are my certificates soon to expire? Make a new order.
- Do I have saved state from a pending order? Go nudge that state along,
e.g. trying to redownload any unfinished alternate URLs.

Then the server operator would glue it all together by arranging for the
ACME client to run on a cron job. And since that cron job both has access
to authentication and ACME state, the fact that ACME authenticates all its
URLs is not a huge deal. A separate unauthenticated URL would suggest a
world where the server operator has a *separate* scheduled job that's have
the ACME account key, but does have read/write access to certificate state.
I assumed that doesn't currently exist and we may as well piggy-back off
the existing job schedulingn.

I gather this does not match how you think about this?


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