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

[Russ Housley <[e-mail]>]

Nalini:

The LAMPS WG already produced https://datatracker.ietf.org/doc/rfc9881/

What else needs to be said about using ML-DSA in a PKI?  If the document is not about MTC, it does not belong in the PLANTS WG.

Russ


> On Sep 23, 2026, at 11:19 AM, [e-mail] wrote:
> 
> > I am growing in the opinion that MTC is probably wrong for many private PKIs, including specifically IDevID ones.  I think it important that we set the scope sensibly.
> 
> I agree that MTC is potentially wrong for many private PKIs (actually, IMHO public PKIs also!).    Maybe we need a "Standalone ML-xxx Certificate Use Cases" document.   Let me think about if I have time to do this by San Francisco.  
> 
> Thanks,
> 
> Chief Technology Officer
> Outside the Stacks, Inc.
> https://www.outsidethestacks.com
> 
> Chief Operating Officer
> Industry Network Technology Council
> https://www.industrynetcouncil.org
> 
> 
> On Wednesday, September 23, 2026 at 07:21:18 AM PDT, Kampanakis, Panos <kpanos=[e-mail]> wrote:
> 
> 
> Hi Michael,
> 
> > okay, I agree: but adoption != publication, and late adoption hurts WG process in my opinion.
> > Adopting the document is a sign that this problem is important to the WG, not that you agree with the solution.
> 
> I don't know. What if I wrote a draft on how to use SLH-DSA in WebPKI in LAMPS? Should it be adopted on the premise that SLH-DSA could somehow, some day, find a use in WebPKI? If MTC or CT does not have a compelling benefit for Private PKI, or Code-Signing PKI, or constrained usecases and their operational reality, I don't think it should be adopted. I would like to see these compelling reasons before it makes sense to adopt, in my opinion. For now, they seem to be the cert transparency and auditability benefit which was already there with CT but these ecosystems did not pursue it, the batching benefit which is generally marginal in the grand scheme of things, and the size benefit.
> 
> 
> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Saturday, September 19, 2026 2:59 PM
> To: Kampanakis, Panos <kpanos=[e-mail]>; [e-mail] <mailto:[e-mail]>
> Subject: RE: [EXTERNAL] [Plants] Re: Call for adoption: draft-gray-plants-mtc-deploy-use-cases-01 (Ends 2026-10-02)
> 
> 
> Kampanakis, Panos <kpanos=[e-mail]> wrote:
>     > 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.
> 
> okay, I agree: but adoption != publication, and late adoption hurts WG process in my opinion.
> Adopting the document is a sign that this problem is important to the WG, not that you agree with the solution.
> 
>     > 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.
> 
> I am growing in the opinion that MTC is probably wrong for many private PKIs,
> including specifically IDevID ones.  I think it important that we set the
> scope sensibly.
> 
>     > On the use-case front...
> 
> I agree with you strongly, and that's why I want to adopt a work item around this.
> 
> --
> Michael Richardson <[e-mail]>  . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> **      My working hours and your working hours may be different.        **
> ** Please do not feel obligated to reply outside your normal working hours **
> 
> 
> 
> 
> _______________________________________________
> Plants mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> _______________________________________________
> Plants mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]