Summary

  • RFC 1991 placed a signature beside literal data, compressed that pair, encrypted the result with a session key, prepended a public-key packet for each recipient, and optionally wrapped the binary object in ASCII Armor. The order determines what each check actually covers.
  • Armor and CTB made a PGP file transportable and parseable. Their CRC, type and length fields are framing receipts, not proof of authorship, trusted time, authorisation, complete processing or human receipt.
  • Even a valid signature covers a defined byte sequence, classification and freely chosen timestamp—not every literal-packet field, a natural person or the purpose for which a relying system uses the message.

Six green lights on one old message

Imagine a 1996 operations desk receiving a block of printable characters. The header says it is a PGP message. The radix-64 text converts cleanly into binary. Its Armor checksum matches. The first control byte names a public-key-encrypted packet and its length lands precisely on the next packet. A private key recovers a session key; the key-check bytes agree. The ciphertext opens. The compressed object expands. The signature verifies.

That sequence feels like one verdict because the interface can present it as one. RFC 1991 describes something more exact. Each green light belongs to a different transformation. The standard’s achievement was to make those transformations composable. The evidentiary danger begins when a successful outer operation is allowed to speak for an inner one—or when an inner cryptographic result is promoted into identity, authority or delivery.

The distinction matters historically. RFC 1991 did not merely add encryption to electronic mail. It documented a file as one or more packets, allowed packets to be nested, and set an ordinary order for signing, compression, symmetric encryption, public-key session-key delivery and printable transport. A message became a compound object whose layers could be reversed by software. That was interoperability. It was not a universal witness.

The order fixes the signed object

The default construction begins at the literal data. PGP creates a signature for the message and places the signature packet before the literal data packet. If compression is selected, it compresses that pair into a compressed data packet. It then encrypts the compressed packet with a one-time conventional session key. Finally, it encrypts that session key for each recipient and places one public-key-encrypted packet per recipient before the conventional ciphertext.

The order is not cosmetic. The signature is made before compression and encryption. A verifier who later sees the plaintext is checking the signed bytes recovered from inside those outer transformations. The encryption layer does not expand the signature’s coverage. Nor does a successful signature retrospectively authenticate the Armor header, the mail route or every field that travelled beside the literal bytes.

RFC 1991 makes that last point unusually concrete. A literal data packet contains a mode byte, a suggested filename, a time field and literal data. Only the literal data field enters the document-signature digest. The filename may look authoritative; the time may look like a file-system fact; the mode may direct how software writes the result. Under this format, those fields are not covered by the ordinary document signature.

Detached signatures expose the same geometry from another angle. They are calculated on a separate file without the literal-packet header fields, so the same signature can work whether attached or detached. Multiple independent signers may each sign the document. If signatures are nested instead, a later signer covers both the document and an earlier signature. “The signatures verify” is therefore incomplete unless the record also says which bytes and which prior signatures each one covered.

CTB is a map, not a witness

RFC 1991’s packet structure field begins with the cipher type byte, or CTB. Its bits distinguish packet types—signature, compressed data, conventional-key-encrypted data, literal data and others—and specify whether the following length occupies one, two or four bytes. A special no-length form was used for compressed data until the end of its enclosing structure.

This was valuable machinery. A receiver could walk a concatenated file, identify the next envelope and know where its body ended. Nested objects could be processed without treating the entire file as one undifferentiated byte stream.

But type and length are syntactic claims. A well-formed CTB proves that the bits fit a declared packet grammar. A matching length proves that the parser reached the declared boundary. Neither proves that the body came from the named person, that the selected algorithm is supported safely, that the enclosing structure was complete, or that the application should execute what it found.

Indefinite-length compressed data makes the boundary especially visible. “Until the end of the enclosing structure” is meaningful only if the enclosing structure itself is known. Successful local parsing can coexist with a wrong higher-level assumption. The parser’s jurisdiction ends where the next layer’s evidence begins.

Armor solved a transport problem

Binary ciphertext and signatures did not fit every mail path of the period. RFC 1991 therefore mapped each three binary bytes into four printable ASCII characters, excluded characters likely to be altered by mail systems, and wrapped the result in a header, optional Armor headers, body, checksum and tail. The 24-bit CRC was calculated over the binary data before radix-64 conversion.

