РегистрацияФормат метки времени
Введение
Метка времени – это подписанный (ЭЦП) сертификат, содержащий штамп времени, выдаваемый сервисом меток времени. С помощью такого сертификата можно установить факт существования информации в засвидетельствованный момент времени.
«Метки времени» образуют цепочку, в которой каждая последующая метка содержит доказательство, что выдана именно после предыдущей (в метку включается хеш предыдущей). Таким образом, снижается риск фальсификации «метки времени» — если сервис выдаст «метку времени» задним числом, это можно будет обнаружить.
Использования связывания «меток времени» позволяет вам контролировать сервис.
Цепочка меток времени – последовательность «меток времени», где каждая последующая «метка времени» имеет доказательство, что была выдана именно после предыдущей.
Формат метки времени
Примечание: Хеш значение атрибута Ref-Hash считается от следующей части предыдущей метки:
Немного подробнее формат "меток времени" описан в статье Формат «Меток времени»
p.s. Для упрощения в настоящий момент упразднил два формата меток времени.
© 2007 ntldr
© 2008 poptalk
© 2009 Анонимные пользователи
Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 371 документов: 19 редакций: 20
Изобрерать свой протокол, свой формат меток времени, и другие велосипеды имхо будет не полезно, а наоборот крайне вредно. Тем более – ни в коем случае никаких собственных форматов подписи. Для этого давно есть OpenPGP, для которого давно существует куча софта.
Имхо теперешний ваш подход напоминает политику проприетарных компаний, которые стараются сделать все по своему, не как у людей. Для открытого сервиса это неприемлимо.
комментариев: 143 документов: 31 редакций: 143
А хеш предыдущей метки? Автора ведь тоже нужно как-то определить – иначе какой смысл?
Вобщем нужно четко определиться с атрибутами.
ntldr, мое "желание" сделать все по своему продиктовано количеством моих знаний, очень спасибо за советы. Какие отрибуты нужны?
Я исходил из того что формат XML понятен всем (всем платформам), с ним удобно работать. Все таки разбор XML документа гораздо проще парсинга текстовых файлов.
Да, позже я перепишу все эти страницы с нормальными формулировками.
комментариев: 371 документов: 19 редакций: 20
комментариев: 371 документов: 19 редакций: 20
Для ускорения проверки цепочки подписей можно выпускать предыдущие штампы в .zip архивах по 10000 штук в каждом. И обязательно нужно написать софт который может автоматизировать такую проверку.
Оставляйте XML, он даёт бОльшую гибкость и уменьшает неоднозначность. Да и читать его проще – не надо так часто заглядывать в документацию, где что стоит. (В конце концов, убрать разметку можно одной строчкой -
s/<.*>//g :)
комментариев: 371 документов: 19 редакций: 20
Ну а разбор XML не проще парсинга текстового файла по CRLF разделителям. Берите пример с формата HTTP запросов, они легко читаются и легко поддаются парсингу.
XML это стандарт. Под него есть куча софта. Вот например смотри в начале – уже встроенная в wiki цветовая разметка XML. Вам легче читать черно-белый или цветной текст (когда программируете в VC, неужели отключаете?) В XML тоже никто не мешает, но это делается стандартным образом, не надо переписывать парсер, и самое главное, мозги пользователя.
Вообще, XML – это обычный текстовый файл, и это просто "протокол" следующего уровня. Кому-то ведь проще писать на ассемблере, но таковых меньшинство.
Лучше берите пример с формата HTTP-ответов :)
комментариев: 371 документов: 19 редакций: 20
Для начала обьясните, зачем может понадобиться переписывать парсер, и почему в описаный мной формат поля добавляются "нестандартным образом".
И обьясните, зачем заставлять пользователя ставить "кучу стандартного софта для XML", либо напрягатьть мозги разбираясь в хитросплетении тегов, если plain text формат можно читать и проверять без напряга.
Повторяю еще раз: ориентироваться стоит на пользователей у которых нет, и которые не хотят использовать какой-либо дополнительный софт, будь он хоть трижды стандартным. Работа с сервисом должна быть комфортной при наличии минимума софта (стандартного или нет). В моем случае для постановки штампа потребуется только броузер чтобы зайти на сайт, а для проверки – только PGP/GPG.
Имхо пусть автор сделает поддержку нескольких форматов, и пусть каждый выбирает то, что ему больше нравиться.
комментариев: 143 документов: 31 редакций: 143
А как быть с изображениями, вы же сами считаете возможность заверять изображения (скриншоты) полезной.
p.s. сервис будет реализован на C#, в виде веб-сервиса XML. Такой сервис может принимать POST, GET запросы, но все же наилучшее решение, ИМХО, SOAP-сообщения.
комментариев: 371 документов: 19 редакций: 20
А может быть клиент не хочет оставлять о себе никакой информации? Ну а если хочет, пусть указывает произвольную информацию в части для пользовательских данных. Сила сервиса в универсальности, и установление авторства не единственное возможное его применение.
Сервис делает скриншот в формате gif или png и вычисляет SHA512 от картинки. Хеш и урл с которого снят скриншот записываются в поле для пользовательских данных.
Все современные броузеры понимают XML Для полного счастья ещё надо CSS – стандартное описание правил визуализации помеченного. (HTML – частный случай XML :)
Пусть автор делает (или не делает) что ему хочется. У нас тут только совещательный голос.