Re: [therightkey] Draft charter for a Transparency Working Group

Ralph Holz <> Sat, 14 December 2013 11:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EBB221ADF6E for <>; Sat, 14 Dec 2013 03:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id etUqCNpYVcoP for <>; Sat, 14 Dec 2013 03:08:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 058321ADF6A for <>; Sat, 14 Dec 2013 03:08:50 -0800 (PST)
Received: by (Postfix, from userid 5001) id 992DA80B0E; Sat, 14 Dec 2013 12:08:42 +0100 (CET)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 9D4CB80A89 for <>; Sat, 14 Dec 2013 12:08:41 +0100 (CET)
Message-ID: <>
Date: Sat, 14 Dec 2013 12:08:41 +0100
From: Ralph Holz <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.8 at ex6
X-Virus-Status: Clean
Subject: Re: [therightkey] Draft charter for a Transparency Working Group
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 Dec 2013 11:08:53 -0000

On 12/11/2013 05:55 PM, Ben Laurie wrote:
> Who's in?

I'd like to be part of it.

> Cryptographically verifiable logs can help to ameliorate the problems
> by making it possible to discover and rectify errors before they can
> cause harm.

Correct me if I am wrong, but the following comes to mind. I'd probably
say "too much harm" or "significant harm": the public log concept allows
for a short time window for successful attack. Much depends on the
number of logs a CA pushes their certs to, and how many monitors watch
these logs for suspicious changes. I am less concerned about the
consistency proofs and audit paths here, and more about what monitors
actually do. I.e., deployment issues.

> Work items: Specify a standards-track mechanism to apply verifiable
> logs to HTTP/TLS (i.e. RFC 6962-bis).

One thing that I was wondering about is whether the work can be taken
further at some point to include that mechanism from Sovereign Keys that
allows to give, say, an alternate Tor routing (or hidden service), for a
given domain, in order to avoid censorship. I'd agree that's not a
primary topic for CT, but a worthwhile goal to keep in mind for later.


Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
Phone +
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF