OpenPGP: what RFC 9580 actually defines
A standards-first look at OpenPGP: certificate-free email encryption built on a web of trust instead of a CA hierarchy, plus its default algorithms.
Confidentiality without a certificate authority
S/MIME solves message confidentiality and integrity by hanging trust off a certificate authority: a third party that issues a certificate and vouches that a given public key belongs to a given identity. OpenPGP addresses the same problem, encrypting a message so only the intended recipient can read it and signing it so tampering is detectable, but without requiring any centralized authority to issue or vouch for that identity.
What RFC 9580 defines
RFC 9580 defines the OpenPGP message and key format. It updates and replaces RFC 4880, the previous OpenPGP specification.
The standard covers three things: the structure of public and private key pairs, a web-of-trust model for verifying whose key is whose in place of a CA hierarchy, and the packet format used to represent signed and encrypted data.
How it works
A sender encrypts a message using the recipient's public key. The recipient can publish that key, or the two parties can exchange it directly, with no certificate authority involved at any point. The sender can also sign the message with their own private key, or do both at once.
Trust in a given public key doesn't come from a certificate authority. It comes either from the web of trust, other people who have already signed that key and vouched that it belongs to who it claims to, or from out-of-band verification: checking the key's fingerprint directly with its owner, over a phone call or in person, through a channel separate from the email itself.
Anatomy
OpenPGP data is built from a small set of packet types:
| Packet type | Purpose |
|---|---|
| Public key packet | Carries the public half of a key pair, used to encrypt to or verify signatures from that key |
| Secret key packet | Carries the private half of a key pair, used to decrypt or sign |
| Signature packet | Binds a signature to a message, a key, or another packet |
| Encrypted data packet | Carries the ciphertext of the encrypted message content |
RFC 9580 also sets a new default algorithm suite, moving away from the RSA-based defaults most existing OpenPGP deployments still carry:
| Purpose | RFC 9580 default | Older default |
|---|---|---|
| Key agreement | X25519 | RSA |
| Digital signatures | Ed25519 | RSA |
| Symmetric encryption | AES-OCB | AES-CFB |
| Hashing | SHA2-256 | SHA-1 / SHA2-256 |
Worked example
An encrypted message travels as an ASCII-armored block, plain text that can pass through any mail transport without corruption:
-----BEGIN PGP MESSAGE-----hQEMA4tG5x8kQm3xAQf/dJ2VnT8yLKp4X0rWvHqM3fBzC9sT6eYxN1oQpL8kR2wZmV5jH3nS7uF9tK1dA6bE0cP4gX2iY8lM3rQ7sN9vT1oK5wZ2xH6jL4mF8pR3dS0eY9uV1nT5oL7wQ2xZ6jM8kR4pS1dF3nH9tG5vE0cB7yX2iM4lQ8rN6sT9oK1wA3jH=Ab3D-----END PGP MESSAGE-----
Verifying who a public key belongs to relies on its fingerprint, a fixed-length hash of the key printed as hex, grouped in blocks of four:
9F2C 8A11 4D6B 7E20 3C45 1A9F 6D2E 8B77 C013 5F42
Two people comparing this string over the phone, or in person, is enough to confirm a key without any CA in the loop.
What OpenPGP doesn't solve
The web of trust doesn't scale the way a CA hierarchy does. A large organization coordinating keys for hundreds of employees has no equivalent of a corporate CA issuing and revoking certificates centrally; it has to rely on individual signatures accumulating over time.
Key discovery is a practical friction point. Finding someone's current public key, and knowing it's still the one they use, has no centralized directory to check against.
And like S/MIME, OpenPGP only works once both parties have working key infrastructure in place. A sender with a key and a recipient with no key, or no way to find one, still can't exchange encrypted mail.
Check it yourself
Run gpg --list-keys to inspect the public keys stored locally, including their fingerprints. To find a key you don't already have, fetch it directly from a public keyserver.
Where it fits
S/MIME solves the same confidentiality and integrity problem as OpenPGP, but through a CA hierarchy instead of a web of trust. The two are separate standards, not interchangeable.
An encrypted OpenPGP block still needs to travel inside a standard email. PGP/MIME wraps that block using MIME's multipart structure so it survives ordinary email transport.
For the full standards landscape this page sits inside, see the reference hub.
FAQ
Does OpenPGP require a certificate authority?
No. That's the core difference from S/MIME. OpenPGP verifies identity through a web of trust, other people vouching for a key, or direct out-of-band fingerprint verification, not a CA hierarchy.
What changed in RFC 9580's default algorithms?
It sets a modern suite as default: X25519 for key agreement, Ed25519 for signatures, AES-OCB for symmetric encryption, and SHA2-256 for hashing. That moves away from the older RSA-based defaults most existing OpenPGP deployments still carry.
How do I know a public key actually belongs to who it claims?
Either through the web of trust, where other people have already signed and vouched for that key, or by verifying the key's fingerprint directly with its owner through some other channel.
Can OpenPGP and S/MIME interoperate?
No. They use incompatible trust models and message formats. A recipient needs support for whichever one the sender used.
RFC reference
RFCs covered: RFC 9580. Superseded / updated by: None. RFC 9580 obsoletes RFC 4880 and its errata, RFC 5581 and RFC 6637.