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

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

Введение

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

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

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

Данная метка публикуется на сервере:
-----BEGIN PGP SIGNED MESSAGE----- Timestamp-version: (версия принятого формата метки времени) Description: (здесь краткое описание того, что из себя представляет это сообщение) Signed-by: (URL сервиса) Timestamp: (метка времени по гринвичу в формате принятом по RFC 822) Number: (порядковый номер метки) Ref-Hash-SHA512: (SHA512 хеш от предыдущей метки) Ref-Hash-RIPEMD160: (RIPEMD160 хеш от предыдущей метки) Hash-SHA512: (SHA512 хеш пользовательских данных) Hash-RIPEMD160: (RIPEMD160 хеш пользовательских данных) -----BEGIN PGP SIGNATURE----- подпись в формате OpenPGP -----END PGP SIGNATURE-----

Пользователь (автор) получает данные в следующем виде:
-----BEGIN PGP SIGNED MESSAGE----- Timestamp-version: (версия принятого формата метки времени) Description: (здесь краткое описание того, что из себя представляет это сообщение) Signed-by: (URL сервиса) Timestamp: (метка времени по гринвичу в формате принятом по RFC 822) Number: (порядковый номер метки) Ref-Hash-SHA512: (SHA512 хеш от предыдущей метки) Ref-Hash-RIPEMD160: (RIPEMD160 хеш от предыдущей метки) Hash-SHA512: (SHA512 хеш пользовательских данных) Hash-RIPEMD160: (RIPEMD160 хеш пользовательских данных) ############## Timestamped data follows ############### пользовательские данные (сообщение или ascii-кодированный файл) -----BEGIN PGP SIGNATURE----- подпись в формате OpenPGP -----END PGP SIGNATURE-----

Два формата меток нужны, что бы на сервере не хранилась информация пользователя (автора).

Примечание: Хеш значение атрибута Ref-Hash считается от следующей части предыдущей метки:
Timestamp-version: (версия принятого формата метки времени) Description: (здесь краткое описание того, что из себя представляет это сообщение) Signed-by: (URL сервиса) Timestamp: (метка времени по гринвичу в формате принятом по RFC 822) Number: (порядковый номер метки) Ref-Hash-SHA512: (SHA512 хеш от предыдущей метки) Ref-Hash-RIPEMD160: (RIPEMD160 хеш от предыдущей метки) Hash-SHA512: (SHA512 хеш пользовательских данных) Hash-RIPEMD160: (RIPEMD160 хеш пользовательских данных)

© 2007-2008 Alex_B, SATtva, serzh
© 2007 ntldr
© 2008 poptalk

Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike

На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.

Комментарии [скрыть комментарии/форму]

—	SATtva (20/12/2007 17:07) профиль/связь <#> комментариев: 5483 документов: 801 редакций: 823
	отпечаток ключа: ...`FAEB26F78443620A`

Уберите MD5! Этот алгоритм не должен применяться в контексте цифровых подписей.

—	ntldr (20/12/2007 17:38) профиль/связь <#> комментариев: 329 документов: 10 редакций: 16
	отпечаток ключа: ...`C48251EB4F8E4E6E`

Зачем изобретать велосипед? Пусть метка времени выглядит как обычный текст подписаный в формате clear sign. В тексте должна быть ссылка на сервис, id предыдущей метки времени, дата и время и определенный пользователем текст. Короче все как в stamper.
Изобрерать свой протокол, свой формат меток времени, и другие велосипеды имхо будет не полезно, а наоборот крайне вредно. Тем более – ни в коем случае никаких собственных форматов подписи. Для этого давно есть OpenPGP, для которого давно существует куча софта.
Имхо теперешний ваш подход напоминает политику проприетарных компаний, которые стараются сделать все по своему, не как у людей. Для открытого сервиса это неприемлимо.

—	*Гость* (20/12/2007 17:42) <#>

"Сертификат авторства" – неудачный термин, поскольку удостоверяется не авторство.

