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

Разбить на страницы

Показывать лекцию целиком

Профиль CRL и расширений CRL

CRLs используются во многих приложениях и окружениях. Рассмотрим информацию, которая может содержаться в CRL, определим расположение в CRL часто используемых атрибутов и представление этих атрибутов.

Выпускающий CRL создает CRLs. В общем случае выпускающий CRL является СА. СА публикует CRLs для предоставления информации о статусе выпущенных им сертификатов. Однако СА может делегировать это право другому доверенному уполномоченному органу. Всякий раз, когда выпускающий CRL не является СА, который выпускает сертификаты, CRL считается непрямым CRL.

Каждый CRL имеет определенную область. Областью CRL является множество сертификатов, которые могут появиться в данном CRL . Например, область может быть "все сертификаты, выпущенные СА Х", "все сертификаты СА, выпущенные СА Х", "все сертификаты, выпущенные СА Х, которые отменены по причинам компрометации ключа и компрометации ключа СА" или может быть множество сертификатов, основанное на произвольной локальной информации, такой как "все сертификаты, выпущенные для сотрудников факультета ВМиК МГУ".

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

САs могут не выпускать CRLs, если предусмотрены другие механизмы отмены или предоставления статуса сертификата. CRLs должны иметь версию 2, включать дату в поле nextUpdate следующего выпуска CRL, расширение номера CRL и расширение идентификатора ключа уполномоченного органа.

Поля CRL

Рассмотрим синтаксис CRL v2. Для вычисления подписи подписываемые данные представлены в ASN.1 DER-представлении. ASN.1 DER-представление определяет систему представления тега, длины и значения для каждого элемента.

CertificateList ::= SEQUENCE  {
  tbsCertList        TBSCertList,
  signatureAlgorithm AlgorithmIdentifier,
  signatureValue     BIT STRING  
}
TBSCertList ::= SEQUENCE  {
  version    Version OPTIONAL,
  -- если присутствует, должно быть v2
  signature  AlgorithmIdentifier,
  issuer     Name,
  thisUpdate Time,
  nextUpdate Time OPTIONAL,
  revokedCertificates SEQUENCE OF SEQUENCE {
    userCertificate CertificateSerialNumber,
    revocationDate  Time,
    crlEntryExtensions Extensions OPTIONAL
    -- если присутствует, должно быть v2
 }   OPTIONAL,
 crlExtensions [0] EXPLICIT Extensions OPTIONAL
  -- если присутствует, должно быть v2
}

Поля CertificateList

CertificateList есть последовательность трех обязательных полей.

tbsCertList

Первым полем в последовательности является tbsCertList. Данное поле само представляет собой последовательность, состоящую из имени выпускающего, даты выпуска, даты выпуска следующего списка, необязательного списка отмененных сертификатов и необязательных расширений CRL. Когда отмененных сертификатов нет, список отмененных сертификатов отсутствует. Когда один или более сертификатов отменены, каждая запись в списке отмененных сертификатов определяет последовательность из серийного номера сертификата пользователя, даты отмены и необязательных расширений записи CRL.

signatureAlgorithm

Поле signatureAlgorithm содержит идентификатор алгоритма, использованного выпускающим CRL для подписи CertificateList. Данное поле должно содержать те же самые идентификаторы алгоритмов, что и поле signature в последовательности tbsCertList.

signatureValue

Поле signatureValue содержит цифровую подпись, вычисленную над ASN.1 DER-представлением tbsCertList. ASN.1 DER-представление tbsCertList используется в виде входа в функцию подписывания. Данное значение подписи представлено в виде строки битов и содержится в поле CRL signatureValue. Детали данного процесса для разных алгоритмов различны.

САs, которые выпускают и CRL, могут использовать один закрытый ключ для подписывания сертификатов и CRL или могут иметь разные закрытые ключи для подписывания сертификатов и CRL. Когда используются разные закрытые ключи, один имеет установленный бит keyCertSign в расширении использования ключа, другой имеет установленный бит cRLSign в расширении использования ключа. Когда используются разные закрытые ключи, соответствующие им сертификаты содержат разные идентификаторы ключа. Считается, что использование разных сертификатов СА для проверки действительности подписей сертификатов и подписей CRL должно повышать уровень безопасности; однако это усложняет приложения и может ограничивать интероперабельность. Многие приложения создают сертификационный путь и затем проверяют его действительность. Проверка CRL оборачивается требованием, чтобы отдельный сертификационный путь был создан и проверен для сертификата, которым подписан CRL. Приложения, которые выполняют проверку CRL, должны поддерживать проверку действительности сертификационного пути, когда сертификаты и CRLs подписаны закрытыми ключами различных СА.

Список сертификатов "To Be Signed"

Подписанный список сертификатов или TBSCertList представляет собой последовательность обязательных и необязательных полей. Обязательные поля идентифицируют выпускающего CRL, используемый для подписывания CRL алгоритм, дату и время, когда был выпущен CRL, а также дату и время, когда будет выпущен следующий CRL.

Необязательные поля включают список отмененных сертификатов и расширения CRL. Список отмененных сертификатов является необязательным, если СА не отменил никакого не истекшего сертификата после выпуска предыдущего CRL.

Версия

Данное необязательное поле описывает версию представления CRL. Когда используются расширения, данное поле должно присутствовать и указывать версию 2.

Подпись

Данное поле содержит идентификатор алгоритма, использованного для подписывания CRL. Оно должно содержать тот же самый идентификатор алгоритма, что и поле signatureAlgorithm в последовательности CertificateList.

Имя выпускающего

Имя выпускающего определяет участника, который подписал и выпустил CRL. Идентификация выпускающего выполняется в поле issuerName. В расширении issuerAltName могут присутствовать альтернативные формы имени. Поле issuerName должно содержать уникальное имя (DN) X.500. Данное поле определено как Х.501 типа Name и должно следовать правилам представления для поля issuerName в сертификате.

Дата данного изменения

Данное поле указывает дату выпуска данного CRL. ThisUpdate может быть представлено как UTCTime или GeneralizedTime.

Следующее изменение

Данное поле определяет дату, когда будет выпущен следующий CRL. Следующий CRL может быть выпущен до указанной даты, но не может быть выпущен позднее указанной даты. Выпускающие CRL должны выпускать CRLs со временем nextUpdate равным или более поздним, чем все предыдущие CRLs. nextUpdate может быть представлено в виде UTCTime или GeneralizedTime.

