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

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

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

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

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

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

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

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

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

Входы отмены

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

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

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

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

1. Reasons_mask: данная переменная содержит множество причин отмены, поддерживаемых для обрабатываемых CRLs и дельта CRLs. Допустимыми элементами множества являются следующие значения возможных причин отмены: unspecified, superseded, cessationOfOperation, certificateHold, privilegeWithdrawn и aACompromise. Специальное значение all-reasons используется для обозначения множества всех возможных членов. Данная переменная инициализируется в пустое множество.
2. Cert_status: данная переменная содержит статус сертификата. Ей может быть присвоено одно из следующих значений: unspecified, keyCompromise, caCompromise, affiliationChanged, superseded, cessationWithdrawn, aACompomise, специальное значение UNREVOKED или специальное значение UNDETERMINED. Данная переменная инициируется в специальное значение UNREVOKED.
3. Interim_reasons_mask: это множество причин отмены, поддерживаемых CRL или дельта CRL, обрабатываемых в настоящий момент.

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

Обработка CRL

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

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

1. Изменить локальный кэш CRL получением полного CRL, дельта CRL или обоих, как определено локальной политикой:
   1. Если текущее время больше значения поля CRL next update, выполнить следующие действия:
      1. Если use-deltas установлен и либо сертификат, либо CRL содержат расширение freshest CRL, получить дельта CRL со значением next update, которое больше текущего времени.
      2. Изменить локальный кэш CRL текущим полным CRL, убедиться, что текущее время – меньше значения next update в новом CRL, и продолжить обработку с новым CRL.
   2. Если текущее время меньше значения поля next update и use-deltas установлен, получить текущий дельта CRL, который может быть использован для изменения локального кэшированного полного CRL.
2. Проверить выпускающего и область полного CRL следующим образом:
   1. Если DP включает cRLIssuer, убедиться, что поле выпускающего в полном CRL соответствует cRLIssuer в DP, и что полный CRL содержит расширение, описывающее точки распространения выпускающего с установленным булевским значением indrectCRL. В противном случае убедиться, что выпускающий CRL соответствует выпускающему сертификат.
   2. Если полный CRL включает расширение CRL, описывающее точки распространения выпускающего (IDP), проверить следующее:
      1. Если присутствует имя точки распространения в расширении CRL IDP и присутствует поле распространения в DP, убедиться, что одно из имен в IDP соответствует одному из имен в DP. Если имя точки распространения представлено в расширении CRL IDP и поле распространения опущено в DP, убедиться, что одно из имен в IDP соответствует одному из имен в поле cRLIssuer DP.
      2. Если булевское onlyContainsUserCerts установлено в расширении CRL IDP, проверить, что сертификат не включает расширение базовых ограничений с установленным булевским сА.
      3. Если булевское onlyContainsCACerts установлено в расширении CRL IDP, проверить, включает ли сертификат расширение базовых ограничений с установленным булевским сА.
      4. Убедиться, что булевское onlyContainsAttributeCerts не установлено.
3. Если установлен use-deltas, проверить выпускающего и область дельта CRL следующим образом:
   1. Проверить, соответствует ли выпускающий дельта CRL выпускающему полного CRL.
   2. Если полный CRL включает расширение CRL выпускающей точки распространения (IDP), убедиться, что дельта CRL содержит соответствующее расширение CRL IDP. Если в полном CRL расширение CRL IDP опущено, убедиться, что в дельта CRL также опущено расширение CRL IDP.
   3. Убедиться, что расширение идентификатора ключа уполномоченного органа дельта CR L соответствует расширению идентификатора ключа уполномоченного органа полного CRL.
4. Вычислить interim_reasons_mask для данного CRL следующим образом:
   1. Если расширение CRL выпускающей точки распространения (IDP) присутствует, включает onlySomeReasons и DP включает reasons, то установить interim_reasons_mask в пересечение reasons в DP и onlySomeReasons в расширении CRL IDP.
   2. Если расширение CRL IDP включает бит onlySomeReasons, но в DP опущены reasons, то установить interim_reasons_mask в значение onlySomeReasons в расширении CRL IDP.
   3. Если расширение CRL IDP не присутствует или опущено onlySomeReasons, но DP включает reasons, то установить interim_reasons_mask в значение DP reasons.
   4. Если расширение CRL IDP не присутствует или опущено onlySomeReasons и в DP опущены reasons, то установить interim_reasons_mask в специальное значение all-reasons.
5. Убедиться, что interim_reasons_mask включает одну или более reasons, которые не включены в reasons_mask.
6. Получить и проверить действительность сертификационного пути для выпускающего полный CRL. Если расширение использования ключа в сертификате выпускающего CRL присутствует, проверить, установлен ли бит cRLSign.
7. Проверить действительность подписи в полном CRL, используя открытый ключ, действительность которого проверена на шаге (6).
8. Если use-deltas установлен, проверить действительность подписи для дельта CRL, используя открытый ключ, действительность которого проверена на шаге (6).
9. Если use-deltas установлен, выполнить поиск для сертификата в дельта CRL. Если найдена запись, которая соответствует выпускающему сертификат и серийному номеру, как описано выше, установить переменную cert_status в значение, соответствующее указанной причине, следующим образом:
   1. Если расширение записи CRL кода причины присутствует, установить переменную cert_status в значение расширения записи CRL кода причины.
   2. Если расширение записи CRL кода причины не присутствует, установить переменную cert_status в значение unspecified.
10. Если cert_status есть UNREVOKED, то выполнить поиск для сертификата в полном CRL. Если найдена запись, соответствующая выпускающему сертификат и серийному номеру, установить переменную cert_status в указанную причину, как описано в шаге (9).
11. Если ( cert_status есть removeFromCRL ), то установить cert_status в UNREVOKED.

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

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