It's not possible to do this purely client side (how could it be? If the client can compute it on their own then they can forge it on their own), so a server/pr

It's not possible to do this purely client side (how could it be? If the client can compute it on their own then they can forge it on their own), so a server/protocol modification is inevitable. I'm think what you're saying with "offer very tiny signed messages instead" is that you think TLS is the wrong protocol layer to solve this problem at. Maybe so, but I feel like (a) that charge could be levied at TLS itself too (why not just do encryption at the application layer?) and (b) putting it into TLS means that perhaps eventually most of the web would support it. I also wanted to draw attention to the rather clever way they allow the client to selectively redact sensitive information without losing the non-repudation property by computing a Merkle tree over the content. It's pretty neat: > Our design is based on content extraction signatures and thereby allows the generation of non-interactive proofs based on the signed evidence provided by the generator (typically the server). During proof creation the requester can hide certain parts of the original conversation, but this will clearly visible in the proof. All the non-hidden parts are verifiable, no matter how many parts are hidden. To achieve these properties we generate commitments and aggregate them in Merkle trees for every TLS record. This allows efficient hiding of information. The hiding granularity is determined by the chunk size, which is negotiated during the TLS handshake. A smaller chunk size provides more precision while a bigger chunk size is more computationally efficient.