[Acme] Re: ACME and PLANTS

[Mike Ounsworth <[e-mail]>]

[Chair hat on]

Thanks for the discussion. Stepping back a bit, I think there are two
possible outcomes of the interaction between MTC and ACME: either a
draft-mtc-acme-00 is needed, or it's not. Given that this still seems to be
in the "Large design space, needs to be narrowed down" stage, and that the
right experts already seem to be engaged, I'm inclined to not put this on
the ACME agenda this go-around but please keep discussion on the list. Is
that reasonable?



On Thu, 12 Mar 2026 at 23:55, David Benjamin <[e-mail]> wrote:

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