tl;dr: your questions are good ones, but there are solid answers to them. :)
Is [the Web of Trust] something people really even focus on any more?
As with most things, there is no easy yes or no answer here. Everyone has their own particular GnuPG use case and threat model: under some of these the Web of Trust is irrelevant, and under others the Web of Trust is irreplaceable. As an example of irreplaceable Web of Trust usage: businesses that wish for all employees to automatically treat other employee certificates as validated might want to run their own certificate authority (CA), which will sign each employee's certificate with the business's certificate before putting the certificate in a company-wide keystore. When employees need to send email within the company, it acquires the needed certificate, checks the CA has signed it, and presto. This is probably the most common way the Web of Trust is used in the real world. Other good examples of the Web of Trust include things like software supply chains, where each individual release might have its own certificate signed by the project's master certificate.
Also, how can the web of trust remain intact when there will inevitably come a time when key structures/algorithms will change again and people will need to generate new keys?
The trust spider needs to do constant upkeep on its web, that's for sure. But a lot of this can be mitigated via trusted introducer chaining, or dual signatures, or both. E.g.: certificate 23806BE5D6B98E10 was revoked in January of 2017. Before it did, though, it signed certificate 1DCBDC01B44427C7. If you trusted [email protected] as identified by certificate 23806BE5D6B98E10, you would probably also be fairly safe trusting [email protected] as identified by certificate 1DCBDC01B44427C7. That's how introducer chaining works. Dual signatures exploit the fact that messages can bear more than one signature. If I want to create public trust in a new certificate (say, 1E7A94D4E87F91D5), one can publicly sign messages with both the old certificate (1DCBDC01B44427C7) and the new certificate (1E7A94D4E87F91D5). Get a few messages out there in the wild with both signatures, and people begin to get the idea maybe the same person is behind both certificates.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list [email protected] https://lists.gnupg.org/mailman/listinfo/gnupg-users
