[harshreality]

New wannabe CA Entity B can approach an established CA entity A, convince A to sign B's root or intermediate cert, and then B can forge browser-trusted certs for every SSL website on the net that's not pinned.

In this case, B is LetsEncrypt and is (hopefully) pretty solid, but that isn't always the case. Earlier this year, it became known that CNNIC had issued a CA cert to MCS Holdings (of Egypt), which then did bad things.[1]

The news that everyone is suddenly trusting a new entity B, whether it's some Egyptian IT firm, or LetsEncrypt, comes out of nowhere. Neither cooperation nor even awareness is needed of the major browsers' dev teams.

[1] https://googleonlinesecurity.blogspot.com/2015/03/maintainin...

[MichaelGG]

How is this any worse than trusting the original CA? There's almost assuredly some high standard they use to cross sign, and they'd get revoked if they do that incorrectly. You're failing to note that MCS was revoked as was CNNIC. So, boom, 2 bad/laughably incompetent players are out.

Trusting a CA means trusting them to write certs, even via an intermediary. If you don't actually trust them, remove those CAs.

The CA model has lots of problems, but I don't see what additional harm this actually causes.

[Natanael_L]

Because it doesn't settle with having as many single points of failure as the number of CA entries in your root CA list, they are getting multiplied over and over.

[MichaelGG]

How would it be any different if these CA's made a choice to instead issue end-user certs but based off of Let's Encrypt's authorization?

[Natanael_L]

Fewer master keys to target

[MichaelGG]

I'm gonna guess that getting into Let's Encrypt's HSM is as hard or harder than breaking their auth procedures.

[rplnt]

Is it (technically) possible to limit CAs validity to certain subset of.. something? I.e. certain CAs could only be used to verify limited number of.. domains? something?

[geofft]

If you're talking about limiting to certain TLDs, like American CAs not being able to issue .ca or .in or .paris, there is a spec for that, called name constraints. It is intermittently supported, and there was a thread on mozilla.dev.security.policy, primarily focusing on government CAs, which argued that doing such a thing fractures the open/egalitarian nature of the internet, by making zones where security is less important:

https://groups.google.com/d/topic/mozilla.dev.security.polic...

I can imagine other ways you would restrict certificates (for instance, I'd kinda like to see a spec for a "half-CA", where you need two half-CAs under distinct organizational control to sign you), but I don't think anyone has specified the problem for those precisely, let alone proposed a solution.

[grhmc]

Yes using "Name Constraints" but that RFC / extension is really broken, and implementations don't support it. See 4.2.1.10 of https://tools.ietf.org/html/rfc5280.

[wtbob]

That's how SPKI (RFCs 2692 & 2693) worked: one only trusted an authority for certain things. This would work very well for DNS names and IP addresses alike, since both are allocated hierarchically; with SPKI one could guarantee that one is talking to one of the parties who is allowed to use a name or an address.

Sadly, SPKI more-or-less died on the vine: the atrocious XPKI 'system' won by default. One of my rainy-day projects is to try to revive it: if the last 15 years have taught us anything, it's that centralised global trust is insane.

[IgorPartola]

AFAIK, no it's not. However, this is the solution as far as I see it. When you buy a domain name from a registrar they should give you a mini-CA that's valid for just that domain for as long as the domain is registered. Then it's up to you to create and sign any certs for any subdomains. This would cut out the CA businesses entirely, enabled security-by-default, and simplify the whole system.