OpenPGP standards: RFC 1991, 2440, 4880, 9580 and LibrePGP

Updated November 2026

OpenPGP is defined by a chain of IETF documents: RFC 1991 (PGP 2, 1996), RFC 2440 (1998), RFC 4880 (2007) and RFC 9580 (July 2024), plus RFC 9980 for post-quantum algorithms (June 2026). Since 2023 there is also LibrePGP, a separate specification backed by GnuPG. For everyday use the safe choice today is still a version 4 key, which every current tool reads.

IETF standards (solid) and the LibrePGP Internet-Draft (dashed), which is not an IETF standard.

The documents at a glance

OpenPGP specifications, as of November 2026
Document	Date	Status	Key points
RFC 1991, PGP Message Exchange Formats	Aug 1996	Informational	Describes PGP 2.x formats (2.6 and 2.7; 2.3 with minor differences). RSA, IDEA, MD5, version 3 keys.
RFC 2440, OpenPGP Message Format	Nov 1998	Proposed Standard	First IETF OpenPGP standard. Version 4 keys and signatures. Must implement DSA, ElGamal, Triple-DES, SHA-1.
RFC 4880, OpenPGP Message Format	Nov 2007	Proposed Standard	Obsoletes 1991 and 2440. Integrity-protected encryption (MDC), AES and SHA-2 assigned. Extended by RFC 5581 (Camellia, 2009) and RFC 6637 (elliptic curves, 2012).
RFC 9580, OpenPGP	Jul 2024	Proposed Standard	The “crypto refresh”. Obsoletes 4880, 5581 and 6637. Version 6 keys, Ed25519/X25519, AEAD encryption, Argon2.
RFC 9980, Post-Quantum Cryptography in OpenPGP	Jun 2026	Proposed Standard	Extends RFC 9580 with ML-KEM, ML-DSA and SLH-DSA.
draft-koch-librepgp-06, LibrePGP	Sep 2026	Individual Internet-Draft	Alternative to RFC 9580, based on rfc4880bis. Version 5 keys.

RFC 1991: PGP 2

RFC 1991 was written by Derek Atkins, William Stallings and Philip Zimmermann. It “does not specify an Internet standard of any kind”; it documents what PGP 2.x already did. Keys and signatures were version 3, encryption used IDEA, and hashing used MD5. RFC 9580 now explains why version 3 keys are weak: it is easy to make a key with the same key ID as another, and the fingerprint does not cover the key length. GnuPG 1.4 is the last GnuPG branch that still supports these “unsafe PGP-2 keys”, in its own words.

RFC 2440 and RFC 4880: classic OpenPGP

RFC 2440 (Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer) turned PGP into an open IETF standard. It introduced the version 4 key and signature formats still used by most keys today. The mandatory algorithms were DSA for signatures, ElGamal for encryption, Triple-DES and SHA-1; AES only had reserved numbers.

RFC 4880 (the same authors plus David Shaw) became the reference for almost twenty years. Its main addition was the Symmetrically Encrypted Integrity Protected Data packet with a Modification Detection Code, which lets a recipient detect tampering with encrypted data. It assigned AES-128/192/256 and listed the SHA-2 hashes. Elliptic-curve keys came later in RFC 6637 (June 2012). GnuPG’s manual notes that its --rfc2440 mode creates encryption packets “without MDC protection” and calls this dangerous.

RFC 9580: the crypto refresh

RFC 9580 (Paul Wouters as editor, Daniel Huigens, Justus Winter, Yutaka Niibe) was developed as draft-ietf-openpgp-crypto-refresh by the IETF OpenPGP working group. Its Appendix B lists the changes. The most important for users:

Version 6 keys and signatures. A v6 fingerprint is a 256-bit SHA2-256 hash, instead of the 160-bit SHA-1 fingerprint of v4 keys. The spec says implementations “SHOULD create keys with version 6 format”, and that v4 keys are deprecated but “SHOULD” still be accepted.
New mandatory algorithms: Ed25519 for signatures, X25519 for encryption, AES-128, SHA2-256, and OCB as the AEAD mode.
AEAD encryption (version 2 SEIPD packets) with OCB, EAX or GCM, and Argon2 for passphrase-based key derivation.
Things to avoid: MD5, SHA-1 and RIPEMD-160; IDEA, Triple-DES and CAST5; DSA and ElGamal; version 3 keys and signatures; the old unprotected encryption packet.

RFC 9980 (June 2026) builds on it. It defines ML-KEM (formerly Kyber) combined with X25519 or X448 for encryption, ML-DSA combined with EdDSA for signatures, and SLH-DSA on its own. ML-KEM-768+X25519 may be used with v4 or v6 keys; the ML-DSA and SLH-DSA signature schemes require v6 keys.

LibrePGP and GnuPG’s position

Work on a revision of RFC 4880, called rfc4880bis, began in 2015. According to librepgp.org, the working group reached consensus on that draft in September 2021, after which “a small group” started a larger revision, the one that became RFC 9580. LibrePGP was created in response, as a separate specification maintained by a study group that includes the companies g10 Code and Ribose and other implementers; its first draft appeared in November 2023. librepgp.org lists GnuPG, RNP and Gpg4win as supporters.

The current text, draft-koch-librepgp-06 by Werner Koch and Ronald Henry Tse, is dated 7 September 2026. It is an individual Internet-Draft: it has no IETF standing. It uses version 5 keys and signatures, which are not the same as RFC 9580’s version 6 format.

In practice:

GnuPG follows LibrePGP. Its current 2.5 series (2.5.24 as of November 2026) adds a post-quantum encryption algorithm (FIPS-203, that is ML-KEM), first released in 2.5.1 in September 2024. Check interoperability with other tools before relying on post-quantum keys.
Distribution builds can differ. Debian 13’s gpg manual says --gnupg “is now LibrePGP behavior” and that its default, --openpgp, means “OpenPGP compatible (RFC-9580) behavior”, adding: “Note that not all of RFC-9580 is implemented by GnuPG.”
GnuPG and v6 keys. In our test, GnuPG 2.4.7 on Debian 13 refused the sample v6 certificate from RFC 9580 Appendix A.3 with packet(6) with unknown version 6 and imported nothing.
Sequoia (sq, version 1.5.0 as of November 2026) added RFC 9580 support in version 1.3.0 and RFC 9980 post-quantum support in 1.4.0. In the sq 1.3 manual shipped with Debian 13, sq key generate --profile offers rfc9580 and rfc4880, with rfc4880 as the default; the manual says the default will change “once support for RFC9580 is rolled out further”.
OpenPGP.js version 6 added RFC 9580 support. It dropped generation of v5 keys, and reading v5 keys or signatures needs an opt-in setting.

What this means for you

Keep using a v4 key with Ed25519/Curve25519 or RSA 3072+ if you exchange mail or signatures with GnuPG users. Every current implementation reads v4, and both camps still accept it.
Do not create v6 or v5 keys for general use yet unless everyone you communicate with uses software that handles that format. A v6 key cannot be imported into the GnuPG version tested above, and v5 keys need special settings in OpenPGP.js.
Retire old material: v3 (PGP 2) keys, DSA keys and anything that depends on SHA-1 or IDEA. See Security questions.
Publish your fingerprint in full. v4 fingerprints have 40 hex digits; v6 fingerprints have 64.
Watch the post-quantum work. RFC 9980 is standardized, but tool support differs between implementations as of November 2026.

How the formats fit together inside a message is explained in How PGP works; the history behind the standards is in PGP history.