On Tue, Jul 14, 2026 at 07:41:16AM -0700, Eric Rescorla wrote: > On Tue, Jul 14, 2026 at 5:10 AM Rifaat Shekh-Yusef <[email protected]> > wrote: > > > > Can you elaborate on what you mean by "superior" in this case? > > > > Yes, I think the complexity of this approach outweighs the alleged > benefits.
I do not think this is complex (after some simplification). I think the main drawback is the hell this plays with TLS client APIs. Yes, I used to think this would be far too complex to feasibly implement. With regards to benefits (after simplification), I think the main one is avoiding a combinatorial explosion in an exceptionally nasty place. I consider both pretty major. So one has annoying high benefit, high cost situation. > > Given modern automation (ACME) and shortened certificate > >> lifetimes, it's hard to believe just issuing the certificates is a big > >> deal, though perhaps technically being able to make the composites is? > >> > > > > I am not sure I understand this comment. Can elaborate on this? > > > > You're going to need to issue a lot of certificates anyway, I don't see why > issuing the composite certificate is a big deal. As an operator, I can say that issuing composite certificate is a big deal, even with automation like ACME. Because it involves actions that can not be feasibly automated. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