Требуется включать nextUpdate во все CRLs, выпускаемые конкретным выпускающими. Заметим, что ASN.1 синтаксис TBSCertList описывает данное поле как OPTIONAL, которое состоит из ASN.1-структур, определенных в стандарте X.509.

Отмененные сертификаты

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

Расширения

Данное поле может появиться, если версия есть 2. Если данное поле присутствует, оно является последовательностью одного или более расширений CRL.

Расширения CRL

Расширения, определенные ANSI X9, ISO/IEC и ITU-T для X.509 v2 CRLs предоставляют методы для связывания дополнительных атрибутов с CRLs. Формат X.509 v2 CRL также позволяет определять частные расширения. Каждое расширение в CRL может быть обозначено как критичное или некритичное. Проверка действительности CRL не должна выполняться, если встречается критичное расширение, которое неизвестно как обрабатывать. Однако нераспознанные некритичные расширения могут игнорироваться. Рассмотрим наиболее часто используемые расширения. Следует заметить, что не рекомендуется устанавливать критичные расширения в CRLs, которые могут использоваться общими приложениями, так как невозможность обработать критичное расширение может привести к тому, что приложение не сможет получить полный список отмененных сертификатов.

Идентификатор ключа уполномоченного органа

Расширение идентификатора ключа уполномоченного органа предоставляет способы идентификации открытого ключа, соответствующего закрытому ключу, который использовался для подписывания CRL. Идентификация может быть основана либо на идентификаторе ключа (идентификаторе ключа субъекта в сертификате CRL подписывающего), либо на имени выпускающего и серийном номере. Данное расширение особенно полезно, когда выпускающий имеет более одного ключа подписывания или была выполнена замена сертификата для подписывания CRL.

Альтернативное имя выпускающего

Расширение альтернативных имен выпускающего позволяет задействовать дополнительные идентификаторы, которые связаны с выпускающим CRL. Альтернативными именами могут быть e-mail адрес, имя DNS, IP-адрес и URI. Могут быть включены несколько вариантов имен и несколько форм имени. Всякий раз, когда такие идентификаторы используются, должно применяться расширение для альтернативного имени; однако имя DNS может быть представлено в поле выпускающего посредством атрибута domainComponent.

Расширение issuerAltName не должно быть помечено как критичное.

Номер CRL

Номер CRL является некритичным расширением CRL, которое представляет собой монотонно возрастающую последовательность номеров для данной области CRL и данного выпускающего CRL. Данное расширение позволяет пользователям без труда определить, когда один CRL заменяет другой. Номера CRL также обеспечивают идентификацию полных CRLs и дельта CRLs.

Если выпускающий CRL создает дельта CRLs в дополнение к полным CRLs для данной области, полные CRLs и дельта CRLs должны иметь одну последовательность чисел. Если дельта CRL и полный CRL, которые охватывают одну и ту же область, выпущены в одно и то же время, они должны иметь одни и те же номера CRL и предоставлять одну и ту же информацию об отмене. Это означает, что комбинация дельта CRL и выпущенного полного CRL должна предоставлять ту же самую информацию об отмене, что и одновременно выпущенный полный CRL.

Если выпускающий CRL создает два CRLs (два полных CRLs, два дельта CRLs или полный CRL и дельта CRL ) для некоторой области в различное время, два CRLs не должны иметь один и тот же номер CRL.

Индикатор дельта CRL

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

Расширение индикатора дельта CRL содержит единственное значение типа BaseCRLNumber. Номер CRL определяет CRL, полный для данной области, который использовался в качестве исходного при создании данного дельта CRL. Дельта CRL содержит все изменения в статусе сертификата для той же самой области. Комбинация дельта CRL плюс упоминаемый базовый CRL эквивалентна полному CRL для рассматриваемой области в момент опубликования дельта CRL.

Когда конформный выпускающий CRL создает дельта CRL, дельта CRL должен содержать критичное расширение индикатора дельта CRL.

Когда дельта CRL выпущен, он должен охватывать то же самое множество причин и то же множество сертификатов, которое охватывает базовый CRL, на который он ссылается. Выпускающий CRL должен использовать тот же самый закрытый ключ для подписывания дельта CRL и соответствующего полного CRL.

Полный CRL и дельта CRL могут быть скомбинированы, если выполнены следующие четыре условия:

Полный CRL и дельта CRL имеют одного и того же выпускающего.

Полный CRL и дельта CRL имеют одну и ту же область. Два CRLs имеют одну и ту же область, если выполнено одно из следующих условий:

Расширение issuingDistributionPoint опущено и в полном CRL, и в дельта CRL.

Расширение issuingDistributionPoint присутствует и в полном CRL, и в дельта CRL, и значения каждого из этих полей одинаковы в обоих CRLs.

Номер CRL полного CRL больше или равен BaseCRLNumber, указанному в дельта CRL. Это означает, что полный CRL включает (как минимум) всю информацию об отмене, которая содержится в упоминаемом базовом CRL.

Номер CRL полного CRL меньше, чем номер CRL дельта CRL. Это означает, что в последовательной нумерации дельта CRL следует за полным CRL.

Считается, что статус сертификата изменяется, если он отменяется, приостанавливается, восстанавливается после приостановки или изменяется причина его отмены.

Если сертификат был приостановлен в любом CRL, выпущенном после базового, но перед данным дельта CRL, а затем был восстановлен после приостановки, он должен быть указан в дельта CRL с причиной отмены removeFromCRL.

Выпускающий CRL может дополнительно указать сертификат в дельта CRL с кодом причины removeFromCRL, если время notAfter, указанное в сертификате, предшествует времени thisUpdate, указанному в дельта CRL, и сертификат был перечислен в упоминаемом базовом CRL или в любом CRL, выпущенном после базового, но перед данным дельта CRL.

Если упоминание об отмене сертификата впервые появилось в дельта CRL, то, возможно, что период действительности сертификата истечет до выпуска следующего дельта CRL. В этом случае упоминание об отмене должно быть включено во все последующие дельта CRL до тех пор, пока упоминание об отмене не будет включено, по крайней мере, в один выпущенный полный CRL.

Приложение, которое поддерживает дельта CRLs, должно иметь возможность создавать текущий полный CRL посредством комбинации ранее выпущенного полного CRL и самого последнего дельта CRL. Приложение, которое поддерживает дельта CRLs, также может иметь возможность создавать текущий полный CRL комбинацией предыдущего локально созданного полного CRL и текущего CRL. Считается, что дельта CRL является текущим, если текущее время находится между временем, содержащимся в полях thisUpdate и nextUpdate.

