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