Add something about the trust on the long-term public keys

[juniorz]

This paragraph keeps coming as something that should be in the prekey server spec:

i. If the versions and the long-term keys used in the messages are the same, and they are
compatible with Alice's version, one of the prekey messages must be invalid, but Alice cannot know
which. She should not send a message using either prekey message.
ii. If the prekey message versions are the same and the version is supported by Alice, but the
long-term keys are different from each other, Alice should look at whether she trusts the keys. If
she trusts both, she may send a message to both. If she trusts only one, she may decide to only
send one message or she may send a message to the untrusted key as well. If she trusts neither,
she may not send any messages or she may decide to send a message to one or both, despite the
risks.
iii. If the prekey message versions are different and Alice supports both versions, Alice may choose
to send a message with both versions or only with one, depending on whether she trusts the long
term key or keys associated with them.
iv. If the prekey message versions are different and Alice supports only one, then she can only
send a message with the prekey message she supports. If the long-term key associated with this
message is untrusted, she may decide not to send a message. If it is trusted, she may send a
message.

It is unsure if we should add this to this spec or to the OTRv4 spec, since OTRv4 will not have to bother with multiple versions of prekey messages.

See: https://github.com/otrv4/otrv4-prekey-server/commit/17b0a3a6e5e84c664bf4c3efa5988b2fad8fccbc#r28241471

[juniorz]

• A client might decide to take as valid a prekey message only if it trusts the long-term public key on it. This should be noted. Check ADR9:

" Alice receives two prekey messages for Bob because Bob uses two OTRv4 clients, one for his phone and one for his laptop (or the same client in different devices). Each client maintains their own set of prekey messages on the same prekey server. These two prekey messages will be different by instance tag. This scenario can, therefore, follow different paths:

a. The two prekey messages may have user profiles created with different long term keys and two prekey profiles signed by those different keys respectevely. At this point, if Alice trusts only one key, she may decide to send a message only to the client with the key she trusts. If Alice trusts both keys, she may decide to send a message to one or both. If Alice does not trust either key, she may decide not to send a message or she may send messages without validating the keys. b. The two prekey messages may have user profiles created with the same long term key and prekey profiles signed by the same key. If this key is trusted, Alice may decide to send a message to both client instances. Or Alice may decide to send a message only to the first Prekey message received. If Alice does not trust the key, she may decide not to send a message or send an message to both instances without validating the keys.

"

[claucece]

I just wrote:

Optionally, a client can only use prekey messages that contain trusted long-term public keys.

just like an option... what do you think?

[claucece]

I think this is solved @juniorz ?