Mike Ounsworth <[email protected]> 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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
