учебники, программирование, основы, введение в,

 

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

On-line протокол статуса сертификата
Обзор протокола
Рассмотрим протокол, используемый для определения текущего статуса сертификата без использования CRLs.
В противоположность периодической проверке CRL иногда бывает необходимо получать текущую информацию о статусе сертификата. В качестве примера таких случаев можно привести пересылку ценных бумаг большого достоинства или масштабных фондовых продаж.
OCSP необходим приложениям для определения состояния отмены указанного сертификата в текущий момент времени. OCSP может использоваться для обеспечения требований, касающихся получения более своевременной информации об отмене, чем это возможно с использованием CRLs. Данный протокол также может применяться для получения дополнительной информации о статусе. Клиент OCSP выполняет запрос статуса и приостанавливает решение о признании сертификата действительным до тех пор, пока не получит ответ.
Данный протокол определяет данные, которые необходимы для осуществления операций обмена между приложением, проверяющим статус сертификата, и сервером, предоставляющим этот статус.
Запрос
Запрос OCSP содержит следующие данные:

  • Версия протокола.
  • Запрос сервиса.
  • Идентификация целевого сертификата.
  • Необязательные расширения, которые могут быть обработаны OCSP Responder.

При получении запроса OCSP Responder определяет, что:

  1. Сообщение является правильно форматированным.
  2. Responder сконфигурирован для предоставления запрошенного сервиса.
  3. Запрос содержит информацию, необходимую Responder.

Если хотя бы одно из этих условий не выполнено, OCSP Responder создает сообщение об ошибке; в противном случае он возвращает окончательный ответ.
Ответ
Ответы OCSP могут быть нескольких типов. Ответ OCSP состоит из типа ответа и байтов самого ответа. Существует один базовый тип ответа OCSP, который должен поддерживаться всеми клиентами и серверами OCSP. Далее мы будем рассматривать только данный базовый тип ответа.
Все сообщения окончательного ответа должны быть подписаны. Ключ, используемый для подписи ответов, должен принадлежать одному из следующих участников:

  • СА, который выпустил сертификат, указанный в запросе.
  • Responder, чьему открытому ключу доверяет запрашивающая сторона.
  • Responder, назначенный СА (Уполномоченный орган для OCSP-ответов), который имеет специально маркированный сертификат, выпущенный непосредственно СА. Сертификат указывает, что Responder может выпускать OCSP-ответы для данного СА.

Сообщение окончательного ответа состоит из:

  • Версии синтаксиса ответа.
  • Имени Responder.
  • Ответов для каждого из сертификатов в запросе.
  • Необязательных расширений.
  • OID алгоритма подписи.
  • Подписи, вычисленной для хэша ответа.

Ответ для каждого сертификата в запросе состоит из:

  • Идентификатора целевого сертификата.
  • Значения статуса сертификата.
  • Интервала действительности ответа.
  • Необязательных расширений.

Определены следующие варианты статуса сертификата в окончательных ответах:

  • Good
  • Revoked
  • Unknown

Состояние good определяет положительный ответ на запрошенный статус. Как минимум, данный положительный ответ указывает, что сертификат не отменен, но это не обязательно означает, что он был хотя бы выпущен или что время, в которое был сделан запрос, находится в интервале действительности сертификата. Расширения ответа могут использоваться для передачи дополнительной информации или предположений, сделанных Responder относительно статуса сертификата, таких как положительное утверждение о выпуске, действительности и т.д.
Состояние revoked указывает, что сертификат отменен (либо постоянно, либо временно).
Состояние unknown указывает, что отвечающий не знает о сертификате, который был запрошен.
Исключительные случаи
В случае ошибок OCSP Responder может вернуть соответствующее сообщение. Оно не подписывается. Ошибки могут быть следующих типов:

  • MalformedRequest
  • InternalError
  • TryLater
  • SigRequired
  • Unauthorized

Сервер создает malformedRequest ответ, если полученный запрос не соответствует OCSP-синтаксису.
Ответ internalError указывает, что OCSP Responder перешел в несогласованное внутреннее состояние. Запрос должен быть повторен с другим Responder.
Если OCSP Responder функционирует, но не может вернуть статус запрошенного сертификата, ответ tryLater может указывать на то, что сервис существует, но временно не может выдать ответ.
Ответ sigRequired возвращается в том случае, когда сервер для создания ответа требует, чтобы клиент подписал запрос.
Ответ unauthorized возвращается в том случае, когда клиент не авторизован выполнять данный запрос для данного сервера.
Семантики thisUpdate, nextUpdate и producedAt
Ответы могут содержать три значения времени - thisUpdate, nextUpdate и producedAt. Смысл этих полей следующий:

  • ThisUpdate: время, когда стало известно, что статус корректный.
  • NextUpdate: время, не позднее которого будет доступна более новая информация о статусе сертификата.
  • ProducedAt: время, когда OCSP Responder подписал данный ответ.

