Формат метки времени
Введение
Метка времени – это подписанный (ЭЦП) сертификат, содержащий штамп времени, выдаваемый сервисом меток времени. С помощью такого сертификата можно установить факт существования информации в засвидетельствованный момент времени.
«Метки времени» образуют цепочку, в которой каждая последующая метка содержит доказательство, что выдана именно после предыдущей (в метку включается хеш предыдущей). Таким образом, снижается риск фальсификации «метки времени» — если сервис выдаст «метку времени» задним числом, это можно будет обнаружить.
Использования связывания «меток времени» позволяет вам контролировать сервис.
Цепочка меток времени – последовательность «меток времени», где каждая последующая «метка времени» имеет доказательство, что была выдана именно после предыдущей.
Формат метки времени
Примечание: Хеш значение атрибута Ref-Hash считается от следующей части предыдущей метки:
Немного подробнее формат "меток времени" описан в статье Формат «Меток времени»
p.s. Для упрощения в настоящий момент упразднил два формата меток времени.
© 2007 ntldr
© 2008 poptalk
© 2009 Анонимные пользователи
Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike
комментариев: 143 документов: 31 редакций: 143
А знаки тире в сообщении пользователя должны ставиться только перед
BEGIN PGP SIGNED MESSAGE ,
BEGIN PGP SIGNATURE и
END PGP SIGNATURE
А "пользовательские данные (сообщение или ascii-кодированный файл)" не должны оформляться таким же способом?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 271 документов: 13 редакций: 4
Если два человека спорят, кто автор некоторой идеи, кто считается автором? Тот, кто зарегистрировал идею раньше. Поэтому дата метки времени важна.
Допустим, настощий автор зарегистрировал идею в момент T1, а потом опубликовал. Мошенник берёт идею, подписывает своим именем, и регистрирует в момент T2>T1, но на метке стоит дата T3<T1, благодаря тому, что сервис в сговоре.
комментариев: 11558 документов: 1036 редакций: 4118
Дальше сервис должен внести метку Т3 в свою базу — ой, номера меток и даты оказываются непоследовательны (поскольку Т3 была сгенерирована позднее, она будет иметь больший порядковый номер, но её дата по условию будет меньшей). Не забывайте, что вставить метку в базу "задним числом" (т.е. с меньшим порядковым номером) сервис не может благодаря связыванию по хэшам.
Допустим также, что оператор пошёл на самое крайнее нарушение протокола: он просто заверил подложную метку ключом сервиса, но не стал вносить её в базу ни в каком виде. Это с очевидностью будет раскрыто при возникновении конфликтной ситуации, поскольку метка с данным номером в базе сервиса не будет иметь ничего общего с представленной.
Ну и, наконец, как я уже говорил, сервис меток — это репутационная система. В любом из этих сценариев подлог с высокой вероятностью будет раскрыт. Это подорвёт доверие к сервису и сделает несостоятельными любые свидетельства, выданные им ранее, как легитимные, так и нет.
комментариев: 271 документов: 13 редакций: 4
Вы исходите из того, что сервис всего один. Представим, что оных много. Настоящий автор и мошенник пользовались разными сервисами. Мошеннический сервис до некоторого момента выдавал только легитимные метки, а после только нелегитимные. Соответственно, он выдаёт T3, но не T1.
комментариев: 11558 документов: 1036 редакций: 4118
Если это ключевой момент, то обратите внимание на формат метки, приведённый в документе, где URL сервиса является одним из важных полей. Впрочем, даже если бы его не было, разные сервисы заверяли бы метки разными ключами. Не вижу, как спутать метки, выданные разными сервисами. Каждый сервис отвечает исключительно за собственные выданные метки; остальные — это не его дело и не его ответственность.
комментариев: 143 документов: 31 редакций: 143
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 143 документов: 31 редакций: 143
первым пунктом.
Потом, поле
излишне, да и ключ пользователь должен получать из других источников.
Более ни каких изменений не вносил.
Тот который сейчас.
комментариев: 11558 документов: 1036 редакций: 4118
Ещё раз посмотрите внимательно два блока кода наверху. Поля в одном: Timestamp-version, Signed-by, Timestamp, Number, Ref-Hash-SHA512, Ref-Hash-RIPEMD160, Hash-SHA512, Hash-RIPEMD160. Поля в другом: Timestamp-version, Description, Signed-by, Timestamp, Number, Hash-SHA512, Hash-RIPEMD160. Найдите три отличия. :-)
комментариев: 143 документов: 31 редакций: 143
В одном формате метки хранятся(публикуются) на сервере, в другом метка, для удобства использования, передается клиенту.
комментариев: 11558 документов: 1036 редакций: 4118
Почему бы не привести оба формата к общему знаменателю? К каким это приведёт потерям?
комментариев: 232 документов: 17 редакций: 99
Они всё равно будут отличаться, т.к. отсылаемые пользователю данные содержат оригинальный документ.
В данном случае с высылаемой пользователю метки удаляются все лишние поля, дабы не путать пользователя. А все поля необходимые для контроля находятся на сервере, а следить за их достоверностью будет гораздо меньше людей, понимающих что и как.
комментариев: 143 документов: 31 редакций: 143
Может все же действительно, перенсти все метаданные из сохраняемой метки времени в выдаваемую?
Нужно добавить всего-то два поля:
Ref-Hash-SHA512: (SHA512 хеш от предыдущей подписи)
Ref-Hash-RIPEMD160: (RIPEMD160 хеш от предыдущей подписи)
И все равно будет два формата – нельзя же на сервере хранить информацию пользователя.
И еще стоит ли подписывать храняющуюся метку времени?
комментариев: 11558 документов: 1036 редакций: 4118
Это нерелевантно, пользователь будет этого ожидать.
Получается всё наоборот. :-)
Три, там Description ещё. Оно сильно место не сэкономит.
Каждую — не обязательно. Блоками (суточными) — надо.