One of the projects I alluded to in that post makes a technological solution to what you want easy to build, but the harder problem to solve is societal (i.e., getting it adopted).

https://github.com/fedi-e2ee/public-key-directory-specificat...

My current project aims to bring Key Transparency to the Fediverse for building E2EE on ActivityPub so you can have DMs that are private even against instance moderators.

One of the things I added to this design was the idea of "Auxiliary Data" which would be included in the transparency log. Each AuxData has a type identifier (e.g. "ssh-v2", "age-v1", "minisign-v0", but on the client-side, you can have friendly aliases like just "ssh" or "age"). The type identifier tells the server (and other clients) which "extension" to use to validate that the data is valid. (This is to minimize the risk of abuse.)

As this project matures, it will be increasingly easy to do this:

  // @var pkdClient -- A thin client-side library that queries the Public Key Directory
  // @var age -- An implementation of age
  async function forwardSecureEncrypt(file, identity) {
    const agePKs = await pkdClient.FetchAuxData(identity, "age");
    if (agePKs.length === 0) {
      throw new Error("No age public keys found");
    }
    return age.Encrypt(file, agePKs[0]);
  }

(The degree of "forward secure" here depends on how often your recipient adds a new age key and revokes their old one. Revocation is also published through the transparency log.)

However, email encryption is such a mess that most people don't quite appreciate, so I'm blogging about that right now. :)

Also, Filippo just created a transparency-based keyserver for age, fwiw: https://words.filippo.io/keyserver-tlog/

Tall order.