On Fri, Mar 13, 2026 at 12:54:49PM +0800, David Benjamin wrote: > On Fri, Mar 13, 2026 at 4:10 AM Ilari Liusvaara <[email protected]> > 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.
The X.509 code from TLS library I have written thinks MTCs are malformed. Extending that code to handle MTCs is not acceptable due to security concerns. > > 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. Well, if one wants to avoid modifying meaning of existing MIME type (in compatible way), then I think MTCs should have their own MIME type. > > 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. Dealing with incomplete orders, or multiple orders in parallel, is much more complicated than only dealing with a single complete order at a time. Especially multiple orders in parallel: There are some very nasty race conditions lurking in there. I have written ACME client, making it do either of those things would require a major rewrite. > 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. What if the authentication fails? For ARI replace, for reliablity one should drop the replace on any error. Which also handles any authentication failure with ARI. I implemented that logic in the ACME client I wrote after seeing some certificate renewals getting into hung state (requiring manual intervention (assume-revoke the existing certificate) to get those unstuck). > 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. Even if the job runs in the same process as certificate renewal, determining which ACME account key to use can be difficult. If that ACME key even still exists. Some subscribers have nasty habit of erasing/revoking old ACME account keys for "security" reasons. -Ilari _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
