6.1.3. Фаза основной обработки сертификата
В этой фазе обрабатывается i-ый сертификат (для всех i из [1…n]). В это фазе проводятся следующие операции:
Проверка основной информации сертификата. Сертификат должен удовлетворять, в обязательном порядке, каждому из следующих условий:
Подпись сертификата может быть проверена с использованием переменных «working_public_key_algorithm», «working_public_key» и «working_public_key_parameters».
Период действия сертификата включает текущее время.
В текущее время сертификат не является аннулированным. Это может быть установлено путём получения соответствующего СОС, с помощью данных о состоянии или с помощью автономных способов получения информации о сертификате. Имя издателя сертификата соответствует значению переменной «working_issuer_name».
Если i-ый сертификат является само-изданным и не является последним сертификатом маршрута, то пропускаем эту операцию для i-ого сертификата. В противном случае, проверяем, что имя владельца сертификата представлено в одном из разрешённых субдеревьев «permitted_subtrees» для уникальных имён в соответствие с Рекомендацией ITU-T X.500, а также проверяем, что каждое из альтернативных имён, указанных в субполе «subjectAltName» (как критичное или не критичное), представлено в одном из разрешённых субдеревьев «permitted_subtrees» для данного формата имён.
Если i-ый сертификат является само-изданным и не является последним сертификатом маршрута, то пропускаем эту операцию для i-ого сертификата. В противном случае, проверяем, что имя владельца сертификата не представлено ни в одном из разрешённых субдеревьев «excluded_subtrees» для уникальных имён в соответствие с Рекомендацией ITU-T X.500, а также проверяем, что каждое из альтернативных имён, указанных в субполе «subjectAltName» (как критичное или не критичное), не представлено ни в одном из разрешённых субдеревьев «excluded_subtrees» для данного формата имён.
Если в сертификате представлено субполе «certificatePolicies», а дерево «valid_policy_tree» не нулевое (не пустое), то обрабатываем данные о политике следующим образом:
Для каждой P-ой политики, не эквивалентной «anyPolicy», представленной в субполе «certificatePolicies», пусть P-OID обозначает идентификатор P-ой политики, а P-Q — определитель группы для P-ой политики. Проведём следующие операции:
Для каждого узла глубиной 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. Операция сравнения на предмет совпаденияЕсли на 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»
Если субполе «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»Если в дереве «valid_policy_tree» с узлом глубиной i-1 или меньше присутствует узел без каких-либо дочерних узлов, то удаляем этот узел. Повторяем эту операцию до тех пор, пока не будет узлов глубиной i-1 или меньше без дочерних узлов.
Например, рассмотрим дерево «valid_policy_tree», изображённое на рис. 7. Два узла глубиной i-1, помеченные как «X», и не имеющие дочерних узлов, удаляются. Следуя этому правилу, будет сформировано итоговое дерево, в котором расположен узел голубиной i-2, помеченный как «Y» и подлежащий удалению. В итоговом дереве отсутствуют узлы глубиной i-1 или меньше, и не имеющие дочерних узлов. И на этом данная операция завершается;
Если субполе «certificatePolicies» отсутствует, то устанавливаем дерево «valid_policy_tree» в нулевое значение («NULL»).
Проверяем, либо переменная «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»