Skip to main content

Multiple Public-Key Algorithm X.509 Certificates

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Alexander Truskovsky , Daniel Van Geest , Scott Fluhrer , Panos Kampanakis , Mike Ounsworth , Serge Mister
Last updated 2024-02-25 (Latest revision 2023-08-24)
RFC stream (None)
Intended RFC status (None)
Additional resources Related Implementations
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


Tombstone notice: This draft is no longer being pursued at the IETF. A variant of this proposal was adopted in [itu-t-x509-2019], which allows two keys to be placed in a certificate but only one used at a time. The major downside of this proposal is that it requires the large PQC key to be sent even to legacy clients which will not use it. Additionally, this proposal does not present a generic encoding for the multiple signatures produced by the multiple keys contained in a hybrid certificate, leaving the responsibility to dependent protocols and applications for how to carry multiple signatures and how to signal that multiple signatures should have been present in order to detect stripping attacks. As such, this document represents only a partial solution to the dual-signature problem. How, and whether, to implement dual-signatures is an active and ongoing discussion topic at the IETF and work continues in this area across several working groups. The PQUIP WG serves as a central location for all PQC- related discussion. Original abstract: This document describes a method of embedding alternative sets of cryptographic materials into X.509v3 digital certificates, X.509v2 Certificate Revocation Lists (CRLs), and PKCS #10 Certificate Signing Requests (CSRs). The embedded alternative cryptographic materials allow a Public Key Infrastructure (PKI) to use multiple cryptographic algorithms in a single object, and allow it to transition to the new cryptographic algorithms while maintaining backwards compatibility with systems using the existing algorithms. Three X.509 extensions and three PKCS #10 attributes are defined, and the signing and verification procedures for the alternative cryptographic material contained in the extensions and attributes are detailed.


Alexander Truskovsky
Daniel Van Geest
Scott Fluhrer
Panos Kampanakis
Mike Ounsworth
Serge Mister

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)