Если nextUpdate не установлено, это означает, что более новая информация об отмене доступна постоянно.
Ответ Pre-production
OCSP Responder может заранее создать подписанные ответы, указывающие статус сертификата в заданное время. Время, когда было известно, что статус корректный, должно быть отражено в поле thisUpdate ответа. Время, когда или до которого доступна более новая информация, отражается в поле nextUpdate, тогда как время, когда был создан ответ, указано в поле produceAt ответа.
Делегирование полномочий OCSP Responder'у
Ключ, которым подписывается информация о статусе сертификата, не должен быть тем же самым ключом, которым подписан сертификат. Выпускающий сертификаты явно делегирует OCSP Responder выпуск сертификатов. Сертификат OCSP Responder содержит уникальное значение для extendedKeyUsage. Данный сертификат должен быть выпущен непосредственно для Responder ответственным за это СА.
Компрометация ключа СА
Если OCSP Responder знает, что закрытый ключ конкретного СА компрометирован, он может возвращать статус отмены для всех сертификатов, выпущенных данным СА.

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

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

Для того чтобы передавать клиентам 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 проверить подпись запрашивающего.

Синтаксис ответа
Опишем 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 определяет, следует проверять сертификат на отмену или нет.

Обязательные и дополнительные криптографические алгоритмы

Клиенты, которые запрашивают сервис OCSP, должны иметь возможность обрабатывать ответы, подписанные с использованием ключей DSA. Клиенты также должны иметь возможность обрабатывать подписи RSA. Отвечающие OCSP должны поддерживать алгоритм хэширования SHA-1.

Расширения

Опишем некоторые стандартные расширения, основываясь на модели расширений, применяемой в сертификатах Х.509 v3. Поддержка всех расширений не обязательна как для клиентов, так и для Responder. Для каждого расширения укажем его синтаксис и обработку, выполняемую OCSP Responder. Также перечислим все расширения, которые включаются в соответствующий ответ.

Nonce

Nonce криптографически связывает запрос и ответ для предотвращения replay-атак. И в запросе, и в ответе nonce должен идентифицироваться идентификатором объекта id-pkix-ocsp-nonce, значением nonce является extnValue.

id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= 
    { id-pkix-ocsp 2 }
                
Ссылки на CRL

Может потребоваться для отвечающего OCSP указать CRL, в котором можно найти отмененный или приостановленный сертификат. Это может быть полезно, когда OCSP используется для взаимодействия между репозиториями, а также в качестве механизма аудита. CRL может указываться с помощью URL (по которому CRL доступен), номера (номер CRL) или времени (время, когда соответствующий CRL был создан). Эти расширения специфицируются как singleExtensions. Идентификатор для данного расширения есть id-pkix-ocsp-crl, значением должно быть CrlID.

id-pkix-ocsp-crl OBJECT IDENTIFIER ::= 
    { id-pkix-ocsp 3 }
CrlID ::= SEQUENCE {
  crlUrl  [0] EXPLICIT IA5String OPTIONAL,
  crlNum  [1] EXPLICIT INTEGER OPTIONAL,
  crlTime [2] EXPLICIT GeneralizedTime 
      OPTIONAL }
                

Для crlUrl IA5String указывает URL, по которому доступен CRL. Для crlNum INTEGER определяет значение расширения номера CRL соответствующего CRL. Для crlTime GeneralizedTime определяет время, когда был выпущен соответствующий CRL.

Типы принимаемых ответов

Клиент OCSP может захотеть указать типы ответов, которые он распознает. Для того чтобы сделать это, он должен использовать расширение с OID id-pkix-ocsp-response и значением AccepttableResponses. Данное расширение включается в одно из requestExtensions в ответах. OIDs, включенные в AccepttableResponses, являются OIDs различных типов ответов, которые данный клиент может принимать (например, id-pkix-ocsp-basic).

id-pkix-ocsp-response OBJECT IDENTIFIER ::= 
    { id-pkix-ocsp 4 }
AcceptableResponses ::= SEQUENCE OF 
    OBJECT IDENTIFIER
                

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

Архивное хранение

