id: Гость   вход   регистрация
текущее время 11:42 28/03/2024
Владелец: Alex_B редакция от 28/12/2007 14:36 (автор: SATtva) Печать
Категории: инфобезопасность, политика, разное
создать
просмотр
редакции
ссылки

Это старая редакция страницы Черновики / Статьи / Сервисметоквремени / Формат Метки Времени за 28/12/2007 14:36.


Формат метки времени


Не хотелось бы изобретать велосипед, но видимо придется. Прошу высказаться по теме. Далее следует набросок требующий доработки.


Оглавление документа:

Введение


Метка времени – это сертификат, выдаваемый сервисом меток времени. С помощью такого сертификата можно проверить время сертификации информации.


«Метки времени» образуют цепочку, в которой каждая последующая метка содержит доказательство, что выдана именно после предыдущей. Таким образом снижается риск фальсификации «метки времени» — если сервис выдаст «метку времени» задним числом, это можно будет обнаружить.

Формат метки времени

Данная метка публикуется на сервере.
Примечание: Ref-Hash считается только от заголовка метки, что будет достаточным для поддержания следа, но не раскрывает пользовательские данные.


Для упрощения доказательства третьей стороне пользователь получает данные в следующем виде:


  • Timestamp-version – протокол описывает формат файла, перечень используемых хэш функций и т.д.
  • Поле Timestamp-OpenPGP избыточно, как Timestamp — все эти данные содержатся в хэшируемых субпакетах подписи OpenPGP. — SATtva
  • По части Timestamp-OpenPGP согласен, но поле Timestamp улучшает читабельность метки и необходимо для корректной поддержки следа, так как Ref-Hash считается только от заголовка метки, а не от OpenPGP пакета. — ntldr
  • Я предлагаю отказаться от поля Timestamp по той причине, что это создаст неоднозначность с меткой времени в самой PGP-подписи. Что, если системное время сервера установлено не в UTC, а со смещением на местный часовой пояс? Тогда время в подписи и время в поле Timestamp покажут расхождение. И какому из показателей пользователь должен доверять? Лично я бы смотрел на метку времени в подписи, это для меня самоочевидно, раз данные заверены с помощью PGP.
    Что касается хэширования заголовка VS хэширования всего пакета данных, я не вижу преимуществ у первого варианта. Смотрите: поле Hash содержит хэш-значение текущего пакета данных (n), а поле Ref-Hash — то же самое хэш-значение предыдущего пакета данных (n-1), т.е. данные хэшируются один раз, а не два (для Ref-Hash они просто берутся из предыдущей метки). А целостность заголовка и его связь с пакетом данных обеспечивает цифровая подпись.
    Я настаиваю, что Timestamp-OpenPGP следует убрать из-за его избыточности, Timestamp — из-за отсутствия практической пользы и, что важнее, вероятного создания им неоднозначности. — SATtva
  • Имхо поле Hash следует убрать, так как целостность данных обеспечивается OpenPGP подписью, и оно здесь избыточно. Но если убрать поле Timestamp, то для проверки следа будет необходимо сохранение всей метки целиком, включая пользовательские данные. А что, если пользователь не хочет раскрывать эти данные раньше времени? Поэтому для поддержки следа стоит сохранять только заголовок метки. Проблему с расхождением времени подписи и значения поля Timestamp легко решить при написании кода сервиса (OpenPGP подпись должна содержать время в UTC). — ntldr
  • Ну, положим, все данные в любом случае сохранять не надо, достаточно пакет цифровой подписи (ибо ни хэш исходных данных, ни метку времени из подписи Вы без самих исходных данных всё равно не проверите). Но в целом с Вами соглашусь, для наглядности так лучше.
    Остаётся один вопрос: как расширить формат выдачи результата на распределённое заверение метки несколькими аналогичными службами? Может быть несколько полей Approved-by, каждое из которых содержит URL соответствующей службы и через двоеточие номер её метки? Сами эти службы могут хранить след в формате, аналогичном приведённому выше. — SATtva