Существуют устаревшие прикладные системы, в которых адрес электронной почты встроен в уникальное имя владельца сертификата в качестве атрибута типа «emailAddress» (4.1.2.6). Когда на имена формата .html822Name» наложено ограничение, но сертификат не включает альтернативное имя владельца сертификата (субполе «subjectAltName» поля «Расширения»), тогда на атрибут типа «emailAddress» в составе уникального наименования владельца сертификата должно в обязательном порядке распространяться ограничение на имена формата .html822Name». В Приложении А представлен 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)