Точка распространения CRL

Точка распространения CRL является критичным расширением CRL, которое определяет точку распространения CRL и область для конкретного CRL ; она также указывает, охватывает ли CRL отмену только сертификатов конечных участников, только сертификатов СА или ограниченное множество кодов причин. Хотя расширение и является критичным, не требуется, чтобы все приложения поддерживали данное расширение.

CRL подписан с использованием закрытого ключа выпускающего CRL. Точки распространения CRL не имеют собственной пары ключей.

Коды причин, связанные с точкой распространения, должны быть указаны в onlySomeReasons. Если onlySomeReasons не присутствует, точка распространения должна содержать отмены для всех кодов причин. САs могут использовать точки распространения CRL для разбиения CRL в соответствии с причиной отмены. В этом случае отмены с кодом причины keyCompromise (1), cACompromise (2) и aACompromise (8) появляются в одной точке распространения, а отмены с другими кодами причины появляются в другой точке распространения.

Если поле distributionPoint присутствует и содержит URI, должна предполагаться следующая семантика: объект является указателем на самый последний CRL, выпущенный данным выпускающим CRL. Для этой цели определены схемы URI FTP, HTTP, MAILTO и LDAP. URI должен быть абсолютным, а не относительным путем, и должен указывать хост.

Если поле distributionPoint отсутствует, CRL должен содержать записи для всех отмененных и неистекших сертификатов, выпущенных конкретным выпускающим CRL в данной области CRL.

Выпускающий CRL должен установить булевское indirectCRL, если область CRL включает сертификаты, выпущенные другими уполномоченными органами, отличными от данного. Уполномоченный орган ответственен за каждую запись, определяемую расширением записи CRL.

id-ce-issuingDistributionPoint
  OBJECT IDENTIFIER ::= { id-ce 28 }

issuingDistributionPoint ::= SEQUENCE {
  distributionPoint [0]
    DistributionPointName OPTIONAL,
  onlyContainsUserCerts [1]
    BOOLEAN DEFAULT FALSE,
  onlyContainsCACerts [2] BOOLEAN
    DEFAULT FALSE,
  onlySomeReasons [3] ReasonFlags OPTIONAL,
  indirectCRL     [4] BOOLEAN DEFAULT FALSE,
  onlyContainsAttributeCerts [5] BOOLEAN
    DEFAULT FALSE 
}

Наиболее свежий CRL (точка распространения дельта CRL)

Расширение наиболее свежий CRL определяет, как получена информация дельта CRL для данного полного CRL. Расширение должно быть некритичным. Данное расширение не должно появляться в дельта CRLs.

Для данного расширения и для расширения сертификата cRLDistributionPoints используется один и тот же описанный выше синтаксис. Поля причины и CRLIssuer в данном расширении CRL должны быть опущены.

Каждое имя точки распространения указывает местоположение дельта CRL для данного полного CRL. Содержимое данного расширения CRL используется только для размещения дельта CRL ; содержимое не используется для проверки действительности CRL или указываемых дельта CRLs. Соглашения по представлению, определенные для точек распространения, применимы и к данному расширению.

Расширения записи CRL

Расширения записи CRL, определенные ISO/IEC, ITU-T и ANSI Х9 для Х.509 v2 CRLs, предоставляют методы для связывания дополнительных атрибутов с записями CRL. Формат Х.509 v2 CRL также позволяет определять частные расширения записей CRL для хранения информации, используемой конкретным сообществом. Каждое расширение в записи CRL может быть определено как критичное и некритичное. CRL не должен проходить проверку на действительность, если встретилось критичное расширение записи, которое неизвестно как обработать. Однако нераспознанное некритичное расширение записи CRL можно проигнорировать. Рассмотрим рекомендуемые расширения, используемые в записях CRL Internet, а также стандартное размещение информации.

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

Код причины

Расширение reasonCode является некритичным расширением записи CRL, которое указывает причину отмены сертификата. Выпускающие CRL должны включать важные коды причин в записи CRL ; однако расширение записи CRL кода причины должно быть опущено вместо использования неспецифицированного значения (0) reasonCode.

id-ce-cRLReason OBJECT IDENTIFIER ::=
  { id-ce 21 }
  -- reasonCode ::= { CRLReason }
CRLReason ::= ENUMERATED {
    unspecified            (0),
    keyCompromise          (1),
    cACompromise           (2),
    affiliationChanged     (3),
    superseded             (4),
    cessationOfOperation   (5),
    certificateHold        (6),
    removeFromCRL          (8),
    privilegeWithdrawn     (9),
    aACompromise           (10) 
}

Код инструкции приостановки

Код инструкции приостановки является некритичным расширением записи CRL, которое предоставляет зарегистрированный идентификатор инструкции, указывающий действие, которое будет выполнено после того, как встретится сертификат, который следует приостановить.

Дата недействительности

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

Проверка действительности сертификационного пути

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

Рассмотрим алгоритм проверки действительности сертификационного пути. Строгая реализация данного алгоритма не требуется, но конечный результат должен быть аналогичен данной процедуре.

Действительные пути начинаются с сертификатов, выпущенных доверенным корневым органом. Алгоритм должен иметь открытый ключ корневого СА, имя корневого СА и все ограничения, накладываемые на множества путей, которые могут считаться действительными.

Выбор доверенного корневого органа является вопросом политики: это может быть самый верхний СА в иерархии, либо CA, который выпустил свой(и) сертификат(ы) для проверки, или какой-то другой СА. Процедура проверки действительности пути является той же самой, независимо от выбора корневого органа.

Рассмотрим шаги, которые необходимо выполнить, чтобы определить, имеет ли сертификат статус отмененного или приостановленного, когда CRLs является механизмом отмены, используемым выпускающим сертификат.

Проверка действительности базового пути

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

Например, некоторым клиентам не требуется поддержка расширения отображения политики безопасности. Клиенты, которые не поддерживают данное расширение, могут пропустить шаги проверки действительности пути, где обрабатываются отображения политики. Заметим, что клиенты должны отвергать сертификат, если он содержит неподдерживаемое критичное расширение.

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

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

