AtHeartEngineer/docs-mdbook
1
0
Fork 0
mirror of https://github.com/AtHeartEngineer/docs-mdbook.git synced 2026-01-09 00:58:13 -05:00
Code Issues Packages Projects Releases Wiki Activity

Remove old notarization page (#29)

Browse Source
This commit is contained in:
sinu
2023-09-06 09:56:23 -07:00
parent 6af5644216
commit 80b85ec9fa
1 changed files with 3 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
src/protocol/notarization/README.md
View File

@@ -1,32 +1,9 @@
# Notarization Phase
During the Notarization Phase the `Requester`, otherwise referred to as the `User`, and the `Notary` work together to generate an authenticated `Transcript` of a TLS session with a `Server`.
During the Notarization Phase the `Prover`, otherwise referred to as the `User`, and the `Notary` work together to generate an authenticated `Transcript` of a TLS session with a `Server`.
Listed below are some key points regarding this process:
- The identity of the `Server` is not revealed to the `Notary`, but the `Requester` is capable of proving the `Server` identity to a `Verifier` later.
- The identity of the `Server` is not revealed to the `Notary`, but the `Prover` is capable of proving the `Server` identity to a `Verifier` later.
- The `Notary` only ever sees the *encrypted* application data of the TLS session.
- The protocol guarantees that the `Requester` is not solely capable of constructing requests, nor can they forge responses from the `Server`.
## Requester
The `Requester` is the party which runs the TLS connection with the `Server`. The `Requester` constructs application payloads, eg. HTTP requests, and coordinates with the `Notary` to encrypt them with the TLS session keys prior to sending them. Subsequently, the `Requester` works with the `Notary` to decrypt responses from the `Server`. The plaintext of the application data is only ever revealed to the `Requester`.
## Notary
The `Notary` is the party of which the authenticity of the `Transcript` relies on. During the session the `Notary` withholds its' shares of the TLS keys and participates in a series of secure MPC protocols with the `Requester` to operate the TLS connection.
## Server
The `Server` can be any server which supports TLS. The TLSNotary protocol is entirely transparent to the `Server`, thus it cannot be censored nor does it have to support any additional functionality.
<img src="../../png-diagrams/tls12-multiround.png">
## Transcript
The primary artifact generated from this phase is called the `Transcript`. It contains session meta-data, handshake data, and commitments to all the requests and responses. Typically the `Transcript` is signed by the `Notary`, however that is not necessary in the case where the `Notary` will also act as the `Verifier` in the selective disclosure phase.
> Note that the server ephemeral key does not reveal the identity of the server to the `Notary`.
<img src="../../png-diagrams/transcript.png">
- The protocol guarantees that the `Prover` is not solely capable of constructing requests, nor can they forge responses from the `Server`.