Summary

  • RFC 2440 defined many OpenPGP packet tags but deliberately supplied no routine procedure for adding permanent new ones: feature interactions could reduce the security of the whole protocol.
  • The packet header's spare number space was not a license. The specification reserved 60–63 for private or experimental use and sent requests for new values to Security Area review or an appropriate IETF working group.
  • Inside signatures, an unknown subpacket was normally ignored; setting its critical bit let a signer prefer an error to silently losing a feature's meaning. Recognition still did not prove implementation, and unhashed metadata was not definitive evidence.
  • Later versions turned the restraint into explicit registries and stronger review rules. An assigned number, accepted parse, valid signature or test still proves only its own layer—not safe composition or deployment.

The empty slot was not the decision

Imagine a developer finding an unused tag in an OpenPGP packet. A prototype on two new clients writes the value, reads it back and passes a test. The bytes fit. But what will an older verifier do with the feature? Can a sender negotiate it away? Does another packet alter its meaning? Can a signature remain mathematically valid while the new semantics are ignored? A local round trip answers none of those questions.

That was the concern written into RFC 2440's IESG Note in November 1998. The document defined many tag values but no normal mechanism for adding more. Although new-format packet headers could represent tags through 63, the specification warned that subtle interactions between new and existing features could significantly reduce overall security. Requests for new values—encryption algorithms were the example—were to go to the IESG Security Area Directors or an appropriate working group. Values 60 through 63 remained private or experimental. Number space existed; a safe extension process did not follow automatically.

The note matters because OpenPGP was not a bag of independent algorithms. Packets are composed into keys, signatures and encrypted messages. A feature can alter how old software parses a sequence, how new software interprets a legacy field, or what a recipient believes a signature covers. A tag can be syntactically available while its interactions remain unexamined. RFC 2440 separated encoding capacity from protocol permission.

Signatures made the boundary visible

The same tension appeared at a smaller scale in signature subpackets. Forward compatibility favored ignoring an unfamiliar subpacket: an older implementation could still process a signature carrying metadata it did not know. RFC 2440 therefore said implementations should ignore unrecognized subpacket types. Yet silent ignorance could also erase a feature on which the signer relied.

Bit 7 of the subpacket type supplied a choice. If the bit marked an unknown subpacket critical, the evaluator should consider the signature erroneous. The signer could prefer visible failure over acceptance after dropping meaning. It was not a universal guarantee: the evaluator had to recognize the rule, and a recognized subpacket might still not be implemented. The standard explicitly distinguished those states.

Even a recognized value attached to a valid signature did not necessarily have signature authority. Subpackets could appear in hashed or unhashed sections. RFC 2440 warned that information in an unhashed subpacket was not definitive because it was outside the signature proper. A packet reader could see it; a verifier could parse it; neither fact made it cryptographically covered. The boundaries—present, parsed, recognized, implemented, covered—were separate.

From caution to a registry

RFC 4880, which replaced RFC 2440 in 2007, moved packet allocation into explicit IANA registries and required IETF consensus for new packet types, treating them as major features. It also called out downgrade and cross-grade risks around extensions to modification-detection behavior. The governance became more legible, but review could not collapse interoperability, implementation and security analysis into one checkbox.

RFC 9580, published in 2024, replaced RFC 4880 and retains differentiated allocation procedures. Some OpenPGP registries use Specification Required; packet types and selected version or identity spaces use the stricter RFC Required policy. Its experts are asked to consider security properties and interoperability with existing implementations. That is an institutional answer to the earlier gap, not proof that any accepted extension is safe in every deployment.

The documents do not establish that every possible extension was harmful, that all implementers followed one practice, or that a review process can predict every interaction. They show a more useful historical fact: in a cryptographic protocol, adding a meaning can change the behavior of existing paths. An available integer is only an address in the format. It is not evidence of compatibility, cryptographic coverage, user understanding or operational safety.

Sources