7.2. Отображение ИСНА в обобщённые имена «GeneralName»
ИСНА могут содержаться в сертификатах и СОС, а именно в субполях «subjectAltName», «issuerAltName», «nameConstraints», «subjectInfoAccess», «authorityInfoAccess» и «cRLDistributionPoints» поля «Расширения» сертификата, в последовательностях «authorityInformationAccess» и «issuingDistributionPoint» субполя «crlExtensions» («Расширения СОС»). Каждое из этих расширений использует формат обобщённых имён «GeneralName». Единственным вариантом обобщённого имени «GeneralName» является dNSName-формат с соответствующей кодировкой «IA5String».
Кодировка «IA5String» ограничивается совокупностью ASCII-символов. Для адаптации ИСНА к текущему формату, прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны преобразовывать ИСНА, перед тем как сохранить его в поле «dNSName», в формат кодирования, совместимый с ASCII-кодом (ASCII Compatible Encoding — ACE), как это определено в параграфе 4 стандарта RFC-3490. А именно, прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны провести процедуру преобразования, как это определено в параграфе 4 стандарта RFC-3490, с учётом следующих изменений:
На первой итерации, целесообразно, чтобы наименование сегмента/области рассматривалось, как «сохраняемая последовательность символов» («stored string»). Т.е. флаг «AllowUnassigned» не должен быть установлен.
На третьей итерации, устанавливаем флаг, именуемый как «UseSTD3ASCIIRules».
На четвёртой итерации, обрабатываем каждый маркер с помощью операции «ToASCII».
На пятой итерации, изменяем все разделители в последовательности маркеров на код «U+002E» (далее полная остановка).
Когда сравниваются DNS-имена на предмет их совпадения, прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны провести процедуру точного сравнения всего DNS-имени в режиме игнорирования регистра написания символов. Когда анализируется субполе «nameConstraints», прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны провести процедуру точного последовательного сравнения маркеров (label-by-label basis) в режиме игнорирования регистра написания символов. Как было отмечено в 4.2.1.10, любое DNS-имя, которое может быть сформировано путём добавления маркеров с левой стороны наименования сегмента/области, являющегося запрещённым, считается неприемлемым в рамках указанного субдерева.
Целесообразно, чтобы прикладные системы и ИТС отображали ИСНА в Юникод (Unicode), перед тем, как выводить ИСНА на дисплей. А именно, целесообразно, чтобы прикладные системы и ИТС, придерживающиеся данного стандарта, проводили процедуру преобразования, представленную в параграфе 4 стандарта RFC-3490, с учётом следующих изменений:
На первой итерации, целесообразно, чтобы наименование сегмента/области рассматривалось, как «сохраняемая последовательность символов». Т.е. флаг «AllowUnassigned» не должен быть установлен.
На третьей итерации, устанавливаем флаг, именуемый как «UseSTD3ASCIIRules».
На четвёртой итерации, обрабатываем каждый маркер с помощью операции «ToASCII».
Переход на пятую итерацию.
Примечание. Прикладные системы и ИТС обязаны признавать расширение диапазона требований в интересах ИСНА. ACE-маркер в ИСНА будет начинаться с четырёх дополнительных символов «xn--» и может потребовать и более пяти ASCII-символов с целью указания одиночного международного символа.