The arguments from Google about separate hierarchies is discussed. bit here,
https://googlechrome.github.io/chromerootprogram/moving-forward-together/ See "Understanding dedicated hierarchies" section. On Fri, May 23, 2025 at 12:49 AM Eliot Lear via NANOG <[email protected]> wrote: > It's not that hypothetical. I bring to your attention draft-halen-fedae > <https://datatracker.ietf.org/doc/draft-halen-fedae/>, which has been > deployed in Sweden to create trust within a federation of private CAs. > But it's not sufficient for non-federated or non-prearranged use cases. > This draft focuses on m2m, and specifically excludes web-based > transaction, because the security analysis required for browser > interactions is a hard problem. > > Creating multiple public hierarchies due to EKUs is a huge effort for > what precise security benefit? I'd really like someone from Google to > answer that question. > > Eliot > > On 22.05.2025 23:21, John R. Levine via NANOG wrote: > > > On Thu, 22 May 2025, Jay Acuna wrote: > >> This does not work for applications where the client authentication > >> is between > >> servers at different organizations. Such as the SMTP server or Web > >> server which wishes to connect to another company's SMTP server or > >> Web server using > >> mutual TLS to verify the web server FQDN for authentication to send > >> mail or > >> access an API endpoint as that server's identiy. > > > > This is sounding awfully hypothetical. I have seen a lot of SMTP > > software and I have never, ever, seen one send a client certificate in > > an SMTP session. Submission clients sometimes use them, but that's > > different, and the client cert is provided by whoever runs the server. > > > > Mail servers either check the client's IP address with SPF, which > > works poorly for a variety of reasons, or there's a DKIM signature in > > the message the client sends, unrelated to the SMTP transport. > > > > R's, > > John > > > > PS: in the IETF we are nearly done with a long overdue update to RFC > > 5321 and I can assure you there is not a whiff of client certs there > > either. > > _______________________________________________ > > NANOG mailing list > > > https://lists.nanog.org/archives/list/[email protected]/message/FS3UXBW4DARFXL4GC47VNVSEMRYGJG3I/ > > > _______________________________________________ > NANOG mailing list > > https://lists.nanog.org/archives/list/[email protected]/message/KT3Q4C62FMLHRCNFUKX7ZLW5Q6MDF5KY/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/2Z5BSMXHXXWPO5KMS5C3LQZW2DFIE7QI/
