Отвечающие уполномоченные органы
Ключ, которым подписана информация о статусе сертификата, не должен быть тем же самым ключом, которым подписан сертификат. Тем не менее, необходимо гарантировать, что участник, подписавший данную информацию, авторизован делать это. Следовательно, выпускающий сертификат должен либо сам подписать ответы OCSP, либо явно делегировать соответствующие полномочия другому участнику. Делегирование подписывания OCSP должно быть выполнено путем включения id-kp-OCSPSigning в расширение extendedKeyUsage сертификата, подписывающего OCSP-ответ. Данный сертификат должен быть выпущен непосредственно СА.
id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
Проверка отмены сертификата Responder
Так как Responder предоставляет информацию о статусе для одного или более САs, клиенты OCSP должны знать, как проверить, не отменен ли сертификат отвечающего уполномоченного органа. САs могут выбрать один из трех способов решения проблемы:
- СА может определить, что клиент OCSP может доверять отвечающему в течение времени жизни сертификата отвечающего. СА делает это посредством включения расширения id-pkix-ocsp-nocheck. Это должно быть некритичное расширение. САs, выпускающие такие сертификаты, должны осознавать, что компрометация ключа Responder'а так же опасна, как и компрометация ключа СА, используемого для подписывания CRLs. СА могут выпускать данный тип сертификата с очень коротким сроком действия и часто обновлять его.
id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }
- СА может указать, как проверять отмену сертификата Responder. Это можно сделать с помощью точек распределения CRL, если проверка должна быть выполнена с использованием CRL.
- СА может не указывать какой-либо метод проверки отмены для сертификата Responder'а, в этом случае локальная политика безопасности клиента OCSP определяет, следует проверять сертификат на отмену или нет.
