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

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-символов с целью указания одиночного международного символа.

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