CAB has nothing to do with trust/distrust here. Its the Root CA Store Operators (Mozilla, Google, Apple, Microsoft, Adobe) which have to distrust here.
In other words: the CAB members would distrust the CA because the CA would be in violation of their individual root store policies, specifically the "you must follow the rules set by the CAB" part.
Google (GTS) has done the same. GTS controls GlobalSign R4. GlobalSign R4 was a root cert which was created by GlobalSign and later sold to Google.
If a bad actor starts buying up CA's, then very quickly that CA would be distrusted by Root Cert Store Operators. No different than what happened with DigiNotr and Entrust.
What you are proposing sounds like DANE with TLSA and DNSSec. Great idea but most CC TLDs are still using 1024 RSA ZSKs. Right now PQ DNSSEC is very uncertain. PQ DNSSEC will likely take about 5 more years or so to standardise. And thats too late for companies like Google and Cloudlfare which want to go PQ Crypto by 2029.
No, I'm proposing that TLD can handle issuance themselves since they technically have 100% control over domains under their TLDs anyways. I think this might be important when we look at a combination of short (and getting shorter) lifetimes for end-user certificates and increasing volatility of the world (cyberattacks, sabotage and war). It would be desirable for ccTLD's specifically to be able to maintain certificate issuance even though the country was virtually or physically isolated from the rest of the world. (Which DANTE could/would have mitigated but is not my proposal here)
It's almost like they could put their CA's public key into the dns, and the sub-zones could carry signatures over their own keys, to make dns secure. you could call it something like "dnssecure".
A very welcome move because for years Cloudflare has freeloaded certs from Let's Encrypt without sponsoring Let's Encrypt finacially. Though Cloudflare has contributed in otherwise to the ecosystem like by running CT logs etc.
Now, it looks like WebPKI is going to fracture into two regarding PQ Crypto. With Google (GTS and Chrome), Cloudflare and Let's Encrypt all preferring MTC and legacy CA's like Digicert, Sectigo, Globalsign all heading towards non MTC.
If Cloudflare would not have decied to become a PQ CA for MTC. We would have a duopoly with GTS and Let's Encrypt. This is a worse off situation. Therefore I welcome Cloudflare CA for MTC.
Also, its not like they are going to make any money of the CA business if they are going to issue DV certs for free. It will reduce the pressure on Let's Encrypt from carrying the burden of securing 60% of the world's webistes.
> A very welcome move because for years Cloudflare has freeloaded certs from Let's Encrypt without sponsoring Let's Encrypt finacially.
It's not freeloading to accept a gift freely given. I'm sure the people who do fund LE are happy to see the world's largest TLS terminator using LE certs to secure the web - that is and was the whole point of LE in the first place. It's being used as intended.
I don't agree that this is a positive development if a resilient worldwide PKI
is desired.
1. We have seen how Cloudflare can "break the Internet" due to their position
as a SPoF. Let's Encrypt also became a SPoF as their popularity grew.
2. Cloudflare's main service depends on breaking the trust model of TLS, which
is to say that users must be assured that they can communicate with a server
without the possibility that third parties are observing or tampering with the
connection. If I direct my user agent to example.com, I expect that my TLS
connection is terminated by the operators of example.com, and any contents sent
and received are between me and the servers associated with example.com.
Cloudflare breaks that assumption by performing TLS interception between my
user agent and the server. Yes it is true that other services, such as cloud
load balancers, do the same thing, but we should not accept that this creates
an important opportunity for interception or tampering due to commercial
interest, duress etc.
3. Furthermore Cloudflare allows operators to present a TLS certificate to
clients even when the origin server does not use TLS, leading them to believe
that their connection is secure even when the leg between Cloudflare and the
server is not encrypted: the so-called TLS façade.
4. Cloudflare is incorporated in a jurisdiction that has been seen to behave in
a hostile, or at a minimum highly arbitrary, fashion, and has been involved in
pressuring infrastructure operators to do their geopolitical bidding and
personal favors to the executive. Of course Let's Encrypt also has this
weakness.
Are we to believe it is a good thing that a known SPoF becomes an even more
critical SPoF? That an actor who subverts TLS becomes a CA? More concentration
of infrastructure control in a single jurisdiction that does not respect
international norms?
Cloudflare promoters will say that points 2 and 3 are always the choice of the
server operator. However Cloudflare takes advantage of the fact that most
server administrators actually understand very little about how TLS, or even
the Internet, works. I frequently observe that the operators of critical public
services on the Internet fundamentally misunderstand basic technologies such as
DNS, IP, TLS and HTTP. For those people, Cloudflare gives them an easy option
to "stop the DDoS", without understanding the implications of sending their
traffic to a foreign actor who will perform TLS interception. And in many
cases, using Cloudflare turns into a ritualistic mimicry that is performed as a
preventative rite to placate the DDoS spirits.
It is also concerning to me the suggestion that CAs which are not GTS, CF and
LE are somehow considered "legacy CAs" now. In what sense?
LE recently updated their policies to say explicitly that they will comply with
export restrictions:
Let me remind you that the implied "modern" CAs mentioned must also comply
with export restrictions, but furthermore they are subject to non-public
pressure dynamics from the executive which may result in arbitrary service
terminations at the individual, organization or country levels. This as well as
compliance requirements with CLOUD and collection programs.
I propose that the goal should be to look for a way in which we can have
widespread availability of free DV certificates for everyone who needs one,
independent of their nationality, from multiple geographically distributed
providers in diverse jurisdictions, coupled with a sustainable economic model
for CAs which are not operated by the tech behemoths.
There are actually non-behemoth CAs, besides LE, which already provide free DV
certs, ACME compatible, for example:
If a script zeroed out the private key, wont the public key not work anymore?
reply