—	Alex_B (20/12/2007 17:59, исправлен 20/12/2007 18:00) профиль/связь <#> комментариев: 112 документов: 20 редакций: 63

>Пусть метка времени выглядит как обычный текст подписаный в формате clear sign. В тексте должна быть ссылка на сервис, id предыдущей метки времени, дата и время и определенный пользователем текст.

А хеш предыдущей метки? Автора ведь тоже нужно как-то определить – иначе какой смысл?
Вобщем нужно четко определиться с атрибутами.

ntldr, мое "желание" сделать все по своему продиктовано количеством моих знаний, очень спасибо за советы. Какие отрибуты нужны?

Я исходил из того что формат XML понятен всем (всем платформам), с ним удобно работать. Все таки разбор XML документа гораздо проще парсинга текстовых файлов.

>"Сертификат авторства" – неудачный термин, поскольку удостоверяется не авторство.

Да, позже я перепишу все эти страницы с нормальными формулировками.

—	*Гость* (20/12/2007 18:08) <#>

Может "Свидетельство момента наличия"?

—	ntldr (20/12/2007 18:28, исправлен 20/12/2007 22:33) профиль/связь <#> комментариев: 329 документов: 10 редакций: 16
	отпечаток ключа: ...`C48251EB4F8E4E6E`

Формат текстовой части подписи добавляемой сервисом:

-----BEGIN PGP SIGNED MESSAGE----- ####################################################### Description:(здесь краткое описание того, что из себя представляет это сообщение) Signed-by: (URL сервиса и id его PGP ключа) Timestamp: (метка времени по гринвичу в формате принятом по RFC 822) Ref-Id: (порядковый номер предыдущей метки, по которому можно получить ссылку на нее) Ref-Hash: (SHA512 хеш от предыдущей подписи) ####################################################### пользовательские данные (произвольный переданый на подпись текст) -----BEGIN PGP SIGNATURE----- подпись в формате OpenPGP -----END PGP SIGNATURE-----

—	ntldr (20/12/2007 18:31, исправлен 20/12/2007 18:34) профиль/связь <#> комментариев: 329 документов: 10 редакций: 16
	отпечаток ключа: ...`C48251EB4F8E4E6E`

Для проверки цепочки штампов нужно будет получить предыдущий штамп по ссылке http://signer.com/ref.php?id=Ref-Id, вычислить SHA512 от него, и сравнить с полем Ref-Hash текущего штампа.
Для ускорения проверки цепочки подписей можно выпускать предыдущие штампы в .zip архивах по 10000 штук в каждом. И обязательно нужно написать софт который может автоматизировать такую проверку.

—	*Гость* (20/12/2007 18:45) <#>

Я исходил из того что формат XML понятен всем (всем платформам), с ним удобно работать. Все таки разбор XML документа гораздо проще парсинга текстовых файлов

Оставляйте XML, он даёт бОльшую гибкость и уменьшает неоднозначность. Да и читать его проще – не надо так часто заглядывать в документацию, где что стоит. (В конце концов, убрать разметку можно одной строчкой -
s/<.*>//g :)

—	ntldr (20/12/2007 18:55) профиль/связь <#> комментариев: 329 документов: 10 редакций: 16
	отпечаток ключа: ...`C48251EB4F8E4E6E`

Тогда лучше сделайте возможность выбора формата подписи. Например мне нравяться playn text форматы, которые читаются легче. И никто не помешает в такой формат добавить в будующем дополнительные поля. Метки создаваемые подобным сервисом должны легко проверяться человеком без привлечения стороннего софта (кроме разве что PGP/GPG).
Ну а разбор XML не проще парсинга текстового файла по CRLF разделителям. Берите пример с формата HTTP запросов, они легко читаются и легко поддаются парсингу.

—	*Гость* (20/12/2007 19:20) <#>

Например мне нравяться playn text форматы, которые читаются легче

XML это стандарт. Под него есть куча софта. Вот например смотри в начале – уже встроенная в wiki цветовая разметка XML. Вам легче читать черно-белый или цветной текст (когда программируете в VC, неужели отключаете?)

И никто не помешает в такой формат добавить в будующем дополнительные поля.

В XML тоже никто не мешает, но это делается стандартным образом, не надо переписывать парсер, и самое главное, мозги пользователя.
Вообще, XML – это обычный текстовый файл, и это просто "протокол" следующего уровня. Кому-то ведь проще писать на ассемблере, но таковых меньшинство.

Берите пример с формата HTTP запросов

Лучше берите пример с формата HTTP-ответов :)

