finish section 6.4.1

Author: bitfl0wer

docs/Protocol Specifications/core.md

@@ -902,11 +902,11 @@ After evicting a cached ID-Cert:
 #### 6.4.1 Verifying that a newly retrieved ID-Cert is not out-of-date
 
 While the goal of achieving dynamic server load distribution to increase the viability of small,
-low-resource home servers is a noble one, this goal must not undermine P2s trust model, which other
-aspects of the protocol work very hard to uphold. Retrieving ID-Certs from a middleman introduces
-a new attack surface which must be mitigated. Consider the following example:
+low-resource home servers is a noble one, this goal must not undermine [P2s trust model](#2-trust-model),
+which other aspects of the protocol work very hard to uphold. Retrieving ID-Certs from a middleman
+introduces a new attack surface which must be mitigated. Consider the following example:
 
-???+ example "Example attack abusing blind middleman trust"
+??? example "Example attack abusing blind middleman trust"
 
     1. One of Alice's private identity keys is compromised.
     2. Malicious actor Eve logs onto a malicious Server X which is controlled by Eve, impersonating
@@ -923,7 +923,38 @@ a new attack surface which must be mitigated. Consider the following example:
        certificates). Until then, users do not notice that this certificate has been revoked and
        should no longer be valid.
 
-This kind of attack has been considered and mitigated in polyproto. bla
+This kind of attack mentioned above has been considered and mitigated in polyproto. This mitigation
+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                                                                                                         |
+| ------------------- | --------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
+| `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. |
+
+A server generates the `cacheSignature` by concatenating the serial number of the ID-Cert in
+question with the `cacheValidNotBefore` timestamp and the `cacheValidNotAfter` timestamp, then
+generating the signature of the resulting, concatenated string using the private identity key of
+the server.
+
+!!! warning
+
+    Concatenation operations are not commutative.
+
+!!! quote "Definition: Concatenation"
+
+    > In formal language theory and computer programming, string concatenation is the operation of
+    joining character strings end-to-end. For example, the concatenation of "snow" and "ball" is
+    "snowball".
+
+    *From Wikipedia, The Free Encyclopedia. [Source](https://en.wikipedia.org/w/index.php?title=Concatenation&oldid=1266032132#:~:text=In%20formal%20language,a%20primitive%20notion.)*
+
+Because digital signatures rely on asymmetric key cryptography, possession of this server's public
+identity key allows an actor to validate that a cached ID-Cert is both genuine and up-to-date.
+
+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