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

[David Benjamin <[e-mail]>]

Ah true, a certificate viewer might want to just generically dump an
MTCProof, even if it cannot usefully validate it. Fair enough.

https://github.com/ietf-plants-wg/merkle-tree-certs/pull/334

On Tue, Sep 22, 2026 at 3:02 PM Corey Bonnell <dev=
[e-mail]> wrote:

> > Wouldn't you need such a mapping anyway?
>
> If MTCProof had a new OID, then no. The decoder sees the new OID and
> decodes the MTCProof with the 3-octet signatures length. If it sees the old
> OID, then it can decode with the 2-octet signatures length. None of that
> requires knowledge of the issuer, and no out-of-band information is
> required to decode.
>
> If the decoder is question is tightly coupled to a verifier, then perhaps
> it's acceptable to require context to decode. But there's other tooling
> such as certificate viewers, etc. that may not have access to
> issuer-specific information to successfully decode. For that tooling,
> having a fully self-describing format is optimal, and bumping the OID
> accommodates that.
>
> Thanks,
> Corey
>
>
>
> Sep 22, 2026, 12:24 by [e-mail]:
>
> (Well it wouldn't strictly be a mapping from the issuer. I assume, when
> you parse the new OID out of the issuer, you record the protocol version it
> is. And then based on the protocol version, you decide what signatures you
> verify. But yes.)
>
> Wouldn't you need such a mapping anyway? A relying party should not accept
> a draft-05 signatureValue from a draft-06 MTCA. Granted, converting between
> draft-05 and draft-06 is "obvious" but if you crossed the streams between,
> say, draft-03 and draft-04, you'd have a problem because we added an
> extensions block at that point.
>
> On Tue, Sep 22, 2026 at 11:42 AM Corey Bonnell <dev=
> [e-mail]> wrote:
>
> 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)
> 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]
>
>
>
> _______________________________________________
> Plants mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> Plants mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>