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

[Corey Bonnell <[e-mail]>]

My assumption is that it's unwieldy to maintain a mapping of issuers to MTCProof serialization formats, especially when that information can be directly encoded in the OID.
Thanks,
Corey



Sep 22, 2026, 11:20 by [e-mail]:

> OIDs are cheap, so that's easy enough. Though I was also thinking of requesting candidate[*] "final" OIDs from the PKIX registry soon, and that'll make this moot.
>
> I originally didn't bump those just because their contents are meaningless without knowing the issuer anyway. If you know the issuer, you know the issuer 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 for you. I'm curious where the gap is.
>
> David
>
> [*] Obviously 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 ones. But OIDs are cheap, so that's not a huge deal.
>
> On Tue, Sep 22, 2026 at 9:54 AM Corey Bonnell <> [e-mail]> > 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.
>>
>> 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 >> [e-mail]>> :
>>
>>> 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 <>>> [e-mail]>>> > 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 -- >>>> [e-mail]
>>>> To unsubscribe send an email to >>>> [e-mail]
>>>>
>>
>>