fix RST warnings

1 files changed, 14 insertions, 15 deletions

diff --git a/anastasis.rst b/anastasis.rst
index c27b66df..d0012c7a 100644
--- a/anastasis.rst
+++ b/anastasis.rst
@@ -255,16 +255,16 @@ individual **key share**, we use different salts ("erd" and "eks" respectively).
     (iv_i, key_i) = HKDF(key_id, nonce_i, "eks", [optional data], keysize + ivsize)
     (encrypted_key_share_i, aes_gcm_tag_i) = AES256_GCM(key_share_i, key_i, iv_i)
 
-**encrypted_recovery_document**: The encrypted **recovery document** which contains the escrow methods, policies 
+**encrypted_recovery_document**: The encrypted **recovery document** which contains the escrow methods, policies
 and the encrypted **core secret**.
 
-**nonce0**: Nonce which is used to generate *key0* and *iv0* which are used for the encryption of the *recovery document*. 
+**nonce0**: Nonce which is used to generate *key0* and *iv0* which are used for the encryption of the *recovery document*.
 Nonce must contain the string "ERD".
 
 **optional data**: Key material that optionally is contributed from the authentication method to further obfuscate the key share from the escrow provider.
 
-**encrypted_key_share_i**: The encrypted **key_share** which the escrow provider must release upon successful authentication.  
-Here, **i** must be a positive number used to iterate over the various **key shares** used for the various **escrow methods** 
+**encrypted_key_share_i**: The encrypted **key_share** which the escrow provider must release upon successful authentication.
+Here, **i** must be a positive number used to iterate over the various **key shares** used for the various **escrow methods**
 at the various providers.
 
 **nonce_i**: Nonce which is used to generate *key_i* and *iv_i* which are used for the encryption of the *key share*. **i** must be
@@ -356,7 +356,7 @@ Obtain salt
   **Response:**
 
   Returns a `SaltResponse`_.
-  
+
   .. _SaltResponse:
   .. ts:def:: SaltResponse
 
@@ -509,7 +509,7 @@ In the following, UUID is always defined and used according to `RFC 4122`_.
   Upload a new version of the customer's encrypted recovery document.
   While the document's structure is described in JSON below, the upload
   should just be the bytestream of the raw data (i.e. 32 bytes nonce followed
-  by 16 bytes tag followed by the encrypted document). 
+  by 16 bytes tag followed by the encrypted document).
   If request has been seen before, the server should do nothing, and otherwise store the new version.
   The body must begin with a nonce, an AES-GCM tag and continue with the ciphertext.  The format
   is the same as specified for the response of the GET method. The
@@ -644,8 +644,7 @@ In the following, UUID is always defined and used according to `RFC 4122`_.
 
     }
 
-.. _manage-truth:
-
+.. _Truth:
 
 Managing truth
 ^^^^^^^^^^^^^^
@@ -692,7 +691,7 @@ charge per truth operation using GNU Taler.
       // Contains the information of an interface `EncryptedKeyShare`, but simply
       // as one binary block (in Crockford Base32 encoding for JSON).
       key_share_data: []; //bytearray
-    
+
       // Key share method, i.e. "security question", "SMS", "e-mail", ...
       method: string;
 
@@ -720,7 +719,7 @@ charge per truth operation using GNU Taler.
 .. http:get:: /truth/$UUID[?response=$RESPONSE]
 
   Get the stored encrypted key share. If $RESPONSE is specified by the client, the server checks
-  if $RESPONSE matches the expected response specified before within the TruthUploadRequest_ (see encrypted_truth).  
+  if $RESPONSE matches the expected response specified before within the TruthUploadRequest_ (see encrypted_truth).
   Also, the user has to provide the correct *truth_encryption_key* with every get request (see below).
   When $RESPONSE is correct, the server responses with the encrypted key share.
   The encrypted key share is returned simply as a byte array and not in JSON format.
@@ -768,7 +767,7 @@ charge per truth operation using GNU Taler.
       //
       // HKDF for the key generation must include the
       // string "eks" as salt.
-      // Depending on the method, 
+      // Depending on the method,
       // the HKDF may additionally include
       // bits from the response (i.e. some hash over the
       // answer to the security question)
@@ -811,10 +810,10 @@ FIXME: details!
 Video identification (vid)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Requires the user to identify via video-call. The user is expected to delete all metadata revealing 
-information about him/her from the images before uploading them. Since the respective images must 
-be passed on to the video identification service in the event of password recovery, it must be 
-ensured that no further information about the user can be derived from them. 
+Requires the user to identify via video-call. The user is expected to delete all metadata revealing
+information about him/her from the images before uploading them. Since the respective images must
+be passed on to the video identification service in the event of password recovery, it must be
+ensured that no further information about the user can be derived from them.
 FIXME: details!