[Plants] Re: Call for adoption: draft-gray-plants-mtc-deploy-use-cases-01 (Ends 2026-10-02)

[John Gray <[e-mail]>]

Hi Panos,

Thanks for looking at the document.

I agree that the current draft reads like a big brainstorm.   That's largely because our work so far has focused on exploring where MTCs might provide value based on their key properties: small landmark-relative certificates, batch signing, and downgrade protection. Part of that exploration is determining where MTCs do not provide meaningful benefits.

In private PKI, certificates issued by public PKIs are common, and we expect that to remain true when MTCs are deployed. One challenge is how private PKI systems verify landmark certificates outside of browsers. That led to the landmark verifier concept. I agree there is enough material there for a separate draft, and I intend to move that detailed work out of this document in the next update.

At the working group meeting, we discussed pulling detailed topics into their own documents, and that's our plan for the next revision.  We also plan to address the question of when MTCs are and are not appropriate and add a section on when "To MTC or Not to MTC".   So, we are asking for adopting with the assumption that the working group thinks this work is useful.

We considered many potential use cases, but not all prove compelling. For example, we concluded that size savings for large code-signed binaries are unlikely to justify MTCs, whereas constrained environments with many signatures may benefit. Documenting both the successful and unsuccessful use cases is an important goal of this draft.

Another interesting use case is revocation, which is definitely going to continue to be needed in private PKI because keys usually live longer in private PKI.  We already have several ideas for how MTCs could help there.

In summary, we are seeking adoption so the working group can develop a document that clearly identifies where MTCs provide advantages, where they do not, and what problems they are best suited to solve. I fully agree the document needs work, as is often the case with newly adopted drafts.


Cheers,

John Gray


________________________________
From: Kampanakis, Panos <kpanos=[e-mail]>
Sent: Friday, September 18, 2026 11:27 PM
To: Thom Wiggers <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [EXTERNAL] RE: [Plants] Call for adoption: draft-gray-plants-mtc-deploy-use-cases-01 (Ends 2026-10-02)

I am against the adoption of this doc in its current state. Some reasons below. The document is trying to do too much in my opinion. To me, it reads like a set of brainstorming thoughts regarding MTC, operational considerations and theoretical


I am against the adoption of this doc in its current state. Some reasons below.

The document is trying to do too much in my opinion. To me, it reads like a set of brainstorming thoughts regarding MTC, operational considerations and theoretical non WebPKI use-cases, but it does not achieve what it says in the abstract which is to clearly explain how MTC would be used in no WebPKI use-cases and how.

The MTC landmark distribution mechanisms (section 3.1) could have value as a separate document for how Landmarks will be distributed operationally in any system, WebPKI or elsewhere.

On the use-case front, it reads like a brainstorming document that looks for problems for an existing solution. It is doubtful that ecosystems like Code Signing PKI or Private Enterprise PKI can reap the benefits of MTC because they can't stay up to date. There are certain reasons these systems did not pursue CT in the past, and they are not likely to go after MTC. The code-signing use-cases especially, it is impractical to consider boot sequences that have not even initialized the OS or brought up the networks to make use of landmarks. Additionally, the advantage of Cosigners in closed systems like Private PKI or Code Signing that is doubtful because these will still represent an entity which is part of the "system" operated by the "system". Things are different in the WebPKI, transparency and auditability have a different meaning. External independent Logs or Cosigners are different on the Internet compared to closed systems. Also, MTC in constrained devices (section 3.7) is farfetched. These ecosystems have devices competing in very low bandwidth environments additionally to their low storage. Synchronizing and fetching landmarks relatively frequently does not play well in these environments.

If a non WebPKI use-case could benefit from MTC, it needs to be clearly explained. For the Web it was relatively simple. Lots of small byte size connections which would suffer from big signatures, a CT ecosystem that was under pressure and needed redesign, existing infrastructure that could distribute the landmarks. Batch signing to alleviate the CAs was not a big factor. These characteristics are not attributes of all use-cases, so any use-case that can benefit needs to be clearly explained.

