[gpm]

That seems like the correct state of things. More packages means more possibility of bugs. We want to trust as little code as possible.

Now if only the same policy would be applied to CAs (possibly a few to mitigate abuse of power concerns, but far less than are in my trust store today).

[geofft]

Counterpoint (which I'm not fully convinced of myself, to be fair): CAs are supposed to be interchangeable and easy to revoke. While the CA ecosystem as a whole must be robust, no individual CA can be too big to fail. If a serious bug is found in software used by one or a few CAs (imagine something like the Debian OpenSSL bug from 11 years ago), revoking them and requiring customers to move to other CAs is feasible. If a serious bug is found in software used by all CAs, you can't revoke all the certs on the web and leave HTTPS useless globally while CAs set up new software.

On a tangent: one practice I'd genuinely like to see for security reasons (and which I'm surprised the CAs haven't proposed themselves, since it would make them twice as much money) is that major sites should always hold valid certs from two CAs, so that if a CA gets revoked it's just updating a file or even flipping a feature flag and certainly not signing up with a new CA. It would make sense to have two certs generated by different software, then. (It might also make sense, re abuse of power concerns, to present both certs and have browsers verify that a site has two valid certs from two organizationally-unrelated CAs. That way you can be significantly more confident that the certs aren't fraudulent.)

[kardos]

Would two signatures on the same cert fit the bill?

Two complete certs is twice as much data to transmit, making the TLS setup a bit heavier.

[isostatic]

A typical webpage is something like 2MB

A typical cert is 0.1% of that

[kardos]

Lots of things use TLS that is much smaller than a bloated webpage, for example REST APIs.