Post-Quantum Certificates for Public TLS Are Three Proposals That Disagree - Merkle Tree Certificates, Pure ML-DSA Chains, Composite Signatures, and Where AWS Fits

First Published: 2026-10-21
Last Updated: 2026-10-21

On October 20, 2026, the path for moving publicly trusted TLS certificates to post-quantum (PQ) signatures is not settled on one. Chrome's root program has published, as a draft, the policy for a new root store that accepts only Merkle Tree Certificates (MTC). A proposal (SC-106) to add pure ML-DSA chains to the Baseline Requirements sits as a Draft pull request on the CA/Browser Forum's GitHub. The IETF LAMPS working group's Internet-Draft for composite signatures has IESG approval and is in the RFC Editor queue. Apple's root program has announced that it will establish a policy for MTC for server authentication and amend its policy to accept composite root certificates for Secure Email.

This article reads these three paths not as feature introductions but as contract tables. For each path, it lists who decides, what is required, the stage on the check date, what signs what, what is currently possible on AWS, what the sources do not state, and what stays with the user. It does not say which path is better, nor does it estimate when the transition will be complete. Pricing is also not discussed.

This article was checked on October 20, 2026. The results in Section 11 were checked on a configuration built with a local OpenSSL 3.5. The other sections were written from the sources.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. The Three Paths at a Glance
4. Merkle Tree Certificates: Chrome's CQRP Draft and Apple's Announcement
5. Pure ML-DSA Chains: SC-106 at the CA/Browser Forum
6. Composite Signatures: The IETF LAMPS Format and Apple's Secure Email Plan
7. Where the Sources Disagree
8. CAs and Operators That Have Announced or Are Testing MTC Issuance
9. How to Read the Migration Timelines
10. Choosing a Chain During a Cross-Signed Transition
11. What This Configuration Returned: A Record from a Local OpenSSL 3.5
12. Where AWS Comes In
13. Failure Modes
14. Frequently Asked Questions About Post-Quantum Certificates for Public TLS
15. Summary
16. References

1. Scope and Assumptions

This section defines the intended audience, outlines the scope of this article, clarifies the differences between signatures and key exchanges, and distinguishes between public PKI and private PKI. It also names the sources read. The conclusions come first:

MTC: The policy of Chrome's Chrome Quantum-resistant Root Program (CQRP) is [DRAFT] Version 0.3.0 (last updated August 14, 2026). The draft says that the new root store will consist only of MTC CAs. Apple has announced that it expects to publish a draft MTC policy for server authentication by the end of October 2026. The MTC format is an Internet-Draft of the IETF PLANTS working group.
Pure ML-DSA Chains: SC-106 proposes adding chains that use ML-DSA for signatures from root to leaf to the Baseline Requirements. As of October 20, 2026, this is a Draft pull request on GitHub. The CA/Browser Forum ballots page has no row for SC-106. The proposal's summary names users other than browsers as its target.
Composite Signatures: This format combines traditional signatures with ML-DSA signatures within a single signature. The IETF draft is currently in the RFC Editor's queue and does not yet have an RFC number. Apple's announcement relates to Secure Email. No root program or CA/Browser Forum document proposing composite for public TLS server certificates was found.
AWS's Position: The sources for ACM, ALB, NLB, and CloudFront give certificate keys as RSA and ECDSA. AWS Private CA can create ML-DSA CAs and issue ML-DSA certificates, but that is inside a private PKI. The AWS Private CA FAQ says that it does not support MTC at this time.

1.1 Intended Readers

This article is for developers and operators who:

Obtain TLS certificates from ACM, Let's Encrypt, or commercial Certificate Authorities (CAs).
Utilize those certificates with ALB, CloudFront, or servers they manage themselves.
Assume the following: getting an ML-DSA X.509 certificate from today's CA takes care of PQ certificates; Chrome already accepts ML-DSA certificates; the CA/Browser Forum has decided the PQ path; composite is now a standard; ACM can request ML-DSA certificates.

None of these matches the text of the sources this article read. The CQRP draft says Chrome will not add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. Chrome's ML-DSA support, shipped in June 2026, is listed under the heading User-added roots in the Chromium slides (Section 5.4). SC-106 is a Draft pull request (Section 5). The draft for composite signatures is currently in the RFC Editor's queue (Section 6). The ACM User Guide says ACM supports these RSA and ECDSA public key algorithms (Section 12).

1.2 What This Article Covers and What It Does Not

This article covers three paths for moving TLS server certificates on the public web to PQ signatures. For each path, it lists who decides, what is required, the stage on the check date, the chain shape, where the sources disagree, and the position on AWS.

This article does not cover:

Pricing and billing structures.
How the three paths rank, predictions about which path will spread, or estimates for the completion of the transition.
Key exchange. Hybrid key exchange using ML-KEM is a separate transition from signatures (Section 1.3). Information on PQC standardization timelines and AWS key exchange support can be found on this site's Post-Quantum Cryptography Standardization Timeline and Migration on AWS.
The cryptographic details of the Merkle tree in MTC. This article limits its discussion to a single paragraph in Section 4.1.
Methods for enforcing ML-DSA variants within AWS. This is covered in this site's Enforcing an ML-DSA Policy on AWS.
The network perspectives from which CAs validate domains. This is addressed in this site's When Five Network Perspectives Must Agree.
Procedures for signature forgery, downgrade attacks, or attacks that strip a PQ requirement.
Proposals other than the three paths.

1.3 Signatures and Key Exchange

Making TLS quantum-resistant involves two separate transitions: key exchange and certificate signatures.

Key exchange is the portion of the handshake process responsible for establishing a shared secret. Hybrid key exchanges, such as X25519MLKEM768, modify only the computations performed at each end, without changing the server's certificate. AWS's "What's New" announcements indicate that CloudFront (September 5, 2025) and ALB and NLB (November 21, 2025) offer post-quantum key exchange options. These involve key exchanges using ML-KEM and do not pertain to certificate signatures. Key exchange is addressed in detail on this site at Post-Quantum Cryptography Standardization Timeline and Migration on AWS.

Certificate signatures are the part that shows the server is genuine. Signatures from the CA, intermediate CAs, and Certificate Transparency travel in the handshake. This article is about paths for moving these signatures to post-quantum algorithms. The Apple post says that TLS handshakes typically contain 5 signatures and 2 public keys.

1.4 Public PKI and Private PKI

This article will discuss public PKI and private PKI separately.

