[Acme] Re: ACME and PLANTS

[Michael Richardson <[e-mail]>]

Mike Ounsworth <[e-mail]> wrote:
    > 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

Yes, we need a document to collect options/discussion.
(Ask me in 12-ish days if I want to volunteer to start it)

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

I think that's exactly the right thing right now.

1. Sometime in early May, decide if a (joint) virtual-interim meeting would help.
2. Make sure IETF126's conflict lists ACME<->PLANTS<->LAMPS as conflicts.
3. EST will need to solve the same problem.  It may be similiar, or
   completely different.

I think David wrote:
    >> 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.

My understanding is that some operators of many tenanted web-hosting systems
run their ACME client on a management system.  This discussion previously
informed the design of the renewal-info (RFC9773).

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