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

[David Benjamin <[e-mail]>]

On Wed, Sep 23, 2026 at 3:57 PM Michael Richardson <[e-mail]>
wrote:

>
> [e-mail] <[e-mail]> wrote:
>     > The problem is that I was not able to make a cert with ML-DSA work
>     > correctly without importing the root cert.  Try it yourself with
>     > mldsa.digicert.com.  I, personally, feel this is not something
> which is
>
> Nalini, this is true for every algorithm.
>
> If/When the public anchors move to MLDSA (or MTC or 3ROT13), then those
> anchors will be commonly present.
>
> RFC9915 is necessary, but I don't think it is sufficient.
>
> {If we want non-MTC PKI to work with browsers, such as for Quantum-Safe
> Enterprise
> (private) PKI, then we'll need to make sure that the non-MTC does not go
> away.  I think that there is a real risk}
>

Chrome already supports RFC 9915 in non-MTC private PKIs, and has since I
think around June. The way you use a *private* PKI in a *browser* is that
you add that root, and it sounds like adding that root indeed worked.

If you *don't* add any roots, now you're talking about the *default* trusted
roots. For Chrome, that is the Chrome Root Store. There, yes, the plan is
to use MTCs because, for *this* configuration, there is a security
requirement to use a transparency mechanism, which then leads to all the
motivations discussed in the interim for MTCs.

None of that needs to impact private PKIs. Sure, *i**f* some private PKI
*does* get value out of MTCs, I'm very interested in making MTCs work for
that PKI. But, if not, that's cool. Use RFC 9915. The RFC 9915 support in
Chrome isn't going to go away with MTCs or anything.

David