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)
Авторы: , , , , , ,
Перевод: Мельников Дмитрий Анатольевич
4.2.1.10. Ограничения на форматы имён

Субполе «nameConstraints», которое может использоваться только в сертификатах УЦ, указывает на пространство имён, в рамках которого все имена владельцев сертификатов в последовательности сертификатов на пути сертификации должны быть в обязательном порядке обнаруживаемыми (устанавливаемыми). Ограничения накладываются на уникальное и альтернативные имена владельца сертификата. Ограничения накладываются только тогда, когда имеет место определённый формат наименования. Если в сертификате нет имени разрешённого типа (формата), то сертификат считается не приемлемым (не допустимым).

Ограничения на форматы имён (субполе «nameConstraints» поля «Расширения») не применяются в само-изданных сертификатах (до тех пор, пока сертификат не является финальным сертификатом на МС). (Такой подход мог бы предотвратить применение УЦ, использующими ограничения на форматы имён, само-изданных сертификатов для многократного продления срока действия криптоключа.)

Ограничения определяются в терминах субдеревьев имён (ветвей дерева имён), которые разрешены или запрещены к использованию. Любое имя, совпадающее с ограничением, которое указанном в последовательности «excludedSubtrees», является недопустимым, даже невзирая на информацию, содержащуюся в последовательности «permittedSubtrees». УЦ, придерживающиеся данного стандарта, обязаны помечать субполе «nameConstraints» как «критичное», а также не должны налагать ограничений на имена в форматах «x400Address», «ediPartyName» или «registeredID». УЦ, придерживающиеся данного стандарта, обязаны не издавать сертификаты, в которых субполе «nameConstraints» представлено в виде пустой (нулевой) последовательности. Т.е., в сертификатах обязательно должна быть, как минимум, одна из двух последовательностей, либо «excludedSubtrees», либо «permittedSubtrees».

Прикладные системы, придерживающиеся данного стандарта, обязаны обрабатывать субполе «nameConstraints», которое налагает ограничения на имена в формате «directoryName». И целесообразно, чтобы они обрабатывали субполе «nameConstraints», которое налагает ограничения на имена в форматах .html822Name», «uniformResourceIdentifier», «dNSName» и «iPAddress». Если субполе «nameConstraints», помеченное как «критичное», налагает ограничения на соответствующий формат имён, а элемент имени в таком формате представлен в поле «Subject» или в субполе «subjectAltName» данного сертификата, то прикладная система обязана, либо обработать субполе «nameConstraints», либо уничтожить сертификат.

В данном стандарте последовательности «minimum» и «maximum» не используются ни при каких форматах имён. Таким образом, минимальное значение должно быть нулевым, а максимальное — вообще отсутствовать. Однако, если прикладная система с «критичным» субполем «nameConstraints», в котором указаны иные значения минимума или максимума для форматов имён, представленный в данном сертификате, то прикладная система обязана, либо обработать эти субполе и последовательности, либо уничтожить сертификат.

Страница 34 из 108

2007 - 2022 © Русские переводы RFC, IETF, ISOC.