improve parts for storing trust message infromation of section "Implementation Notes"

This commit is contained in:
Melvin Keskin 2019-03-08 00:27:17 +01:00
parent 4c6492293f
commit 421fb2132f
1 changed files with 25 additions and 8 deletions

View File

@ -260,14 +260,31 @@
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>
A client MUST save the information of a trust message until the key of the sending device of that message is authenticated, so that the key can then be authenticated or revoked.
Afterwards the information of the trust message can be deleted.
</p>
<p>
A client MUST save the information of a trust message until it has fetched the corresponding key so that the key can then be authenticated or revoked.
Afterwards the information of the trust message can be deleted.
</p>
<section2 topic='Storing Trust Message Information from Devices with Unauthenticated Keys' anchor='impl-storing-trust-message-information-unauthenticated-keys'>
<p>
A client MUST save the information of a trust message until the key of the device which sent the trust message is authenticated, so that the key can then be authenticated or revoked.
Afterwards the information of the trust message MAY be deleted.
</p>
<p>
Example:
When Alice's device A1 authenticates the key of Bob's device B1, A1 sends a trust message containing the keys of Alice's other device A2 to B1.
If B1 has not already authenticated A1's key, B1 stores the information provided by the trust message.
B1 authenticates A1's key and is then able to automatically authenticate A2's key.
</p>
</section2>
<section2 topic='Storing Trust Message Information for Unknown Keys' anchor='impl-storing-trust-message-information-unknown-keys'>
<p>
A client MUST save the information of a trust message until it has fetched the corresponding key so that the key can then be authenticated or revoked.
Afterwards the information of the trust message can be deleted.
</p>
<p>
Example:
Alice's device A1 receives an authentication message from Bob's device B1.
That authentication message contains the key for Bob's other device B2.
If A1 has not already fetched B2's key, A1 stores the information provided by the trust message.
A1 fetches B2's key and is then able to automatically authenticate A2's key.
</p>
</section2>
<p>
It can happen, that device 1 manually authenticates the key of device 2 while device 1 is offline.
If then device 3 also manually authenticated the same key and sends authentication messages for it while device 1 is still offline, there would be, after device 1 got online again and sent its authentication messages, several authentication messages with the same content circulating.