[Plants] Re: I-D Action: draft-ietf-plants-merkle-tree-certs-06.txt

Corey Bonnell <dev@cbonnell.com> Tue, 22 September 2026 13:54 UTC

Received: from mail.w14.tutanota.de (mail.w14.tutanota.de [185.205.69.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id B81EA3F for <plants@ietf.org>; Tue, 22 Sep 2026 13:54:37 +0000 (UTC)
Authentication-Results: mx.ietf.org; dkim=pass header.d=cbonnell.com header.s=s1 header.b=A4rDnjTF; dmarc=pass (policy=quarantine) header.from=cbonnell.com; spf=pass (mx.ietf.org: domain of dev@cbonnell.com designates 185.205.69.214 as permitted sender) smtp.mailfrom=dev@cbonnell.com
Received: from tutadb.w10.tutanota.de (w10.api.tuta.com [IPv6:fd:ac::d:10]) by mail.w14.tutanota.de (Postfix) with ESMTP id 4485E1884B357 for <plants@ietf.org>; Tue, 22 Sep 2026 15:54:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1790085270; s=s1; d=cbonnell.com; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=eeNbejepVYceR09BpyMPpb+AcrcAfoUEdnlBiK20s3c=; b=A4rDnjTFhcLeMtLTFHzeHCLrPCjWw9GNcSKZYus7O50+tC3rqcrVW2Ih0abG4pdq G8YistzXOS5XViB7DhfjUilN2vz0UsU7nVLgqvKYJmTbQc3im70kvIBnvDb1PGHOZ+b hVMNiegmX0F7nf55txmuiIpmTSznwAxDATUliGIVW9wRJmigekMJzUZcyhu7lGexcxj NsVB6g/wXvGhQ3GNEbk0ncXup16xOsNiF9Lko5318jt8xHVicEOx1ooQK5g2sNHhlzj paqIzMyT9p1mifd4uqL2Sc/pg+eJUTt8c3V3fcZdg4WZj0nOqmXuQ6WqmcR+B4GVt9U j0AHz83I3Q==
Date: Tue, 22 Sep 2026 15:54:30 +0200
From: Corey Bonnell <dev@cbonnell.com>
To: David Benjamin <davidben@chromium.org>
Message-ID: <P28OJsf--V-9@cbonnell.com>
In-Reply-To: <CAF8qwaDhL7ZbeiXG6cbrwq7EGGfV8w+AD6y7_BQshZLM_OL1TQ@mail.gmail.com>
References: <179002381788.457812.14528431091737903783@dt-datatracker-fffdbdc97-z7cq6> <CAF8qwaDhL7ZbeiXG6cbrwq7EGGfV8w+AD6y7_BQshZLM_OL1TQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_175508_814686751.1790085270274"
Feedback-ID: 01630311c468dee1f4dfda761a0f37d9a63d24abe1cfb4e8834f835feb0645bf230f6976df198db852fa356e768398d2255c64ec88955bef9d0183c358a84c331a:TurnOnPrivacy!:tutamail
X-Spamd-Bar: /
Message-ID-Hash: GDJ4LNEDSS3MWT3OYNSQGL2PRKP5SDPY
X-Message-ID-Hash: GDJ4LNEDSS3MWT3OYNSQGL2PRKP5SDPY
X-MailFrom: dev@cbonnell.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Plants <plants@ietf.org>
X-Mailman-Version: 3.3.10
Precedence: list
Subject: [Plants] Re: I-D Action: draft-ietf-plants-merkle-tree-certs-06.txt
List-Id: "PKI, Logs, And Tree Signatures" <plants.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/plants/IjmmPfsEHfx2EpPWcB2ZNmlUJLg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/plants>
List-Help: <mailto:plants-request@ietf.org?subject=help>
List-Owner: <mailto:plants-owner@ietf.org>
List-Post: <mailto:plants@ietf.org>
List-Subscribe: <mailto:plants-join@ietf.org>
List-Unsubscribe: <mailto:plants-leave@ietf.org>

Hello,
I was glad to see that a new (temporary) OID was assigned for the TrustAnchorID attribute type to reduce confusion caused by the switch from UTF8String to RELATIVE-OID.

Given that the wire format of the MTCProof has changed (signatures field can now be up to 16 MB in size instead of 64KB), it would be good to assign a new temporary OID for id-alg-MTCProof to similarly reduce confusion.
Could this be done in a fast follow-up -07?
Thanks,
Corey



Sep 21, 2026, 16:58 by davidben@chromium.org:

> Hi buds!
>
> Here is a cutting of draft-06 from the main branch. Here's a copy of the changelog. Implementations are starting to sprout, so things have shifted to rooting out the last few issues in advance of a concrete target for the first real deployments. Here's the changelog, reproduced from the appendix:
>
> * Use 24-bit length prefix for MTCProof subtree signatures.
> * Renamed MerkleTreeCertEntry, etc., structures to MTCLogEntry to be consistent with MTCProof, shorter, and help disambiguate the many English meanings of "entry".
> * Fixed one of the accumulated test vectors to better reflect one of the edge cases in subtree covering.
> * Make empty subtrees valid, so the subtree covering function always returns two subtrees.
> * Add an informative reference to the MTC-TLOG profile (> c2sp.org/mtc-tlog <http://c2sp.org/mtc-tlog>> ) and mention it where tile-based logs are discussed.
> * Clarify that a landmark consists of both a number and a tree size, and that a landmark's subtrees share its landmark number.
> * Give an exact procedure for selecting the landmark and covering subtree when constructing a landmark-relative certificate.
> * Prune the pruning discussion. It's really a property of the log serving protocol and is better described in [MTC-TLOG] and [TLOG-TILES].
> * Fix the maximum log index to account for also end being 48-bit.
> * Discuss a potential overflow in the valid subtree definition.
> * Describe how a party holding a standalone certificate can construct the corresponding landmark-relative certificate itself.
> * Added test vectors for subtree algorithms in larger trees.
> * Align the experimental OID with the final one in the X.509 name construction in using RELATIVE-OID directly.
> * Lifted the tree hash into the MTC CA extension OID, so it can capture new tree constructions more generally.
> * Update for draft-ietf-tls-trust-anchor-ids-05, and spell out certificate configuration explicitly.
> * Define active landmarks around landmark expiry and put the expiry time in the landmark format.
> * Fix an interaction between landmark-relative certs and TLS certificate_authorities.
>
> A peony for your thoughts,
>
> David
>
> On Mon, Sep 21, 2026 at 4:51 PM <> internet-drafts@ietf.org> > wrote:
>
>> Internet-Draft draft-ietf-plants-merkle-tree-certs-06.txt is now available. It
>>  is a work item of the PKI, Logs, And Tree Signatures (PLANTS) WG of the IETF.
>>  
>>     Title:   Merkle Tree Certificates
>>     Authors: David Benjamin
>>              Devon O'Brien
>>              Bas Westerbaan
>>              Luke Valenta
>>              Filippo Valsorda
>>     Name:    draft-ietf-plants-merkle-tree-certs-06.txt
>>     Pages:   104
>>     Dates:   2026-09-21
>>  
>>  Abstract:
>>  
>>     This document describes Merkle Tree certificates, a new form of X.509
>>     certificates which integrate public logging of the certificate, in
>>     the style of Certificate Transparency.  The integrated design reduces
>>     logging overhead in the face of both shorter-lived certificates and
>>     large post-quantum signature algorithms, while still achieving
>>     comparable security properties to existing X.509 constructions and
>>     Certificate Transparency.  Merkle Tree certificates additionally
>>     admit an optional size optimization that avoids signatures
>>     altogether, at the cost of only applying to up-to-date relying
>>     parties and older certificates.
>>  
>>  The IETF datatracker status page for this Internet-Draft is:
>>  >> https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/
>>  
>>  There is also an HTML version available at:
>>  >> https://www.ietf.org/archive/id/draft-ietf-plants-merkle-tree-certs-06.html
>>  
>>  A diff from the previous version is available at:
>>  >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-plants-merkle-tree-certs-06
>>  
>>  Internet-Drafts are also available by rsync at:
>>  rsync.ietf.org::internet-drafts
>>  
>>  
>>  _______________________________________________
>>  Plants mailing list -- >> plants@ietf.org
>>  To unsubscribe send an email to >> plants-leave@ietf.org
>>