Re: Massive change in Public Cert behaviour coming soon

[Crist Clark via NANOG <nanog () lists nanog org>]

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 <nanog () lists nanog org>
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/nanog () lists nanog org/message/FS3UXBW4DARFXL4GC47VNVSEMRYGJG3I/
> >
> _______________________________________________
> NANOG mailing list
>
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/KT3Q4C62FMLHRCNFUKX7ZLW5Q6MDF5KY/
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/2Z5BSMXHXXWPO5KMS5C3LQZW2DFIE7QI/