Public PKI: This refers to a PKI hierarchy rooted in certificate authorities that are pre-trusted by browsers and operating systems. The Chrome Root Store and the Apple Root Program are examples. Publicly issued web certificates fall under this category.
Private PKI: This refers to a PKI hierarchy rooted in certificate authorities that are added by organizations or users themselves. Google's blog describes private PKIs as those not included in the Chrome Root Store. Certificates issued by AWS Private CA, for example, fall under this category.

ML-DSA certificates can already be made in a private PKI. Chrome's CQRP FAQ says Beginning in Chrome 150, Chrome supports ML-DSA in private PKI hierarchies. Which path a public PKI accepts is what the three paths in this article are about.

1.5 Sources Read and the Check Date

This article was written after reviewing the following materials on October 20, 2026. Because the sources are of different kinds, the text and the tables say which kind each statement comes from.

Kind	Sources
Draft policy	Chrome Quantum-resistant Root Program Policy (`[DRAFT]`, Version 0.3.0), its testing instructions, FAQ, and application page
GitHub pull request	`cabforum/servercert` pull request #679 (SC-106) and its comments
IETF documents	Datatracker pages of `draft-ietf-plants-merkle-tree-certs`, `draft-ietf-lamps-pq-composite-sigs`, `draft-ietf-lamps-pq-composite-kem`, `draft-ietf-tls-mldsa`, and RFC 9881
Blog posts	Google (2026-02-27), Let's Encrypt (2026-06-03), Cloudflare (2026-09-29, two posts), AWS Security Blog (2026-10-12)
Slides	IAB Workshop on Accelerating the Deployment of Post-Quantum Authentication (pqws, 2026-10-11 and 2026-10-12): Chromium, and AWS with OpenSSL
Group post	Apple Root Program post on the Chromium `ct-policy` group (2026-09-21 UTC)
AWS documentation	ACM User Guide, Application Load Balancer guide, CloudFront Developer Guide, AWS Private CA User Guide, API Reference and FAQ, What's New

Chrome's list of test cosigners, cosigners.json, was obtained on October 20, 2026. Its version is 2.0.11, and its timestamp is 2026-10-15T22:30:30Z.

2. How to Read the Tables

This section defines the columns of the tables in this article and the terms for status.

2.1 Common Columns

The tables in this article use the following seven column names. The Chain Shape column is specific to this article. The other six columns are common to two related articles on this site.

Column	What the cell holds
`Who Sets It`	The body that decides: a root program, the CA/Browser Forum, the IETF, or AWS
`What It Requires`	What the document requires or permits, in its own words
`Status on the Check Date`	The stage of the document on 2026-10-20, using the terms in Section 2.2
`Chain Shape`	What signs what, from the root to the server's key
`Where AWS Comes In`	What you can set on AWS today, and what AWS has already done
`No Statement Found`	What the sources do not state, with the sources searched
`What Stays With You`	What no document takes over and remains with the certificate user

2.2 Terms for Status on the Check Date

The Status on the Check Date column holds only the following eight terms. This article does not describe a document's status in stronger terms than these.

Term	Meaning in this article
`Draft policy`	A policy text published and marked as a draft
`Draft pull request`	A GitHub pull request marked as Draft
`Internet-Draft`	An active IETF Internet-Draft that the IESG has not approved
`In the RFC Editor queue`	Approved by the IESG and waiting for an RFC number
`Published RFC`	Published with an RFC number
`In effect`	Shipped in a product or in force in a published policy
`Scheduled`	A date written into a policy that is not a draft
`Announced`	A plan or intent stated in a blog post, slide, or group post, without a policy text

An effective date written in a Draft policy is listed as Draft policy, not Scheduled, because the date can change if the draft changes.

2.3 Documented Values, This Article's Inferences, and Demo Values

The tables in this article hold only values from the sources. When a specific statement cannot be found in the source material, it is marked No statement found, and the sources searched are named in the same cell or sentence. It does not say that the feature does not exist. When a conclusion comes from combining statements in the sources, the text calls it an inference.

The values in Section 11 are the results of one configuration built on a local OpenSSL 3.5. They sit in a separate section from the source values, and the tables do not mix the two.

3. The Three Paths at a Glance

This section summarizes the shape and status of the three paths in one table. Sections 4 to 6 give the detailed requirements.

MTC: The CA signs the head of a tree (tree head) that collects many certificates. The server sends a short proof (inclusion proof) that its certificate is in that tree. Chrome's CQRP also requires a cosignature from another operator's mirror, and Apple's announced policy is expected to require one as well; the IETF draft makes mirroring optional.
Pure ML-DSA chain: This path keeps the existing X.509 chain structure, but makes the keys and signatures of the root, intermediate CA, and leaf all ML-DSA.
Composite signatures: This path creates a single signature using a combination of ML-DSA and a traditional signature algorithm. The LAMPS draft lists RSA, ECDSA, Ed25519, and Ed448 as the traditional algorithms; Apple's post names ECDSA or RSA.

Path	`Chain Shape`	`Who Sets It`	`Status on the Check Date`
MTC in Chrome	CA cosigner signs a tree head; a mirror cosigns; the server sends an inclusion proof, or a standalone certificate with at least two cosignatures	Chrome Root Program (CQRP)	`Draft policy` (Version 0.3.0, last updated 2026-08-14)
MTC at Apple	Expected to require three cosignatures per certificate: ML-DSA and ECDSA from the issuing operator, ML-DSA from a mirror operator	Apple Root Program	`Announced` (draft policy expected by the end of October 2026)
MTC format	Merkle Tree certificates, an X.509 form with built-in logging	IETF PLANTS working group	`Internet-Draft` (`-07`, 2026-10-07)
Pure ML-DSA chain	ML-DSA root, ML-DSA intermediate, ML-DSA leaf	Proposed to the CA/Browser Forum Server Certificate Working Group	`Draft pull request` (opened 2026-08-26)
Composite signatures	One signature combining ML-DSA with a traditional algorithm (RSA, ECDSA, Ed25519, or Ed448 in the LAMPS draft)	IETF LAMPS working group	`In the RFC Editor queue` (IESG approved 2026-04-22)
Composite at Apple	Traditional X.509 root CA certificates with composite algorithms, for Secure Email	Apple Root Program	`Announced`

4. Merkle Tree Certificates: Chrome's CQRP Draft and Apple's Announcement

This section discusses Merkle Tree Certificates (MTCs), reading Chrome's draft policy, the test root store, Apple's announcement, and the IETF draft.

4.1 What an MTC Signs

In MTC, CAs do not sign certificates individually. The Chrome CQRP FAQ says that a CA signs a single "Tree Head" representing millions of certificates and that the server sends a compact Merkle Tree proof of inclusion. Because adding a certificate to the tree is the issuance itself, transparency becomes part of issuance. The abstract of the MTC draft says that an optional size optimization avoids signatures, at the cost of applying only to up-to-date relying parties and older certificates. A Let's Encrypt blog post describes the standalone form as the fallback when a relying party's information is out of date. The CQRP testing instructions require at least two cosignatures for standalone certificates (Section 4.3). The idea of MTC is also described in the Where This Is Heading section of this site's TLS Certificate Ecosystem History and Timeline.

4.2 What Chrome's CQRP Draft Requires

The title of the CQRP policy page is [DRAFT] Chrome Quantum-resistant Root Program Policy, Version 0.3.0, and its last update is August 14, 2026. The draft calls the new root store the Chrome Quantum-resistant Root Store (CQRS) and keeps it separate from the existing Chrome Root Store. The draft states that the CQRS relies entirely on MTC CAs and that Inclusion in the Chrome Root Store does not guarantee admission into the CQRS.

The following table extracts what the draft requires of MTC CAs, based on the version as of the check date.

Item	What the draft says
Traditional X.509 with PQ	`Chrome will not add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store`
CA cosigner keys	ML-DSA-44; Active CA Cosigner #1 and Reserve CA Cosigners #1 and #2 are required; Active CA Cosigners #2 to #4 are optional (three to six keys)
Subscriber validity	7 days for Active CA Cosigner #1; up to 47 days for the optional Active CA Cosigners
Recommendation	`In general, the use of ML-DSA-44 keys and a 7-day Subscriber certificate validity is RECOMMENDED.`
Future keys	`A future policy update is expected to allow use of up to 3 ML-DSA-87 CA Cosigner Keys.` These keys `MUST only issue 7-day certificates`
Mirroring cosigner keys	`Mirroring Cosigner Keys MUST be ML-DSA-44`
ML-DSA variant	`MUST NOT use HashML-DSA; only "pure" ML-DSA is permitted`
Subscriber keys	The Baseline Requirements algorithms, and ML-DSA-44, ML-DSA-65, or ML-DSA-87 as `MAY`
Pre-issuance linting	`Effective September 15, 2027`, linting must block issuance for certificates that fail it
Cosigner HSMs	`Effective January 1, 2029`, HSMs storing CA cosigner keys not already trusted by Chrome must have a CMVP certification that covers ML-DSA and ML-KEM
References to the MTC specification	`[TODO: point to final/latest spec before v1.0.0 of this policy]` remains in the text

The draft still contains the marker [TODO: point to final/latest spec before v1.0.0 of this policy] where references to the specification are to be filled in later. As Section 2.2 says, the effective dates in the draft are read as Draft policy values.

4.3 The Test Root Store and cosigners.json

The CQRP testing instructions page (last updated October 16, 2026) describes a test root store that is separate from production. According to that page, the test root store is delivered to Chrome but is not trusted for production. Users can test it by enabling two flags in Chrome 152 and later (Chrome Canary on the check date). For requests for test cosigners, the page says Chrome will begin processing requests starting July 31, 2026.

Test cosigners appear in cosigners.json with the realm value UNTRUSTED_VALIDATION_ONLY. The page says that this value distinguishes them from production CAs, which use PUBLICLY_TRUSTED. The cosigners.json retrieved on October 20, 2026 (version 2.0.11) contains data for 4 operators, 3 issuers, and 3 mirrors, and all six issuers and mirrors have a realm value of UNTRUSTED_VALIDATION_ONLY. There was no entry for PUBLICLY_TRUSTED. All three issuers have a spec_version of DRAFT05.

The page says that testing requires the same number of cosignatures as production. Standalone certificates require at least two cosignatures: one from the MTC CA operator and one from the mirror. New CA cosigners must follow draft-ietf-plants-merkle-tree-certs-07.

4.4 The MTC Policy Apple Has Announced

The Apple Root Program posted to the Chromium ct-policy group (shown as September 22, 2026 in UTC+9, which is September 21, 2026 in UTC; posted by Dustin Hollenback). The post says:

A new Apple Root Program policy is being established for Merkle Tree Certificates (MTCs), for Server Authentication only.
Apple Root Program expects to publish a draft MTC policy by the end of October 2026 at https://github.com/apple/apple-root-program.

The post lists six things that the draft is expected to require:

Three cosignatures per certificate: one from the issuing operator using ML-DSA (minimum ML-DSA-44), one from the issuing operator using ECDSA (minimum ECDSA-P256-SHA256), and one from a separate operator acting as a mirror (minimum ML-DSA-44).
Cosigner keys must be held within a FIPS 140-3 Level 3 or Common Criteria EAL 4+ HSM.
Operators register PENs with IANA as the basis for Trust Anchor Identifiers.
The maximum validity period for certificates is seven days.
Annual audits are required.
Operators publish far more non-private operational detail than before, including a record for every domain validation.

The post says that Apple expects to begin accepting applications from MTC CA operators by late Summer 2027. As of October 20, 2026, the MTC draft was not found in the apple/apple-root-program repository. The latest commit was made on October 16, 2026. Therefore, the Status on the Check Date is Announced.

The post states that a reason for choosing MTC is that experimentation with ML-DSA in traditional X.509 hierarchies has shown to cause significant degradation of TLS handshakes in real-world deployments.

4.5 The IETF MTC Draft

The MTC format is the IETF PLANTS working group's draft draft-ietf-plants-merkle-tree-certs-07 (October 7, 2026). According to the datatracker, the working group status is WG Document, and the IESG status is I-D Exists. The draft's header says Intended status: Standards Track, and the datatracker field Intended RFC status is (None). The authors are from Google, Apple, Cloudflare, and Geomys. Therefore, the Status on the Check Date is Internet-Draft.

4.6 MTC Contract Tables

The following two tables list the four MTC sources in the columns of Section 2.1.

Source	`Who Sets It`	`What It Requires`	`Status on the Check Date`
CQRP policy (production CQRS)	Chrome Root Program	MTC CAs only; ML-DSA-44 cosigner keys; 7-day or up to 47-day subscriber validity; no HashML-DSA	`Draft policy`
CQRP testing root store	Chrome Root Program	Cosigners listed with `UNTRUSTED_VALIDATION_ONLY`; at least two cosignatures on a standalone certificate	`In effect` for testing only (Chrome 152 or later with flags)
Apple MTC policy	Apple Root Program	Expected to require: three cosignatures (ML-DSA and ECDSA from the issuer, ML-DSA from a mirror); 7-day validity; annual audit	`Announced`
MTC specification	IETF PLANTS working group	The certificate, log, and cosignature formats	`Internet-Draft`

Source	`Where AWS Comes In`	`No Statement Found`	`What Stays With You`
CQRP policy (production CQRS)	AWS Private CA FAQ: `AWS PCA does not support Merkle Tree Certificates (MTC) at this time.`	An AWS service that issues or serves MTCs (AWS Private CA FAQ, ACM User Guide, What's New)	Choosing a CA that will issue MTCs; ACME client support
CQRP testing root store	None; the test root store is in Chrome	None	Testing with Chrome Canary and flags
Apple MTC policy	None	The draft policy text (`apple/apple-root-program`, latest commit 2026-10-16)	Watching the repository for the draft
MTC specification	None	An RFC number (datatracker)	Tracking the draft version

5. Pure ML-DSA Chains: SC-106 at the CA/Browser Forum

This section reads pull request #679 in the CA/Browser Forum's servercert repository (titled SC-106: Enable Post-Quantum Cryptography (PQ) Key Pairs in TLS Server Certificates).

5.1 What SC-106 Proposes

The summary of the pull request describes the proposal as follows:

This ballot adds ML-DSA (FIPS 204) as a permitted key and signature algorithm in publicly-trusted TLS server certificates, including ML-DSA-signed CA certificates, CRLs, and OCSP responses, enabling the certificate ecosystem to begin migrating to post-quantum authentication.

The commit description says that it permits ML-DSA-44, ML-DSA-65, and ML-DSA-87 and requires pure post-quantum chains. An ML-DSA public key is certified by an ML-DSA signature, and an ML-DSA signature certifies only an ML-DSA public key. CRLs and OCSP responses, which do not certify a public key, are the exception. The commit description also states that this proposal is a continuation of cabforum#662.

Under the heading Why not permit mixed classical and post-quantum chains? in the Policy Rationale section, the pull request text explains that if a chain contains a traditional signature anywhere, the authentication below it is only as strong as that traditional signature.

5.2 Who the Proposal Is For

The summary states who the proposal is for:

Many Relying Parties validate server certificates through system and library trust stores and have no practical path to post-quantum authentication within the existing X.509 public trust infrastructure. These include SDK-based service clients, embedded and IoT systems, enterprise middleware, and applications that authenticate against system trust stores managed by operating system vendors.

The summary states the effect on root programs:

Passing this ballot does not compel any Root Store Operator to accept ML-DSA. Whether ML-DSA certificates are trusted within a root program's hierarchy remains governed entirely by that program's own policy, and those policies today restrict keys to RSA and ECDSA.

In other words, SC-106 is not written as an alternative to MTC for the browser web. Its target is relying parties other than browsers, and even if it entered the Baseline Requirements, it would not make root programs accept ML-DSA. One of the comments on the pull request also states the target of the proposal as the use-cases that this ballot is focusing on (non WebPKI).

5.3 The Status of SC-106

As of October 20, 2026, pull request #679 is a GitHub Draft. It was created on August 26, 2026, and the author's display name is slghtr-says. The author changed the title number from SC-1XX to SC-106 on August 27, 2026. The CA/Browser Forum ballots page lists ballots up to SC105 and has no row for SC-106. The last comment was made on August 31, 2026.

Therefore, the Status on the Check Date is Draft pull request. This article does not describe SC-106 as voted on, passed, failed, or withdrawn. It uses the number SC-106 as the number in the pull request title.

5.4 The X.509 and TLS Pieces

To use a pure ML-DSA chain, both X.509 and TLS require ML-DSA definitions.

RFC 9881: Defines the algorithm identifiers for ML-DSA in X.509. The status in the datatracker is RFC - Proposed Standard (October 2025).
draft-ietf-tls-mldsa: Specifies how to use ML-DSA in TLS 1.3. The version is -06, and the intended status is Informational. The datatracker history shows that the IESG approval announcement was sent on September 10, 2026, after a hold while an appeal was reviewed. The IESG status is RFC Ed Queue, and the RFC number is not yet assigned. The history also shows that the document was held at the RFC Editor stage from September 24 to October 5, 2026.

Page 5 of the Chromium slides at the IAB pqws (October 2026) says under the heading User-added roots: Chrome shipped RFC 9881 and draft-ietf-tls-mldsa in June 2026. Under the heading Chrome root store on the same page, it says about MTC: Expect to have CAs and client support early 2027. The June 2026 shipment was for roots that users add.

5.5 Pure ML-DSA Chain Contract Tables

Source	`Who Sets It`	`What It Requires`	`Status on the Check Date`
SC-106 (pull request #679)	Proposed to the CA/Browser Forum Server Certificate Working Group	ML-DSA-44, ML-DSA-65, ML-DSA-87; an ML-DSA key certified only by an ML-DSA signature; CRLs and OCSP excepted	`Draft pull request`
RFC 9881	IETF LAMPS working group	Algorithm identifiers for ML-DSA in X.509	`Published RFC`
`draft-ietf-tls-mldsa`	IETF TLS working group	ML-DSA signature schemes in TLS 1.3	`In the RFC Editor queue`
Chrome, user-added roots	Chrome	RFC 9881 and `draft-ietf-tls-mldsa` for roots that users add	`In effect` (shipped June 2026)

Source	`Where AWS Comes In`	`No Statement Found`	`What Stays With You`
SC-106 (pull request #679)	ACM requests and imports accept RSA and ECDSA keys (Section 12)	A ballots page entry for SC-106 (`cabforum.org` ballots page)	A public CA that issues ML-DSA certificates under a root program's policy
RFC 9881	AWS Private CA issues ML-DSA CA certificates and certificates in a private PKI	None	Client libraries that verify ML-DSA in X.509
`draft-ietf-tls-mldsa`	ALB and NLB listeners accept RSA and ECDSA certificates (AWS Security Blog, 2026-10-12)	An AWS endpoint that negotiates ML-DSA in TLS (AWS documentation, including the Elastic Load Balancing, CloudFront, and API Gateway security policy pages)	TLS libraries on both ends
Chrome, user-added roots	AWS Private CA can be the private root	None	Distributing the private root to the clients

6. Composite Signatures: The IETF LAMPS Format and Apple's Secure Email Plan

This section examines the IETF draft on composite signatures, and Apple's announcement for Secure Email.

6.1 The Composite Signatures Draft

The format for composite signatures follows the IETF LAMPS working group's draft-ietf-lamps-pq-composite-sigs-19. The title is Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure, and the intended status is Proposed Standard.

According to the datatracker history, the IESG approved the draft on April 22, 2026, and its IESG state became RFC Ed Queue on April 23, 2026. On October 20, 2026, its RFC Editor status became blocked: Final Approval Pending. The draft does not yet have an RFC number. Therefore, the Status on the Check Date is In the RFC Editor queue. This article does not call the composite draft an RFC.

The same working group also has draft-ietf-lamps-pq-composite-kem-23. This draft is for a KEM (Key Encapsulation Mechanism), that is, keys for encryption, and not for signatures. The IESG approved it on October 12, 2026, and it is also currently in the RFC Editor queue.

6.2 Apple's Secure Email Announcement

Apple's post (the same post as in Section 4.4) says this about composite:

An amendment will be made to the existing Apple Root Program Policy to accept traditional X.509 Root CA Certificates with composite algorithms, for Secure Email.

The S/MIME paragraph of the post describes composite as a combination of ML-DSA with ECDSA or RSA. As the reason, it says that S/MIME has a lower volume of issuance than TLS and is less sensitive to latency. The announcement is in the future tense, and no text of the amendment was found in the apple/apple-root-program repository as of October 20, 2026. Therefore, the Status on the Check Date is Announced.

6.3 Composite for Public TLS Server Certificates

No root program or CA/Browser Forum document proposing composite for public TLS server certificates was found. The search covered the SC-106 pull request and its comments, the Apple post, the CQRP draft policy, FAQ, and testing instructions, and the Google blog. Apple's composite plan is for Secure Email, and its announced policy for server authentication is MTC (Section 4.4).

This article does not say that composite cannot be used in public TLS. It says that no statement was found in the sources.

6.4 Composite Contract Tables

Source	`Who Sets It`	`What It Requires`	`Status on the Check Date`
`draft-ietf-lamps-pq-composite-sigs-19`	IETF LAMPS working group	One signature that combines ML-DSA with a traditional algorithm in X.509	`In the RFC Editor queue`
`draft-ietf-lamps-pq-composite-kem-23`	IETF LAMPS working group	Composite ML-KEM for X.509; a KEM, not a signature	`In the RFC Editor queue`
Apple, Secure Email	Apple Root Program	Traditional X.509 root CA certificates with composite algorithms, for Secure Email	`Announced`

Source	`Where AWS Comes In`	`No Statement Found`	`What Stays With You`
`draft-ietf-lamps-pq-composite-sigs-19`	None	Composite algorithms in the AWS Private CA `KeyAlgorithm` values (API Reference)	Tracking the RFC number
`draft-ietf-lamps-pq-composite-kem-23`	None	None	None (a KEM does not sign certificates)
Apple, Secure Email	None	A root program or CA/Browser Forum proposal for composite in public TLS server certificates (SC-106, Apple post, CQRP pages, Google blog)	Keeping the TLS and S/MIME plans apart

7. Where the Sources Disagree

This section lists where the sources disagree, without calling either side wrong.

7.1 The Strength of Chrome's Two Statements

Two Chrome documents say the same thing with different strength.

A Google blog post (February 27, 2026, Chrome Secure Web Networking Team) says Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store.
The CQRP draft policy says As announced in February 2026, Chrome will not add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. The testing instructions page uses the same sentence in the form to its root store.

The blog says there is no immediate plan, and the draft says Chrome will not add them. The draft cites the blog as its source. This article names which document it quotes. The draft is a Draft policy.

7.2 Reactions to the Pure PQ Chain Provisions of SC-106

The SC-106 pull request has comments from August 27 to August 31, 2026. This article gives commenters' affiliations only as far as their GitHub display names and the text of their comments show.

Comment by the display name BenWilson-Mozilla (August 27, 2026): Regarding the provisions that limit ML-DSA to pure PQ chains, the comment states should be removed. The reasoning provided is: The security of a certificate path depends on the path constructed and accepted by the relying party. The comment further states that mixed chains serve a migration purpose, and that both the root program and the relying party should be able to define their own policies.

Comment written for Chrome (display name ChristopherRC, August 31, 2026): The comment contains the words in Chrome and is written as Chrome's position. It states We agree with @BenWilson-Mozilla, and also have a few concerns with the proposal as written. It splits mixed chains into two directions:

A classical CA might sign a PQ EE key (forbidden in 7.1.3.1.3), or a PQ CA might sign a classical EE key (forbidden in 7.1.3.2.3).

About the first direction (a classical CA signing a PQ key), the comment says that it carries risk to CT and serves no security purpose, and that The restrictions in 7.1.3.2.3 make sense. The section number is as in the original. From the surrounding sentences, it reads as referring to the provision that prohibits the first direction (7.1.3.1.3).

About the second direction (a PQ CA signing a classical key), the comment says that it has a use for downgrade protection:

While we do not plan to support this particular PQ CA construction in Chrome (Merkle Tree Certificates are much more suitable for a PKI with CT), these downgrade protection considerations are broadly applicable. We agree with @BenWilson-Mozilla and @bwesterb here and think this second provision in 7.1.3.2.3 should be removed.

In other words, the comment written for Chrome agreed to remove only the provision that prohibits the second direction. It says that prohibiting the first direction makes sense. This article does not summarize this as Mozilla and Chrome opposing the pure PQ chain provisions.

The same comment further discusses the scope of the proposal. It says that the Server Certificate Working Group charter is about browsers, and then says

For a browser, we don’t see this PQ CA construction as viable due to constraints from message size, CT logging, and CT enforcement.

(the original sets the word browser in bold). It goes on to say that it may be time to consider a separate working group in the CA/Browser Forum for users other than browsers. At the end, it says Rather than continuing to push this proposed ballot forward as is, we encourage exploring broader structural separation.

Two other people also commented. The display name bwesterb asked about using a mixed chain as a signal against downgrade during the transition. The display name csosto-pk replied that the proposal is about use cases outside browsers, and later wrote that if concerns regarding payload size and CT coverage could be addressed through operational practices and policies, it would be reasonable to remove the requirement for a pure ML-DSA chain. This article did not check the affiliations of these two commenters.

No record was found indicating that Cloudflare opposed SC-106. The search covered the pull request page and three WebSearch queries.

7.3 Apple's Reason and the Target of SC-106

About experimentation with ML-DSA in traditional X.509 hierarchies, Apple's post says that it has shown to cause significant degradation of TLS handshakes in real-world deployments. The CQRP FAQ also notes that sending chains of PQ signatures and CT proofs in the handshake creates a large bandwidth burden.

The SC-106 summary names relying parties other than browsers as its target (Section 5.2). Apple's statement is the reason for its server authentication policy, and the SC-106 summary names different users. The two documents have different scopes. This article does not state that either document is incorrect.

7.4 Has the CQRS Launched?

A Cloudflare blog post (September 29, 2026) says that Cloudflare's CA is targeting early 2027 for inclusion in Chrome’s newly launched Quantum-resistant Root Store. Meanwhile, the CQRP policy is at Version 0.3.0, marked [DRAFT], on the check date. cosigners.json has no PUBLICLY_TRUSTED entry (Section 4.3). The CQRP FAQ places the launch of the CQRS in the Q3 2027 phase (Section 9). This article gives the status of the CQRS as Draft policy. launched is the Cloudflare blog's word.

7.5 Phase Numbers

Chrome's sources number the phases differently from page to page.

Google's blog and the CQRP FAQ: Phase 1 involves experimentation with Cloudflare (labeled underway on both pages; Cloudflare's post of September 29, 2026, says it began winding down the experiment in August 2026), Phase 2 (Q1 2027) is the bootstrapping of public MTCs by CT log operators, and Phase 3 (Q3 2027) is the onboarding of MTC CA operators; the CQRS launch is the CQRP FAQ's wording.
The CQRP testing instructions: One question states that Phase 2 (production inclusion in the default Chrome Quantum-resistant Root Store) launches in 2027. The answer to that question also uses the term the first Phase 3 eligible MTC CA Operators.
The Chromium PQ authentication roadmap page (the Post-Quantum HTTPS Authentication Roadmap) uses a different numbering system, referring to Stages 1 through 4.

This article does not refer to phases by number alone; it adds the name of the source and the quarter.

8. CAs and Operators That Have Announced or Are Testing MTC Issuance

This section lists CAs that have announced their intention to issue MTCs, and the operators listed in the test root store. All of them are plans or tests, not production issuance.

Organization	What it has stated	Date	`Status on the Check Date`
Let's Encrypt	`The path we’re planning to take is Merkle Tree Certificates`; `We are targeting late 2026 for a staging environment that issues MTCs, and 2027 for a production-ready environment`	2026-06-03	`Announced`
Cloudflare	Becoming a CA; `We have applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs`; first production MTCs `in the first quarter of 2027`	2026-09-29	`Announced`
TrustAsia	Two test CAs and one test mirror in `cosigners.json`	Operator start 2026-08-19	`In effect` for testing only (`UNTRUSTED_VALIDATION_ONLY`)
Geomys	One test mirror in `cosigners.json`	Operator start 2026-08-19	`In effect` for testing only (`UNTRUSTED_VALIDATION_ONLY`)

The Let's Encrypt blog states that, in addition to their work on MTCs, they are also tracking RFC 9881 and draft-ietf-tls-mldsa, and says that the transition needs support in browsers, libraries, and ACME clients whether the certificates ultimately delivered are MTCs or ML-DSA signed X.509. For Let's Encrypt users, the message is: Nothing changes today.

cosigners.json also lists the operators of the mtcs.dev test CA and test mirror.

9. How to Read the Migration Timelines

This section puts the dates and periods in the sources into one table. Read each row together with its source and its status. This is not a table of predictions.

The timeline on pages 22 and 23 of the Chromium slides is labeled An (optimistic) timeline in the upper right corner. On page 23, three events sit directly below half-year marks on the vertical axis: Chrome accepts first MTC CAs from current CT log operators below 2027H1, Chrome accepts MTC CAs from other organizations below 2027H2, and Chrome Root Store removes all non-MTC CAs* below 2028H2. The footnote is No impact to user-added roots or private PKIs. This article read the half-year assignments from the placement on the slide.

Date or period	Event	Source	`Status on the Check Date`
June 2026	Chrome shipped RFC 9881 and `draft-ietf-tls-mldsa` for user-added roots	Chromium slides, p.5	`In effect`
Chrome 150	ML-DSA in private PKI hierarchies	CQRP FAQ	`In effect`
From 2026-07-31	Requests for test cosigners processed	CQRP testing page	`In effect`
Late 2026	Let's Encrypt staging environment that issues MTCs	Let's Encrypt blog	`Announced`
By the end of October 2026	Apple draft MTC policy	Apple post	`Announced`
Q1 2027	Phase 2: CT log operators bootstrap public MTCs	Google blog, CQRP FAQ	`Announced`
Q1 2027	Cloudflare's first production MTCs	Cloudflare blog	`Announced`
Early 2027	`Expect to have CAs and client support early 2027`	Chromium slides, p.5	`Announced`
2027H1	Chrome accepts first MTC CAs from current CT log operators	Chromium slides, p.23 (optimistic)	`Announced`
Q3 2027	Phase 3: onboarding of MTC CA operators (the CQRP FAQ also names the CQRS launch)	Google blog, CQRP FAQ	`Announced`
2027H2	Chrome accepts MTC CAs from other organizations	Chromium slides, p.23 (optimistic)	`Announced`
By late Summer 2027	Apple begins accepting MTC CA operator applications	Apple post	`Announced`
2027	Let's Encrypt production-ready MTC environment	Let's Encrypt blog	`Announced`
2027-09-15	Pre-issuance linting must block failing certificates	CQRP policy	`Draft policy`
2028H2	Chrome Root Store removes all non-MTC CAs, with no impact to user-added roots or private PKIs	Chromium slides, p.23 (optimistic)	`Announced`
2029-01-01	CMVP certification covering ML-DSA and ML-KEM for cosigner HSMs	CQRP policy	`Draft policy`

This article does not say that non-MTC CAs will be removed from the Chrome Root Store in 2028. That row is one line on a slide labeled An (optimistic) timeline.

10. Choosing a Chain During a Cross-Signed Transition

This section reads which chain a server sends in a migration that links classical roots and PQ roots by cross-signing.

Chain Selection During a Signature Transition

10.1 What the Slides Say

The slides (titled Practical Challenges with Cross-signed Certs) by AWS and OpenSSL at the IAB pqws examine which chain TLS implementations send. Pages 5 and 6 state the following:

Reminder: Today, typically only the first configured cert chain with a leaf PK algorithm matching the client sigAlgs is picked.
Reminder: Today, typically only the leaf cert PK algorithm is matched against the relying party’s sigAls.

Page 5 says that, with this selection, a client that advertises PQ signatures but does not have the PQ root in its trust store may fail to connect. The slides use the words typically and may. This article does not say that a cross-signed migration always fails. Section 11 records this shape happening in one local configuration.

In the SC-106 pull request, the display name csosto-pk also wrote that cross-signing needs tighter root signaling and chain selection in common TLS implementations.

10.2 The Proposed Remedies

Page 7 of the same slides gives a general solution in which the relying party signals the roots it trusts and the server honors them: the TLS 1.3 certificate_authorities extension and draft-ietf-tls-trust-anchor-ids. About certificate_authorities, the slides say Very limited support today. The PEN registration that the Apple post expects is also the basis for Trust Anchor Identifiers (Section 4.4).

10.3 How ALB Chooses a Certificate

ALB allows a single listener to hold multiple certificates. The ALB guide says that when a client's hostname matches multiple certificates, ALB selects the best certificate that the client can support, and lists Public key algorithm (prefer ECDSA over RSA) first among its selection criteria. ALB accepts both RSA and ECDSA certificates (Section 12). This article does not say how ALB's selection would treat PQ certificates, because no statement was found and ML-DSA is not among the certificates ALB accepts.

11. What This Configuration Returned: A Record from a Local OpenSSL 3.5

This section records the results of one configuration built with a local OpenSSL 3.5.9 (macOS, October 20, 2026). They are not values from the sources, and they do not mean that TLS implementations or servers in general behave the same way. MTC and composite signatures were not built in this configuration.

11.1 The Configuration

Three hierarchies were built: an ECDSA P-256 root, intermediate CA, and leaf; an ML-DSA-65 root, intermediate CA, and leaf; and a cross-signed intermediate CA, for which the ECDSA root signed the same key and name as the ML-DSA intermediate CA. The leaf name is www.example.com.
The server is openssl s_server and uses TLS 1.3 only. The first certificate slot (-cert) contains the ML-DSA leaf, and the second slot (-dcert) contains the ECDSA leaf. Server A attaches the ML-DSA intermediate CA to the ML-DSA chain, and Server B attaches the cross-signed intermediate CA.
The client uses openssl s_client and varies the trusted root (-CAfile) and the order of the signature algorithms it advertises (-sigalgs).
The keys and certificates are disposable and were deleted after the checks (October 20, 2026). The private keys and PEM files are not included in this article.

11.2 Path Validation Without a Handshake

With openssl verify, the pure ML-DSA chain, the ECDSA chain, and the ML-DSA leaf through the cross-signed intermediate CA (trusting the ECDSA root) all returned OK. The ML-DSA leaf, intermediate CA, and root all had ML-DSA-65 as both the Public Key Algorithm and the Signature Algorithm. The cross-signed intermediate CA had an ML-DSA-65 key and an ecdsa-with-SHA256 signature.

Certificate in this configuration	DER size (bytes)
ECDSA P-256 root	414
ECDSA P-256 intermediate	422
ECDSA P-256 leaf	469
ML-DSA-65 root	5540
ML-DSA-65 intermediate	5548
ML-DSA-65 leaf	5595
ML-DSA-65 intermediate signed by the ECDSA root	2306

This table shows the size of the certificates in this configuration. The speed and failure rate of the handshake were not measured.

11.3 The Chain Sent and the Verification Result

Case	Server	Client trusts	Client `-sigalgs` (in order)	Chain sent	`Verify return code`
A1	A	ECDSA root	`ecdsa_secp256r1_sha256`	ECDSA leaf and ECDSA intermediate	`0 (ok)`
A2	A	ML-DSA root	`mldsa65`	ML-DSA leaf and ML-DSA intermediate	`0 (ok)`
A3	A	ECDSA root	`mldsa65:ecdsa_secp256r1_sha256`	ML-DSA leaf and ML-DSA intermediate	`20 (unable to get local issuer certificate)`
A4	A	ML-DSA root	`ecdsa_secp256r1_sha256:mldsa65`	ECDSA leaf and ECDSA intermediate	`20 (unable to get local issuer certificate)`
B1	B	ECDSA root	`mldsa65:ecdsa_secp256r1_sha256`	ML-DSA leaf and the intermediate signed by the ECDSA root	`0 (ok)`
B2	B	ML-DSA root	`mldsa65:ecdsa_secp256r1_sha256`	ML-DSA leaf and the intermediate signed by the ECDSA root	`20 (unable to get local issuer certificate)`

s_client does not disconnect by default, even if verification fails. Cases A3, A4, and B2 completed the handshake, but the verification ultimately failed.

11.4 What This Configuration Showed

A3 and A4: In this configuration, the server sent the chain whose leaf matched the algorithm that the client listed first in -sigalgs. The roots that the client trusted did not enter the selection. A client that advertised both algorithms but trusted only one root failed verification. This is the same shape as the typically statement in the slides in Section 10.1.
B1: When the server sent the cross-signed intermediate CA, a client that trusted only the ECDSA root could also verify the ML-DSA leaf. However, this chain contains one ECDSA signature. This is the shape that the SC-106 pull request text gives as its reason for prohibiting mixed chains (Section 5.1).
B2: A client that trusted only the ML-DSA root could not verify the same chain, because the server sent only the cross-signed intermediate CA and not the intermediate CA that leads to the ML-DSA root.

12. Where AWS Comes In

This section lists, with check dates, what can be done on AWS today with public TLS and private PKI certificates. How to constrain ML-DSA variants inside AWS is covered on this site's Enforcing an ML-DSA Policy on AWS.

12.1 Where Public TLS Certificates Go

The ACM User Guide says ACM supports these RSA and ECDSA public key algorithms and lists four RSA algorithms and three ECDSA algorithms. ACM can request new certificates with only three of them: RSA 2048-bit, ECDSA 256-bit, and ECDSA 384-bit. The others are for imported certificates only.

An article on the AWS Security Blog (October 12, 2026, Quantum-resistant signing on AWS, Part 2) says

At the time of writing, ACM requests and imports accept RSA and ECDSA keys only, and NLB and ALB listeners accept RSA and ECDSA certificates only, so no ML-DSA certificate can be bound to a listener today.

The CloudFront Developer Guide says about the key type CloudFront supports RSA and ECDSA public–private key pairs.

12.2 What a Private PKI Can Use

AWS Private CA announced support for ML-DSA CA creation and certificate issuance in a "What's New" update on November 10, 2025. The "What's New" announcement also states that CRL and OCSP responders can be used with ML-DSA. The API reference lists ML_DSA_44, ML_DSA_65, and ML_DSA_87 as valid values for the KeyAlgorithm parameter. The user guide says that for ML-DSA, the same value is used for the key algorithm and the signing algorithm. Information on selecting a key algorithm can be found on this site at AWS Private CA Hierarchy Design.

IAM Roles Anywhere announced in a "What's New" update on March 9, 2026, that ML-DSA-signed CA certificates can be used as trust anchors.

About MTC, the AWS Private CA FAQ says AWS PCA does not support Merkle Tree Certificates (MTC) at this time. As the reason, the FAQ says that most private PKI use cases have not integrated Certificate Transparency (CT), so their size benefit from MTC would be insignificant.

12.3 AWS Contract Tables

AWS service	`What It Requires`	`Status on the Check Date`	`Where AWS Comes In`
ACM	RSA and ECDSA keys; requests limited to `RSA_2048`, `EC_prime256v1`, `EC_secp384r1`	`In effect`	The public certificate you attach to ALB, NLB, CloudFront, and other integrated services
ALB and NLB listeners	RSA and ECDSA certificates (AWS Security Blog, at the time of writing on 2026-10-12)	`In effect`	Where public TLS terminates on AWS
CloudFront	RSA and ECDSA key pairs	`In effect`	Where public TLS terminates at the edge
AWS Private CA	ML-DSA CAs, certificates, CRLs, and OCSP; `ML_DSA_44`, `ML_DSA_65`, `ML_DSA_87`	`In effect` (since 2025-11-10)	A private PKI that issues ML-DSA certificates
IAM Roles Anywhere	ML-DSA-signed CA certificates as trust anchors	`In effect` (since 2026-03-09)	Workload authentication with ML-DSA certificates

AWS service	`No Statement Found`	`What Stays With You`
ACM	Support for ML-DSA or MTC certificates (ACM User Guide, What's New searched 2026-10-20)	Tracking the ACM key algorithm list
ALB and NLB listeners	Support for ML-DSA certificates on listeners (ALB guide, What's New)	Rechecking the `at the time of writing` statement
CloudFront	Support for ML-DSA certificates (CloudFront Developer Guide, What's New)	Rechecking the key type list
AWS Private CA	A plan for MTC support (the FAQ says `at this time`); composite algorithms in `KeyAlgorithm` (API Reference)	Distributing the private root to clients
IAM Roles Anywhere	None	Issuing ML-DSA end-entity certificates from your CA

No statement that AWS endpoints negotiate ML-DSA signatures in TLS was found in the AWS documentation searched. No statement about ML-DSA for API Gateway was found in the API Gateway security policy pages either.

13. Failure Modes

These are mistakes that are easy to make when reading the tables in this article:

Assuming that an ML-DSA X.509 certificate from today's CA is enough: The CQRP draft says that Chrome will not add traditional X.509 certificates containing PQ cryptography to the Chrome Root Store. SC-106 is a Draft pull request and does not make root programs accept ML-DSA (Sections 4.2 and 5.2).
Assuming that Chrome accepted ML-DSA certificates in June 2026: That shipment is listed in the Chromium slides under the heading User-added roots. It is for roots that users add (Section 5.4).
Assuming that SC-106 went to a CA/Browser Forum vote: SC-106 is a Draft pull request and has no row on the ballots page (Section 5.3).
Assuming that Mozilla and Chrome opposed pure PQ chains: The comment by the display name BenWilson-Mozilla asked to remove the provisions, but the comment written for Chrome agreed to remove only the prohibition on a PQ CA signing a classical key (Section 7.2).
Assuming that composite signatures are a standard: The draft for composite signatures is currently in the RFC Editor's queue, and it does not yet have an RFC number (Section 6.1).
Assuming that Apple will accept composite in public TLS: Apple's composite announcement is for Secure Email. For server authentication, Apple's announced policy is MTC (Section 6.2).
Assuming that non-MTC CAs will be removed in 2028: That row is one line on a slide labeled An (optimistic) timeline (Section 9).
Assuming that a cross-signed transition always fails: The AWS and OpenSSL slides use the words typically and may (Section 10.1).
Assuming that ACM can request ML-DSA certificates: ACM keys are RSA and ECDSA. ML-DSA certificates come from AWS Private CA, inside a private PKI (Section 12).
Assuming that hybrid key exchange makes the certificates quantum-resistant: Key exchange and signatures are separate transition processes (Section 1.3).

14. Frequently Asked Questions About Post-Quantum Certificates for Public TLS

Q1. Has the path for post-quantum certificates in public TLS been settled?

No. As of October 20, 2026, Chrome's CQRP policy is a draft, Apple's MTC policy is an announcement, SC-106 is a Draft pull request, and the composite draft is in the RFC Editor queue (Section 3).

Q2. Does Chrome trust ML-DSA certificates?

In private PKIs, yes. The CQRP FAQ says that Chrome supports ML-DSA in private PKI hierarchies beginning in Chrome 150. For the public Chrome Root Store, the CQRP draft says that Chrome will not add traditional X.509 certificates containing PQ cryptography (Sections 1.4 and 7.1).

Q3. Has SC-106 been adopted?

No. SC-106 is a Draft pull request on GitHub and does not appear on the CA/Browser Forum ballots page. The last comment was dated August 31, 2026 (Section 5.3).

Q4. Have composite signatures become an RFC?

No. draft-ietf-lamps-pq-composite-sigs-19 received approval from the IESG on April 22, 2026, and is currently in the RFC Editor queue. It does not yet have an RFC number (Section 6.1).

Q5. Can ML-DSA certificates be used with ACM or ALB?

Not according to the sources on the check date. ACM keys are RSA and ECDSA, and the AWS Security Blog says that, as of October 12, 2026, ALB and NLB listeners accept only RSA and ECDSA certificates. ML-DSA certificates can be issued by AWS Private CA, inside a private PKI (Section 12).

Q6. Has Apple's draft MTC policy been published?

As of October 20, 2026, it was not found in the apple/apple-root-program repository. The Apple post says that Apple expects to publish it by the end of October 2026 (Section 4.4).

Q7. When was this article checked?

The source materials were reviewed on October 20, 2026. The results in Section 11 were checked on a local OpenSSL 3.5 configuration. Many of the sources are drafts or announcements, and the pages can change after the check date (Section 1.5).

15. Summary

The three paths differ in who decides and in stage: MTC is a Chrome draft policy and an Apple announcement, the pure ML-DSA chain is a Draft pull request at the CA/Browser Forum, and composite signatures are in the RFC Editor queue at the IETF (Section 3).
Chrome's new root store is a draft built only from MTC CAs: The blog says there is no immediate plan, and the draft says Chrome will not add traditional PQ certificates. Read which document says which (Section 4.2, Section 7.1).
SC-106 is intended for users other than browsers: Its summary names SDK-based service clients, embedded and IoT systems, and enterprise middleware. The comment written for Chrome agreed to remove one of the two prohibitions regarding mixed chains (Section 5.2, Section 7.2).
For cross-signed chains, the sources say typically: The AWS and OpenSSL slides say that servers typically pick the chain by the leaf key type and the client's signature algorithms. In the configuration in Section 11 as well, the trusted roots did not enter the selection (Section 10, Section 11).
The timelines are plans, and one slide calls its own timeline optimistic: Read the half-year and quarter rows together with the names of their sources (Section 9).
Public TLS certificates on AWS are RSA and ECDSA: ML-DSA certificates can be used in a private PKI with AWS Private CA, and AWS Private CA's FAQ says that it does not support MTC at this time (Section 12).

16. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi