> you must install the authorization certificate using a secure method.
No.
You must be able to trust the authorisation certificate.
Again, PGP/GPG and PKI: keyservers are not authenticated, anyone can post a key. Anyone can sign a key. And if keys are transmitted via plaintext methods (such as an ASCII-armoured key exported and posted to an HTML website), then that can be distributed and installed in an insecure method.
The security for PKI comes from the trust and integrity of those signing keys. Whilst anyone can sign a key, the catch, for the attacker, is that you choose the keys you trust, and extent to which you trust them.
This isn't a magick bullet, and has numerous issues and challenges (trust roots, scale, trust revocation, general comprehensibility to the lay public, etc., etc., etc.)
But, given the following components, an insecure distribution method is absolutely possible and has in fact been the mainstay of PGP/GPG networks over the past quarter century:
1. A robust and cryptographically valid cipher system and implementation for generating, signing, and validating keys and signatures.
2. Key signers trusted to you who have signed keys.
3. Reasonable assurance of the validity of a given key relative to the claimed identity by those you trust as signers.
I think that's pretty much it. How you distribute the information generated within this system doesn't matter, because the cryptography, implementation, trust, and keysigning practices are where the integrity of the system are manifested. That is, the system does not rely on transport-layer security outside those domains.
If you look up PGP keysigning protocols, you find that these are generally based on in-person procedures, which is to say, the transport layer for that element is highly assured. There are other alternatives, including TOFU or numerous informal-but-generally-sufficient mechanisms.
What PGP/GPG lack that the SSL/TLS systems have (generally) is the notion of universally trusted authorities. If you introduce that particular element, you end up with numerous cans of worms. And in fact what we've started seeing are effectively secondary (or greater) checks on CA reliability, in the form largely of major browser vendors, or operating systems, who maintain their own lists of trusted and untrusted CAs. This is a step, by TLS, in the direction of PGP's distributed WoT. PGP, on the other hand, has moved somewhat toward centralised trust in the form of auto-signing systems (PGP Inc., now part of Symantec, ran one such keyserver). Signatures by such keyservers are not a strong assurance of trust, but do establish a documentary record of key existence and history which may prove useful.
Full and true trust are phenomenally complex and/or difficult. Ultimately, impossible as an absolute, but useful even in imperfect form.
One clarification: You choose the signing keys you trust.
You can also partially trust keys, in which case a given key requires multiple signatures (from partially-trusted signers) to itself be considered trusted.
Note the distinction between trusting a key and its signers.
Among core problems with PGP/GPG is the lack of a notion of a negative trust signature. That is "I am signing this key to indicate that I know it is not what it claims to be and/or is otherwise not trustworthy". That would be generally useful (and, of course, also generally exploitable in various ways, a common story).
Yes, but you must install the authorization certificate using a secure method.
Honestly I think far too many CAs are "trusted" by default, especially for executing things (such as javascript) on my computer.