HTTP plus a trusted hash would provide an integrity measure of the content of a page, and enable hashing.
It would not prevent anyone from examining that content in flight, or altering it. It would allow any such alteration to be identified.
It is possible to offer various levels of assurance on unencrypted communications.
Mind: I'm describing a possible world, not the one most of us happen to live in. Unless, say, you're retrieving Debian package repositories over FTP or HTTP transport, and rely on the package signature rather than HTTPS for integrity.
You can't have encryption without authentication, because a man in the middle can snoop your connection.
You can have authentication without encryption. This is what PGP signed messages are.
I'll admit it's weird to call a cryptographic signature a "trusted hash", which makes it seem like the author of the post you're responding to doesn't know what they're talking about. But it's totally possible to to have trust without encryption or TLS. TLS isn't even the best protocol for signing out there, as the whole thing depends on CAs being trustworthy (which they aren't).
All that said, if you want trust on the internet, start with HTTPS. Sure, you don't need the encryption for delivering non-secret content, but it's the easiest way to set up trust and the only one non-technical people are likely to verify in any way (because their browser does it for them). It doesn't provide very strong guarantees, but it's better than nothing. If you want more go with PGP.
And the fact that you can use PGP over HTTP doesn't in any way mean that HTTP is secure in general.
> 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).
Except when a party also has the certificate information and private key and does a man in the middle attack without you knowing, because of resigning the data with the exact same key :)
This statement is wholly incorrect. HTTP is not generally secure.
> for publishing
When I publish something I do not intend for third parties to interfere with the delivery of what I publish.
> and has the added advantage of being cacheable by proxies
If you trust your proxy, you can still have cached data at your proxy. If you don't trust your proxy, then why are you proxying through it?