Summary

  • RFC 1984 treated a certificate, an escrowed private key, a recovery service, a signature credential and a live session as different control surfaces; none was a receipt for the others.
  • Its international argument was operational as much as political: conflicting restrictions could force one product toward the weakest common mechanism, while mutually suspicious governments still could not become a credible shared escrow holder.

A third party can attest without possessing

The Internet Architecture Board and the Internet Engineering Steering Group issued RFC 1984 as an institutional statement. Its sharpest passage does not reject third parties. It assigns them a narrower job.

Public-key systems often need a certification authority to sign a binding between an identity and a public key. Higher authorities may certify lower ones. The statement called that structure legitimate and necessary, and said governments could and should operate CAs for citizens’ transactions with government. A CA makes an assertion that relying parties can inspect. It need not receive the subject’s private key.

An escrow centre performs a different act. It receives or can reconstruct a secret that enables decryption or signing. That changes the set of principals who can exercise the capability. RFC 1984 therefore refused to treat “trusted third party” as a sufficient design description. The question is what the third party can do.

A certificate proves that a named authority signed a particular identity–public-key binding under its policy. It does not prove that the authority generated the private key, stored it, tested the user’s endpoint or witnessed every later signature. The public record and the private capability occupy different sides of the trust boundary.

Recovery chosen by the owner is not compelled access

The document then separates two reasons that were often placed under one label. An owner may want a recoverable copy of a key used to protect stored files. That is a continuity choice: the owner accepts another custody risk to reduce the risk of permanent data loss. RFC 1984 did not forbid the choice. It insisted that the customer should make it.

Compelled escrow reallocates that choice. A government or designated third party holds a secret for access purposes whether or not the data owner wants a recovery service. If the government has the only extra copy, the arrangement may be useless when the owner loses access. The same database can therefore be described as “recovery” while failing the person whose data is supposed to be recovered.

Purpose matters as well. Stored data may need to survive for years. An ephemeral conversation may have no legitimate recovery requirement after it ends. Treating both as the same key-management problem turns retention into a default even where the application does not need it.

An escrow receipt consequently proves little on its own. It may show that a blob was deposited, but not that it is the current key, that the right party can retrieve it, that access was authorised, that the copy has not leaked, or that it covers the data of interest.

A signing key cannot have two exclusive owners

RFC 1984’s treatment of signature and authentication keys is categorical because their evidentiary role depends on controlled exclusivity. A digital signature is useful when the verifier can rely on the proposition that only the legitimate holder could have exercised the private key.

Escrow introduces another possible signer. The third party may never misuse the key, but the proof structure has changed. The legitimate holder can later say the escrow holder signed; an accused party can allege that government access produced the evidence. The system has not merely acquired a recovery path. It has acquired a second source of apparently valid acts.

This is why a valid certificate is not evidence of a unique signer. The certificate binds a public key to an identity. Uniqueness depends on private-key generation, custody, access control, device integrity, revocation and audit. Copying the private key preserves certificate validity while weakening the inference a verifier wants to draw from a signature.

Confidentiality keys present different consequences. Sharing one may expose old or future data, depending on the design, but it does not automatically create a valid signature. Key purpose must be recorded before anyone can say what escrow enables.

The weakest common mechanism was a product decision

The international section of RFC 1984 is often remembered as an objection to export controls. Its more durable observation concerns product architecture. A company selling into countries with conflicting restrictions may use one weak mechanism to satisfy all of them. The legal intersection becomes the engineering ceiling.

That choice can simplify development, testing and support, but it exports the weakest jurisdictional rule into markets that did not require it. Separate builds can preserve stronger protection elsewhere, yet they create version inventories, compatibility branches, update obligations and the risk that a restricted build travels outside its intended market. Neither path is costless.

Key escrow did not solve the coordination problem. If two governments regard one another as potential adversaries, neither has reason to disclose its access keys to the other. A supposedly universal recovery mechanism then requires a new transnational trust arrangement more demanding than the commercial transaction it was meant to protect.

An export licence is only a bounded receipt. It can establish that a specified item was authorised under specified conditions. It cannot prove that the same build is available in every country, installed by customers, interoperable with other builds, free of escrow, or secure in operation.

The compliant outer layer may not contain the plaintext

RFC 1984 also attacks a simple equation: possession of an escrow key equals access to the user’s information. A user can encrypt content first and then place it inside an approved escrowed layer. Recovering the outer layer reveals another ciphertext, not the message. The mandate may be visible in the product while being irrelevant to a determined actor.

The same boundary appears in its short discussion of perfect forward secrecy. Theft or escrow of a long-term private key need not make earlier session traffic recoverable. In a forward-secret design, access may require control during the conversation. The RFC explicitly called its explanation an oversimplification, which is itself an evidence instruction: do not convert a directional design point into a universal claim.

One successful decryption proves that a particular ciphertext was readable with a particular combination of key and state. It does not prove that every session used that key, that earlier traffic can be reconstructed, that the plaintext was authored by a named party, that access was lawful or that the system remains secure.

Key length was one variable, not a verdict

The statement opposed restrictions based on short keys because computing power and the time value of secrets move. A key that resists an attack today may not protect a conversation that must remain confidential for years. A mechanism breakable by one well-resourced actor may be breakable by another.

Yet the inverse does not follow. A long key is not a security certificate for a system. Random generation can fail. Implementations can leak. Endpoints can be compromised. Protocol composition can expose metadata or permit substitution. Custody can be weak. Key length affects the cost of one class of attack; it does not close the rest of the system.

What changed in 2015—and what did not

The RFC Editor record now lists RFC 1984 as Best Current Practice, BCP 200. The IETF status-change record shows that the IESG approved an in-place change in September 2015. The rationale emphasised continuity and said the original principles had held up; the text was not rewritten.

That is a standards-community receipt. It proves a later status decision about the existing document. It does not prove that governments changed law, that vendors shipped one uniform cryptographic build, that escrow disappeared, or that a particular system satisfies the statement.

RFC 1984’s lasting contribution is therefore not a claim that one institution settled cryptographic policy. It is a map of non-substitutable evidence. Certification is not custody. Custody is not owner recovery. Recovery is not authorship. Long-term key access is not session plaintext. Permission to export is not secure availability. The Internet’s trust boundary becomes clearer when each proposition has to present its own receipt.

Primary records

RFC 1984 TXT · RFC 1984 HTML · RFC Editor record · IETF document record · status change · status history · IESG ballot · IAB overview · IESG overview · existing IETF directory entry