Summary

  • RFC 9980 permits a sender to encrypt one OpenPGP message for PQ/T and traditional recipients during migration, while explicitly limiting the post-quantum confidentiality claim to messages whose every recipient key is PQ/T.
  • The control object is the actual recipient set and emitted PKESKs, not a reassuring key-directory badge. Compatibility exceptions need an owner, a message-class boundary and an expiry.

A new key does not relabel an old ciphertext

The tempting operational shorthand is simple: the directory contains an ML-KEM-768+X25519 key, so the organisation is “post-quantum ready.” RFC 9980 does not support that sentence. It defines algorithms and packet formats. It does not attest a client, a directory, a mailbox, a person or a deployed fleet.

More importantly, OpenPGP can encrypt the same content-encryption session key to several recipients. During the transition, Section 8.1 permits an implementation to send both PQ(/T) and traditional recipient packets so that communication does not break. That may be a sensible local choice. The protocol makes the cost visible: a future attack on any traditional recipient path can still expose the same message. Section 3.1 therefore reserves post-quantum confidentiality for the stricter case in which all keys used for those recipient packets support PQ(/T) encryption.

The word “all” changes the evidence task. A security record cannot stop at “a PQ key exists.” It needs the exact message class, recipient identities as the sending system resolved them, every encryption-capable key selected or excluded, each algorithm and key version, the recipient packets actually emitted, the capability evidence for the consuming implementation, and the policy decision that allowed a traditional path. A recipient set is a decision surface, not a decorative address list.

A composite key is not a second recipient

RFC 9980 deliberately distinguishes two constructions that can look similar in a dashboard. Its composite encryption scheme combines ML-KEM and an ECDH KEM inside one PQ/T recipient key. The sender derives a single key-encryption key from both component key shares, the ECDH ciphertext and protocol binding data, then wraps the session key. The required component operations are both part of that one construction.

OpenPGP also supports parallel encryption by placing multiple PKESK packets in a message. A traditional recipient packet beside a PQ/T recipient packet is not another component of a composite key. It is a separate route to the same session key. Conflating these shapes produces the exact false assurance RFC 9980 warns about: “hybrid” describes one eligible recipient construction; it does not upgrade a message that also offers a separate classical decryption route.

This is where labels turn into governance. A message may legitimately remain compatible because a counterparty has not upgraded, a recovery contact requires a legacy path, or a service class has a defined continuity obligation. Those reasons do not disappear because the sender also added a stronger key. They should be named as exceptions with a business owner and a review date, rather than silently inherited by every message tagged confidential.

Encryption compatibility and signature compatibility are different choices

RFC 9980 supplies a second, intentionally different transition pattern for signatures. A sender may sign with both a PQ(/T) key and a traditional key because legacy software can fall back to the traditional signature. A PQ/T-only signature is not backwards compatible. A verifier may accept both; a verifier that knows a peer has a PQ/T signing key and is concerned about a cryptographically relevant quantum computer may instead choose to ignore that peer’s traditional signature.

That rule is not a universal identity policy. A valid signature does not establish the sender’s authority, the correctness of the message, recipient consent or endpoint safety. It does establish that encryption and signing cannot be governed by one undifferentiated “PQC enabled” flag. They have different packet shapes, compatibility effects, verification choices and relying parties.

Version, capability and observation remain local facts

The standard requires all PQ(/T) asymmetric algorithms to use v6 or newer keys and certificates, except that ML-KEM-768+X25519 may also appear in v4 encryption-capable subkeys. It requires a baseline of ML-DSA-65+Ed25519 and ML-KEM-768+X25519, while other listed algorithms have different requirement levels. IANA registration makes these identifiers intelligible; it does not prove that any particular sender or recipient implements them.

The useful operating proof is consequently small and replayable. Preserve a sample of the emitted packet metadata or a privacy-safe cryptographic audit record; map recipient keys to the message class; retain capability tests or interoperable acceptance evidence where it is warranted; and record the decision to permit a traditional recipient. Do not store message content merely to create a migration dashboard. The point is to prove the construction and decision boundary with the minimum information needed to review it.

Sources