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 804C630 for ; Tue, 22 Sep 2026 15:42:29 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=cbonnell.com header.s=s1 header.b=swdYBh3f; 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 7177F1885F5E0 for ; Tue, 22 Sep 2026 17:42:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1790091748; 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=J4m7pvCIsCswBPUX3Oxp7756cm6myG0KfgADbVl5kPI=; b=swdYBh3fHugBXYtDBthCkvbJi483LFsP9iTDfK1YPVNt7bc6GhpIZMUek9SceyAr 6a7xLzbJBGOXFIPGfPI+clyaF9ZfnmefVbnOnCjQgCDZJzPdd5ibxCHWg3L8bZ9S58Z n92aUHNTgCU+pbzhzqzHvIsaqk1wuQ+V3YGJ/HszwOibrwnSVhIdZgid4wsxP0tYZb/ 84WT/y5sFF/6128nDzI1PDTd1S/tIK/1mZzh7Q12crYWgoZww7hfY28qECiOrQlJjV6 ZR4AR3VVxp82RWMC2tVKAr+me5Y38FIrgTn5KH7mgdmmrXvE99R8yhaMzyjjIbZNmFL Puzw+4UgFQ== Date: Tue, 22 Sep 2026 17:42:28 +0200 (CEST) From: Corey Bonnell To: David Benjamin Message-ID: In-Reply-To: References: <179002381788.457812.14528431091737903783@dt-datatracker-fffdbdc97-z7cq6> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_193774_162365215.1790091748458" Feedback-ID: 01630311c468dee1f4dfda761a0f37d9a63d24abe1cfb4e8834f835feb0645bf230f6976df198db852fa356e768398d2255c64ec88955bef9d0183c358a84c331a:TurnOnPrivacy!:tutamail X-Spamd-Bar: / Message-ID-Hash: VGXWLKCJUCHWICDAKWKRBTOLGHNOCMDW X-Message-ID-Hash: VGXWLKCJUCHWICDAKWKRBTOLGHNOCMDW 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 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" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: ------=_Part_193774_162365215.1790091748458 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My assumption is that it's unwieldy to maintain a mapping of issuers to MTC= Proof serialization formats, especially when that information can be direct= ly encoded in the OID. Thanks, Corey Sep 22, 2026, 11:20 by davidben@chromium.org: > OIDs are cheap, so that's easy enough. Though I was also thinking of requ= esting candidate[*] "final" OIDs from the PKIX registry soon, and that'll m= ake this moot. > > I originally didn't bump those just because their contents are meaningles= s without knowing the issuer anyway. If you know the issuer, you know the i= ssuer version and can interpret the MTCProof accordingly. If you don't know= the issuer, the signature value isn't very useful to you anyway (you don't= even know the log hash). > > Clearly my reasoning was overly simplistic, since it's been a nuisance fo= r you. I'm curious where the gap is. > > David > > [*] Obviously the document won't be done and the WG may yet make backward= s-incompatible changes. If we do, we'll need to get new final OIDs and aban= don the old ones. But OIDs are cheap, so that's not a huge deal. > > On Tue, Sep 22, 2026 at 9:54=E2=80=AFAM Corey Bonnell <> dev@cbonnell.com= > > wrote: > >> Hello, >> I was glad to see that a new (temporary) OID was assigned for the TrustA= nchorID attribute type to reduce confusion caused by the switch from UTF8St= ring 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 assig= n 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 th= e 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=C2=A0app= endix: >>> >>> * Use 24-bit length prefix for MTCProof subtree signatures. >>> * Renamed MerkleTreeCertEntry, etc., structures to MTCLogEntry to be co= nsistent with MTCProof, shorter, and help disambiguate the many English mea= nings of "entry". >>> * Fixed one of the accumulated test vectors to better reflect one of th= e edge cases in subtree covering. >>> * Make empty subtrees valid, so the subtree covering function always re= turns two subtrees. >>> * Add an informative reference to the MTC-TLOG profile (>>> c2sp.org/mt= c-tlog >>> ) and mention it where tile-based logs= are discussed. >>> * Clarify that a landmark consists of both a number and a tree size, an= d that a landmark's subtrees share its landmark number. >>> * Give an exact procedure for selecting the landmark and covering subtr= ee when constructing a landmark-relative certificate. >>> * Prune the pruning discussion. It's really a property of the log servi= ng 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 t= he 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 const= ruction 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 certific= ate configuration explicitly. >>> * Define active landmarks around landmark expiry and put the expiry tim= e in the landmark format. >>> * Fix an interaction between landmark-relative certs and TLS certificat= e_authorities. >>> >>> A peony for your thoughts, >>> >>> David >>> >>> On Mon, Sep 21, 2026 at 4:51=E2=80=AFPM <>>> internet-drafts@ietf.org>>= > > wrote: >>> >>>> Internet-Draft draft-ietf-plants-merkle-tree-certs-06.txt is now avail= able. It >>>> is a work item of the PKI, Logs, And Tree Signatures (PLANTS) WG of th= e IETF. >>>> >>>> =C2=A0 =C2=A0Title:=C2=A0 =C2=A0Merkle Tree Certificates >>>> =C2=A0 =C2=A0Authors: David Benjamin >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Devon O'Brien >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bas Westerbaan >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Luke Valenta >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filippo Valsorda >>>> =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 draft-ietf-plants-merkle-tree-certs-06= .txt >>>> =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0104 >>>> =C2=A0 =C2=A0Dates:=C2=A0 =C2=A02026-09-21 >>>> >>>> Abstract: >>>> >>>> =C2=A0 =C2=A0This document describes Merkle Tree certificates, a new f= orm of X.509 >>>> =C2=A0 =C2=A0certificates which integrate public logging of the certif= icate, in >>>> =C2=A0 =C2=A0the style of Certificate Transparency.=C2=A0 The integrat= ed design reduces >>>> =C2=A0 =C2=A0logging overhead in the face of both shorter-lived certif= icates and >>>> =C2=A0 =C2=A0large post-quantum signature algorithms, while still achi= eving >>>> =C2=A0 =C2=A0comparable security properties to existing X.509 construc= tions and >>>> =C2=A0 =C2=A0Certificate Transparency.=C2=A0 Merkle Tree certificates = additionally >>>> =C2=A0 =C2=A0admit an optional size optimization that avoids signature= s >>>> =C2=A0 =C2=A0altogether, at the cost of only applying to up-to-date re= lying >>>> =C2=A0 =C2=A0parties 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=3Ddraft-ietf-plants-merkle-t= ree-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 >>>> >> >> ------=_Part_193774_162365215.1790091748458 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My assumption is that it's unwieldy to maintain a mapping= of issuers to MTCProof serialization formats, especially when that informa= tion can be directly encoded in the OID.

<= div dir=3D"auto">Thanks,
Corey



Sep 22, 2026, 11:20 by davidben@chromium.org:
<= blockquote class=3D"tutanota_quote" style=3D"border-left: 1px solid #93A3B8= ; padding-left: 10px; margin-left: 5px;">
OIDs are cheap, so that's easy enough. Though I was also thinking of reque= sting candidate[*] "final" OIDs from the PKIX registry soon, and that'll ma= ke this moot.

I originally didn't bump those j= ust because their contents are meaningless without knowing the issuer anywa= y. If you know the issuer, you know the issuer version and can interpret th= e MTCProof accordingly. If you don't know the issuer, the signature value i= sn't very useful to you anyway (you don't even know the log hash).

