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

Существуют устаревшие прикладные системы, в которых адрес электронной почты встроен в уникальное имя владельца сертификата в качестве атрибута типа «emailAddress» (4.1.2.6). Когда на имена формата «rfc822Name» наложено ограничение, но сертификат не включает альтернативное имя владельца сертификата (субполе «subjectAltName» поля «Расширения»), тогда на атрибут типа «emailAddress» в составе уникального наименования владельца сертификата должно в обязательном порядке распространяться ограничение на имена формата «rfc822Name». В Приложении А представлен ASN.1-синтаксис для атрибута типа «emailAddress» и соответствующего OID.

Ограничения на имена формата «directoryName» обязаны налагаться на поле «Subject» в сертификате (если сертификат содержит не пустое поле «Subject») и на любые наименования типа «directoryName» в субполе «subjectAltName». Ограничения на имена формата «x400Address» обязаны налагаться на любые наименования типа «x400Address» в субполе «subjectAltName».

Если на имена формата «directoryName» наложены ограничения, то прикладной программный модуль обязан сравнивать DN-атрибуты. Как минимум, прикладные системы (программные модули) обязаны «выполнять» правила сравнения СЕК-имён, которые рассматриваются ниже. УЦ, выпускающим сертификаты с ограничениями на имена формата «directoryName», не целесообразно полагаться на реализацию алгоритма сравнения полных ISO/DN-имён. Это означает, что ограничения на форматы имён должны в обязательном порядке точно совпадать с кодированием, которое используется в поле «Subject» или в субполе «subjectAltName».

Синтаксис IP-адресов должен быть точно таким же, как он представлен в 4.2.1.6. И вместе с тем, специально для ограничений форматов имён существуют некоторые дополнения. При использовании IPv4-адресов субпоследовательность «iPAddress» в последовательности «GeneralName» должна в обязательном порядке включать восемь (8) октетов, которые закодированы в формате, определённом в стандарте RFC-4632, предназначенном для описания диапазонов IP-адресов. При использовании IPv6-адресов субпоследовательность «iPAddress» в последовательности «GeneralName» должна в обязательном порядке включать 32 октета, которые закодированы аналогичным способом. Например, ограничение на формат имён для подсети «192.0.2.0» класса С будет иметь вид следующей последовательности октетов «C0 00 02 00 FF FF FF 00», т.е. маска подсети «255.255.255.0», а префиксная форма — «192.0.2.0/24».

Дополнительные правила кодирования и обработки субполе «nameConstraints» будут представлены ниже.

Синтаксис и семантика ограничений для форматов имён «otherName» «ediPartyName» и «registeredID» в данном стандарте не рассматриваются. Тем не менее, синтаксис и семантика ограничений для иных форматов имён могут быть представлены в других документах.

id-ce-nameConstraints  OBJECT IDENTIFIER ::=  { id-ce 30 }

NameConstraints ::=  SEQUENCE {
     permittedSubtrees        [0]     GeneralSubtrees OPTIONAL,
     excludedSubtrees         [1]     GeneralSubtrees OPTIONAL }

GeneralSubtrees ::=  SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {
     base                    GeneralName,
     minimum         [0]     BaseDistance DEFAULT 0,
     maximum         [1]     BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)
2007 - 2017 © Русские переводы RFC, IETF, ISOC.