Лично мне OCSP как протокол для использования в РФ не очень нравится, мы даже это отдельно обсуждали на программном комитете PKI-Forum.

В выходные образовалось чуть времени на подумать про один из разделов программы про сопутствующие протоколы с точки зрения нашей действительности, так вот помимо DVCS, на мой взгляд и OCSP весьма проблематичен в использовании и на него надо бы с осторожностью смотреть.
Мысли следующие:
Во-первых, Из-за одного логически непродуманного места в самом протоколе OCSP, степень доверия в системах на его основе более чем в два раза меньше, чем в обычных PKI системах. Поясняю, в обычных PKI системах существует безусловное доверие единственному предмету – ключам издателя УЦ, для случая их компрометации регламентом должны быть определены особые способы оповещения пользователей, телефон, публикация в газете …. Т.е. далеко не RealTime. И приходится с этим мириться. Теперь смотрим, что происходит в системах с использованием OCSP. Протокол OCSP подразумевает, что квитанция имеет ЭЦП респонтдера и тут же встаёт вопрос – а чем (как) проверить ЭЦП на квитанции, как обеспечить доверие к ключам самого респондера – автора этой самой ЭЦП, что нужно делать ещё один или более OCSP запроса? Это привело бы в тупик. На практике чтоб расшить ЭТО, сертификат респондера имеет специальную метку - «но чек», т.е. пользователь должен безусловно доверять ключам респондера, информация о возможной компрометации которых тоже должна быть расписана в регламенте аналогичным выше описанным способом. Т.е. у нас появилось уже два предмета которым мы верим безусловно (ключи УЦ и ключи OCSP респондера). Теперь посмотрим от чего зависит вероятность компрометации, ну вполне очевидно (среди прочего), что от степени использования ключа, поясняю, что если ключи издать и спрятать в сейф и никогда ими не пользоваться, то скомпрометировать их крайне сложно, а вот с ключами респондера дела обстоят совсем не так. Его ключи постоянно находятся в использовании внутри системы и степень их использования много больше чем ключей издателя УЦ. Именно по этому я и говорю, что степень недоверия больше двух.
Во-вторых, у нас в РФ более 330 УЦ, а протокол предполагает вложить в запрос сертификат издателя, т.е. на рабочем месте должны где то хранится все 330 сертификатов аккредитованных УЦ, причем по возможность в актуальном виде, что фактически не реально сделать. Теперь про сам сертификат издателя, этот сертификат издателя который должен прикладывается в запрос, не содержится в ЭЦП, этот сертификат где то надо раздобыть, чтобы потом вложить в запрос. Причём раздобыть где-то в правильном месте, а если вспомнить что у нас в РФ сертификаты энд-юзеров пекут из-под самоподписанных сертификатов аккредитованных УЦ, то на лицо явная дыра рисуется, поскольку встаёт почти не решаемая задача: каким образом, доверенно на рабочее место загрузить один из 330 сертификатов УЦ, ну не ногами же предварительно за ним идти, возможно в другой даже город
В-третьих, спецификация протокола не обязывает вкладывать в запрос сам проверяемый сертификат, в этом смысле становится не очень понятно, что получается в результате услуги, то ли мы говорим что сертификат действителен ни разу его не видя, может он весь кривой (примеров масса) и битый, то ли строго ограничиваемся тем, что сертификат с определённым номером отсутствует в реестре отозванных сертификатов, что как то маловато для последующего его использования.

С уважением,

1. Чтобы сделать хэшь нужно то от чего этот хэшь считать. И это что то надо откуда то взять (причём доверенным образом) и этих чего то может быть в РФ в общем случае более 340.
2. Слово "обычно" это эфимерно, повторяюсь, технология должна ложится на конкретику, через Регламент опираясь на техспецификации. Если в вашем кокнретном случает ЭЦП респондеоа выпускает СА проверяемого юзера - да свала богу, но это частный случай.
3. "Здравый смысл" мы не обсуждаем.
4. Я говорил про случай когда квиток подписывает сам СА (что допустимо по стандарту), видимо неправильно вашу ситуацию понял. Кстати если в сертификат подписателя квитка вставлен флан "но чек" то у вас явное прямое доверие и сертификат подписателя вообще не проверяется на стороне пользователя, поэтому пользователь даже не узнает что ему надо что то переоборачивать повторно на новых ключах. Если вы не ставите флаг "но чек" то смысл OCSP вообще сводится к нулю, поскольку потребует проверки сертификата подписателя квитка, я об этом в письме писал.