Background

In the section on Key Substitution, you wrote:

One mitigation for this attack is key-fingerprint verification, in which participants in a group compare the fingerprints they see for keys for an identity.

Professional cryptographers tell me they have never verified a key fingerprint or safety number in their private chats with their family members. This is a box-checking exercise that only the most pedantic tech nerds will ever bother with. This doesn't provide security for most users.

The cryptography and privacy communities have spent 30 or so years trying to get Johnny to be able to encrypt in paradigms where "manually verify a key fingerprint" is part of the user experience. See also: https://cups.cs.cmu.edu/soups/2006/posters/sheng-poster_abstract.pdf

Separately, I have sketched out a proposed specification for building a special kind of ActivityPub server that can be used to provide a security property known as Key Transparency. You can read the draft specification here.

Proposal

In addition to whatever fingerprint / safety number / etc. mechanism you want to provide, key transparency should be used as an automated, distributed verification for the integrity of the mapping between Actors and their keyPackages.

To this end, W3C SHOULD adopt a specification for Key Transparency, and use it to augment the security of the current MLS-based design. This is the direction that incumbent E2EE systems today are moving towards (WhatsApp, Signal, etc.).

If there is any interest in adopting my designs, I've released my relevant work under public domain (as well as a public domain-equivalent license, CC0, for jurisdictions that do not recognize public domain declarations).

Related Issues

• Verifiably end-to-end encrypted #14 - This provides verification of the end-to-end nature of the keys in question
• No manual key management #32 - This obviates the need for manual key management