Инфраструктура Открытого Ключа (часть 7)

Синтаксис ответа

Опишем ASN.1-спецификацию ответов. Реальное форматирование сообщения может зависеть от используемого механизма транспорта (НТТР, SMTP, LDAP и т.д.).

ASN.1 спецификация для OCSP ответа

OCSP -ответ состоит, как минимум, из поля responseStatus, указывающего полученный статус запроса. Если значение responseStatus является одним из кодов ошибки, responseBytes не установлены.

OCSPResponse ::= SEQUENCE {
  responseStatus OCSPResponseStatus,
  responseBytes  [0] EXPLICIT ResponseBytes
OPTIONAL
}
OCSPResponseStatus ::= ENUMERATED {
  successful (0),
  -- ответ содержит подтверждение 
  -- действительности
  malformedRequest (1),
  --неправильно отформатированный запрос
  internalError (2),  
  --внутренняя ошибка
  tryLater (3),  
  --попытаться снова позднее
         --(4) не используется
  sigRequired  (5),  
  --запрос должен быть подписан
  unauthorized (6)   
  --неавторизованный запрос
}

Значение responseBytes состоит из OBJECT IDENTIFIER и синтаксиса ответа, определяющего, что OID представляется как OCTET STRING.

ResponseBytes ::= SEQUENCE {
  responseType OBJECT IDENTIFIER,
  response     OCTET STRING }

Для основного OCSP отвечающего responceType будет id-pkix-ocsp-basic.

id-pkix-ocsp OBJECT IDENTIFIER ::= {
    id-ad-ocsp }
id-pkix-ocsp-basic OBJECT IDENTIFIER ::= {
    id-pkix-ocsp 1 }

OCSP отвечающие должны иметь возможность создавать ответы с типом id-pkix-ocsp-basic. Соответственно OCSP клиенты должны иметь возможность получать и обрабатывать ответы с типом id-pkix-ocsp-basic.

Значение ответа должно иметь DER-представление BasicOCSPResponse.

BasicOCSPResponse ::= SEQUENCE {
    tbsResponseData  ResponseData,
    signatureAlgorithm AlgorithmIdentifier,
    signature BIT STRING,
    certs [0] EXPLICIT SEQUENCE OF 
	    Certificate OPTIONAL }

Значение подписи должно вычисляться для хэша DER-представления ResponseData.

ResponseData ::= SEQUENCE {
  version [0] EXPLICIT Version DEFAULT v1,
  responderID ResponderID,
  producedAt  GeneralizedTime,
  responses   SEQUENCE OF SingleResponse,
  responseExtensions [1] EXPLICIT Extensions
      OPTIONAL 
}
ResponderID ::= CHOICE {
  byName [1] Name,
  byKey  [2] KeyHash 
}
KeyHash ::= OCTET STRING 
  -- SHA-1 хэш открытого ключа Responder'а 
  -- (включая поля тега и длины)
SingleResponse ::= SEQUENCE {
  certID     CertID,
  certStatus CertStatus,
  thisUpdate GeneralizedTime,
  nextUpdate [0]  EXPLICIT GeneralizedTime
      OPTIONAL,
  singleExtensions [1] EXPLICIT Extensions
      OPTIONAL 
}
CertStatus ::= CHOICE {
  good    [0]IMPLICIT NULL,
  revoked [1]IMPLICIT RevokedInfo,
  unknown [2]IMPLICIT UnknownInfo 
}
RevokedInfo ::= SEQUENCE {
  revocationTime GeneralizedTime,
  revocationReason [0] EXPLICIT CRLReason
      OPTIONAL 
}
UnknownInfo ::= NULL 
-- данное поле может быть изменено

Замечания об OCSP-ответах

Время

Поля thisUpdate и nextUpdate определяют рекомендуемый интервал повторной проверки действительности. Данный интервал соответствует {thisUpdate, nextUpdate} интервалу в CRLs. Ответы, у которых значение nextUpdate меньше значения локального системного времени, должны считаться ненадежными.

Ответы, у которых время thisUpdate больше, чем локальное системное время, должны считаться ненадежными. Ответы, у которых значение nextUpdate не установлено, эквивалентны CRL с отсутствием времени для nextUpdate.

Время producedAt - это время, когда ответ был подписан.

Отвечающие уполномоченные органы

Ключ, которым подписана информация о статусе сертификата, не должен быть тем же самым ключом, которым подписан сертификат. Тем не менее, необходимо гарантировать, что участник, подписавший данную информацию, авторизован делать это. Следовательно, выпускающий сертификат должен либо сам подписать ответы 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 определяет, следует проверять сертификат на отмену или нет.