Формат метки времени
Введение
Метка времени – это подписанный (ЭЦП) сертификат, содержащий штамп времени, выдаваемый сервисом меток времени. С помощью такого сертификата можно установить факт существования информации в засвидетельствованный момент времени.
«Метки времени» образуют цепочку, в которой каждая последующая метка содержит доказательство, что выдана именно после предыдущей (в метку включается хеш предыдущей). Таким образом, снижается риск фальсификации «метки времени» — если сервис выдаст «метку времени» задним числом, это можно будет обнаружить.
Использования связывания «меток времени» позволяет вам контролировать сервис.
Цепочка меток времени – последовательность «меток времени», где каждая последующая «метка времени» имеет доказательство, что была выдана именно после предыдущей.
Формат метки времени
Примечание: Хеш значение атрибута Ref-Hash считается от следующей части предыдущей метки:
Немного подробнее формат "меток времени" описан в статье Формат «Меток времени»
p.s. Для упрощения в настоящий момент упразднил два формата меток времени.
© 2007 ntldr
© 2008 poptalk
© 2009 Анонимные пользователи
Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike
комментариев: 371 документов: 19 редакций: 20
комментариев: 232 документов: 17 редакций: 99
В подписи может быть использована более слабая функция хэширования.
комментариев: 371 документов: 19 редакций: 20
комментариев: 232 документов: 17 редакций: 99
Он ещё не устарел и его можно было оставить для скорости, но впринципе согласен.
комментариев: 271 документов: 13 редакций: 4
Ведь если я передам оригинальный документ, что мешает сервису заменить в документе автора на другого? Если имя автора в док. будет прописываться стандартным образом, подмена автора может быть автоматической. :-( Борьба с плагиатом станет невозможной.
И, кстати, мошеннический сервис может выдать не только свою метку времени, но и получить метки на других серверах. Так что даже нельзя будет определить, кто из сервисов является М.
комментариев: 232 документов: 17 редакций: 99
Достаточно хэша, хотя можно послать и документ.
Легко проветь правильность работы сервиса, т.е. сервис рискует быть пойманым.
В метке содержится адрес сервиса.
комментариев: 271 документов: 13 редакций: 4
Так сервис и работает правильно, когда он подменяет автора. Подмена не противоречит правилам работы сервиса.
комментариев: 232 документов: 17 редакций: 99
Они избыточны, т.к. для проверки цепочки всё равно нужно получать список меток.
комментариев: 232 документов: 17 редакций: 99
Противоречит, т.к. сервис должен заверять оригинальный документ.
комментариев: 271 документов: 13 редакций: 4
Только что вы говорили, что оригинальный документ посылать не обязательно, а теперь уже обязательно.
комментариев: 271 документов: 13 редакций: 4
Таким доказательством является порядковый номер метки. Если порядковые номера только возрастают и занимают сплошной диапазон. Действительно ли нужны эти поля?:
Обосную свою точку зрения: сервис выдал мне метку с номером N1 и временем T1. Теперь сервис хочет создать метку задним числом, то есть со временем T2<T1 (и номером N2). Следовательно, N2<N1. Но весь диапазон 0.. N1 уже занят. (Отрицательные N запрещены. ;-) )
комментариев: 271 документов: 13 редакций: 4
Можно более гибко, разрешить запросы вида
http://signer.com/ref.php?min_id=Ref-Id&max_id=Ref-Id
а результат сжать штатным сжатием http.
комментариев: 232 документов: 17 редакций: 99
Если я вступил в сговор со службой меток, то могу сначала "застолбить" себе место, а после заменить необходимую метку.
Связывающие хэши противостоят этой атаке.
комментариев: 143 документов: 31 редакций: 143
Нужна именно цепочка меток, где каждая метка связана с предыдущей и последующей.
Каждое заинтересованное лицо может сделать несколько «контрольных» меток времени и запомнить их. Потом клиенту достаточно проверить цепочку до такой сохраненной метки.