include invalidatedAt in cache signature, clarify correct ordering of concatentations

Author: bitfl0wer

docs/Protocol Specifications/core.md

@@ -1619,19 +1619,31 @@ 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                                                                                                         |
-| --------------------- | --------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
-| `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. |
+| 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.                                                                   |
+| `invalidatedAt`       | String?   | Unsigned 64-bit integer                   | If present, represents a UNIX timestamp at which the certificate was [invalidated](#614-early-revocation-of-id-certs) on. Certificate was not prematurely invalidated if not present. |
 
 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. Clients must reject certificates of which the `cacheSignature` can not be verified to be
+question with the `cacheValidNotBefore` timestamp, the `cacheValidNotAfter` timestamp, and the `invalidatedAt`
+timestamp, if present.
+
+!!! warning
+
+    The order in which the concatenation operations are executed is important and must be adhered
+    to. The order is as follows:
+
+    `cacheSignature ⋅ cacheValidNotBefore ⋅ cacheValidNotAfter ⋅ (invalidatedAt|"")¹`
+
+    ¹: The value of invalidatedAt, if present; otherwise, an empty string.
+
+The resulting string is signed using the home servers private identity key.
+Clients must reject certificates of which the `cacheSignature` can not be verified to be
 correct.
 
-!!! note "Note/Fun fact"
+??? note "Note/Fun fact"
 
     Note how the cache validity period is determined by the "original" home server and automatically
     propagated through—and respected by—every server and client caching the certificate. If another