Re: [TLS] Merkle Tree Certificates

Ilari Liusvaara <> Tue, 06 June 2023 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AEF4BC1516E0 for <>; Tue, 6 Jun 2023 09:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HZS7ITKihU1W for <>; Tue, 6 Jun 2023 09:19:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BB9FC15154D for <>; Tue, 6 Jun 2023 09:19:09 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14FDDBC77 for <>; Tue, 6 Jun 2023 19:19:08 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id PqVtfAl_spL1 for <>; Tue, 6 Jun 2023 19:19:07 +0300 (EEST)
Received: from LK-Perkele-VII2 ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C7F362309 for <>; Tue, 6 Jun 2023 19:19:06 +0300 (EEST)
Date: Tue, 06 Jun 2023 19:19:06 +0300
From: Ilari Liusvaara <>
To: "<>" <>
Message-ID: <ZH9cei5JY6+0q7yr@LK-Perkele-VII2.locald>
References: <> <> <ZBsxgM/cv+vuBPEj@LK-Perkele-VII2.locald> <> <ZH7mrdGzq/Za4Ypm@LK-Perkele-VII2.locald> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [TLS] Merkle Tree Certificates
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Jun 2023 16:19:15 -0000

On Tue, Jun 06, 2023 at 01:28:17PM +0200, Bas Westerbaan wrote:
> > > Thanks! That’s indeed inconsistent, we’ll fix it.
> > >
> >
> > Hmm... Looking at that construct, why is the pad there?
> We pad to the hash block size. When computing the full Merkle tree, or
> verifying an authentication path, the values before the pad are the same,
> and thus we can precompute the hash state after digesting those fixed
> values.
> (With the current inputs and sha256, it will only make a difference for
> HashAssertion though.)

I mean, is there a cryptographic reason for it? 

If one wanted to really micro-optimize performance, I think the optimal
design for SHA-256 would be to have padding for assertions but not for
empty nor nodes (since not padding empty and node saves one block).

(However, absent cryptographic reasons, this all is way premature.)

> > And there does not seem to be any way to salt the hash. WebPKI requires
> > what effectively amounts to salting the hash via serial number (even
> > for SHA-256).
> >
> Please elaborate.

>From CABForum Baseline Requirements version 1.8.7 (2.0.0 has the same
requirement, but in several places), section 7.1.:

"CAs SHALL generate non‐sequential Certificate serial numbers greater
than zero (0) containing at least 64 bits of output from a CSPRNG."

In certificate structure, serial number comes very early (it is in
fact the first non-length field that varies). What that in effect does
is to make it much more difficult to exploit chosen-prefix collisions in
hash function.

However, that requirement holds irrespective of the hash function used,
and it has in fact been held for SHA-256 (regardless of there not being
any known even remotely feasible attacks) instead of just being a dead
letter from the past with much worse hash functions.