—	ntldr (20/12/2007 19:29) профиль/связь <#> комментариев: 329 документов: 10 редакций: 16
	отпечаток ключа: ...`C48251EB4F8E4E6E`

> В XML тоже никто не мешает, но это делается стандартным образом, не надо переписывать парсер

Для начала обьясните, зачем может понадобиться переписывать парсер, и почему в описаный мной формат поля добавляются "нестандартным образом".
И обьясните, зачем заставлять пользователя ставить "кучу стандартного софта для XML", либо напрягатьть мозги разбираясь в хитросплетении тегов, если plain text формат можно читать и проверять без напряга.
Повторяю еще раз: ориентироваться стоит на пользователей у которых нет, и которые не хотят использовать какой-либо дополнительный софт, будь он хоть трижды стандартным. Работа с сервисом должна быть комфортной при наличии минимума софта (стандартного или нет). В моем случае для постановки штампа потребуется только броузер чтобы зайти на сайт, а для проверки – только PGP/GPG.

Имхо пусть автор сделает поддержку нескольких форматов, и пусть каждый выбирает то, что ему больше нравиться.

—	Alex_B (20/12/2007 19:30, исправлен 20/12/2007 19:34) профиль/связь <#> комментариев: 112 документов: 20 редакций: 63

ntldr, среди предложенных атрибутов не обнаружил никакой информации о клиенте.

>пользовательские данные (произвольный переданый на подпись текст)

А как быть с изображениями, вы же сами считаете возможность заверять изображения (скриншоты) полезной.

p.s. сервис будет реализован на C#, в виде веб-сервиса XML. Такой сервис может принимать POST, GET запросы, но все же наилучшее решение, ИМХО, SOAP-сообщения.

—	ntldr (20/12/2007 19:52) профиль/связь <#> комментариев: 329 документов: 10 редакций: 16
	отпечаток ключа: ...`C48251EB4F8E4E6E`

> ntldr, среди предложенных атрибутов не обнаружил никакой информации о клиенте.

А может быть клиент не хочет оставлять о себе никакой информации? Ну а если хочет, пусть указывает произвольную информацию в части для пользовательских данных. Сила сервиса в универсальности, и установление авторства не единственное возможное его применение.

> А как быть с изображениями, вы же сами считаете возможность заверять изображения (скриншоты) полезной.

Сервис делает скриншот в формате gif или png и вычисляет SHA512 от картинки. Хеш и урл с которого снят скриншот записываются в поле для пользовательских данных.

—	*Гость* (20/12/2007 20:12) <#>

Для начала обьясните, зачем может понадобиться переписывать парсер, и почему в описаный мной формат поля добавляются "нестандартным образом".

Вот именно потому, что описанный вами! Нестандартный.

В моем случае для постановки штампа потребуется только броузер

Все современные броузеры понимают XML Для полного счастья ещё надо CSS – стандартное описание правил визуализации помеченного. (HTML – частный случай XML :)

Имхо пусть автор сделает поддержку нескольких форматов

Пусть автор делает (или не делает) что ему хочется. У нас тут только совещательный голос.

—	*Гость* (20/12/2007 20:23) <#>

Дизайн документов XML

На страницу: 1, 2, 3, 4, 5, 6, 7, 8, 9 След.

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

Ваша оценка документа [показать результаты]