Исходная цель проверки действительности пути состоит в проверке связи между уникальным именем субъекта или альтернативным именем субъекта и открытым ключом субъекта, представленными в сертификате субъекта, на основе открытого ключа доверенного начального сертификата. Это требует получения последовательности сертификатов, которые поддерживают данную связь. Процедура, выполняемая для получения данной последовательности сертификатов, не рассматривается.

Для достижения данной цели процесс проверки действительности пути проверяет, помимо прочего, чтобы ожидаемые сертификационные пути (последовательность из n сертификатов) удовлетворяли следующим условиям:

Для всех х в {1, ..., n-1} субъект сертификата х является выпускающим сертификата х+1.

Сертификат 1 выпущен доверенным начальным сертификатом.

Сертификат n является действительным сертификатом.

Для всех х в {1, ..., n-1} сертификат был действительным в момент запроса.

Когда начальный доверенный сертификат представлен в форме самоподписанного сертификата, данный самоподписанный сертификат не включается как часть ожидаемого сертификационного пути. Информация о доверенных начальных сертификатах предоставляется в качестве входных параметров в алгоритм проверки действительности сертификационного пути.

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

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

Данный раздел описывает алгоритм, состоящий из четырех основных шагов:

Инициализация.

Базовая обработка сертификата.

Подготовка для обработки следующего сертификата.

Завершение (wrap-up).

Шаги (1) и (4) выполняются только один раз. Шаг (2) выполняется для всех сертификатов в пути. Шаг (3) выполняется для всех сертификатов в пути, за исключением последнего. На рис.17.1 представлена высокоуровневая диаграмма потока для данного алгоритма.

Входы

Данный алгоритм предполагает наличие следующих семи входов:

Ожидаемый сертификационный путь длиной n.

Текущие дата и время.

User-initial-policy-set: множество идентификаторов политик сертификации, принимаемых пользователем сертификата. User-initial-policy-set имеет специальное значение anyРolicy, если пользователю политика сертификации не важна.

Информация о доверенном начальном сертификате в сертификационном пути. Информация о доверенном начальном сертификате включает:

Имя выпускающего.

Алгоритм открытого ключа.

Открытый ключ.

Необязательно – параметры данного открытого ключа.

Информация доверенного начального сертификата может быть предоставлена процедуре обработки пути в форме самоподписанного сертификата. Информации начального сертификата можно доверять, так как она предоставлена процедуре обработки пути некоторой внешней надежной процедурой. Если алгоритм доверенного открытого ключа требует параметров, то эти параметры предоставляются вместе с доверенным открытым ключом.

Initial-policy-mapping-inhibit, который определяет, является ли отображение политики допустимым в сертификационном пути.

Initial-explicit - policy, который определяет, что путь должен быть действительным для, по крайней мере, одной сертификационной политики в user-initial-policy-set.

Initial-any-policy-inhibit, который определяет, должен ли OID anyPolicy обрабатываться, если он включен в сертификат.

(рис 17.1) Диаграмма потока при обработке сертификационного пути

Инициализация

Данная фаза инициализации устанавливает одиннадцать переменных состояния на основании семи входов:

Valid_policy_tree: дерево политик сертификации с соответствующими необязательными квалификаторами; каждый из листьев дерева является действительной политикой на данной стадии в проверке действительности сертификационного пути. Если действительная политика существует на данной стадии в проверке действительности сертификационного пути, глубина дерева равна числу сертификатов в цепочке, которые обработаны. Если действительная политика не существует на данной стадии в проверке действительности сертификационного пути, дерево устанавливается в NULL. После того как дерево установлено в NULL, обработка политики прекращается.

Каждый узел в valid_policy_tree включает четыре объекта данных: действительную политику, множество соответствующих квалификаторов политики, множество из одного или более ожидаемых значений политики и индикатор критичности. Если узел имеет глубину х, компоненты узла имеют следующую семантику:

Valid_policy есть единственный OID политики, представляющий действительную политику для пути длиной х.

Qualifier_set является множеством квалификаторов политики, связанных с действительной политикой в сертификате х.

Criticality_indicator определяет, было ли расширение политики в сертификате х маркировано как критичное.

Expected_policy_set содержит один или более OIDs политик, которые должны соответствовать данной политике в сертификате х+1.

Начальным значением valid_policy_tree является единственный узел с valid_policy anyPolicy, пустым qualifier_set, expected_policy_set с единственным значением anyPolicy и criticality_indicator FALSE. Считается, что данный узел имеет глубину ноль.

Рис. 17.2 графически представляет начальное состояние valid_policy_tree. Дополнительные рисунки будут использовать данный формат для описания изменений в valid_policy_tree при обработке пути.

Permitted_subtrees: множество корневых имен для каждого типа имени (например, Х.500 уникальные имена, e-mail адреса или IP-адреса), определяющее множество поддеревьев, в которых все имена субъектов в последующих сертификатах в сертификационном пути должны считаться действительными. Данная переменная включает множество для каждого типа имени: начальное значение для множества Distinguished Names является множеством всех уникальных имен; начальное значение множества имен RFC822 является множеством всех RFC822 имен и т.д.

Excluded_subtrees: множество корневых имен для каждого типа имени (например, Х.500 уникальное имя, email адреса или IP-адреса), определяющее множество поддеревьев, в которых имя субъекта в последующих сертификатах в сертификационном пути не может считаться действительным. Данная переменная включает множество для каждого типа имени, и начальное значение для каждого множества является пустым.

(рис 17.2) Начальное значение переменной состояния valid_policy_tree

Inhibit_any-policy: целое, которое определяет, можно ли считать идентификатор политики anyPolicy принимаемым. Целое определяет число игнорируемых несамовыпущенных сертификатов, обрабатываемых до OID anyPolicy, если он присутствует в сертификате. Однажды установленная, данная переменная может уменьшаться, но не может возрастать. Это означает, что если сертификат в пути не допускает обработку anyPolicy, последующие сертификаты не могут разрешить принимать данную политику. Если initial-any-policy-inhibit установлено, то начальное значение есть 0, в противном случае начальное значение есть n+1.

Policy_mapping: целое, которое определяет, допустимо ли отображение политики. Целое определяет число несамовыпущенных сертификатов, которые могут быть обработаны до запрещения отображения политики. Однажды установленная, данная переменная может уменьшаться, но не может возрастать. Таким образом, если сертификат в пути указывает, что отображение политики недопустимо, это не может быть перекрыто следующим сертификатом. Если initial-policy-mapping-inhibit установлено, то начальное значение есть 0, в противном случае начальное значение есть n+1.

