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/nanog@lists.nanog.org/message/FS3UXBW4...