OCSP Responder может выбрать сохранение информации об отмене после истечения срока действительности сертификата. Дата, полученная путем вычитания сохраненного внутреннего значения из времени producedAt в ответе, определяется как дата архивации сертификата.
Приложения, которым требуется OCSP, должны использовать дату архивного хранения для получения доказательства того, что цифровая подпись была (или не была) надежна на момент, когда она была создана, даже если сертификат в настоящее время уже недействителен.
OCSP-серверы, которые предоставляют поддержку таких исторических ссылок, должны включать в ответы расширение данных archive cutoff. Если оно включено, то данное значение должно быть предоставлено как OCSP singleExtensions расширение, идентифицируемое id-pkix-ocsp-archive-cutoff и имеющее синтаксис GeneralizedTime.

id-pkix-ocsp-archive-cutoff OBJECT 
    IDENTIFIER ::= { id-pkix-ocsp 6 }
ArchiveCutoff ::= GeneralizedTime
                

В качестве иллюстрации можно привести такой пример: для сервера, функционирующего с семилетним сохранением внутренней политики, если статус некоторого сертификата был создан в момент времени t1, значение для ArchiveCutoff в ответе будет (t1 - 7 лет).

Расположение сервиса

OCSP сервер может функционировать в режиме, в котором он получает запросы и перенаправляет их другому OCSP-серверу, про который известно, что он имеет полномочия для указанного сертификата. Для данной цели определено расширение запроса serviceLocator.

id-pkix-ocsp-service-locator OBJECT 
    IDENTIFIER ::= { id-pkix-ocsp 7 }
ServiceLocator ::= SEQUENCE {
    issuer  Name,
    locator AuthorityInfoAccessSyntax 
       OPTIONAL 
}

Обсуждение проблем безопасности
Для того чтобы данный сервис был эффективным, использующие сертификаты системы должны соединяться с провайдером сервиса статуса сертификата. В случае если такое соединение не может быть получено, использующие сертификаты системы могут задействовать обработку CRL в качестве запасного варианта.
Уязвимость отказа сервиса при большом потоке запросов является очевидной. Вычисление криптографической подписи оказывает существенное влияние на время создания ответа, в результате чего ситуация обостряется. Неподписанные ответы об ошибках открывают протокол для других подобного рода атак, когда злоумышленник посылает ложные сообщения об ошибках.
Использование заранее вычисленных ответов допускает replay-атаки, в которых старый (хороший) ответ повторяется до даты своего истечения, но после того, как сертификат был отменен. Развертывание OCSP должно быть тщательно просчитано для получения преимуществ от заранее вычисленных ответов, чтобы не допустить вероятность replay-атак в противовес большой цене, связанной с вычислениями.
Запросы не содержат Responder, к которому они обращаются. Это позволяет атакующему повторить запрос к любому количеству OCSP Responder.
Использование кэширования НТТР в некоторых сценариях развертывания может привести к непредсказуемым результатам, если промежуточные серверы некорректно сконфигурированы или известно, что возможны ошибки при управлении кэшем.
OCSP поверх НТТР
Опишем форматирование, которое должно быть выполнено, если запрос и ответ используют НТТР.
Запрос
НТТР, лежащий в основе OCSP-запросов, может использовать либо GET, либо POST метод для submit-запросов. Для возможности НТТР-кэширования небольшие запросы (меньше 255 байтов) могут пересылаться с использованием GET. Если НТТР-кэширование не требуется или размер запроса превышает 255 байтов, запрос должен пересылаться с использованием POST. Если требуется защита, то OCSP-транзакции, применяющие НТТР, могут быть защищены с помощью TLS/SSL или другого протокола более низкого уровня.
OCSP-запрос, использующий метод GET, конструируется следующим образом:
GET {url}/{url-encoding of base-64 encoding
of the DER encoding of the OCSPRequest}

где {url} может быть получено из значения AuthorityInfoAccess или локальной конфигурации OCSP-клиента.
OCSP-запрос, использующий метод POST, конструируется следующим образом: заголовок Content-Type имеет значение application/ocsp-request, а тело сообщения является бинарным значением DER-представления OCSPRequest.
Ответ
Ответ OCSP, основанный на НТТР, создается в соответствии с заголовками НТТР, за которыми следует бинарное значение DER-представления OCSPResponse. Заголовок Content-Type имеет значение application/ocsp-response. Заголовок Content-Length должен специфицировать длину ответа. Остальные заголовки НТТР могут присутствовать и могут игнорироваться, если запрашивающим они не распознаются.

Понятие политики сертификата и регламента сертификационной практики

Введение

