Merkle Tree Certificates and Enterprises

[Nalini Elkins]

All,

I have started looking at the impact of Merkle Tree Certificates (MTC) on enterprise and private PKI deployments.

https://datatracker.ietf.org/doc/draft-ietf-plants-merkle-tree-certs/

This work was prompted by a discussion with a large enterprise. They pointed out that, for them, a certificate is much more than something used during a TLS handshake.

For example, imagine an employee authenticates to a corporate VPN using a client certificate. In some deployments, during authentication, the certificate is validated and the employee's identity is established. Many enterprise deployments then use certificate information—such as the Subject Distinguished Name (DN), Subject Alternative Name (SAN), Extended Key Usage (EKU), Certificate Policies, or enterprise-specific extensions—as inputs to authorization decisions, identity mapping, or audit logging. Years later, the organization may also need to retain enough information to reconstruct the authentication event for an audit, regulatory inquiry, or legal proceeding.

Another example is code signing. Organizations often archive signed software, the associated certificate, and validation information for many years. As enterprises migrate to post-quantum PKI and potentially to MTC, they will need guidance on what information should be preserved to maintain existing operational, audit, compliance, and evidentiary practices.

The enterprise's question was straightforward:

How should an enterprise continue to perform these functions in an MTC world?

As many of you know, one of the motivations for MTC is to reduce the impact of larger post-quantum certificates, particularly those using ML-DSA and related algorithms. Google and Cloudflare are actively evaluating MTC, and Cloudflare has described their work here:

https://blog.cloudflare.com/bootstrap-mtc/

DigiCert has also announced an MTC Playground for private PKI deployments.

I am trying to understand what guidance enterprises will need as they migrate to post-quantum PKI and, potentially, to MTC-based deployments.

Some of the questions I am exploring include:

• Can an MTC relying party continue to access and process certificate information—such as Subject DN, SAN, EKU, Certificate Policies, Name Constraints, and enterprise-specific extensions—in the same way it does today?

• If application, middleware, or validation library changes are required, what migration guidance should be provided?

• What information should enterprises archive for long-term audit, compliance, forensic, and evidentiary purposes?

• How should private PKIs deploy and operate MTC?

• What enterprise deployment patterns or best practices should be documented?

My intent is to feed these deployment considerations into the IETF PLANTS Working Group. If appropriate, I may also write an Internet-Draft describing enterprise/private PKI deployment considerations.

https://datatracker.ietf.org/group/plants/about/

If you work with a large enterprise or operate a significant private PKI, I would appreciate the opportunity to interview you about how your organization uses certificates today—not just for TLS authentication, but also for identity, authorization, compliance, auditing, and operational purposes.

Examples of topics include:

• How applications consume certificate information

• Reliance on SANs, EKUs, Certificate Policies, Subject DNs, and custom extensions

• Certificate retention and archival practices

• Private PKI deployment models

• Migration concerns for post-quantum PKI

• Enterprise operational practices that should be preserved during migration

All responses will be treated anonymously unless you explicitly indicate otherwise.

If you are interested in participating, please contact me at:

nalini...@outsidethestacks.com

Thank you,

Nalini Elkins
Chief Technical Officer

Outside the Stacks, Inc.

[John Mattsson]

Nalini Elkins wrote:

>How should an enterprise continue to perform these functions in an MTC world?

An enterprise would not necessarily use MTC. If ML-DSA/SLH-DSA meets the performance requirements, using normal ML-DSA/SLH-DSA certs is likely preferable. MTC must offer a clear advantage that justifies its additional complexity; otherwise, I think existing ML-DSA/SLH-DSA-based PKI deployments remain the natural choice.

Cheers,

John Preuß Mattsson

[Nalini Elkins]

John,

>An enterprise would not necessarily use MTC. If ML-DSA/SLH-DSA meets the performance requirements, using normal ML-DSA/SLH-DSA certs is likely preferable. MTC must offer a clear >advantage that justifies its additional complexity; otherwise, I think existing ML-DSA/SLH-DSA-based PKI deployments remain the natural choice.

That is interesting.  Yes, it does make life simpler, in some ways, for enterprises.  I am doing some testing / benchmarking of ML-DSA / classical certs.   Let me see if I can get some numbers for enterprises on what testing with mldsa.digicert.com provides as far as performance, size, etc.   Enterprises often have many SANs, so their certs are big to start with!   We are also putting up the Digicert MTC playground to see how hard that will be for enterprises to do.  If you know of other playgrounds, test sites, that will be great to know.

[Brent Kimberley]

Would SIS “MooN” ML-DSA signing improve determinism without compromising security strength?

 

From: 'John Mattsson' via pqc-forum <pqc-...@list.nist.gov>
Sent: June 25, 2026 11:42 AM
To: pqc-...@list.nist.gov; nalini...@insidethestack.com
Subject: [pqc-forum] Re: Merkle Tree Certificates and Enterprises

 

⚠️CAUTION: This email is from an external source. Verify sender before opening links and attachments.⚠️

 

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/AS4PR07MB88257153BBDFF37614E2C3AC89EC2%40AS4PR07MB8825.eurprd07.prod.outlook.com.

[Nalini Elkins]

Is there any kind of public test point for this?  Or a github where this is implemented?   We can also compare this.

[Antony Vennard]

On Thu, 2026-06-25 at 08:48 -0700, Nalini Elkins wrote:
> John,
>
> > An enterprise would not necessarily use MTC. If ML-DSA/SLH-DSA
> > meets the performance requirements, using normal ML-DSA/SLH-DSA
> > certs is likely preferable. MTC must offer a clear >advantage that
> > justifies its additional complexity; otherwise, I think existing
> > ML-DSA/SLH-DSA-based PKI deployments remain the natural choice.
>
> That is interesting.  Yes, it does make life simpler, in some ways,
> for enterprises.  I am doing some testing / benchmarking of ML-DSA /
> classical certs.   Let me see if I can get some numbers for
> enterprises on what testing with mldsa.digicert.com provides as far
> as performance, size, etc.   Enterprises often have many SANs, so
> their certs are big to start with!   We are also putting up the
> Digicert MTC playground to see how hard that will be for enterprises
> to do.  If you know of other playgrounds, test sites, that will be
> great to know.

MTC specifically requires cosigners to validate CA operation when
issuing certificates. This inverts the model of certificate
transparency. There's nothing to prevent running cosigners in an
enterprise but whether that is something people do is another question.

For your performance metrics you may wish to look at pre-existing work
such as this excellent talk at the PKI Consortium:
https://pkic.org/events/2025/pqc-conference-austin-us/THU_BREAKOUT_1130_Panos-Kampanakis_How-much-will-ML-DSA-affect-Webpage-Metrics.pdf

The video is available as well I believe.

As you might expect, a significant variable is whether you are
requesting a TLS round-trip per resource, or multiplexing over a small
number of connections.

Kind regards,

Antony

[Bas Westerbaan]

MTC specifically requires cosigners to validate CA operation when
issuing certificates.

Not necessarily. You don't need it if you don't care about transparency. Even if you need it, it might be simpler in private PKIs.

[Antony Vennard]

On Mon, 2026-06-29 at 11:44 +0200, 'Bas Westerbaan' via pqc-forum
wrote:

Ah indeed, I misread. The CA could indeed "co"-sign itself and not
submit anywhere else if not required.

> --
> You received this message because you are subscribed to the Google
> Groups "pqc-forum" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pqc-forum+...@list.nist.gov.
> To view this discussion visit

> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMjbhoXzRu58uUzxiBA2fCrT%3DfpAsPyF5A3sL7Ljabd_8xVcfw%40mail.gmail.com
> .