Кратко

  • RFC 1805 предложил подписанный доверенной третьей стороной сертификат с хешем файла, датой и сведениями об авторе; проверка содержимого не зависела от адреса сервера.
  • Способ проверки автора протокол оставлял открытым. В описанной системе Bellcore Betsi для подтверждения регистрации и открытого ключа пользовались телефонной справкой и обратным звонком.

Скопировать файл по сети легко. Перенести доверие к человеку, чьё имя стоит рядом, намного сложнее. Aviel Rubin посвятил этому RFC 1805, опубликованный в июне 1995 года. В проекте действовали автор, получатель и доверенная третья сторона. Файл мог пройти через сомнительный узел; отдельный сертификат позволял сверить байты и дату. А установление личности автора, как показывает реализация Betsi в Bellcore, ещё могло начинаться с обращения в телефонную справочную. Техника получила мобильность, доверие — маршрут до конкретного человека.

Rubin сначала усомнился даже в программе проверки. Если злоумышленник подменил и файл, и проверяющее приложение, его зелёный результат не добавляет уверенности. Поэтому схема использовала ASCII-сообщения и распространённые средства цифровой подписи. Получатель мог написать независимый проверяющий код или взять надёжную копию из другого источника. Единственная программа не получала монополии на заключение о файле.

Пять этапов составляли весь путь: регистрация автора, подтверждение личности, сертификация файла, распространение и итоговая проверка. Второй этап был намеренно не задан до последней детали. Разные приложения могли удостоверять людей по-разному, но сертификат обязан был назвать использованный способ. Подпись показывает связь сообщения с ключом; кому принадлежит ключ, приходится устанавливать отдельно. Betsi, по тексту RFC, работала в США. Доверенная сторона искала номер автора через городскую справочную, звонила и сверяла данные регистрации, особенно открытый ключ.

Телефон здесь — метод конкретной реализации, а не обязательный пункт каждого экземпляра протокола.

Зарегистрированный автор вычислял криптографический хеш файла и посылал подписанный запрос третьей стороне. Та проверяла запрос и выпускала собственный подписанный сертификат: хеш, алгоритм, дата, имя автора и метод его удостоверения. Место хранения файла в запросе было необязательным. Это важнее, чем кажется. Заверялись содержимое и время, а не папка на FTP-сервере. Файл вместе с сертификатом можно было распространять и через площадки, которым получатель не поручил роль хранителя истины.

Получатель проходил цепочку заново со своей стороны. Он добывал открытый ключ третьей стороны из нескольких независимых источников, проверял её подпись, оценивал описанный способ установления автора, вычислял хеш фактически полученного файла и сравнивал значения. Если дата влияла на решение, сверял и её. Наконец, он просматривал актуальный, полный и подписанный список отзыва сертификатов. Красивой печати недостаточно, если документ уже выведен из обращения.

После всех этих действий можно сделать конкретный вывод о соответствии полученных байтов заверенному файлу и указанному моменту при принятых условиях идентификации и отзыва. Сертификат не решает за человека, стоит ли запускать эту программу. Телефонный звонок показывает главное напряжение замысла: адрес копии стал заменяемым, но приписать её автору можно было лишь через отдельный, называемый вслух акт доверия.