RFC: 5280
Оригинал: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
Предыдущие версии: RFC 2459, RFC 3280, RFC 4325, RFC 4630
Категория: Предложенный стандарт
Дата публикации: (с дополнениями из RFC 6818, Январь 2013)
Авторы: , , , , , ,
Перевод: Мельников Дмитрий Анатольевич

6.1.3. Фаза основной обработки сертификата

В этой фазе обрабатывается i-ый сертификат (для всех i из [1…n]). В это фазе проводятся следующие операции:

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

    1. Подпись сертификата может быть проверена с использованием переменных «working_public_key_algorithm», «working_public_key» и «working_public_key_parameters».

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

    3. В текущее время сертификат не является аннулированным. Это может быть установлено путём получения соответствующего СОС, с помощью данных о состоянии или с помощью автономных способов получения информации о сертификате. Имя издателя сертификата соответствует значению переменной «working_issuer_name».

  2. Если i-ый сертификат является само-изданным и не является последним сертификатом маршрута, то пропускаем эту операцию для i-ого сертификата. В противном случае, проверяем, что имя владельца сертификата представлено в одном из разрешённых субдеревьев «permitted_subtrees» для уникальных имён в соответствие с Рекомендацией ITU-T X.500, а также проверяем, что каждое из альтернативных имён, указанных в субполе «subjectAltName» (как критичное или не критичное), представлено в одном из разрешённых субдеревьев «permitted_subtrees» для данного формата имён.

  3. Если i-ый сертификат является само-изданным и не является последним сертификатом маршрута, то пропускаем эту операцию для i-ого сертификата. В противном случае, проверяем, что имя владельца сертификата не представлено ни в одном из разрешённых субдеревьев «excluded_subtrees» для уникальных имён в соответствие с Рекомендацией ITU-T X.500, а также проверяем, что каждое из альтернативных имён, указанных в субполе «subjectAltName» (как критичное или не критичное), не представлено ни в одном из разрешённых субдеревьев «excluded_subtrees» для данного формата имён.

  4. Если в сертификате представлено субполе «certificatePolicies», а дерево «valid_policy_tree» не нулевое (не пустое), то обрабатываем данные о политике следующим образом:

    1. Для каждой P-ой политики, не эквивалентной «anyPolicy», представленной в субполе «certificatePolicies», пусть P-OID обозначает идентификатор P-ой политики, а P-Q — определитель группы для P-ой политики. Проведём следующие операции:

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

        Например, рассмотрим дерево «valid_policy_tree» с узлом глубиной i-1, в котором компонент «expected_policy_set» имеет значение {Gold, White}. Предположим, что в субполе «certificatePolicies» i-го сертификата представлены политики сертификации «Gold» и «Silver». Политика «Gold» совпала, а политика «Silver» — нет. В соответствие с этим правилом будет сформирован дочерний узел глубиной i для политики «Gold». Результат этой операции представлен на рис. 4;

        +-----------------+
        |       Red       |
        +-----------------+
        |       {}        |
        +-----------------+   Узел глубиной i-1
        |  {Gold, White}  |
        +-----------------+
                 |
                 |
                 |
                 V
        +-----------------+
        |      Gold       |
        +-----------------+
        |       {}        |
        +-----------------+   Узел глубиной i
        |     {Gold}      |
        +-----------------+
        
        Рис. 4. Операция сравнения на предмет совпадения
      2. Если на i-ом шаге совпадение не обнаружено и дерево «valid_policy_tree» содержит узел глубиной i-1, в котором «valid_policy» содержит значение «anyPolicy», то формируем дочерний узел со следующими значениями: установим «valid_policy» в P-OID, «qualifier_set» в P-Q, а «expected_policy_set» в {P-OID}.

        Например, рассмотрим дерево «valid_policy_tree» с узлом глубиной i-1, в котором «valid_policy» имеет значение «anyPolicy». Предположим, что в субполе «certificatePolicies» i-го сертификата представлены политики сертификации «Gold» и «Silver». Политика «Gold» не содержит определителя, а тоже время политика «Silver» имеет определитель «Q-Silver». Если политики «Gold» и «Silver» не совпали, как это было указано выше в §(i), то в соответствие с этим правилом будут сформированы два дочерних узла глубиной i для каждой из политик. Результат представлен на рис.5;

                       +-----------------+
                       |    anyPolicy    |
                       +-----------------+
                       |       {}        |
                       +-----------------+ Узел глубиной i-1
                       |   {anyPolicy}   |
                       +-----------------+
                          /           \
                         /             \
                        /               \
                       /                 \
        +-----------------+            +-----------------+
        |      Gold       |            |     Silver      |
        +-----------------+            +-----------------+
        |       {}        |            |   {Q-Silver}    |
        +-----------------+    Узлы    +-----------------+
        |     {Gold}      | глубиной i |    {Silver}     |
        +-----------------+            +-----------------+
        
        Рис. 5. Операция сравнения, обнаружившая не совпадение политик,
        когда лист/узел дерева содержит значение «anyPolicy»
    2. Если субполе «certificatePolicies» содержит политику «anyPolicy» с определителем, установленным в значение «AP-Q», а также, (a) либо переменная «inhibit_anyPolicy» имеет значение > 0, (b) либо сертификат является само-изданным, тогда:

      Для каждого узла в дереве «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, White}. Предположим, что в субполе «certificatePolicies» i-го сертификата содержится значение «anyPolicy» без определителей политик, но значения «Gold» и «Silver» отсутствуют. В соответствие с этим правилом будут сформированы два дочерних узла глубиной i для каждой из политик. Результат представлен на рис. 6;

                     +-----------------+
                     |      Red        |
                     +-----------------+
                     |       {}        |
                     +-----------------+ Узел глубиной i-1
                     |  {Gold, Silver} |
                     +-----------------+
                        /           \
                       /             \
                      /               \
                     /                 \
      +-----------------+            +-----------------+
      |      Gold       |            |     Silver      |
      +-----------------+            +-----------------+
      |       {}        |            |       {}        |
      +-----------------+    Узлы    +-----------------+
      |     {Gold}      | глубиной i |    {Silver}     |
      +-----------------+            +-----------------+
      
      Рис. 6. Операция сравнения, обнаружившая не совпадение политик,
      когда субполе «certificatePolicies» содержит значение «anyPolicy»
    3. Если в дереве «valid_policy_tree» с узлом глубиной i-1 или меньше присутствует узел без каких-либо дочерних узлов, то удаляем этот узел. Повторяем эту операцию до тех пор, пока не будет узлов глубиной i-1 или меньше без дочерних узлов.

      Например, рассмотрим дерево «valid_policy_tree», изображённое на рис. 7. Два узла глубиной i-1, помеченные как «X», и не имеющие дочерних узлов, удаляются. Следуя этому правилу, будет сформировано итоговое дерево, в котором расположен узел голубиной i-2, помеченный как «Y» и подлежащий удалению. В итоговом дереве отсутствуют узлы глубиной i-1 или меньше, и не имеющие дочерних узлов. И на этом данная операция завершается;

  5. Если субполе «certificatePolicies» отсутствует, то устанавливаем дерево «valid_policy_tree» в нулевое значение («NULL»).

  6. Проверяем, либо переменная «explicit_policy» больше нуля, либо переменная «valid_policy_tree» не равна нулевому значению («NULL»).

Если любая из операций a), b), c) или f) в фазе инициализации завершилась неудачей, то процедура прекращается, указывая на неисправность и соответствующую причину.

Если i не равно n, то продолжаем обработку путём реализации подготовительных операций, представленных в 6.1.4. Если i равно n, то переходим к завершению процедуры (6.1.5).

                           +-----------+
                           |           | Узел глубиной i-3
                           +-----------+
                           /     |     \
                          /      |      \
                         /       |       \
             +-----------+ +-----------+ +-----------+
             |           | |           | |     Y     |  Узлы глубиной i-2
             +-----------+ +-----------+ +-----------+
             /   \               |             |
            /     \              |             |
           /       \             |             |
+-----------+ +-----------+ +-----------+ +-----------+
|           | |     X     | |           | |    X      | Узлы глубиной  i-1 
+-----------+ +-----------+ +-----------+ +-----------+
      |                      /    |    \
      |                     /     |     \
      |                    /      |      \
+-----------+ +-----------+ +-----------+ +-----------+
|           | |           | |           | |           | Узлы глубиной i
+-----------+ +-----------+ +-----------+ +-----------+

Рис. 7. Упрощение дерева «valid_policy_tree»
2007 - 2017 © Русские переводы RFC, IETF, ISOC.