Working_public_key_algorithm: алгоритм цифровой подписи, используемый для проверки подписи сертификата. Working_public_key_algorithm инициализируется из алгоритма доверенного открытого ключа, указанного в информации доверенного начального сертификата.

Working_public_key: открытый ключ, используемый для проверки подписи сертификата. Working_public_key инициализируется из доверенного открытого ключа, указанного в информации доверенного начального сертификата.

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

Working_issuer_name: уникальное имя выпускающего, ожидаемое в следующем сертификате в цепочке. Working_issuer_name инициализируется доверенным выпускающим, указанным в информации доверенного начального сертификата.

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

После завершения шагов инициализации выполняются основные шаги обработки, описываемые ниже.

Основная обработка сертификата

Действия по основной обработке сертификата, выполняемые для сертификата i (для всех i в [1..n] ), перечислены ниже.

Проверить основную информацию сертификата. Сертификат должен удовлетворять каждому из следующих условий:

Сертификат подписан working_public_key_algirithm, с использованием working_public_key и working_public_parameters.

Период действительности сертификата включает текущее время.

В текущий момент времени сертификат не отменен и не имеет статуса приостановленного. Это может быть определено получением соответствующего CRL, информации о статусе или внешними механизмами.

Имя выпустившего сертификат есть working_issuer_name.

Если сертификат i является самовыпущенным, и это не последний сертификат в пути, пропустить данный шаг для сертификата i. В противном случае убедиться, что имя субъекта расположено в одном из Permitted_subtrees для уникальных имен Х.500 и что каждое из альтернативных имен в расширении subjectAltName (критичном или некритичном) расположено в одном Permitted_subtrees для данного типа имени.

Если сертификат i является самовыпущенным, и это не последний сертификат в пути, пропустить данный шаг для сертификата i. В противном случае убедиться, что имя субъекта не расположено ни в одном из Excluded_subtrees для уникальных имен Х.500 и что каждое альтернативное имя в расширении subjectAltName (критичное или некритичное) не расположено ни в одном из Excluded_subtrees для данного типа имени.

Если в сертификате имеется расширение политик сертификации и valid_policy_tree не NULL, обработать информацию политики с помощью следующих шагов в указанном порядке:

Для каждой политики 2, не эквивалентной 2, в расширении политик сертификации пусть P-OID обозначает OID политики Р и P-Q обозначает множество квалификаторов для политики Р. Выполняются следующие шаги в указанном порядке:

Если valid_policy_tree включает узел глубины i-1, где P-OID принадлежит expected_policy_set, создать подчиненный узел следующим образом: установить valid_policy в OID-P ; установить qualifier_set в P-Q и установить expected_policy_set в {P-OID}.

Например, рассмотрим valid_policy_tree с узлом глубины i-1, где expected_policy_set есть {Gold, White}. Предположим, что политики сертификации Gold и Silver присутствуют в расширении политик сертификации сертификата i. Это означает, что политика Gold соответствует, а политика Silver – нет. Данное правило будет создавать подчиненный узел глубины i для политики Gold. Результат показан на рис. 17.3.

Если нет соответствия на шаге (1) и valid_policy_tree включает узел глубины i-1 с действительной политикой anyPolicy, создается подчиненный узел со следующими значениями: установить valid_policy в P-OID ; установить qualifier_set в P-Q и установить expected_policy_set в {P-OID}.

Например, рассмотрим valid_policy_tree с узлом глубины i-1, где valid_policy есть anyPolicy. Предположим, что политики сертификации Gold и Silver присутствуют в расширении политик сертификации сертификата i. Политика Gold не имеет квалификатора, но политика Silver имеет квалификатор, Q-Silver. Если Gold и Silver не соответствуют (1), данное правило будет создавать два подчиненных узла глубины i, по одному на каждую политику. Результат показан на рис. 17.4.

Если расширение политик сертификации включает политику anyPolicy с квалификатором, установленным в AP-Q и либо (а) inhibit_any_policy есть больше 0, либо (b) i<n и сертификат самовыпущенный, тогда:

Для каждого узла в valid_policy_tree глубины i-1, для каждого значения в expected_policy_set (включая anyPolicy ), которое не присутствует в подчиненном узле, создается подчиненный узел со следующими значениями: установить valid_policy в значение из expected_policy_set в родительском узле; установить qualifier_set в AP-Q и установить множество expected_policy_set в значение в valid_policy из данного узла.

Например, рассмотрим valid_policy_tree с узлом глубины i-1, где expected_policy_set есть {Gold, Silver}. Предположим, что anyPolicy присутствует в расширении политик сертификации сертификата i, но Gold и Silver нет. Данное правило будет создавать два подчиненных узла глубины i, по одному для каждой политики. Результат показан на рис. 17.5.

Если существует узел в valid_policy_tree глубины i-1 или менее без каких-либо подчиненных узлов, удалить данный узел. Повторять этот шаг до тех пор, пока не останется узлов глубины i-1 или менее без подчиненных узлов.

Например, рассмотрим valid_policy_tree, показанную на рис. 17.6. Два узла глубины i-1, которые помечены ‘X’, не имеющие подчиненных узлов, удаляются. Применяя данное правило к результирующему дереву, узел глубины i-2, помеченный как ‘Y’, будет удален. Следующее применение правила не вызовет удаления каких-либо узлов, и данный шаг завершится.

Если расширение политик сертификации было помечено как критичное, установить criticality_indicator во всех узлах глубины i в TRUE. Если расширение политик сертификации было помечено как некритичное, установить criticality_indicator во всех узлах глубины i в FALSE.

(рис 17.3) Обработка точного соответствия

(рис 17.4) Обработка несоответствующих политик, когда конечный узел специфицирует anyPolicy

(рис 17.5) Обработка несоответствующих политик, когда расширение политик сертификации специфицирует anyPolicy

(рис 17.6) Сокращение valid_policy_tree

Если расширение политик сертификации не присутствует, установить valid_policy_tree в NULL.

Проверить: либо explicit_policy больше нуля, либо valid_policy_tree не эквивалентно NULL ;

Если любой из шагов (1), (2), (3) или (6) не завершается успешно, процедура прекращается, возвращается индикация неудачной проверки и соответствующая причина.

Если i не равно n, продолжается выполнение подготовительных шагов. Если i равно n, выполняются шаги wrap-up.

Подготовка для сертификата i+1

