Re: [therightkey] algorithm blacklisting

Ralph Holz <> Fri, 03 January 2014 18:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 25CC31ADFC4 for <>; Fri, 3 Jan 2014 10:07:41 -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 sFBc9PCK8JtO for <>; Fri, 3 Jan 2014 10:07:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D7B841ADFC3 for <>; Fri, 3 Jan 2014 10:07:38 -0800 (PST)
Received: by (Postfix, from userid 5001) id DB5D580AE0; Fri, 3 Jan 2014 19:07:30 +0100 (CET)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1E42980206 for <>; Fri, 3 Jan 2014 19:07:30 +0100 (CET)
Message-ID: <>
Date: Fri, 03 Jan 2014 19:07:29 +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] algorithm blacklisting
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 03 Jan 2014 18:07:41 -0000


>> Although, in the case you mention, that would not help all that much.
>> Fortunately, the days of MD5 in X.509 are over.
> I imagine other algorithms will see a similar fate at some point.

Yes. SHA1 is next. There used to be some hesitation to switch to SHA1
due to, IIRC, concerns that older Windows versions wouldn't be able to
make the switch. With Microsoft themselves announcing EOL for SHA1, that
problem seems to be gone.

>> But in fact, I've been thinking for a while that an additional
>> monitoring infrastructure would be a nice-to-have thing in addition to
>> CT --- and, FWIW, also TACK --- I view both drafts as naturally
>> complementing each other.
> Yes, better monitoring tools would be very helpful.

I also think that the possibilities of auditors and monitors are
woefully underspecified. Of course, the draft cannot add too many
distinct use cases.

For the monitors, I think it might be nice to have, say, a BCP-like text
that specifies how a CA or a larger company can monitor their domain
names occur only in the correct certificates. Some kind of
straight-forward set of instructions. Maybe extended with a few more
algorithms to check logged certs for other things -- compliance with BR
or EV comes to mind.

As for auditors, I am wondering if anyone is working on a FF or Chrome
add-on that tests consistency of a log. I appreciate it's not a prime


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