Merge pull request #72 from nextleap-project/history-with-metadata

history verification: use metadata in bootstrap code

source/new.rst

@@ -527,8 +527,8 @@ in the metadata part of the bootstrap code.
 
 More precisely:
 
-- in step 1 Alice adds the metadata:
-    ``INVITE=<groupname>``.
+- in step 1 Alice adds the metadata
+  ``INVITE=<groupname>``.
   Where ``<groupname>`` is the name of the group ``GROUP``.
 
 - in step 2 Bob manually confirms he wants to join ``GROUP``
@@ -574,9 +574,13 @@ b. Bob receives the encrypted "vg-member-added" message
 c. Any other group member that receives the encrypted "vg-member-added" message
    will process the gossiped key through autocrypt gossip mechanisms.
    In addition they verify:
-     * The encryption and Alices signature are intact.
-     * They are themselves a member of ``GROUP``.
-     * Alice is a member of ``GROUP``.
+
+   * The encryption and Alices signature are intact.
+
+   * They are themselves a member of ``GROUP``.
+
+   * Alice is a member of ``GROUP``.
+
    If any of the checks fail processing aborts.
    Otherwise they will add Bob to their list of group members
    and mark the gossiped key as verified in the context of this group.
@@ -755,28 +759,29 @@ This is where the history-verification protocol comes in.
 This protocol,
 that again relies on a second channel,
 enables two peers
-to verify key integrity of their shared historic messages.
+to verify integrity, authenticity and confidentiality
+of their shared historic messages.
 After completion, users gain assurance
 that not only their current communication is safe
-but that their past communications have not been tampered with.
+but that their past communications have not been compromised.
 
 By verifying all keys in the shared history between peers,
 the history-verification protocol can detect
 temporary malfeasant substitutions of keys in messages.
 Such substitutions are not caught by current key-fingerprint verification
-workflows, because they only provide assurance about the current keys.j
+workflows, because they only provide assurance about the current keys.
 
 Like in the `setup-contact`_ protocol,
 we designed our history-verification protocol so that
 peers only perform only one "show" and "read" of bootstrap information
 (typically transmitted via showing QR codes and scanning them).
 
 The protocol re-uses the first five steps of the `setup-contact`_ protocol
-(with small modifications)
 so that Alice and Bob verify each other's keys.
 We make one small modifications to indicate that
 the messages are part of the history-verification protocol:
-we substitute the message prefix "vc-" by "kg-".
+In step 1 Alice adds the metadata
+``VERIFY=history``.
 
 If no failure occurred after step 5,
 Alice and Bob have again verified each other's keys.