Для подготовки обработки сертификата i+1 выполняются следующие шаги для сертификата i:

Если представлено расширение отображений политики, проверяется, что специальное значение anyPolicy не присутствует в issuerDomainPolicy или subjectDomainPolicy.

Если представлено расширение отображений политики, то для каждого issuerDomainPolicy ID-P в расширении отображений политики:

Если переменная policy_mapping больше 0, для каждого узла в valid_policy_tree глубины i, где ID-P есть valid_policy, установить expected_policy_set и установить значения subjectDomainPolicy, которые определены, эквивалентными ID-P из расширения отображения политик.

Если нет узлов глубины i в valid_policy_tree, имеющих valid_policy ID-P, но есть узел глубиной i с valid_policy anyPolicy, создать подчиненный узел для узла глубиной i-1, который имеет valid_policy anyPolicy, следующим образом:

Установить valid_policy в ID-P ;

Установить qualifier_set в множество квалификаторов политики anyPolicy в расширении политик сертификации сертификата i ;

Установить criticality_indicator в значение критичности расширения политик сертификации сертификата i ;

Установить expected_policy_set в множество значений subjectDomainPolicy, которое определено эквивалентным ID-P расширения отображений политик.

Если переменная policy_mapping равна 0:

Удалить каждый узел глубины i в valid_policy_tree, где ID-P есть valid_policy.

Если есть узел в valid_policy_tree глубины i-1 или меньше без подчиненных узлов, удалить этот узел. Повторять этот шаг до тех пор, пока не будет узлов глубины i-1 или меньше без подчиненных узлов.

Присвоить working_issuer_name имя субъекта сертификата.

Присвоить working_public_key subjectPublicKey сертификата.

Если поле subjectPublicKeyInfo сертификата содержит поле алгоритма с ненулевыми параметрами, присвоить параметры переменной working_public_key_parameters.

Если поле subjectPublicKeyInfo сертификата содержит поле алгоритма с ненулевыми параметрами или параметры опущены, сравнить алгоритм subjectPublicKey сертификата с working_public_key_algorithm. Если алгоритм subjectPublicKey и working_public_key_algorithm различные, установить working_public_key_algorithm в null.

Определить алгоритм subjectPublicKey сертификата для переменной working_public_key_algorithm.

Если расширение ограничений имени включено в сертификат, модифицировать переменные состояния permitted_subtrees и excluded_subtrees следующим образом:

Если permittedSubtrees присутствует в сертификате, установить переменную состояния permitted_subtrees в пересечение ее предыдущего значения и значения, указанного в поле расширения. Если permittedSubtrees не включает тип конкретного имени, переменная состояния permitted_subtrees для данного типа имени не изменяется. Например, пересечение msu.ru и cmc.msu.ru есть cmc.msu.ru. А пересечение cmc.msu.ru и mm.msu.ru есть пустое множество.

Если excludedSubtrees присутствует в сертификате, установить переменную состояния excluded_subtrees в объединение ее предыдущего значения и значения, указанного в поле расширения. Если excludedSubtrees не включает тип конкретного имени, переменная состояния excluded_subtrees для данного типа имени не изменяется. Например, объединением пространства имен cmc.msu.ru и mm.msu.ru является пространство обеих имен.

Если имена субъекта и выпускающего не идентичны:

Если explicit_policy не 0, уменьшить explicit_policy на 1.

Если policy_mapping не 0, уменьшить policy_mapping на 1.

Если inhibit_any-policy не 0, уменьшить inhibit_any-policy на 1.

Если расширение ограничений политики включено в сертификат, модифицировать переменные состояния 2 и policy_mapping следующим образом:

Если requireExplicitPolicy присутствует и ее значение меньше, чем explicit_policy, установить explicit_policy в значение requireExplicitPolicy.

Если inhibitPolicyMapping присутствует и ее значение меньше, чем policy_mapping, установить policy_mapping в значение inhibitPolicyMapping.

Если расширение inhibitAnyPolicy присутствует в сертификате и меньше, чем inhibit_any-policy, установить inhibit_any-policy в значение inhibitAnyPolicy.

Убедиться, что сертификат есть сертификат СА (если это не указано в расширении basicConstraints, проверить с помощью внешних средств).

Если сертификат не является самовыпущенным, убедиться, что max_path_length больше нуля и уменьшить max_path_length на 1.

Если pathLengthConstraint присутствует в сертификате и меньше, чем max_path_length, установить max_path_length в значение pathLengthConstraint.

Если расширение использования ключа присутствует, проверить, установлен ли бит keyCertSign.

Определить и обработать все остальные критичные расширения в сертификате. Обработать все другие распознанные некритичные расширения, представленные в сертификате.

Если проверки (1), (10), (11), (12) или (13) не прошли, процедура завершается, возвращается индикация недействительности сертификационного пути и соответствующая причина.

Если (1), (10), (11), (12) и (13) завершены успешно, увеличить i и выполнить базовую обработку сертификата, описанную в предыдущем пункте.

Wrap-up процедура

Для завершения обработки сертификата конечного участника выполнить следующие шаги для сертификата n:

Если сертификат n не является самовыпущенным, и значение explicit_policy не 0, уменьшить explicit_policy на 1.

Если расширение ограничений политики включено в сертификат и requireExplicitPolicy присутствует и имеет значение 0, установить переменную состояния explicit_policy в 0.

Присвоить subjectPublicKey сертификата для working_public_key.

Если поле subjectPublicKeyInfo сертификата содержит поле алгоритма с ненулевыми параметрами, определить параметры как переменную working_public_key_parameters.

Если поле subjectPublicKeyInfo сертификата содержит поле алгоритма с нулевыми параметрами или параметры опущены, сравнить алгоритм subjectPublicKeyInfo сертификата с working_public_key_algorithm. Если subjectPublicKeyInfo и working_public_key_algorithm различны, установить working_public_key_parameters в null.

Присвоить значение алгоритма из расширения subjectPublicKey сертификата переменной working_public_key_algorithm.

Определить и обработать все другие критичные расширения, представленные в сертификате n. Обработать все другие распознанные некритичные расширения, представленные в сертификате n.

Вычислить пересечение valid_policy_tree и user-initial-policy-set следующим образом:

Если valid_policy_tree есть NULL, пересечение есть NULL.

Если valid_policy_tree есть не NULL и user-initial-policy-set есть any-policy, пересечение есть valid_policy_tree.