Clearly my reasoning was overly simplistic, since it's= been a nuisance for you. I'm curious where the gap is.

<= /div>
David

[*] Obviousl= y the document won't be done and the WG may yet make backwards-incompatible= changes. If we do, we'll need to get new final OIDs and abandon the old on= es. But OIDs are cheap, so that's not a huge deal.

On Tue= , Sep 22, 2026 at 9:54=E2=80=AFAM Corey Bonnell <dev@cbonnell.com= > wrote:
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.
<= div dir=3D"auto">
Given that the wire format of = the MTCProof has changed (signatures field can now be up to 16 MB in size i= nstead 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 cutti= ng of draft-06 from the main branch. Here's a copy of the changelog. Implem= entations 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 deploym= ents. Here's the changelog, reproduced from the appendix:

* Use 24-bit length prefix for MTCProof = subtree signatures.
* Renamed MerkleTreeCertEntr= y, 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.
* Mak= e 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) and mention it where tile= -based logs are discussed.
* Clarify that a land= mark consists of both a number and a tree size, and that a landmark's subtr= ees share its landmark number.
* Give an exact p= rocedure for selecting the landmark and covering subtree when constructing = a landmark-relative certificate.
* Prune the pru= ning 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 defi= nition.
* Describe how a party holding a standal= one certificate can construct the corresponding landmark-relative certifica= te itself.
* Added test vectors for subtree algo= rithms in larger trees.
* Align the experimental= OID with the final one in the X.509 name construction in using RELATIVE-OI= D directly.
* Lifted the tree hash into the MTC = CA extension OID, so it can capture new tree constructions more generally.<= br>
* 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 ti= me in the landmark format.
* Fix an interaction = between landmark-relative certs and TLS certificate_authorities.
<= /div>

A peony for your thoughts,

David

On Mon, Sep 21, 2026 at 4:51=E2=80=AFPM <internet-draft= s@ietf.org> wrote:
Internet-Draft draft-ietf-plants-merkle-tree-certs-06.txt is now avai= lable. It
is a work item of the PKI, Logs, And T= ree Signatures (PLANTS) WG of the IETF.

   Title:   Merkle Tree Certificate= s
   Authors: David Benjamin
=
            Devon O'Brien
            Bas Wes= terbaan
           = ; Luke Valenta
         = ;   Filippo Valsorda
   Name:&nbs= p;   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 in= tegrate public logging of the certificate, in
&n= bsp;  the style of Certificate Transparency.  The integrated desi= gn reduces
   logging overhead in the = face of both shorter-lived certificates and
&nbs= p;  large post-quantum signature algorithms, while still achieving
=
   comparable security properties to exis= ting X.509 constructions and
   Certif= icate Transparency.  Merkle Tree certificates additionally
   admit an optional size optimization that avoid= s signatures
   altogether, at the cos= t of only applying to up-to-date relying
  =  parties and older certificates.

=
The IETF datatracker status page for this Internet-Draft = is:

There is als= o an HTML version available at:
=
A diff from the previous version is available a= t:

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts

______________________= _________________________
Plants mailing list --= plants@ietf.org
To unsubscribe send a= n email to plants-leave@ietf.org


------=_Part_193774_162365215.1790091748458--