On Wed, Mar 22, 2023 at 11:22 AM Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Wed, Mar 22, 2023 at 01:54:22PM +0100, Bas Westerbaan wrote: > > > > > > Unpopular pages are much more likely to deploy a solution that > > > doesn't require a parallel CA infrastructure and a cryptographer > > > on staff. > > I don't think the server-side deployment difficulties with this have > anything to do with parallel CA infrastructure or admins having to > understand cryptography. > > > > CAs, TLS libraries, certbot, and browsers would need to make changes, > > but I think we can deploy this without webservers or relying parties > > having to make any changes if they're already using an ACME client > > except upgrading their dependencies, which they would need to do > > anyway to get plain X.509 PQ certs. > > I don't agree. > > I think deploying this is much much harder than deploying X.509 PQ > certificates. X.509 PQ certificates are mostly dependency update. This > looks to require some nontrivial configuration work that can not be > done completely automatically. > > And then in present form, this could be extremely painful for ACME > clients to implement (on level of complete rewrite for many). > It’s true that this would require code changes in more components. But TLS, ACME, etc., are deployed many more times than they are implemented. As the code changes happen per software package, hopefully the per-deployment cost beyond that can be minimal. (Though, of course, that will depend on exactly how each package's existing configuration interface looks, and how/whether they apply it to the new thing. Understanding what protocol properties would make this easy or hard would be very useful, but I also suspect it depends on a lot of details we've still left as placeholders right now.) These things also don’t have to happen all at once. It can be a transition over time, or perhaps some sites just stay with the fast-issuance mechanism (be it X.509 PQ or something else) if they’re happy with it. Merkle Tree Certificates themselves cannot be your only certificate type anyway, since they only work with up-to-date RPs. To ACME specifically, we definitely don’t want it to be painful for ACME clients to implement! It’s probably a bit hard to discuss that in the abstract, with our ACME section being just a placeholder. Perhaps, when we’ve gotten an initial draft of that, we can figure out which bits we got wrong and iterate on that? David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
