Web of trust

In cryptography, a web of trust is a concept used in PGP, GnuPG, and other OpenPGP-compatible systems to establish the authenticity of the binding between a public key and its owner.

All OpenPGP-compliant implementations include a certificate vetting scheme to assist with this; its operation has been termed a web of trust.

OpenPGP certificates (which include one or more public keys along with owner information) can be digitally signed by other users who, by that act, endorse the association of that public key with the person or entity listed in the certificate.

[2] OpenPGP-compliant implementations also include a vote counting scheme which can be used to determine which public key – owner association a user will trust while using PGP.

The scheme is flexible, unlike most public key infrastructure designs, and leaves trust decisions in the hands of individual users.

WOT favors the decentralization of trust anchors to prevent a single point of failure from compromising the CA hierarchy.

[3] The OpenPGP web of trust is essentially unaffected by such things as company failures, and has continued to function with little change.

Users had to prepare a signed cancellation certificate against the time when the matching private key was lost or compromised.

Later PGP, and all OpenPGP compliant certificates include expiry dates which automatically preclude such troubles (eventually) when used sensibly.

Despite the wide use of OpenPGP compliant systems and easy availability of on-line multiple key servers, it is possible in practice to be unable to readily find someone (or several people) to endorse a new certificate (e.g., by comparing physical identification to key owner information and then digitally signing the new certificate).

Key signing parties are a relatively popular mechanism to resolve this problem of finding other users who can install one's certificate in existing webs of trust by endorsing it.

However, such a chain is not necessarily useful: the person encrypting an email or verifying a signature not only has to find a chain of signatures from their private key to their correspondent's, but also to trust each person of the chain to be honest and competent about signing keys (that is, they have to judge whether these people are likely to honestly follow the guidelines about verifying the identity of people before signing keys).

Another obstacle is the requirement to physically meet with someone (for example, at a key signing party) to verify their identity and ownership of a public key and email address, which may involve travel expenses and scheduling constraints affecting both sides.

[7] In a paper published in September 2022, Gunnar Wolf and Jorge Luis Ortega-Arjona mentioned the size of the strong set as being 60,000.

It is physically not possible for an original author or developer or file-releaser to provide public-key or trust or ID verification services to millions of users.

Even with multiple trusted people/person (by original-author) in trusted-chain from WOT, its still not physically or practically possible for every developer or author to meet with every other users, and it is also not possible for every users to meet with hundreds of developers whose software they will be using or working on.

To make sure that each users are getting the correct and trusted public-keys and signed-code/file, original dev/author or original-releaser must publish their updated public-keys on their own key server and force HKPS encrypted connection usage, or publish their updated and full public-keys (and signed-code/file) on their own HTTPS encrypted webpage, under their own web server, from their own primary domain website, (not-from any sub-domains which are located in external-servers, not-from any mirror, not-from any external/shared forum/wiki etc website servers, not-from any public or external/shared cloud or hosting service servers), and must have to be located and kept securely inside their own premises: own-home, own-home-office, or own-office.

In that way, those small pieces of original keys/code, will travel intact through internet and will remain unmodified during transit (because of encrypted connection) and will reach destination without being eavesdropped or modified, into user's side, and can be treated as trustworthy public-keys because of single or multi channel TTPA based verification.

When a public-key is obtained (from original developer's own web-server) via more than one TTPA (trusted third party authority) based secured, verified and encrypted connection, then it is more trustworthy.