Mature ID-Cert caching concept, require ed25519

Author: bitfl0wer

docs/Protocol Specifications/core.md

@@ -46,7 +46,7 @@ of the specification document: **v0.1.0-alpha.1**
     - [6.3 Private key loss prevention and private key recovery](#63-private-key-loss-prevention-and-private-key-recovery)
     - [6.4 Caching of ID-Certs](#64-caching-of-id-certs)
       - [6.4.1 Verifying that a newly retrieved ID-Cert is not out of date](#641-verifying-that-a-newly-retrieved-id-cert-is-not-out-of-date)
-    - [6.5 Cryptographic recommendations](#65-cryptographic-recommendations)
+    - [6.5 Cryptographic specifications](#65-cryptographic-specifications)
     - [6.6 Best practices](#66-best-practices)
       - [6.6.1 Signing keys and ID-Certs](#661-signing-keys-and-id-certs)
       - [6.6.2 Home server operation and design](#662-home-server-operation-and-design)
@@ -300,12 +300,12 @@ can only have one active session token at a time.
 
 Regardless of the authentication method used, the foreign server must verify the actor's identity
 before allowing them to perform any actions. This verification must be done by proving the cryptographic
-connection between an actors' home server's public identity key and the actor's ID-Cert. Challenge
-strings, as described in [Section 4.2](#42-challenge-strings) and in [polyproto-auth](./auth.md)
-are used for this purpose within this specification.
+connection between an actors' home server's public identity key and the actor's ID-Cert through
+ID-Cert signature verification.
 
-Servers must also check with the actor's home server to ensure that the ID-Cert has not been revoked.
-APIs for this purpose are defined in the [API documentation](/APIs).
+Before a foreign actor is allowed to send messages on the server, the server must also check with
+the actor's home server to ensure that the ID-Cert has not been revoked. See [section 6.4.1](#641-verifying-that-a-newly-retrieved-id-cert-is-not-out-of-date)
+for information on how this is done.
 
 #### 4.1.2 Sensitive actions
 
@@ -1038,8 +1038,8 @@ This kind of attack mentioned above has been considered and mitigated in polypro
 is achieved through API behaviors enabling the fetching of actor ID-Certs with additional information
 attached to the response body. The additional information is structured as follows:
 
-| Field name          | JSON type | Actual type (if different from JSON type) | Description                                                                                                         |
-| ------------------- | --------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| Field name            | JSON type | Actual type (if different from JSON type) | Description                                                                                                         |
+| --------------------- | --------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
 | `cacheValidNotBefore` | String    | Unsigned 64-bit integer                   | UNIX timestamp that specifies the time from which this cache entry may be treated as valid.                         |
 | `cacheValidNotAfter`  | String    | Unsigned 64-bit integer                   | UNIX timestamp that specifies a time until which this cache entry may be treated as valid.                          |
 | `cacheSignature`      | String    | -                                         | Signature generated by the home server. This signature can be verified using the home servers' public identity key. |
@@ -1074,14 +1074,41 @@ identity key allows an actor to validate that a cached ID-Cert is both genuine a
 This technique remedies the possibility of caching introducing an additional attack vector, allowing
 caching to be used without conflicting with the [trust model](#2-trust-model) of polyproto.
 
-### 6.5 Cryptographic recommendations
-
-For two implementations of polyproto to be interoperable, they must support an overlapping set of
-digital signature algorithms.
-
-If technically practical, all implementations of polyproto must support the use of the Ed25519 digital
-signature algorithm for signing messages and generating ID-Certs. The use of the RSA algorithm for
-digital signatures [is heavily discouraged](https://blog.trailofbits.com/2019/07/08/fuck-rsa/).
+!!! info "Scenarios requiring cache and validity verification"
+
+    **Only** the following scenarios **must require** a server to retrieve, validate and supply invalidation
+    and cache information about a foreign actor's ID-Cert:
+
+    - **Sending messages:** Before a foreign actor is allowed to send any messages on the server. This
+      automatically applies again if the ID-Cert is changed through any means.
+    - **ID-Cert request:** When the server receives a request for a foreign actor's ID-Cert, the server
+      must fetch and validate invalidation and cache information about the foreign actor's ID-Cert before
+      completing the request.
+
+!!! info "Scenarios **not** requiring cache and validity verification"
+
+    The following scenarios **must explicitly not require** a server to retrieve, verify or supply invalidation
+    and cache information about a foreign actor's ID-Cert:
+
+    - **Requesting a challenge string:** When a foreign actor requests a challenge string from the server.
+    - **Requesting a key trial:** When a foreign actor requests a key trial from the server.
+    - **Completing a key trial:** When a foreign actor completes a key trial from the server.
+    - **Re-signing messages request:** When a foreign actor requests to re-sign messages on the server.
+    - **Re-signing messages abortion request:** When a foreign actor requests to abort the re-signing
+      of messages on the server.
+    - **Re-signing messages commitment:** When a foreign actor commits re-signed messages to the server.
+    - **Re-signing messages commitment:** When a foreign actor fetches messages to-be re-signed from
+      the server.
+    - **Requesting a redirect:** When a foreign ("new") actor asks the server of the "old" server to
+      set up a redirect to the "new" actor.
+    - **Key trial information request:** When an actor requests information about completed key trials
+      from the foreign actor.
+
+### 6.5 Cryptographic specifications
+
+All implementations of polyproto **must** use the Ed25519 digital signature algorithm for signing
+messages and generating ID-Certs. The usage of alternative cryptographic algorithms is allowed.
+However, certificates and messages must be made available with Ed25519 signatures per default.
 
 ### 6.6 Best practices