[Acme] Re: ACME and PLANTS

[Michael Richardson <[e-mail]>]

Ilari Liusvaara <[e-mail]> 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.

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

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

    > If that ACME key even still exists. Some subscribers have nasty
    > habit of erasing/revoking old ACME account keys for "security" reasons.

Uhm. "Doctor, it hurts when I shoot myself in the foot."


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide