Hybrid Certificate: Mixed Cryptography & Systems

• Hybrid certificate is a digital credential that integrates classical and post-quantum algorithms to enable seamless migration and legacy compatibility.
• Implementation schemes like Composite, Catalyst, and Chameleon vary in structure, impacting computational performance and validation in mixed certificate hierarchies.
• Beyond cryptographic credentials, hybrid certificates also refer to barrier functions in hybrid dynamical systems, proving safety, eventuality, and diagnosability.

Hybrid certificate denotes a certificate construction or certificate-hierarchy strategy that combines classical and post-quantum cryptographic elements so that systems can preserve interoperability during migration while adding post-quantum security. In current PKI research, the combination may appear inside one X.509 object, in alternative extensions, in an outer/inner certificate pair, or across a mixed root–intermediate–leaf hierarchy. A distinct control-theoretic literature uses the related expression hybrid barrier certificate for proof objects over hybrid dynamical systems rather than PKI credentials; the two usages share the term certificate but not the underlying abstraction (Chen, 30 Oct 2025, Jiménez, 7 Apr 2026, Bisoffi et al., 2020).

1. Core concept and research scope

In the X.509 migration literature, a hybrid certificate is defined as a certificate that combines a classical algorithm and a post-quantum algorithm so systems can preserve interoperability during migration while adding PQ security. This definition is used to distinguish hybrid certificates from pure PQC certificates, composite certificates, chameleon certificates, and parallel certificate chains. The same body of work also treats hybridity as a property not only of a single certificate object but of a certificate hierarchy, since roots, intermediates, and leaves can each carry different signature families (Chen, 30 Oct 2025, Ricchizzi et al., 7 May 2025, Jiménez, 7 Apr 2026).

Two recurrent misconceptions are rejected in the recent literature. The first is that a hybrid certificate is synonymous with a composite certificate; comparative studies instead treat Composite, Catalyst, and Chameleon as different schemes with different validation and migration properties. The second is that post-quantum migration in TLS is a flat substitution problem in which one signature algorithm is simply replaced by another; hierarchy placement studies show that operational cost depends strongly on where a given signature family appears in the certification chain (Chen, 30 Oct 2025, Jiménez, 7 Apr 2026).

A broader reading of the term is also visible in cyber-physical systems and formal methods, where certificates are mathematical witnesses of safety, eventuality, or diagnosability for hybrid dynamical systems. In that setting, a hybrid barrier certificate is not an identity credential, but a function used to separate safe and unsafe behaviors or to prove eventual reachability properties (Bisoffi et al., 2020, Zhong et al., 2024).

2. X.509 structural families

Recent comparison work centers on three X.509 hybrid schemes: Composite, Catalyst, and Chameleon. Composite places both classical and PQC material directly into the same certificate fields. For signature use, the cited example uses alg: id-MLDSA44-ECDSA-P256-SHA256 OID, key: { ML-DSA-44 key || ECDSA P-256 key }, and Sig: { ML-DSA-44 signature || ECDSA P-256 signature }; the verifier must validate both signatures. Catalyst keeps the classical public key and classical signature in the standard X.509 fields and places PQC material in alternative fields, specifically subjectAltPublicKeyInfo, altSignatureAlgorithm, and altSignatureValue. Chameleon embeds an inner Delta Certificate inside an outer classical certificate, allowing duplicated fields such as subject name and validity period to be inherited from the outer certificate (Chen, 30 Oct 2025, Ricchizzi et al., 7 May 2025).

Scheme	Structural idea	Migration and validation
Composite	Classical and PQC keys and signatures are combined in the same SPKI and signature fields	Both signatures must validate; shortest certificate length and shortest computational time; not suitable as a migration transition certificate
Catalyst	Classical base certificate with PQC material in subjectAltPublicKeyInfo, altSignatureAlgorithm, and altSignatureValue	Legacy verifier checks standard fields; PQC-capable verifier checks both layers; intended for transition periods
Chameleon	Classical outer certificate plus embedded Delta Certificate	Legacy verifier validates outer certificate only; PQC-capable verifier validates outer and inner certificates; migration-oriented

The trade-offs are explicit. Composite is reported as the shortest certificate length and the shortest computational time among the three because the CA can generate the two signatures in parallel, but it is not suitable as a migration transition certificate because a legacy device that does not understand the composite structure cannot validate it. Catalyst and Chameleon are both transition certificates because the outer or base certificate remains classical and usable by legacy clients, while upgraded clients can additionally verify the PQC component. Chameleon is reported as the longest certificate size and longest computation time, but it allows fields such as Key Usage to be described separately for the outer and inner parts (Chen, 30 Oct 2025).

Standardization and tooling remain unsettled. The implementation literature states that hybrid and composite certificate OIDs are not yet fully standardized, that temporary Bouncy Castle OIDs are used in practice, and that as of April 2025 no standardized OIDs for composite algorithms had been issued by IANA. The same comparison literature notes that the Catalyst draft expired in 2024, whereas Chameleon remained the more promising transition design in that study because its draft remained active (Ricchizzi et al., 7 May 2025, Chen, 30 Oct 2025).

3. Certificate hierarchy placement in TLS 1.3

TLS 1.3 experiments extend the notion of hybrid certificate from an isolated X.509 object to a mixed certificate hierarchy. The relevant design space includes configurations such as ML root / ML int / ML leaf, SLH root / ML int / ML leaf, ML root / ML int / SLH leaf, and SLH root / SLH int / SLH leaf, evaluated under classical X25519, hybrid X25519MLKEM768, and pure PQC MLKEM768 key exchange. The baseline is explicitly x25519mlkem768__ml_root__ml_int__ml_leaf, which combines hybrid key exchange with a fully ML-DSA certificate chain (Jiménez, 7 Apr 2026).

The central finding is hierarchy-sensitive: the clearest discontinuity appears when SLH-DSA is placed in the server leaf certificate. In Campaign A, under classical key exchange, an ML leaf yields 0.688 ms mean latency, whereas an SLH leaf yields 1464.933 ms, a 2127.865× latency ratio. Under hybrid key exchange, the corresponding values are 0.841 ms and 1413.991 ms, a 1682.137× latency ratio. By contrast, the mixed hierarchy SLH root / ML int / ML leaf has mean latency 2.133 ms, about 2.64× baseline, with server task-clock only 1.19× baseline, and is classified as “penalized but plausible” (Jiménez, 7 Apr 2026).

The same study argues that transport size alone does not explain the heavy regime. When comparing ML-DSA and SLH-DSA at the leaf, bytes_read_mean increases only about 3.2×–3.3×, yet latency increases by more than 1000×; the dominant factor is server-side cryptographic cost. Leaf-SLH scenarios cluster around ~1402–1409 ms mean latency, ~2500× server-side compute relative to baseline, and ~1733×–1741× latency relative to baseline, and are labeled “unsuitable for interactive TLS front-end.” The paper therefore concludes that post-quantum TLS migration must be evaluated as a problem of certificate-hierarchy design, chain exposure, and cryptographic cost concentration during live authentication, not merely as primitive substitution (Jiménez, 7 Apr 2026).

A further implication concerns effective chain exposure. The study notes that a logical depth-3 hierarchy may expose only two certificates during the handshake, for example root + leaf or intermediate + leaf. This makes depth alone an unreliable predictor of cost, and it explains why a depth-3 hierarchy can be cheaper than depth-2 when a heavy root certificate is removed from the effective chain (Jiménez, 7 Apr 2026).

4. Deployment settings and operational constraints

Industrial PKI research presents hybrid certificates as a migration mechanism for certificate-based device onboarding in environments that require long-lived credentials, offline validation, interoperability, and support for constrained or legacy devices. In this setting, a hybrid certificate is explicitly identified with the ITU-T X.509 Section 9.8 “Catalyst” approach using subjectAltPublicKeyInfo, altSignatureAlgorithm, and altSignatureValue. A Bouncy Castle-based proof of concept called pqcli supports classical, hybrid, composite, and partially chameleon certificates with ML-DSA and SLH-DSA, and is designed for headless operation. The same study reports that OpenSSL 3.5 does not support hybrid “Catalyst” certificates, and that oqs-provider has no support for hybrid certificates using the Section 9.8 extensions (Ricchizzi et al., 7 May 2025).

Vehicular communications provide a more constrained case. In the SCMS literature for V2X, the proposed hybrid authorization or pseudonym certificate keeps the end-entity Verify Key Indicator (VKI) as an ECC public key while the issuer signs the certificate with a PQC private key. The size model is given by

$C = c + k + s_1,\qquad U = u + C + s_2,$

where $C$ is certificate length and $U$ is the secure protocol data unit length. With c = 34 bytes and u = 68 bytes, a Falcon-512 certificate signature plus ECDSA P-256 VKI yields C = 733 bytes and U = 866 bytes, below the 1400-byte WAVE/WSM limit; a pure Dilithium-2 certificate yields 3766 bytes and an SPDU length of 6254 bytes, which cannot be carried in a peer-to-peer vehicular packet. On the cited OBU platform, Falcon-512 has verification time 0.87 ms, Dilithium-2 has signing and verification times 12.27 ms and 4.20 ms, and SPHINCS+ SHA2-128f is reported as unsuitable for the 100 ms BSM transmission cycle because signing is too slow (Chen et al., 13 Jan 2025).

A later SCMS study generalizes the pseudonym workflow and again identifies Falcon-512 + ECDSA P-256 as the only practical V2V choice among the tested hybrid combinations. It also reports that a signed SPDU carrying full pseudonym certificate plus BSM is about 813 bytes, while a signed SPDU carrying certificate digest plus BSM is about 122 bytes, both below the 1400-byte limit. Its privacy contribution is to encrypt the pseudonym public key before issuance so that the public key in the pseudonym certificate cannot be inferred from the public key in the enrollment certificate (Chen et al., 12 Jun 2026).

Smart-grid PKI work addresses an adjacent but distinct problem: certificate-status validation at scale. The proposed Hybrid OCSP combines OCSP with CRLs so that the CA generates and signs the CRL, the OCSP server downloads it every hour, parses revoked serial numbers into a local blacklist database, and answers status queries by checking that blacklist instead of the full certificate database. If the OCSP server is unavailable, the client can download the CRL directly. The same study reports that OCSP becomes preferable when the PEM CRL exceeds 14 records or the DER CRL exceeds 24 records, and it frames the design as a high-availability architecture for deployments with tens of thousands of meters (Huang et al., 2024).

5. Cooperative issuance and distributed trust

Another research direction alters the way certificates are issued rather than the internal structure of the certificate. Decentralized certificate authorities split a CA’s private signing key among multiple parties and produce signatures using a generic secure multi-party computation protocol that never exposes the actual signing key. The stated motivation is that CA private-key compromise is a single point of failure with potentially disastrous consequences, so splitting the key can reduce the risk that it would be compromised or misused (Jayaraman et al., 2017).

The proposed model has two distinct uses. First, a single CA can distribute control of its own signing key across multiple parties. Second, certificate generation can require cooperation among multiple CAs, or even between a CA and the certificate recipient. The prototype implementation demonstrates feasibility using secure two-party computation to generate certificates signed with ECDSA on secp192k1 (Jayaraman et al., 2017).

This suggests an additional dimension of hybridity. In the X.509 migration literature, a hybrid certificate typically means mixed algorithmic content or mixed hierarchy placement. In decentralized CA research, a plausible implication is a hybridization of issuance authority itself: the certificate remains a conventional signed credential, but its creation requires joint participation by multiple cryptographic actors rather than unilateral action by a single CA (Jayaraman et al., 2017).

6. Distinct usage in hybrid dynamical systems

In control theory and formal verification, certificate usually means a mathematical witness rather than a public-key credential. The expression hybrid barrier certificate refers to a function used to prove safety or eventuality properties for hybrid systems that combine continuous flows and discrete jumps. For syntactically co-safe LTL satisfaction, one formulation models the plant and automaton as a hybrid system with state $x=(s,o,\xi)$, target set $$R=\{(s,o,\xi): s\in S_f,\ o\in O_s,\ \xi\in \mathbb{R}^n\}$$, and certificate

$B(x)=d(s,S_f)+\lambda U_o(\xi),$

with sufficiently small $\lambda>0$. The proof relies on strict decrease of $B$ along flows and jumps, so eventual reachability of an accepting automaton state certifies satisfaction of the sc-LTL specification (Bisoffi et al., 2020).

Runtime assurance work uses barrier certificates differently. In Barrier-based Simplex, a barrier certificate $h(x)$ proves that a verified-safe baseline controller keeps the plant safe, and a Taylor expansion of $h$ yields a computationally inexpensive forward switching condition

$C$0

where $C$1 and $C$2. The decision module switches from the advanced controller to the baseline controller when the barrier is predicted to become nonpositive within the next control interval or when the approximation guarantee no longer holds. In the cited microgrid case study, the safety property is that the $C$3-component of the inverter output voltage remains within $C$4 of $C$5 kV (Damare et al., 2022).

The synthesis literature supplies two further developments. One line computes barrier certificates for hybrid systems from simulations rather than directly from the system dynamics, using a CEGIS-like loop over simulation segments and allowing optional rigorous post-verification. Another introduces the Exponential Condition, $C$6, and its hybrid extension, arguing that it is less conservative than the convex condition while preserving convexity and enabling SOS/SDP-based synthesis. A more recent diagnosability framework constructs a $C$7-deterministic finite automaton, forms a product system, and verifies diagnosability or non-diagnosability through two kinds of hybrid barrier certificates, $C$8-HBC and $C$9-HBC (Ratschan, 2017, Kong et al., 2013, Zhong et al., 2024).

Taken together, these works show that hybrid certificate has two mature technical meanings. In PKI, it denotes mixed classical/PQC credentials or certificate hierarchies intended to support migration under interoperability, size, and performance constraints. In hybrid-systems verification, it denotes certificate functions that prove safety, eventuality, or diagnosability for systems with combined continuous and discrete dynamics.