Если valid_policy_tree есть не NULL и user-initial-policy-set есть не any-policy, вычислить пересечение valid_policy_tree и user-initial-policy-set следующим образом:

Определить множество узлов политики, у которых родительские узлы имеют valid_policy для anyPolicy. Это есть valid_policy_node_set.

Если valid_policy любого узла в valid_policy_node_set установлено не в user-initial-policy-set и не в anyPolicy, удалить данный узел и все подчиненные узлы.

Если valid_policy_tree включает узел глубины n с valid_policy anyPolicy и user-initial-policy-set есть не any-policy, выполнить следующие шаги:

Установить P-Q в qualifier_set в узле глубины n с valid_policy anyPolicy.

Для каждого P-OID в user-initial-policy-set, который не содержит значение valid_policy узла, создать подчиненный узел, чьим родителем является узел глубины n-1 с valid_policy anyPolicy. Установить значения в подчиненном узле следующим образом: установить valid_policy в P-OID ; установить qualifier_set в P-Q ; копировать criticality_indicator из узла глубины n с valid_policy anyPolicy ; установить expected_policy_set в {P-oid}.

Удалить узел глубины n с valid_policy anyPolicy.

Если существует узел с valid_policy_tree глубины n-1 или менее без подчиненных узлов, удалить этот узел. Повторять данный шаг до тех пор, пока не останется узлов глубины n-1 без подчиненных узлов.

Если либо (1) значение переменной explicit_policy больше нуля, либо (2) valid_policy_tree не есть NULL, то обработка пути выполнена.

Выходные значения

Если обработка пути выполнена, процедура завершается, возвращая индикатор успешного завершения вместе с заключительными значениями valid_policy_tree, working_public_key и working_public_key_algorithm working_public_key_parameters.

Использование алгоритма проверки действительности пути

Алгоритм проверки действительности пути описывает процесс проверки действительности единственного сертификационного пути. Хотя каждый сертификационный путь начинается со специального доверенного корневого сертификата, не существует требования, чтобы все сертификационные пути, проверяемые конкретной системой, разделяли единственный доверенный корневой сертификат. Реализация, которая поддерживает несколько доверенных корневых сертификатов, может расширить описанный здесь алгоритм. Например, модифицировать алгоритм применением ограничений имени к конкретному доверенному корневому сертификату во время начальной фазы, или приложение может потребовать наличия конкретной формы альтернативного имени в сертификате конечного участника, или приложение может потребовать специфических для него расширений. Таким образом, алгоритм проверки действительности сертификационного пути определяет минимальные условия для того, чтобы считать путь действительным.

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

Также можно специфицировать расширенную версию приведенной выше процедуры обработки сертификационного пути. В данной расширенной версии дополнительные входы в процедуру определяют имена Политики Уполномоченного Органа (РСА) и позицию в сертификационном пути, где ожидается РСА. В предполагаемой позиции РСА имя СА сравнивается с данным списком. Если ожидаемое имя РСА найдено, то ограничение SubordinationToCA неявно предполагается для оставшегося сертификационного пути, и обработка продолжается. Если не найдено действительного имени РСА и если сертификационный путь не может быть действительным с учетом идентифицированных политик, то сертификационный путь считается недействительным.

Действительность CRL

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

Данный алгоритм предполагает, что все необходимые CRLs доступны в локальном кэше. Более того, если при следующем изменении CRL был получен, алгоритм предполагает, что текущий CRL будет получен и помещен в локальный кэш CRL.

Данный алгоритм определяет множество входов, множество переменных состояния и шаги обработки, которые выполняются для каждого сертификата в пути. Выходом алгоритма является статус отмены сертификата.

Входы отмены

Для поддержки обработки отмены алгоритму требуется два входа:

Сертификат: алгоритму требуется серийный номер сертификата и имя выпускающего, чтобы определить, содержится ли сертификат в конкретном CRL. С помощью расширения basicConstraints можно убедиться, что рассматриваемый сертификат связан с СА или с конечным участником. Если расширения cRLDistributionsPoint и freshestCRL присутствуют, алгоритм использует их для определения статуса отмены.

Use-deltas: данный булевый вход определяет, применяются ли дельта CRLs к CRLs.

Инициализация и переменные состояния отмены

Для поддержки обработки CRL алгоритму требуются следующие переменные состояния:

Reasons_mask: данная переменная содержит множество причин отмены, поддерживаемых для обрабатываемых CRLs и дельта CRLs. Допустимыми элементами множества являются следующие значения возможных причин отмены: unspecified, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn и aACompromise. Специальное значение all-reasons используется для обозначения множества всех возможных членов. Данная переменная инициализируется в пустое множество.

Cert_status: данная переменная содержит статус сертификата. Ей может быть присвоено одно из следующих значений: unspecified, keyCompromise, caCompromise, affiliationChanged, superseded, cessationWithdrawn, aACompomise, специальное значение UNREVOKED или специальное значение UNDETERMINED. Данная переменная инициируется в специальное значение UNREVOKED.

Interim_reasons_mask: это множество причин отмены, поддерживаемых CRL или дельта CRL, обрабатываемых в настоящий момент.

Замечание: в некоторых окружениях нет необходимости проверять все коды причин. Например, некоторые окружения имеют дело только с caCompromise и keyCompromise для сертификатов СА. Данный алгоритм проверяет все коды причин. Дополнительная обработка и переменные состояния могут потребоваться для ограничения проверки подмножества кодов причин.

Обработка CRL

Данный алгоритм начинается с предположения, что сертификат не отменен. Алгоритм проверяет один или более CRL до тех пор, пока либо статус сертификата не будет определен как отмененный, либо будет проверено достаточное количество CRLs, охватывающих все коды причин.

Для каждой точки распространения (DP) в расширении сертификата точек распространения CRL, для каждого соответствующего CRL в локальном кэше CRL пока ( (reasons_mask не all-reasons) и (cert_status есть UNREVOKED) ) выполнить следующее:

Изменить локальный кэш CRL получением полного CRL, дельта CRL или обоих, как определено локальной политикой:

Если текущее время больше значения поля CRL next update, выполнить следующие действия:

Если use-deltas установлен и либо сертификат, либо CRL содержат расширение freshest CRL, получить дельта CRL со значением next update, которое больше текущего времени.

Изменить локальный кэш CRL текущим полным CRL, убедиться, что текущее время – меньше значения next update в новом CRL, и продолжить обработку с новым CRL.

