Re: [TLS] Merkle Tree Certificates

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 22 March 2023 15:22 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA591C152565 for <tls@ietfa.amsl.com>; Wed, 22 Mar 2023 08:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVHZSCgaVCh5 for <tls@ietfa.amsl.com>; Wed, 22 Mar 2023 08:22:01 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1b.welho.com [83.102.41.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5268DC14CE42 for <tls@ietf.org>; Wed, 22 Mar 2023 08:22:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 24CBB204E4 for <tls@ietf.org>; Wed, 22 Mar 2023 17:21:58 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id FeVupAlTVc88 for <tls@ietf.org>; Wed, 22 Mar 2023 17:21:58 +0200 (EET)
Received: from LK-Perkele-VII2 (87-94-129-82.rev.dnainternet.fi [87.94.129.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id F237C2316 for <tls@ietf.org>; Wed, 22 Mar 2023 17:21:56 +0200 (EET)
Date: Wed, 22 Mar 2023 17:21:56 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <ZBsdFHiMN8lTsGP9@LK-Perkele-VII2.locald>
References: <167848430887.5487.1347334366320377305@ietfa.amsl.com> <CAF8qwaD9x5v1uU6mLtnUAGMnBW881ZE0ymK8rsQzrV2hfj7yHA@mail.gmail.com> <e1bffaf7-bca0-45d0-a844-39d20473c446@redhat.com> <a24924a2cc2b4afba890660bdc2c220d@amazon.com> <CAF8qwaBe6o3ASer_wnztse_Wk7RwofkpzuPfVGdo7AGjN6T9aw@mail.gmail.com> <8f6ffb56-ed99-46b9-92c4-e07b75f7d85c@redhat.com> <CAF8qwaD4HnPvnuHDNeXLgMkuqkFnOfpwk4DsjDb-SBudumeiug@mail.gmail.com> <7cf62fb9-6aaa-47cd-b988-bdfcf8911d63@redhat.com> <CAMjbhoXiw3K9D9t3ig4isRWkfVWHr1B9EOg91quf3Bbg8azopw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAMjbhoXiw3K9D9t3ig4isRWkfVWHr1B9EOg91quf3Bbg8azopw@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZZRjFfOjGRw2VEaTAUtYzwX60sE>
Subject: Re: [TLS] Merkle Tree Certificates
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2023 15:22:08 -0000

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).




-Ilari