Notarization
As part of the TLSNotary protocol, the Prover
can create authenticated commitments to the plaintext and have the Notary
sign them without ever seeing the plaintext. This offers a way for the Prover
to selectively prove the authenticity of arbitrary portions of the plaintext to a different Verifier
later.
A naive approach of creating such authenticated commitments is to extend the Encryption and Decryption
steps to also compute a commitment (e.g. BLAKE3 hash) to the plaintext using MPC and have the Notary
sign that commitment. Unfortunately, such an approach is too resource-intensive, prompting us to provide a more lightweight commitment scheme.
The high-level idea is that the Prover
creates a commitment to the encodings from the MPC protocol used for Encryption and Decryption
. Since those encodings are chosen by the Notary
and are not known to the Prover
at the time when she makes a commitment, they can be thought of as "authenticated plaintext".
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 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 Prover
communicated.