Re: [TLS] Merkle Tree Certificates

David Benjamin <> Mon, 05 June 2023 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DADD4C15107E for <>; Mon, 5 Jun 2023 12:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.247
X-Spam-Status: No, score=-14.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4BNy98iJ178d for <>; Mon, 5 Jun 2023 12:41:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id DB3A3C14CE44 for <>; Mon, 5 Jun 2023 12:41:49 -0700 (PDT)
Received: by with SMTP id 3f1490d57ef6-bb15165ba06so4545209276.2 for <>; Mon, 05 Jun 2023 12:41:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1685994108; x=1688586108; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QweLd3EAZfTc3PJg3QXjGHmT0W8putzscPhHMuwbWm0=; b=JdA+sAysJK6Q0wwQWGqa60S6ZZ3JgRkZ0MiJ6NC4brPFVHJLPRWssLUNqp2Lh12ZAC IltP4D3lm4Wge0/awDqqBx6//u/zNjwBW8DygxUMKzswg4FWyL1pbjNl5WeJaY7t5rC+ W9Kj7cuT5Emw7nretbxK3vQRM09stCSrGw9Aw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1685994108; x=1688586108; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QweLd3EAZfTc3PJg3QXjGHmT0W8putzscPhHMuwbWm0=; b=dEx/wuIbhBNyjt2Fg6+ZhVOqbTJH3uWzva4duAaOv9aQ4hf/WSh24rIpZzeVS20KLx N/mjGih15aRLOJHB+8DmKgeTBjDi8XoM969Aj3uSq88XNxDjftHHo7uVQxoIl1TXEYWh 9FsHfwPxSdG/zGB4FAwpb7PV7/pe6Xxiivqx5NAujBSTqwR8X4lU1PYrXyrV6lFjzsay EV7O1rVFxWK9lAsAA6vF6RrY2KxkQaLEPYS/k8IjBtG4xPNV0GHFNB1T48zr/UnyGGuR chEuF8vkPBRoP25b4CJ9YZdSLhiBGedWLChUEwQeNe+yUsSQ/9DMVfFpgHRWGd4i4Ogy Eqxg==
X-Gm-Message-State: AC+VfDxBRCPLGIQayFhl9IpMlVjDwVMs7aUEOScQMI5oxD0ZRIS3Jx7H GfL6I08WXt44F1DvkEiqHXTBzj18Gd1rPgYRiCoxEwS7XZf1v2aVuHEg
X-Google-Smtp-Source: ACHHUZ41+1Vpcewij5gnXD8HDYVNlqvP7kzsmv1jgaKauxsv5gxoYnCRpFe/yIrH1n0ss2nokkxMPUfmZfP9O4opKT0=
X-Received: by 2002:a25:180a:0:b0:ba8:62ed:2221 with SMTP id 10-20020a25180a000000b00ba862ed2221mr9921533yby.62.1685994108600; Mon, 05 Jun 2023 12:41:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <ZBsdFHiMN8lTsGP9@LK-Perkele-VII2.locald>
In-Reply-To: <ZBsdFHiMN8lTsGP9@LK-Perkele-VII2.locald>
From: David Benjamin <>
Date: Mon, 05 Jun 2023 15:41:31 -0400
Message-ID: <>
To: Ilari Liusvaara <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000f024be05fd67172b"
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: Mon, 05 Jun 2023 19:41:53 -0000

On Wed, Mar 22, 2023 at 11:22 AM Ilari Liusvaara <>

> On Wed, Mar 22, 2023 at 01:54:22PM +0100, Bas Westerbaan wrote:
> > >
> > > Unpopular pages are much more likely to deploy a solution that
> > > doesn't require a parallel CA infrastructure and a cryptographer
> > > on staff.
> I don't think the server-side deployment difficulties with this have
> anything to do with parallel CA infrastructure or admins having to
> understand cryptography.
> > CAs, TLS libraries, certbot, and browsers would need to make changes,
> > but I think we can deploy this without webservers or relying parties
> > having to make any changes if they're already using an ACME client
> > except upgrading their dependencies, which they would need to do
> > anyway to get plain X.509 PQ certs.
> I don't agree.
> I think deploying this is much much harder than deploying X.509 PQ
> certificates. X.509 PQ certificates are mostly dependency update. This
> looks to require some nontrivial configuration work that can not be
> done completely automatically.
> And then in present form, this could be extremely painful for ACME
> clients to implement (on level of complete rewrite for many).

It’s true that this would require code changes in more components. But TLS,
ACME, etc., are deployed many more times than they are implemented. As the
code changes happen per software package, hopefully the per-deployment cost
beyond that can be minimal. (Though, of course, that will depend on exactly
how each package's existing configuration interface looks, and how/whether
they apply it to the new thing. Understanding what protocol properties
would make this easy or hard would be very useful, but I also suspect it
depends on a lot of details we've still left as placeholders right now.)

These things also don’t have to happen all at once. It can be a transition
over time, or perhaps some sites just stay with the fast-issuance mechanism
(be it X.509 PQ or something else) if they’re happy with it. Merkle Tree
Certificates themselves cannot be your only certificate type anyway, since
they only work with up-to-date RPs.

To ACME specifically, we definitely don’t want it to be painful for ACME
clients to implement! It’s probably a bit hard to discuss that in the
abstract, with our ACME section being just a placeholder. Perhaps, when
we’ve gotten an initial draft of that, we can figure out which bits we got
wrong and iterate on that?