Рассмотрим общие принципы написания политик сертификата или понятие регламента сертификационной практики для СА. В частности, рассмотрим список тем, которые следует охватить при определении политики сертификата и регламента сертификационной практики.
Сертификат открытого ключа связывает значение открытого ключа с информацией, которая идентифицирует участника (такого как персона, организация, account или сайт), использующего соответствующий закрытый ключ (данный участник считается "субъектом" сертификата). Сертификат применяется "пользователем сертификата" или "доверяющей группой", которой необходимо задействовать открытый ключ из сертификата. Степень доверия пользователя сертификата осуществленному в сертификате связыванию зависит от нескольких факторов. Эти факторы определяются регламентом, которому следует СА при аутентификации субъекта и выпуске сертификата; политикой функционирования, использующей управление безопасностью СА; обязательствами по отношению к субъекту (например, в отношении защиты закрытого ключа); законодательными обязательствами СА.
Сертификат Х.509 v3 может содержать поля, декларирующие, что для данного сертификата применялись одна или более политик сертификата. Соответственно, политика сертификата есть "поименованное множество правил, которые определяют применимость сертификата для конкретного сообщества и/или класса приложений с общими требованиями безопасности". Политика сертификата может применяться пользователем сертификата при решении вопроса о том, может ли доверять сертификату и содержащейся в нем информации для конкретного приложения.
Детальное описание регламента, которому следует СА при выпуске и управлении сертификатами, содержится в регламенте сертификационной практики (Certification Practice Statement - CPS), публикуемом СА.
Рассмотрим взаимосвязь между политиками сертификата и CPS.
Определим элементы, которые могут потребоваться при создании политики сертификата или CPS.
Мы ограничимся обсуждением понятий политики сертификата (как определено в Х.509) и CPS. В частности, опишем типы информации, которые могут быть включены в определение политики сертификата или CPSs. Хотя предполагается использование формата сертификата Х.509 версии 3, не обязательно ограничиваться применением только данного формата сертификата. Более того, считается, что данная основа может быть адаптирована для других форматов сертификата.

, что некоторые политики в его собственном домене могут считаться эквивалентными некоторым другим политикам в домене субъекта СА.
Например, предположим, что между корпорациями существует соглашение на кросс-сертификацию открытых ключей. Далее предположим, что обе корпорации имеют ранее определенные политики безопасности для защиты финансовых транзакций, которые называются по-разному. Можно видеть, что простое создание кросс-сертификатов не обеспечивает необходимой интероперабельности, так как приложения компаний сконфигурированы таким образом, чтобы принимать свои собственные политики безопасности. Одно из возможных решений состоит в том, чтобы переконфигурировать все финансовые приложения на нужную политику и заново выпустить все сертификаты с другой политикой. Другое решение состоит в использовании поля PolicyMapping. Тогда данное поле должно быть включено в кросс-сертификат.

Расширение PolicyConstraints

Расширение PolicyConstraints поддерживает две дополнительные функции. Первая состоит в возможности для СА требовать, чтобы явные индикации политики сертификата были представлены во всех следующих сертификатах в сертификационном пути. Сертификаты в начале сертификационного пути могут рассматриваться пользователем сертификата как часть доверенного домена, например, САs являются доверенным для всех целей, следовательно, нет необходимости указывать конкретную политику сертификата в расширении CertificatePolicies. Такие сертификаты не содержат явного указания политики сертификата. Однако если СА в доверенном домене сертифицирует внешний домен, он может указать требование явной политики сертификата в следующих сертификатах в сертификационном пути.
Другая дополнительная функция поля PolicyConstraints для СА состоит в возможности запретить отображение политик для следующих САs в сертификационном пути. Это может послужить мерой предосторожности, чтобы запретить отображение политики при сертификации вне домена. Это может помочь контролировать риски при транзитивном доверии, например, домен А доверяет домену В, домен В доверяет домену С, но домен А не хочет быть вынужденным доверять домену С.
Квалификаторы политики
Поле расширения CertificatePolicies предназначено для дополнительной, не зависящей от политики информации, которая содержится в поле квалификатора. Стандарт Х.509 не указывает цель, для которой данное поле используется, и не задает синтаксис для данного поля. Типы квалификаторов политики могут регистрироваться любой организацией.
В настоящий момент определены следующие типы квалификаторов политики:

  1. Квалификатор CPS Pointer содержит указатель на регламент практики сертифицирования (CPS), опубликованный СА. Указатель является URI.
  2. Квалификатор User Notice содержит текстовую строку, которая показывается пользователю сертификата перед тем, как он задействует сертификат.