In many places, the document reads like it is advocating for certificate transparency or certificate auditing which has not been the case for non WebPKI use-cases due to their limitations. But there were reasons CT did not make it to Private PKI use-cases or others. It would be simpler for Private PKI, for example, to start operating a PQ CT Log next to the CA and include a PQ SCT in each Private PKI cert. If you combine that with ICA suppression, the Private PKI cert chain size would not be that big and you would not need to update the CA and all clients and all servers and operate a landmark distribution system. I have even seen repositories of auditable cert issuance logs serving as simple CT in a Private PKI use-case.

The argument about MTC downgrade protection is overstated. This is a certificate auditability advantage, not an MTC advantage necessarily. A CT signing MLDSA certs with MLDSA trees would provide downgrade protection too, it just happens that the WebPKI CT will not get PQ signatures.

The batch signing advantage is overstated. Certificate issuance processing load today is miniscule (an ECDSA signature is very cheap) and I am not sure if the MTC batching, landmarks, calculating and verifying the proofs will be significantly cheaper.

"With post-quantum signature algorithms, the per-operation signing cost increases relative to classical algorithms. " is inaccurate too, at least for MLDSA.

Rgs,
Panos




-----Original Message-----
From: Thom Wiggers via Datatracker <[e-mail]>
Sent: Friday, September 18, 2026 4:13 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: [EXTERNAL] [Plants] Call for adoption: draft-gray-plants-mtc-deploy-use-cases-01 (Ends 2026-10-02)

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



This message starts a plants WG Call for Adoption of:
draft-gray-plants-mtc-deploy-use-cases-01

This Working Group Call for Adoption ends on 2026-10-02

Abstract:
   Merkle Tree Certificates (MTC) I-D.ietf-plants-merkle-tree-certs has
   been defined for the use case of the WebPKI.  In this document we
   explore when and how MTC in parts or full can be used in different
   use cases.  Some of this use-cases may provide benefit for private
   PKI usage.

Please reply to this message and indicate whether or not you support adoption of this Internet-Draft by the plants WG. Comments to explain your preference are greatly appreciated. Please reply to all recipients of this message and include this message in your response.

Authors, and WG participants in general, are reminded of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [2].
Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy can be found at [3].

Thank you.
[1] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp78/__;!!FJ-Y8qCqXTj2!bxnhcXlbkPnwKCkbMI1i-RclIdlyFmdlBsLEjdNTyCeNL0r_sLSrqfEFYjq12YUd2ag6MDEgitzOK0Nc5rA2STr2j7POSmJi$
[2] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/bcp79/__;!!FJ-Y8qCqXTj2!bxnhcXlbkPnwKCkbMI1i-RclIdlyFmdlBsLEjdNTyCeNL0r_sLSrqfEFYjq12YUd2ag6MDEgitzOK0Nc5rA2STr2j9n1dREY$
[3] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/rfc6701/__;!!FJ-Y8qCqXTj2!bxnhcXlbkPnwKCkbMI1i-RclIdlyFmdlBsLEjdNTyCeNL0r_sLSrqfEFYjq12YUd2ag6MDEgitzOK0Nc5rA2STr2j7_bJavP$

The IETF datatracker status page for this Internet-Draft is:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-gray-plants-mtc-deploy-use-cases/__;!!FJ-Y8qCqXTj2!bxnhcXlbkPnwKCkbMI1i-RclIdlyFmdlBsLEjdNTyCeNL0r_sLSrqfEFYjq12YUd2ag6MDEgitzOK0Nc5rA2STr2j0YEX2u_$

There is also an HTML version available at:
https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-gray-plants-mtc-deploy-use-cases-01.html__;!!FJ-Y8qCqXTj2!bxnhcXlbkPnwKCkbMI1i-RclIdlyFmdlBsLEjdNTyCeNL0r_sLSrqfEFYjq12YUd2ag6MDEgitzOK0Nc5rA2STr2j7akbyeu$

A diff from the previous version is available at:
https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-gray-plants-mtc-deploy-use-cases-01__;!!FJ-Y8qCqXTj2!bxnhcXlbkPnwKCkbMI1i-RclIdlyFmdlBsLEjdNTyCeNL0r_sLSrqfEFYjq12YUd2ag6MDEgitzOK0Nc5rA2STr2j-m-EPSU$
_______________________________________________
Plants mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]


Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.