On 2025-06-19 00:57:35, Filippo Valsorda wrote:
Getting roots to ship with operating systems is certainly a hard multi-year
project, but why does ejabberd or an MTA need to use the OS root store?
If the XMPP and/or SMTP ecosystems feel the need for a PKI which behaves
differently from the WebPKI, can't they ship the roots of such a PKI with their
code?
Boulder is open source and ACME is an extensible protocol, so the barrier to
standing up a PKI has never been lower.
Simply but cause ejabberd isn't the only XMPP software in existance,
same for an MTA (however the issue there is mostly caused by microsoft
demanding such a certificate to accept mails within a hybrid deployment,
as someone from Microsoft was so kind to jump in I think we can leave
that part to them to answer)
mutual SMTP between the MX servers is basically considered to have
failed. Exactly for what the Chrome Policy wants everyone to do. Because
it lacked a common trust store for the PKI certificates. RFC7672 even
talks about this in problem and come to the conclusion that reliance on
a common trust store is impractical. Others went the route of re-using
the OS root store, which basically reuses the web browsers Web-PKI for
the most part, but in hind sight probably should have followed the same
approach as RFC7672.
See section 3.1.3 https://www.rfc-editor.org/rfc/rfc7672#section-3.1.3
and section 10 https://www.rfc-editor.org/rfc/rfc7672#section-10 already
explain a lot about why it isn't as easy as "standing up a PKI".
The central idea behind my draft is basically that it is more feasible
to add allowing serverAuth certificates to be used by systems expecting
server-to-server connections even on the TLS-Client side before the
deadline hits, where as re-architecting all current usages to use DANE
and have every operator arround the world populate their DANE records
within DNS is not (esp because still not all TLDs have DNSSEC support,
and even for some that do have it (like e.g. ".de" or ".eu") domain
registrars like e.g. namecheap don't offer it citing that the TLD
supossidly wouldn't support it).
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
