mirror of
https://github.com/tlsnotary/website.git
synced 2026-01-09 14:58:09 -05:00
19 lines
1.6 KiB
Markdown
19 lines
1.6 KiB
Markdown
---
|
|
sidebar_position: 2
|
|
---
|
|
# Notarization
|
|
|
|
Even though the `Prover` can prove data provenance directly to the `Verifier`, in some scenarios it may be beneficial for the `Verifier` to outsource the verification of the TLS session to a trusted `Notary` as explained [here](../intro.md#tls-verification-with-a-general-purpose-notary).
|
|
|
|
As part of the TLSNotary protocol, the `Prover` creates authenticated commitments to the plaintext and has the `Notary` sign them without the `Notary` ever seeing the plaintext. This offers a way for the `Prover` to selectively prove the authenticity of arbitrary ranges of the plaintext to an application-specific `Verifier` later.
|
|
|
|
Please refer to the [Commitments](../mpc/commitments.md) section for low-level details on the commitment scheme; and [Commit Strategy](./commit_strategy.md) section for different strategies the `Prover` can employ when generating these authenticated commitments.
|
|
|
|
## Signing the Session Header
|
|
|
|
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 `Prover`'s commitment to the plaintext and a `Prover`'s commitment to TLS-specific data which uniquely identifies the server.
|
|
|
|
The `Prover` can later use the signed `Session Header` to prove data provenance to an application-specific `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 `Prover` communicated.
|