(Untitled)
Задумался вот. Допустим, пишем мы вебсайт, к которому есть такое интересное требование - non-repudiation. То есть если юзер выполняет на нём некое действие - он не должен иметь возможности отрицать, что он его совершил, даже если сайт вместе со своей датабазою взломан вдребезги и пополам
( Read more... )
Ну да. Насколько я понимаю, этот проект для того и придуман, чтобы можно было позвать. Но в нашем случае это defeats the purpose.
POST/GET запросы подписывать не удобно, КМК. Я бы и с клиента гонял какие-то подписанные сообщения.
Я в общем-то это и имел в виду - POST-ить подписанный XML или JSON.
Кстати, потом нарвёмся на то, что "а кто вам сказал, что это сообщение было подписано в пределах срока жизни сертификата", то есть нужно ещё приключаться с TSA.
Интересно, я об этом не думал, да и что такое TSA, не знал. :-)
Ну а если:
- каждое сообщение включает в себя timestamp,
- сервер не принимает к исполнению запросы, timestamp которых отличается от его личного времени более чем на пять, скажем, минут,
- храним мы запросы, к примеру, не больше года,
- сертификаты выписываем на три, а обновляем через два,
то не закрывает ли это дырку?
Опции импорта ключей в неизвлекаемую память я в российских токенах не видел.
Хм, насколько я вижу, это вполне возможно: 1 (стр. 62), 2.
А неэкспортируемость, увы, палка о двух концах: это значит, что меры по резервированию потребуются совсем третьи.
Ну, если мы не шифруем данные, а лишь подписываем их, то нужно ли нам резервирование? Допустим, смарт-карта накрылась или потерялась. Отзываем сертификат, выдаём новую. Нет?
Reply
Reply
Reply
Leave a comment