Re: [TLS] Merkle Tree Certificates

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2459C15107B for <>; Mon, 5 Jun 2023 12:22:07 -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 ojZiz3AcQbwy for <>; Mon, 5 Jun 2023 12:22:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b29]) (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 87892C151071 for <>; Mon, 5 Jun 2023 12:22:03 -0700 (PDT)
Received: by with SMTP id 3f1490d57ef6-ba8151a744fso5824949276.2 for <>; Mon, 05 Jun 2023 12:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1685992922; x=1688584922; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hJEtllZrOnzWlQ+aNYUdOI8Rv8ZpiTbzVgm/pbEjMfc=; b=GWCMVZxjvi6sSEGWZckWyvRN5idEekhGbyrDi926lPaApfdCIEf6+DKHcI4j67k7eX rOu05PJjoD7ihR6641A/hSOy+goulq3Rhwg9mOfuahruQNv59iWFivdJOFq31vKJW/X2 spD4EoV/jPCs5rRihKvkt6vXJSgOPRrYvqvXk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1685992922; x=1688584922; 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=hJEtllZrOnzWlQ+aNYUdOI8Rv8ZpiTbzVgm/pbEjMfc=; b=bVY+ba53hfe3DceL54tpFfjN5F3MAEbWR4oMSMcqOVzv4t0MPezBEn/3TWqi7ghZ0s 8oNOus2T8jl2tV2n3zGm+wnR+iWZ6SeOvUU6Tmxyy8svDTEd++eJqd6Ap0NZ8JG/5rpZ UCDneerB1bDnukJ6oIIVMGwAXNpROLhuPqc/yGjBWW1+SS5ONAq0GFxJjReGchg3YhHd osNdJBTXhOx9eUIjBWyF3BF8MDlFv6Qsx+uTQNqAh8675Cww6LyWzlZYB/Q6Pvjos6AU ZjNc6IoXptVExhW9kauhBc4vweS30OxXIVyM/mQX4Cw5+OqIetJINHQDcm0Gx0SISVCs vkdA==
X-Gm-Message-State: AC+VfDxnkNyFGhv9jGv2LhDxmKuq4nq7sK1pCDIFCryAfTnYSGKrHuXo zRS9MDgmdprISGFXisytjFCerk0OHy16VEnHsioI
X-Google-Smtp-Source: ACHHUZ5Eyd7PIavYR8irDcmsyBw1ERNacbl3ejjUosLhMs5l4cDpxDprpIGAhHn6Iylzqizgj8/khRkucMX1NAfW/qo=
X-Received: by 2002:a81:a052:0:b0:560:beeb:6fc1 with SMTP id x79-20020a81a052000000b00560beeb6fc1mr11040270ywg.16.1685992922555; Mon, 05 Jun 2023 12:22:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Mon, 05 Jun 2023 15:21:45 -0400
Message-ID: <>
To: Watson Ladd <>
Cc: "<>" <>, Devon O'Brien <>
Content-Type: multipart/alternative; boundary="0000000000003e7e9e05fd66d112"
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:22:07 -0000

On Tue, Mar 14, 2023 at 1:47 PM Watson Ladd <> wrote:

> Come embrace the temptations of the Sea-SIDH!
> Intermediate certs are rarely used, so that would achieve 204 byte sig
> on intermediate+ 64 byte intermediate key + 204 byte  sig of EE cert
> since the signing time doesn't matter. Then with SCT and OCSP, it's
> 204 bytes each.

I wasn’t able to find a reference to a Sea-SIDH signature scheme. Do you
have a pointer? Do you mean this thing?

Taking 2 seconds to generate a signature is... certainly a constraint. :-)

> As for the actual proposal, I like the idea of per-protocol subjects.
> I am worried about the way this makes the PKI a more distributed
> system, in the Lamportian sense. A certificate being used successfully
> depends now on the transparency service propagating the batch from the
> CA and the CA creating the batch, and the user-agent, not the site,
> determines what transparency service is used. This makes it much more
> difficult for sites to be sure their certificates will actually work.

To some degree, subscribers already rely on this. RPs have various
requirements, and it is up to the CA to provide subscribers with
certificates that meet the requirements. Some requirements can be checked
by the subscriber, but some cannot.

In X.509, the certificate chain and signatures can be checked by the
subscriber. (Although X.509 is so complex and variable that it’s unlikely
the subscriber’s checks exactly matched the RP’s!) But other requirements,
notably future policy actions, cannot. The certificate may later be
revoked, the CA or CT log may be distrusted, etc.

In this proposal, we could have the CA pass the subscriber the signed
window alongside the proof (not currently in the draft, but this is a good
reason to include it). The subscriber can then check the inclusion proof,
hopefully with much less implementation variability than X.509.

The subscriber still needs to know if the RP recognizes that batch. These
are more dynamic than X.509 roots, but are covered by the negotiation
mechanism. On mismatch, you just pick another certificate, such as an X.509
one which is as checkable as before. So this part isn’t so much checked as
made moot. (A negotiation mechanism is ultimately “tell me if the RP will
accept this cert, so I can filter down to the ones that work”.)

Finally, subscriber and RP must agree on what, e.g, root hash #42 was. This
flows from CA to TS to RP, which is indeed hard for the subscriber to
directly check. (Though the subscriber could always fetch hashes from known
TSs to compare.) However, a mismatch here means the CA produced a split
view. The responsibilities have shifted, but analogous misbehavior in X.509
+ CT would typically result in a policy action, something the subscriber
already cannot check offline.