Summary

  • RFC 1805 proposed a location-independent certificate binding a file's hash and date to an author statement from a trusted third party, so the file could be distributed separately from its origin site.
  • The protocol deliberately left author-verification methods open; its Bellcore Betsi implementation checked registration offline through directory assistance and a telephone callback.

The Internet could move a file in 1995 far more easily than it could move trust in the person who offered it. Aviel Rubin's RFC 1805 tackled that mismatch with a compact cast: an author, a reader and a trusted third party. The file might pass through an insecure site or an unreliable network. Its integrity and date would travel in a separately signed certificate. But one part of this digital arrangement had a wonderfully stubborn analog accent: in the described Betsi implementation, verifying an author's identity involved looking up a telephone number and calling back.

Rubin began with an uncomfortable problem. A program that claims to check a file can itself be changed by an attacker. Trusting a downloaded verifier simply because it says “all clear” is circular. The proposal therefore used ASCII messages and familiar signature machinery so readers could build or obtain their own verification software. The protocol did not nominate a magic application as the sole judge. It gave independent programs a sequence of checks they could perform against the file, the certificate and a trusted party's public key.

Five phases organize the design: author registration, author verification, file certification, distribution and integrity verification. The second phase was deliberately left open. Different applications could identify authors differently, but the chosen method had to be disclosed in the later certificate. This was no minor footnote. A signature can bind a statement to a key; someone still has to establish whose key it is. In Betsi, Bellcore's trusted party used local directory assistance in the author's city to obtain a number, called it, and checked the registration details and public key. The RFC describes that U.S.

implementation; the wider protocol did not require everyone to verify identity by telephone.

Once registered, an author computed a cryptographic hash of a file and sent a signed certification request to the trusted party. The party checked the request and returned its own signed certificate. That certificate included the file hash, hash-function name, date, author name and the method used to verify the author. File location in the request was optional. The important object was the relation between bytes and certificate, not the FTP directory where someone happened to store a copy. The author could hand out the file and certificate together even through sites the reader did not trust to keep them intact.

The reader's work started where the distribution path ended. First obtain the trusted party's public key from independent sources. Then verify the party's signature on the certificate, decide whether its stated author-verification method is credible, hash the actual file and compare that value with the certified hash. Check the date if the date matters. Finally consult a current, complete, signed revocation list and make sure the certificate has not been revoked. Skipping the last step because the seal looks handsome defeats the point of maintaining a revocation list at all.

This chain says something useful and bounded. Matching hashes and a valid certificate support a claim that the obtained bytes match those the trusted party certified at a stated time, under the disclosed author-check method and revocation state. They do not give the software a moral character reference or prove that executing it is wise. The best historical detail is the telephone. It exposes the seam between a file that can move anywhere and an identity claim that still depends on a situated, accountable act of verification. The route became flexible; the trust decision had to keep its address.