On Fri, Mar 13, 2026 at 06:17:07PM -0400, Michael Richardson wrote: > > Ilari Liusvaara <[email protected]> wrote: > >> 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. > > Do you prefer to have a different set of routines to process MTC PKIX then? > And the application level (or TLS level) has to be aware of the difference? > I can see lots of good reasons to do this long-term: a future steady state > where 5280 certicates do not exist, so one can get rid of that "legacy" > library code.
Yes, a different set of routines. As for application level changes, it is mainly new APIs to provision MTC certificates, and MTC trusted logs. And there might be some oddball server-end APIs that need tweaking for MTC client certificates. The main reason for different code is not eventually ripping out the "legacy" code, but that MTC and classical X.509 work very differently: - The classical X.509 negotiation code can not be easily extended to handle the kind of negotiation MTC needs. - The APIs X.509 negotiation uses for certificate provisioning are not realy compatible with MTC. - Defaults are hard, so X.509 can act as fallback for MTC. - Classical X.509 is hierarchial, but MTCs are not, so validation code needs to handle those differently. And there are security issues here. - The non-hierarchial nature of MTC renders many extensions nonsensical, so merely trying to parse that stuff gives plenty of nonsense. - The "signature" is something very different from signature. Even for standalone certificates. > >> 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? > > Huh? why would that occur. Seems broken, period. > How would you do account linkage over time? Configuration. Which can change out-of-sync with certificates. In ACME client I wrote: - Configuration specifies directory URL and account key for each ACME server. - Configuration specifies which ACME server is the default. - Each certificate request can override the ACME server to use. That gives plenty of room for getting the certificate account out of sync. And even if one manages to break ARI with this, things do not go south very much. And even saving the directory URL and account key in certificate would not help against somebody overwriting the account key file with a new key (for "security" purposes). > >> 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. > > That's seems like a limitation of the code, not something the protocol should > compensate for. There are ACME clients that can use multiple CAs for fallback purposes. -Ilari _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
