Pull to refresh

Comments 17

Никакой. Не существует человека, способного описать эту бездну человеческим языком.
В следующий раз попробую использовать майнд-карты что бы взаимосвязи нарисовать, может хоть так будет понятнее. Хотя коллеги были правы когда минусов наставили, я забыл включить разметку страницы и текст был ужасен по виду.
Что именно в тексте вам не нравится?

Полное отсутствие структуры, скажем.

Она появилась. С первой статьей вышло так себе. Буду внимательнее.
Проблема в слове X.500. Мне потребовалось много лет и десятки мегабайт прочитанных руководств и стандартов, чтобы понять, что надо просто держаться подальше от всего, что имеет нотацию X.xxx. Монструзоные оссифицированные выпердыши бюрократической машины, пытающейся сложностью и «обширностью» стандарта оправдать собственные размеры.
В общем, соглашусь конечно. Но знаю целый ряд разрабов, которые RFC трактуют, так как им удобно местами их перевирая. Как результат, заметные «швы» и нестыковки по различным системам где сталкивается PKI от разных производителей. Хочется верить что со временем хоть что-то изменится.
Размер стандарта не влияет на степень «перевирания» в коде. А вот на «покрытие чтением» — влияет.

(перефразирую: чем меньше стандарт, тем больше вероятность, что человек, который пишет её реализацию, прочитал стандарт целиком).
И это тоже. Но желающих экономить на времени разработки тоже хватает, начинают выкидывать ну или не «покрывать чтением» отдельные куски того, что должно быть. Как пример делать в сертификатах поля почти одного типа, не придерживаясь того, что там в бумагах написано. А потом возмущаться почему это он «не лезет» в другие системы.
Но размеры стандартов впечатляют, да. Пока до сути доберешься заснешь не раз. И технологические вопросы иногда убивают всю ценность этих стандартов и сервисов, отсутствие оффлайна, например.

ППКС, боль связанная с X.500 и X.400 вечна

Вот да. Но судя по рейтингу и замечаниям такое впечатление что x.500 я написал сам)).
"… для этого требуется обратиться к OCSP/TSP-службе ГУЦ, которая ответит – действующий сертификат или же срок действия истек или сертификат отозван."
Зачем вы TSP приписываете? Эта служба подтверждает, что хэш существовал именно в указанный момент времени. А про то, что срок действия сертификата истек не нужно спрашивать ни у какой службы.
OCSP/TSP — эти службы вместе указал намеренно, поскольку человек, который хочет проверить действительность подписи на определенный момент времени будет общаться именно с ними. Так как надо проверить действительность сертификата подписи на момент подписи и действительность подписи под меткой времени от службы TSP.
Подразумевал следующий пример, пользователь по защищенному каналу получил от своего УЦ метку TSP и подписал документ вместе с ней. После чего отправил получившийся пакет получателю. Получатель был в отпуске, были технические проблемы с сетью, болел, занят был, тупил или что-то еще. В итоге, получатель начал проверять подпись под документом когда срок действия сертификата отправителя истек. Дальше есть два пути один совсем правильный — спросить у службы OCSP был ли действителен сертификат пользователя на момент подписания данного сообщения, была ли действительна подпись УЦ под меткой времени от TSP службы если ответ положительный, то имеет смысл попросить службу TSP о еще одной метке времени, добавить к документу OCSP-ответ и после подписания уже своим ключом сложить в архив. В этом случае, архив не будет зависеть от состояния УЦ отправителя, вдруг его закроют, а у вас в сообщении вся информация о подписях есть.

Путь второй, не совсем кошерный, попросить пользователя подписать сообщение заново текущим действующим сертификатом. Но и тут придется службы OCSP и TSP спрашивать в процессе проверки.

Отдельный производители OCSP и TSP делают в одном техническом решении.
Sign up to leave a comment.

Articles