Квалификаторы политики могут применяться для поддержки определения общих или параметризируемых определений политики сертификата. Являясь базовым определением политики сертификата, типы квалификаторов политики могут определять способ предоставления на основе сертификата конкретных дополнительных деталей политики.
Регламент практики сертификации
Термин регламент практики сертификации (CPS) может быть определен следующим образом: детальное описание практики, при которой СА выпускает сертификаты. Данное определение можно дополнить следующими комментариями.
Регламент практик сертификации может быть оформлен как декларация СА о деталях системы и регламентах функционирования и поддержки выпуска сертификатов. Это также может быть часть контракта между СА и его подписчиками. CPS включает несколько документов, содержащих законы, частные контракты и/или декларации.
Доверяющий участник знает или, по крайней мере, предупрежден о содержании сертификата, используемого им для проверки цифровой подписи, включая документы, на которые имеется ссылка в сертификате. Следовательно, желательно вставлять ссылку на регламент сертификационной практики в сертификат.
Регламент сертификационной практики должен указывать на стандарты, в соответствии с которыми СА осуществляет свою деятельность, а также на потенциальную технологическую совместимость сертификатов, выпущенных СА.
Взаимосвязь между политикой сертификата и регламентом сертификационной практики
Понятия политики сертификата и CPS пришли из различных источников и были разработаны по разным причинам. Однако их взаимосвязь важна.
CPS является детальным описанием СА своей практики, которое должно быть принято во внимание подписчиками и пользователями сертификата. Хотя уровень детализации для разных CPSs может быть различным, обычно они бывают более развернутыми, чем определения политики сертификата. Действительно, CPS может быть всеобъемлющим, ясным документом, дающим точное описание предоставляемых сервисов, описывающим процедуры управления жизненным циклом сертификата и уровень детализации, который осуществляет CPS для конкретной реализации предоставляемого сервиса.
Хотя такая детализация может быть необходима и делает регламент заслуживающим доверия при отсутствии аккредитации или каких-то других метрик качества, детальный CPS не может служить подходящим базисом для интероперабельности САs, функционирующих в различных организациях. Политики сертификата скорее являются средством выражения общей основы интероперабельности. СА с единственным CPS могут поддерживать несколько политик сертификата (используемых для различных прикладных целей и/или в различных пользовательских сообществах). Также несколько различных САs с неидентичными CPSs могут поддерживать одну и ту же политику сертификата.
Определение политики сертификата описывает общие характеристики данной политики сертификата и указывает типы приложений, в которых она может использоваться. Различные департаменты или агентства, которые функционируют в качестве САs с разными CPSs, могут поддерживать данную политику сертификата. В то же время такие САs могут поддерживать и другие политики сертификата.
Основное различие между политикой сертификата и CPS заключается в следующем:

  1. Большинство организаций, которые выполняют роль публичных или межорганизационных САs, документируют свои регламенты. CPS является одним из организационных способов защиты себя и своей позиции при деловых отношениях с подписчиками и другими участниками.
  2. С другой стороны, не существует особых причин, чтобы политика сертификата применялась только в одной организации. Если конкретная политика сертификата широко распространена, имеются основания для автоматического принятия сертификата во многих системах, включая системы, не требующие участия человека, и системы, которые управляются людьми, но независимо решают вопрос действительности представленных сертификатов.

Множество постановлений
Множество постановлений определяет регламент практики сертификации.
Например, CPS может выражаться в виде сочетания следующих элементов:

  1. Список политик сертификата, поддерживаемых CPS.
  2. Каждой политики сертификата в (1) существует набор постановлений, которые уточняют политику сертификата деталями, обусловленными данной политикой; такие постановления предназначены для установления того, как конкретный CPS реализует требования конкретной политики сертификата.
  3. Множество постановлений, которые содержат утверждения, относящиеся к регламенту сертификации СА независимо от политики сертификата.

Утверждения, приведенные в (2) и (3), могут уточнить условия применяемости определения политики сертификата, но не должны конфликтовать с другими условиями определения политики сертификата.
Регламент сертификационной практики должен состоять примерно из следующих компонентов:

  • введение;
  • общие постановления;
  • идентификация и аутентификация;
  • требования функционирования;
  • управление физической, административной безопасностью и безопасностью персонала;
  • управление технической безопасностью;
  • профиль сертификата и CRL;
  • oписание администрирования.

