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

Функциональные требования

Содержимое сертификата

Для того чтобы передавать клиентам OCSP точку доступа к информации, САs должны включать расширение AuthorityInfoAccess в сертификаты, которые могут быть проверены с использованием OCSP.

САs, которые поддерживают OCSP -сервис, либо размещающие его локально, либо предоставляющие его внешним клиентам с помощью Responder, должны обеспечивать включение значения URI accessLocation и значения OID id-ad-ocsp для accessMethod в последовательность AccessDescription выпускаемых сертификатов.

Значение поля accessLocation в сертификате субъекта определяет транспорт (например, НТТР), используемый для доступа к OCSP Responder, и может содержать другую относящуюся к транспорту информацию (например, URI).

Требования принятия подписанного ответа

Для того чтобы считать подписанный ответ действительным, клиенты OCSP должны убедиться, что:

1. Сертификат, указанный в полученном ответе, соответствует тому, который был определен в запросе.
2. Подпись в ответе действительна.
3. Идентификация подписавшего соответствует ожидаемому получателю запроса.
4. Подписавший в настоящий момент авторизован подписывать ответы.
5. Время, когда статус был указан как корректный ( thisUpdate ), считается неустаревшим.
6. Время, когда или до которого доступна более новая информация о статусе сертификата ( nextUpdate ), при этом оно должно быть больше текущего времени. Данная информация не является обязательной.

Детали протокола

Используется ASN.1-синтаксис. Для вычисления подписи подписываемые данные представлены с использованием ASN.1 DER.

Запросы

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

Синтаксис запроса

OCSPRequest ::= SEQUENCE {
  tbsRequest   TBSRequest,
  optionalSignature [0] EXPLICIT Signature 
      OPTIONAL 
}
TBSRequest ::= SEQUENCE {
  version [0] EXPLICIT Version DEFAULT v1,
  requestorName [1] EXPLICIT GeneralName 
      OPTIONAL,
  requestList SEQUENCE OF Request,
  requestExtensions [2] EXPLICIT Extensions
      OPTIONAL 
}
Signature ::= SEQUENCE {
  signatureAlgorithm AlgorithmIdentifier,
  signature BIT STRING,
  certs [0] EXPLICIT SEQUENCE OF Certificate
      OPTIONAL
}
Version ::= INTEGER  {  v1(0) }
Request ::= SEQUENCE {
  reqCert   CertID,
  singleRequestExtensions [0] EXPLICIT
      Extensions OPTIONAL 
}
CertID ::= SEQUENCE {
  hashAlgorithm   AlgorithmIdentifier,
  issuerNameHash   OCTET STRING, 
  -- хэш DN выпускающего
  issuerKeyHash   OCTET STRING, 
  -- хэш открытого ключа 
  -- выпускающего
  serialNumber   CertificateSerialNumber
}

IssuerNameHash является хэшем уникального имени выпускающего. Хэш должен вычисляться поверх DER-представления поля имени выпускающего в проверяемом сертификате. IssuerKeyHash является хэшем открытого ключа выпускающего. Хэш должен быть вычислен поверх значения (включая тег и длину) поля открытого ключа субъекта в сертификате выпускающего. Хэш-алгоритм, используемый для вычисления обоих хэшей, указывается в hashAlgorithm. SerialNumber является последовательным номером сертификата, для которого запрашивается статус.

Замечания о синтаксисе запроса

Первая причина использования хэша открытого ключа СА в дополнение к хэшу имени СА, идентифицирующему выпускающего, состоит в том, что, возможно, два САs используют одно и то же имя ( Name ) (отсутствие уникальности имени рекомендуется, но не гарантируется). Тем не менее два САs никогда не будут иметь один и тот же открытый ключ, если они явно не решили разделять один и тот же закрытый ключ или ключ одного из них был компрометирован.

Поддержка любого указанного здесь расширения не является обязательной. Флаг критичности не должен быть установлен ни для кого из них. Далее мы рассмотрим несколько полезных расширений. Могут быть также определены дополнительные расширения. Нераспознанные расширения должны игнорироваться (если только они не критичны).

Запрашивающий может подписать OCSP -запрос. В этом случае подпись вычисляется поверх tbsRequest -структуры. Если запрос подписан, то запрашивающий должен указать свое имя в поле requestorName. Также для подписанных запросов запрашивающий может включить сертификаты, которые помогут OCSP Responder проверить подпись запрашивающего.