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

["Kampanakis, Panos" <kpanos=[e-mail]>]

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://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-gray-plants-mtc-deploy-use-cases/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-gray-plants-mtc-deploy-use-cases-01.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-gray-plants-mtc-deploy-use-cases-01
_______________________________________________
Plants mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]