Merkle Tree Certificates Adaptive Demo

Merkle Tree Certificates
Adaptive Certificate Demo

One server holds three certificate types at the same time. On every handshake it reads the trust_anchors extension in the ClientHello and picks which one to send on the fly — your connection just took the path highlighted below.

ClientHello · trust_anchors?

THIS CONNECTIONPath A

Landmark-Relative Certificate

Matched a landmark ID or landmark group usable for this certificate. Sends a landmark-relative certificate without cosignatures — usually the smallest total size.

THIS CONNECTIONPath B

Standalone Certificate

Matched this MTC CA's CA ID or group, but no usable landmark-relative certificate. Sends a standalone certificate carrying an inclusion proof and enough cosignatures.

THIS CONNECTIONPath C

X.509 chain

No acceptable MTC trust anchor matched, including missing extension or no match. Sends a traditional X.509 chain, compatible with existing clients.

Certificate mode: X.509 chain
Protocol: TLSv1.3
Cipher suite: TLS_AES_256_GCM_SHA384

Fallback negotiation — handshake sequence

How one server holds a landmark-relative certificate, a standalone certificate and a classic X.509 chain at the same time — and picks the right one for every client inside this TLS 1.3 handshake, with no extra round trips.

Clientbrowser / MTC-awareServermtcdemo.trustasia.cn

ClientHello + key_share
optional trust_anchors (0xCA34, experimental codepoint) — anchor IDs this client can verify

server certificate selection:

matches a trust anchor or group declared by the client
when both Landmark-relative and Standalone are usable, prefer Landmark-relative
when no path matches, fall back to the fallback path or return handshake_failure
without trust_anchors, may send an X.509 certificate

ServerHello + key_share

EncryptedExtensions
may carry trust_anchors: the server's AvailableTrustAnchorList — candidate anchors a client can retry with; not the "MTC selected" signal

Certificate — exactly one of:

Landmark-relative certificateStandalone certificateX.509 certificate

on the MTC paths, the first CertificateEntry carries an empty trust_anchors extension — "selected because you declared trust_anchors"

CertificateVerify
signed with the private key of the selected certificate.

Finished

1-RTT · fallback never adds a round trip · no HelloRetryRequest

Selection logic

per draft-ietf-plants-merkle-tree-certs-05

ClientHello carries trust_anchors?

yes

any ID a usable landmark ID / landmark group for this certificate?

yes

Landmark-relative certificateno cosignatures — usually the smallest total size

any ID matches this MTC CA's CA ID / a group containing it?

yes

Standalone certificatecarries an inclusion proof and enough cosignatures

X.509 chainno acceptable MTC anchor matched — compatible with existing clients

Note: this demo environment trusts the standalone certificate — if the ClientHello carries trust_anchors, the server sends standalone.

ClientHello (this connection)

Legacy version: TLSv1.2
Client random: 1545c7d25e4053be54625755a4178363b7d3f39e49831382e668559eeee42c18
Negotiated group: 0x001d (x25519)
Offered cipher suites: 35

Trust Anchors (TrustAsia staging MTC CA)

Reference OIDs for the CAs, logs and cosigner behind this demo's MTC certificates.

Entity	Relative OID	Full OID	Notes
7-day CA	44494.3.1.1	1.3.6.1.4.1.44494.3.1.1	Certs ≤ 7 days, revocation-exempt class
47-day CA	44494.3.1.2	1.3.6.1.4.1.44494.3.1.2	Certs ≤ 47 days, revocation via CQRP
7-day log #1	44494.3.1.1.0.1	1.3.6.1.4.1.44494.3.1.1.0.1	Checkpoint origin oid/1.3.6.1.4.1.44494.3.1.1.0.1
47-day log #1	44494.3.1.2.0.1	1.3.6.1.4.1.44494.3.1.2.0.1	Checkpoint origin oid/1.3.6.1.4.1.44494.3.1.2.0.1
Mirror cosigner	44494.3.2.1	1.3.6.1.4.1.44494.3.2.1	Signed-note name oid/1.3.6.1.4.1.44494.3.2.1

MTC-enabled ACME client: https://github.com/trustasia-com/acme.sh/tree/feat/mtc-certificate-support

MTC CA staging environment: https://acme.mtc-staging.trustasia.com/acme/v2/directory

What is MTC

Merkle Tree Certificates (MTC) is an experimental draft from the IETF PLANTS working group: a CA batches certificates into a Merkle tree, so issuance only needs the hash path from a leaf to the root. Compared with traditional X.509 signature chains, verification is cheaper and certificates can be far smaller — a natural fit for post-quantum signatures with large public keys. This demo implements the draft-05 X.509-compatible envelope and the TLS 1.3 negotiation extension.