On 2025-06-18 23:40:03, Benjamin Kaduk wrote:
On Wed, Jun 18, 2025 at 09:19:09PM +0000, Klaus Frank wrote:
(resent without breaking the thread)
It also was already tried to make Google reconsider. But to no avail.
Basically they don't care about the practical issues and at most say
"just roll your own PKI" as everyone apparently should just stop using
the Web-PKI for other services entirely. Well only issue is that there
I think that's an exaggeration of the actual reality ("everyone should
just stop using the Web PKI for other services entirely").
While we should not be surprised that the Web PKI is being managed for
the benefit of the Web ecosystem with only minimal consideration toward
other ecosystems, the very nature of the Web as decentralized, open,
and with server authentication fundamentally chaining toward effective
control of DNS names implies that quite a lot of non-Web services will
continue to be able to shoehorn their needs into something compatible
with the Web model and thus continue to use the Web PKI. There is some
level of risk in doing this, though, since such non-Web usage is not
reflected by any primary stakeholders in the Web PKI management and thus
the PKI could evolve out from under such usage (which feels like what
we are seeing here).
Don't think it's exaggerated. Google made it clear that they do not care
about breaking any other use case, so even if your service still works
using these certificates that may change in the future with way too
little time to ensure a smooth transition. Basically it makes reusing
the Web-PKI a liability.
But besides that that's basically a quite good summary of what we're seeing.
is basically no other PKI infrastructure to migrate towards. Especially
none that can be assumed to be universally trusted. Call it lazyness or
whatever but almost everyone relied upon the Web-PKI. Or does anyone
know a single one that is e.g. trusted by all operating systems but not
by web browsers that could be used here?
The other big open/distributed PKI that is widely trusted is the DNSSEC
KPI. It is, of course, managed primarily for the benefit of the DNS ecosystem,
but just like the Web PKI it can be leveraged by other consumers for various
purposes, e.g., via DANE as Viktor has already noted.
One of the main reasons why the Web-PKI was used, was also because it
was what all of the common crypto libraries use without additional
effort. Be it openssl or schannel or whatever. When you want to make a
TLS connection it is basically easy to use the Web-PKI and hard to use
anything else.
My draft also covers DANE. It would be the ideal solution, but for that
to be as univeral as using the Web-PKI was up until this policy change
each and every TLD would have to support DNSSec and all of the DNS
providers would have to do the same as well as all of the software would
have to implement DANE support. Which as outlined above is way harder
than just telling the default crypto library to make an outbound TLS
connection with a specific clientAuth certificate...
I can only speculate that this is one of the main reasons why Google
didn't drop the Web-PKI entirely and demand everyone to just use DANE
(2) and point it towards the CA they want to be using or to serve a
self-signed certificate (3) without additional validation (basically
building the chain of trust through the DNSSEC KPI). That approach would
have increased security drastically but isn't practical (yet)...
Given that it takes a pretty significant investment to develop the needed
policies to define the goals and operations of a PKI and provide secure
operation for the root key(s), it does not suprise me that very few
ecosystems have committed the resources to build their own PKI from scratch.
But a robust PKI is just not something to assume you can get for free.
Well we didn't have to "assume" getting it for free. Well at least until
Let' Encrypt joined thescene then we could. Some however still prevered
to buy their certificates from another CA. But yea we kinda were
freeloader upon the Web-PKI. But so are operating systems when they
include the Web-PKI within a centralized system trust store...
-Ben
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
