diff --git a/docs/Protocol Specifications/core.md b/docs/Protocol Specifications/core.md index 90f6673e..47c3fcdb 100644 --- a/docs/Protocol Specifications/core.md +++ b/docs/Protocol Specifications/core.md @@ -608,9 +608,7 @@ require a second factor of authentication. !!! info "Revocation detection" - For information on how revocation detection is supposed to be handled, concern the excerpt - "Caching ID-Certs and cache TTLs" - TODO fix link + For information on how revocation detection is supposed to be handled, concern [section 6.4](#64-caching-of-id-certs) TODO: Write about identifier changing and how to handle that across servers TODO: Perhaps recommend never using more than a specified number of certificates at once to make @@ -654,8 +652,9 @@ ID-Cert attached to the message and ensuring its public key matches the sender's ???+ example Say we have two actors. Alice, who is registered on Server A, and Bob, who is registered - on Server B. Alice and Bob **are having a conversation on Server B**. Given a signed message from Alice, - such as Bob would receive from Server B, the process of verifying the signature would look like this: + on Server B. Alice and Bob **are having a conversation on Server B**. Given a signed message from + Alice, such as Bob would receive from Server B, the process of verifying the signature would look + like this: ```mermaid sequenceDiagram @@ -691,10 +690,6 @@ ID-Cert attached to the message and ensuring its public key matches the sender's Understanding both sections is crucial for building secure, scalable and compliant implementations of polyproto. -TODO: IDEA: To keep other servers from not re-requesting the idcert after the ttls has passed, the -idcert should have some sort of timestamp that is signed by the original server, so that clients can -verify that a server has the most up-to-date idcert cached for a user -flori - !!! info A failed signature verification does not always mean that the message is invalid. It may be that