Далее компоненты могут быть поделены на подкомпоненты.
Содержание множества постановлений
Сначала опишем содержание множества постановлений. Соответственно, темы, рассматриваемые здесь, являются кандидатами на включение в определение политики сертификата или CPS.
Тем не менее, нет необходимости включать каждый раздел в конкретную политику сертификата или CPS. Скорее конкретная политика сертификата или CPS может указать "нет условий" для компонента, подкомпонента или элемента, для которых она не выдвигает требований. В этом случае список тем может рассматриваться как контрольный список при создании политики сертификата или CPS. Рекомендуется, чтобы все компоненты и подкомпоненты были включены в политику сертификата или CPS, даже если там определено "нет условий". Это защищает от случайного пропуска темы и обеспечивает возможность сравнения различных политик или CPSs.
В определении политики сертификата возможен пропуск нескольких компонентов, подкомпонентов и/или элементов, и указание, что необходимая информация будет определена в квалификаторе политики. Такие определения политики сертификата можно рассматривать как параметризованные определения. Множество постановлений должно определять требуемые типы квалификаторов политики и специфицировать все используемые значения по умолчанию.
Введение
Данный компонент определяет множество постановлений и указывает типы участников и приложений, для которых предназначена спецификация.
Данный компонент имеет следующие подкомпоненты:

  • обзор - описывает все используемые имена или другие идентификаторы, включая ASN.1 идентификаторы объектов, для множества постановлений;
  • идентификация;
  • сообщество и применимость - описывает типы участников, для которых выпускаются сертификаты или которые определены как субъекты САs, типы участников, выполняющие функции RA, и типы участников, специфицированные как конечные участники или подписчики;
  • детали контактов.

Общие постановления
Данный компонент описывает все используемые предположения и состоит из следующих подкомпонентов:

  1. Обязательства - содержит для каждого типа участника все используемые постановления, относящиеся к обязательствам участника по отношению к другим участникам.
    • Обязательства СА и/или RA:
      • уведомление подписчика, который является субъектом выпущенного сертификата, о выпуске сертификата;
      • уведомление о выпуске сертификата других участников, которые не являются субъектами сертификата;
      • уведомление об отмене или приостановке сертификата подписчика, чей сертификат отменен или приостановлен;
      • уведомление об отмене или приостановке сертификата других участников, которые не являются субъектами отмененного или приостановленного сертификата.
    • Обязательства подписчика:
      • точность представлений в приложении сертификата;
      • защита закрытого ключа участника;
      • ограничения использования закрытого ключа и сертификата;
      • уведомление о компрометации закрытого ключа.
    • Обязательства доверяющей группы:
      • цели, для которых используется сертификат;
      • ответственность при проверке цифровой подписи;
      • ответственность при проверке отмены и приостановки;
      • признание применяемых законов и полномочий.
    • Обязательства репозитория:
      • своевременное опубликование сертификатов и информации об отмене.
  2. Ответственность.
  3. Финансовая отчетность.
  4. Интерпретация и претворение в жизнь.
  5. Оплата.
  6. Опубликование и хранение:
    • обязательства СА, касающиеся опубликования информации, относящейся к его практикам, сертификатам и текущему статусу сертификатов;
    • частота опубликования;
    • управление доступом к опубликованным информационным объектам, включая определения политики сертификата, CPS, сертификаты, статус сертификата и CRLs;
    • требования, относящиеся к использованию репозиториев.
  7. Согласованный аудит.
  8. Политика конфиденциальности:
    • типы информации, конфиденциальность которых должна обеспечиваться СА или RA;
    • типы информации, которые не считаются конфиденциальными;
    • кто имеет право сообщать о причинах отмены и приостановки сертификатов;
    • политика по сообщению информации об официальном вводе в действие законов;
    • условия, при которых СА или RA могут раскрыть информацию;
    • любые другие условия, при которых конфиденциальная информация может быть раскрыта.
  9. Права интеллектуальной собственности.

Идентификация и аутентификация
Данный компонент описывает процедуры, используемые для аутентификации претендента на сертификат перед тем как СА или RA выпустит его. Также описывается аутентификация участников, которые запрашивают новые ключи или отмену. Данный компонент адресован и практикам именования, включая распознавание собственных имен и разрешение конфликтов имен.
Данный компонент имеет следующие подкомпоненты:

  1. Начальная регистрация.
    • Типы имен, связанные с субъектом.
    • Являются имена значимыми или нет.
    • Правила интерпретации различных форм имени.
    • Должны ли имена быть уникальными.
    • Как разрешается конфликт имен.
    • Признание, аутентификация и роль торговых марок.
    • Как субъект должен доказывать обладание соответствующим закрытым ключом для зарегистрированного открытого ключа.
    • Требования аутентификации для идентификации организации субъекта (СА, RA или конечного участника).
    • Требования аутентификации для персональных действий от имени субъекта (СА, RA или конечного участника), включая:
    • Число требуемых элементов идентификации.
    • Как СА или RA проверяют действительность предоставленных элементов идентификации.
    • Должен ли конкретный человек персонально присутствовать для аутентификации СА или RA.
    • Как аутентифицируется конкретный человек в качестве представителя организации.
  2. Процедура создания нового ключа - описывает процедуры идентификации и аутентификации для процедуры создания нового ключа для каждого типа субъекта (СА, RA и конечного участника).
  3. Создание нового ключа после отмены - описывает процедуры идентификации и аутентификации при создании нового ключа для каждого типа субъекта (СА, RA и конечного участника) после того, как сертификат субъекта был отменен.
  4. Запрос отмены - описывает процедуры идентификации и аутентификации для запроса отмены для каждого типа субъекта (СА, RA и конечного пользователя).

 