Если текущее время меньше значения поля next update и use-deltas установлен, получить текущий дельта CRL, который может быть использован для изменения локального кэшированного полного CRL.

Проверить выпускающего и область полного CRL следующим образом:

Если DP включает cRLIssuer, убедиться, что поле выпускающего в полном CRL соответствует cRLIssuer в DP, и что полный CRL содержит расширение, описывающее точки распространения выпускающего с установленным булевским значением indrectCRL. В противном случае убедиться, что выпускающий CRL соответствует выпускающему сертификат.

Если полный CRL включает расширение CRL, описывающее точки распространения выпускающего (IDP), проверить следующее:

Если присутствует имя точки распространения в расширении CRL IDP и присутствует поле распространения в DP, убедиться, что одно из имен в IDP соответствует одному из имен в DP. Если имя точки распространения представлено в расширении CRL IDP и поле распространения опущено в DP, убедиться, что одно из имен в IDP соответствует одному из имен в поле cRLIssuer DP.

Если булевское onlyContainsUserCerts установлено в расширении CRL IDP, проверить, что сертификат не включает расширение базовых ограничений с установленным булевским сА.

Если булевское onlyContainsCACerts установлено в расширении CRL IDP, проверить, включает ли сертификат расширение базовых ограничений с установленным булевским сА.

Убедиться, что булевское onlyContainsAttributeCerts не установлено.

Если установлен use-deltas, проверить выпускающего и область дельта CRL следующим образом:

Проверить, соответствует ли выпускающий дельта CRL выпускающему полного CRL.

Если полный CRL включает расширение CRL выпускающей точки распространения (IDP), убедиться, что дельта CRL содержит соответствующее расширение CRL IDP. Если в полном CRL расширение CRL IDP опущено, убедиться, что в дельта CRL также опущено расширение CRL IDP.

Убедиться, что расширение идентификатора ключа уполномоченного органа дельта CR L соответствует расширению идентификатора ключа уполномоченного органа полного CRL.

Вычислить interim_reasons_mask для данного CRL следующим образом:

Если расширение CRL выпускающей точки распространения (IDP) присутствует, включает onlySomeReasons и DP включает reasons, то установить interim_reasons_mask в пересечение reasons в DP и onlySomeReasons в расширении CRL IDP.

Если расширение CRL IDP включает бит onlySomeReasons, но в DP опущены reasons, то установить interim_reasons_mask в значение onlySomeReasons в расширении CRL IDP.

Если расширение CRL IDP не присутствует или опущено onlySomeReasons, но DP включает reasons, то установить interim_reasons_mask в значение DP reasons.

Если расширение CRL IDP не присутствует или опущено onlySomeReasons и в DP опущены reasons, то установить interim_reasons_mask в специальное значение all-reasons.

Убедиться, что interim_reasons_mask включает одну или более reasons, которые не включены в reasons_mask.

Получить и проверить действительность сертификационного пути для выпускающего полный CRL. Если расширение использования ключа в сертификате выпускающего CRL присутствует, проверить, установлен ли бит cRLSign.

Проверить действительность подписи в полном CRL, используя открытый ключ, действительность которого проверена на шаге (6).

Если use-deltas установлен, проверить действительность подписи для дельта CRL, используя открытый ключ, действительность которого проверена на шаге (6).

Если use-deltas установлен, выполнить поиск для сертификата в дельта CRL. Если найдена запись, которая соответствует выпускающему сертификат и серийному номеру, как описано выше, установить переменную cert_status в значение, соответствующее указанной причине, следующим образом:

Если расширение записи CRL кода причины присутствует, установить переменную cert_status в значение расширения записи CRL кода причины.

Если расширение записи CRL кода причины не присутствует, установить переменную cert_status в значение unspecified.

Если cert_status есть UNREVOKED, то выполнить поиск для сертификата в полном CRL. Если найдена запись, соответствующая выпускающему сертификат и серийному номеру, установить переменную cert_status в указанную причину, как описано в шаге (9).

Если ( cert_status есть removeFromCRL ), то установить cert_status в UNREVOKED.

Если reasons_mask есть all-resons или cert_status не UNREVOKED, то статус отмены определен, так как возвращается cert_status.

Если статус сертификата не определен, повторить описанный выше процесс с любыми доступными CRLs, не указанными в точке распространения, но созданными выпускающим сертификат. Для обработки таких CRL предполагается DP с обеими причинами, и опущенные поля cRLIssuer, и имя точки распространения выпускающего сертификат. Это означает, что последовательность имен в fullName создается из поля выпускающего сертификат, а также расширения issuerAltName сертификата. Если статус отмены остается неопределенным, то возвращается cert_status UNDETERMINED.

Обсуждение проблем безопасности

Главным в данном стандарте является формат и содержимое сертификатов и CRLs. Так как сертификаты и CRLs подписаны, необходимости в дополнительных сервисах целостности нет. Ни сертификаты, ни CRLs не содержат никаких секретов, поэтому к сертификатам и CRLs возможен неограниченный и анонимный доступ.

Однако факторы безопасности, внешние по отношению к данной спецификации, могут оказывать влияние на гарантии, предоставляемые пользователям сертификатов. Определим основные факторы, которые должны быть рассмотрены разработчиками, администраторами и пользователями.

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

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

К сожалению, некоторые наследуемые приложения (например, TLS/SSL) используют единственную пару ключей для подписывания и для управления ключом.

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

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

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

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

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

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

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

Несогласованность приложений в правилах сравнения имен может привести к тому, что будет принят недействительный сертификационный путь или отвергнут действительный путь. Серия спецификаций Х.500 определяет правила для сравнения уникальных имен, которые требуют сравнения безотносительно регистра, набора символов и нескольких последовательных пробелов, а также первых и последних пробелов. Стандарт Х.509 ослабляет строгость этих правил, требуя поддержки как минимум бинарного сравнения.

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

Кроме того, ограничения имени для уникальных имен должны быть установлены идентично представлениям, используемым в поле субъекта или расширении subjectAltName. Если это не так, то ограничения имени, установленные как excludedSubTrees, не будут соответствовать, и недействительные пути будут приниматься, и ограничения имени, выраженные как permittedSubtrees, не будут соответствовать, и действительные пути будут отвергаться. Для того, чтобы избежать приема недействительных путей, САs должны установить ограничения имени для уникальных имен как permittedSubtrees везде, где это возможно.

Страницы: