The p≡p TOFU protocol

In order to be able to communicate reliably with previously unknown third parties (or with third parties from whom we do not yet have keys), we need an entrance point for encrypted communication. While trust in p≡p always comes through verification, we have to be able to bootstrap key exchange and signing/encryption so that we can move to the point of securely and reliably exchanging verification information. For this, we use the p≡p TOFU (Trust On First Use) protocol.

A prerequisite requirement for any communication which is considered “reliable” (i.e. has the rating PEP_rating_reliable and yellow color) is that all of the usual p≡p requirements for keys and their cryptographic properties will be fulfilled by all communications partners. Presuming that to be the case, one of the usual ways new communication (or encryption) partners can move from no encrypted communication to reliably encrypted (yellow channel) communication is through the establishment of Trust On First Use, described below.

Protocol description

  1. Alice sends a message to Bob.

    • If Alice already has Bob’s key, and that key meets the minimum requirements, that message may be encrypted.
    • If Alice does not have Bob’s key, it will be sent unencrypted.
    • Alice MAY assert that a particular key is in fact her key - the sender key - by explicitly declaring the sender key’s fpr. In order for Bob to be able to accept this as the actual sender key, however, the message MUST be signed with this sender key, and the key material of the public part of the sender key MUST be attached to the message.
    • If, on the other hand, there is no sender key declaration, then if – and only if – there is exactly one public key attached to the message, this key will be accepted as the sender key. The message MAY be (but is not required to be) signed with the sender key.
    • Use of an explicit sender key declaration is dependent on the message format.
  2. Bob receives Alice’s message.

    • If there is no default key for the identity specified in the message’s .from field, Bob will store the sender key as default key for this identity if and only the message follows the specifications in 1).
    • Also, if there is no default key for the user representing Alice, then Bob will, when the default key for Alice’s identity is set, set this identity’s default key as the default key for her user.

TOFU Key default claims

Note that we no longer consider the defunct p≡p 2.0 case for TOFU key import. p≡p 1.0 defaults to OpenPGP in the unencrypted case, since it is all open on the wire. Default keys for pEp users must come from a recent version of pEp.

Encrypted incoming messages

Claims and default keys from encrypted messages
Message format Must be signed Signer key material attached Sender FPR specified specified Number of keys attached Correct filename Signer key must match imported key material
Autocrypt YES YES (header) N/A N/A - we only take header key Header key (N/A) YES
p≡p 2.1 YES YES YES Any. Signer key should match sender FPR N/A YES
p≡p 2.2 YES YES YES Any. Signer key must match sender key FPR claim and imported key material with correct filename YES YES

Unencrypted incoming messages

Claims and default keys from unencrypted messages
Source client Sender FPR specified Number of keys attached Correct filename
OpenPGP N/A 1 N/A
Autocrypt N/A Header (all others ignored) N/A
p≡p 2.1 Yes 1 N/A
p≡p 2.2 Yes Any with correct filename YES