Merge pull request #19 from tlsnotary/signing_doc

Signing section

src/SUMMARY.md

@@ -28,5 +28,8 @@
 - [TLS handhsake](./mpc/tls_handshake.md)
 - [Committed Oblivious Transfer](./mpc/committed_ot.md)
 
+# Specification
+
+- [Notarized session](./spec/notarized_session.md)
 
 +[Glossary](./glossary.md)

src/glossary.md

@@ -17,5 +17,6 @@
 | RSA   | Rivest–Shamir–Adleman (public-key cryptosystem) |
 | PMS   | Pre master secret (TLS)                         |
 | PRF   | Pseudo Random Function                          |
+| PRG   | pseudorandom generator                          |
 | PSE   | Privacy and Scaling Exploration                 |
 | TLS   | transport layer security                        |

src/protocol/notarization/signing.md

@@ -1,16 +1,11 @@
-# Signing the session header.
+# Signing the Session Header
+
+At the end of the TLSNotary protocol, the `Notary` signs an artifact known as a `Session Header`, thereby attesting to the authenticity of the plaintext from a TLS session. A `Session Header` contains a `User`'s commitment to the plaintext and a `User`'s commitment to TLS-specific data which uniquely identifies the server.
+
+The `User` can later use the signed `Session Header` to prove data provenance to a third-party `Verifier`.
+
+It's important to highlight that throughout the entire TLSNotary protocol, including this signing stage, the `Notary` does not gain knowledge of either the plaintext or the identity of the server with which the `User` communicated.
 
-The `Notary` signs the following artifacts called the `Session Header` which are required for the `User` to prove to a third-party `Verifier` the authenticity of the plaintext from the TLS session.
-We emphasize that throughout the whole TLSNotary protocol, the `Notary` never learns the plaintext neither learns what domain the `User` communicates with.
 
-// taken from tlsn/tlsn-core/src/session/header.rs
 
-// TODO: will explain the meaning of each
 
-- encoder_seed:  
-- merkle_root
-- sent_len
-- recv_len
-- time
-- server_public_key
-- handshake_commitment

src/spec/notarized_session.md

@@ -0,0 +1,69 @@
+# Notarized session
+
+The `Notary` signs the following artifacts known as a `Session Header`, thereby attesting to the authenticity of the plaintext from a TLS session. The `User` can then use the signed `Session Header` to prove data provenance to a third-party `Verifier`.
+
+It's important to highlight that throughout the entire TLSNotary protocol, including this signing stage, the `Notary` does not gain knowledge of either the plaintext or the server with which the `User` communicated.
+
+## Session Header
+
+A `Session Header` consists of the following components:
+
+### Server Ephemeral Public Key
+
+In TLS, session keys are derived from a one-time per-TLS-session ephemeral public key. The server signs this key with its certificate and transmits both the key and the signature to the `User`.
+
+Since the `Notary` remains unaware of the signature or the certificate, the server's identity is concealed. However, the `User` can disclose the server's identity to a `Verifier` by revealing the signature and the certificate.
+
+### Plaintext Encodings
+
+These are the [encodings](../../mpc/encodings.md) employed by the Notary to encode the plaintext.
+
+Again, note that the `Notary` does not gain knowledge of the actual plaintext. The `Notary` transmits these encodings to the `User` using [Oblivious Transfer](/mpc/oblivious_transfer.md).
+
+For efficiency, the `Notary` employs a small PRG seed to generate random plaintext encodings.
+
+### Root of the Merkle Tree of Commitments
+
+The root of the Merkle tree, where each leaf represents the `User`'s commitment to plaintext encodings.
+
+### Commitment to the TLS Handshake Data
+
+This represents the `User`'s commitment to various public data from the TLS handshake:
+- Server certificate chain
+- Signature over the `Server Ephemeral Public Key`, created using the `Server Certificate Chain`
+- Client random
+- Server random
+
+### Time
+
+Indicates the time when the Notary signed the `Session Header`.
+
+### Total Bytes Sent and Received
+
+The total amount of application data bytes that the `User` sent to and received from the server.
+
+
+## Session Data
+
+// (can be seen in tlsn-core/src/session/data.rs)
+
+- `handshake_data_decommitment` contains `HandshakeData` which the `User` committed to (with salt)
+`HandshakeData` contains various TLS-specific details:
+    - `server_cert_details` (server certificate chain)
+    - `server_kx_details` (data used in ECDH key exchange)
+    - `client_random` (client random from the `Client Hello` TLS message)
+    - `server_random` (server random from the `Server Hello` TLS message)
+
+- `tx_transcript` and `rx_transcript` contain all application level plaintext bytes which were transmitted to/received from the server
+
+- `merkle_tree` is a Merkle tree the leaves of which are the `User`'s commitments to plaintext. The `User` may commit to multiple slices of plaintext and then selectively disclose to the `Verifier` only those slices which he wants to make public
+
+- `commitments` contains the `User`'s commitments to plaintext, where each commitment structure is:
+    - `merkle_tree_index` is the index in the `merkle_tree`
+    - `commitment` is the actual commitment value e.g. a blake3 hash
+    - `ranges` are byte ranges within `tx/rx_transcript` where the bytes committed to are located
+    - `direction` is used to identify whether it is a commitment to tx or rx data
+    - `salt` is a salt for the `commitment`
+
+
+