ASCII Armor is easy to overread because its boundary is so visible. A complete block looks official. A matching CRC makes it feel sealed. Yet the RFC explicitly says Armor headers belong to the armor, not the message, and must not carry important information because transport may change them. Unknown but correctly formatted header keys are reported, then processing continues.

Armor therefore provides a narrow receipt: these printable characters reconstructed a binary byte stream consistent with the wrapper and checksum. The checksum can detect accidental transmission errors within its design. It does not authenticate the sender. It does not say the ciphertext was meant for this recipient, that the binary object contains a valid signature, or that an attacker did not replace the entire block and recompute the CRC.

That separation is the design’s strength, not a defect. A thin transport wrapper can remain easy to reproduce and inspect because it does not pretend to decide identity or policy.

Decryption has its own narrow receipts

The conventional ciphertext begins with random material plus repeated key-check bits. After decryption, matching bytes let PGP assume that the chosen session key is correct. The public-key-encrypted packet also carries a checksum over the recovered data-encryption key. These checks help reject a wrong key path quickly.

They do not transform decryption into authentication. A key-check match says something about this decryption operation and its internal consistency. It does not establish who invoked the private key, whether the invocation was authorised, whether the endpoint was compromised, whether all ciphertext was processed correctly, or whether a human recipient received the plaintext.

The public-key packet’s 64-bit key ID is similarly bounded. RFC 1991 itself warns that two keys may share an ID by chance or malice. The ID helps select candidates; it does not uniquely identify the key, much less its natural-person owner. A reliable receipt must preserve the actual key material or a stronger identifier, candidate resolution, lifecycle state and the context that authorised its use.

A valid signature still needs a subject and a clock

RFC 1991 describes signature verification as comparing a newly calculated digest with the signed digest recovered under a public key. That verifies a cryptographic relation between a key, a signature packet and defined bytes. The format also supplies signature classifications: binary document, canonical text, several grades of key-and-user-ID certification, revocation and intended timestamping.

Those classifications are not interchangeable. A document signature is not a key certification. A generic certification says less about identity checking than a positive certification. Some classifications were not emitted by PGP 2.6.2 at all. A parser that recognises a number has not proved that a real implementation created or enforced the associated meaning.

Time is another explicit boundary. The ordinary signature timestamp is usually near creation, but the RFC says this is not required and users may date signatures as they wish. Trusted time requires a separate notary signature over the signature packet. A valid ordinary signature can therefore preserve a claimed timestamp without proving freshness, non-replay or a legal signing time.

Identity and authority remain outside the mathematical result. A User ID packet is printable text associated with a key. Verification does not turn that string into a verified natural person, current employer or authorised decision-maker. Private-key control can also change over time. The relevant questions are which key was resolved, who controlled it at the asserted time, which certification policy was trusted, whether it was revoked or compromised, and what action the organisation allowed that principal to take.

The historical contribution was a disciplined stack

The RFC Editor record identifies RFC 1991 as Informational and now obsolete through RFC 4880. That status does not erase its historical value, nor does publication prove universal deployment. The IETF record and the canonical HTML and text preserve what the 1996 document actually specified.

The linked IETF directory entry supplies institutional navigation only; it is not evidence that the organisation endorsed this article’s interpretation.

Read with a running-code discipline, its contribution is a compact lesson in authority. A shared format should define the minimum common facts participants can validate locally. CTB and packet lengths can establish syntax. Armor can establish transport reconstruction. A signature can establish a relation among a key and defined bytes. Later decisions—identity, trusted time, permission, execution and outcome—remain with the systems responsible for them.

That is also the useful separation in Lu Heng’s essays on running-code primacy, minimum initial specification and local future decisions, and reality layers. They are an editorial method here, not evidence about PGP deployment. The wire record should describe what was parsed and verified; it should not borrow authority from facts it never observed.

RFC 1991’s envelopes were valuable because they were narrow. The durable operating rule is equally narrow: preserve one receipt per transformation, and never let a successful layer announce the result of the next.