Требования выполнения

Данный компонент используется для спецификации требований, накладываемых на действия СА, субъектов САs, RАs или конечных участников в зависимости от различных выполняемых действий.
Данный компонент состоит из следующих подкомпонентов:

  1. Применение сертификата - используется для установления требований, относящихся к регистрации субъекта и запроса на выпуск сертификата.
  2. Выпуск сертификата - используется для установления требований, относящихся к выпуску сертификата, и уведомления претендента об этом выпуске.
  3. Получение сертификата - используется для установления требований, относящихся к получению сертификата и к последующей его публикации.
  4. Приостановка и отмена сертификата.
    • Условия, при которых сертификат может быть отменен.
    • Кто может запросить отмену сертификата участника.
    • Процедуры, используемые для запроса отмены сертификата.
    • Допустимый период задержки запроса отмены для субъекта.
    • Условия, при которых сертификат может быть приостановлен.
    • Кто может запросить приостановку сертификата.
    • Процедуры запроса приостановки сертификата.
    • Как долго может продолжаться приостановка.
    • Если используется механизм CRL, то частота выпуска.
    • Требования доверяющим группам к проверке CRLs.
    • Возможность on-line проверки отмены/статуса.
    • Требования к доверяющим группам выполнять on-line проверки отмены/статуса.
    • Другие доступные формы объявления об отмене.
    • Требования для доверяющих групп проверять другие формы объявлений об отмене.
    • Любые варианты приведенных выше условий, когда приостановка или отмена являются результатом компрометации ключа (в противовес другим причинам приостановки или отмены).
  5. Процедуры аудита безопасности.
    • Типы записываемых событий.
    • Частота, с которой записи аудита сохраняются и обрабатываются.
    • Срок хранения записей аудита.
    • Процедура выполнения аудита:
      • Кто может просматривать записи аудита.
      • Защита от модификации записей аудита.
      • Защита от удаления записей аудита.
    • Процедуры back up записей аудита.
    • Является система анализа аудита для участника внутренней или внешней.
    • Оповещается ли субъект, который вызвал событие аудита, о действиях аудита.
    • Предполагаемые уязвимости.
  6. Архивация записей.
    • Типы зарегистрированных событий.
    • Период хранения архива.
    • Защита архива:
      • Кто может просматривать архив.
      • Защита от модификации архива.
      • Защита от удаления архива.
    • Процедуры back up архива.
    • Требования к отметкам времени записей.
    • Система хранения архива является внутренней или внешней.
    • Процедуры для получения и проверки архивной информации.
  7. Изменение ключа.
  8. Компрометация и восстановление.
    • Используемые процедуры восстановления, если вычислительные ресурсы, ПО или данные испорчены наверняка или предположительно. Эти процедуры описывают, как переустановить безопасное окружение, в котором отменены сертификаты или ключ участника, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.
    • Процедуры восстановления, которые используются, если открытый ключ участника отменен. Эти процедуры описывают, как переустановить безопасное окружение, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.
    • Процедуры восстановления, использующиеся в том случае, если открытый ключ скомпрометирован. Эти процедуры описывают, как переустановить безопасное окружение, как предоставить новый открытый ключ участника пользователям и как субъекты сертифицируются повторно.
    • Процедуры, СА, используемые для обеспечения безопасности при восстановлении безопасного окружения либо на исходном сайте, либо на удаленном сайте. Например, процедуры защиты от кражи секретных материалов.
  9. Завершение функционирования СА.

В каждом подкомпоненте может потребоваться отдельное рассмотрение для выпускающего СА, репозитория, субъекта САs, RAs и конечных участников.

Создание и инсталляция пары ключей

Создание и инсталляция пары ключей должна рассматриваться для САs, RAs и конечных участников. Для каждого из этих типов участников необходимо получить ответы на следующие вопросы:

  1. Кто создает пару открытый-закрытый ключи участника?
  2. Каким образом закрытый ключ безопасно доставляется участнику?
  3. Как открытый ключ участника безопасно доставляется выпускающему сертификат?
  4. Если участник является СА (выпускающий или субъект), то как открытый ключ участника безопасно доставляется пользователям?
  5. Каковы размеры ключей?
  6. Кто создает параметры открытого ключа?
  7. Качество параметров проверяется при создании ключа?
  8. Создание ключа выполняется аппаратно или программно?
  9. Для каких целей может использоваться ключ или для каких целей должно быть ограничено применение ключа?
Защита закрытого ключа

Необходимо рассмотреть требования для защиты закрытого ключа для выпускающего СА, репозиториев, субъектов САs, RAs и субъектов конечных участников. Для каждого из этих типов участников нужно ответить на следующие вопросы:

  1. Какие стандарты, если они есть, требуются для модулей, используемых для создания ключей? Если так, то каким должен быть уровень модуля?
  2. Находятся ли закрытые ключи под управлением нескольких человек?
  3. Является ли закрытый ключ распределенным? Если да, то кто является распределенными агентами, которые формируют распределенные ключи, и каково безопасное управление распределенных систем?
  4. Выполняется ли back up для закрытого ключа. Если да, то кто является back up агентом, который формирует back up ключ, и каково безопасное управление back up систем?
  5. Выполняется ли архивация закрытого ключа? Если да, то кто является агентом архивации, какая форма архивации ключа выполняется и каково безопасное управление системой архивации?
  6. Кто вводит закрытый ключ в криптографический модуль? В какой форме? Как закрытый ключ хранится в модуле?
  7. Кто может активизировать (использовать) закрытый ключ? Какие действия должны быть выполнены для активации закрытого ключа? После того как ключ активирован, он активирован на неопределенный срок, активирован для одного раза или активирован на определенный период времени?
  8. Кто может деактивировать закрытый ключ и как, автоматически или по истечении времени?
  9. Кто может уничтожить закрытый ключ?
Другие аспекты управления ключом

Следует рассмотреть и другие аспекты управления ключом для выпускающего СА, репозиториев, субъектов САs, RAs и субъектов конечных участников.
Для каждого из этих типов участников должны быть получены ответы на следующие вопросы:

  1. Архивируется ли открытый ключ? Если да, то кто является агентом архивации и какие средства управления безопасностью предусмотрены для системы архивации? Система архивации должна обеспечивать контроль целостности, отличный от цифровых подписей, т.к. период архивации может быть больше, чем период криптоанализа для ключа, и архив требует дополнительной защиты, которая не обеспечивается цифровыми подписями.
  2. Каковы периоды использования или время жизни архива для открытого и закрытого ключа, соответственно?
Данные активации

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

Управление безопасностью компьютера

Данный подкомпонент используется для описания управления безопасностью компьютера, такого как: использование базового понятия доверенных вычислений, дискреционное управление доступом, метки, мандатное управление доступом, переиспользование объектов, аудит, идентификация и аутентификация, доверенный путь, тестирование безопасности и тестирование проникновения. Может также рассматриваться гарантирование продукта.
Для компьютерных систем может потребоваться оценка безопасности компьютера. Оценка может быть основана, например, на различных используемых критериях (Common Criteria - СС). Данный подкомпонент может быть также адресован требованиям для анализа оценки продукта, тестирования, профилирования, сертификации продукта и/или аккредитации продукта в соответствии с выполняемой деятельностью.

Управление безопасностью жизненного цикла

Данный подкомпонент адресован контролю за разработкой системы и контролю управления безопасностью.
Контроль разработки системы включает безопасность окружения разработки, безопасность персонала разработки, безопасность управления конфигурацией при сопровождении продукта, методологию разработки ПО, модульность, многоуровневость, использование надежного проектирования и технологий реализации.
Контроль управления безопасностью включает выполнение средств и процедур, гарантирующих, что функциональные системы и сети остаются безопасно сконфигурированными. Эти средства и процедуры включают проверку целостности ПО и аппаратуры для гарантии их безопасного функционирования.
Данный компонент также может быть адресован оценке безопасности жизненного цикла, основанного на методологии разработки доверенного ПО (TSDM) уровня IV и V и независимого аудита безопасности жизненного цикла.

Управление криптографическим модулем

Данный подкомпонент адресован следующим аспектам криптографического модуля: идентификация границы криптографического модуля, ввод/вывод, роли и сервисы, машина конечных состояний, физическая безопасность, безопасность ПО, безопасность системы функционирования, согласованность алгоритма, электромагнитная совместимость и самотестируемость.

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика