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.4. Отображение ИРНА

ИРНА-идентификаторы представляют собой дополнение, основанное на национальных алфавитах, к URI-идентификатору. ИРНА-идентификаторы — это последовательности символов Юникода, в то время как URI-идентификаторы — это последовательность символов ASCII-кода. Стандарт RFC-3987 устанавливает правила отображения ИРНА-идентификаторов в URI-идентификаторы. Несмотря на то, что ИРНА-идентификаторы не кодируются непосредственно в полях или расширениях сертификатов, являющиеся их отображением URI-идентификаторы могут включаться в сертификаты и СОС. URI-идентификаторы могут быть включены в субполя «subjectAltName», «issuerAltName», «nameConstraints», «authorityInfoAccess», «subjectInfoAccess» и «cRLDistributionPoints» поля «Расширения» сертификата, последовательности «authorityInformationAccess» и «issuingDistributionPoint» субполя «crlExtensions» («Расширения СОС»). Каждое из этих расширений использует формат обобщённых имён «GeneralName». URI-идентификаторы размещаются в последовательности «uniformResourceIdentifier» в формате «GeneralName», который кодируется как «IA5String».

Для включения ИРНА-идентификаторов в рассматриваемую структуру, прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны преобразовывать ИРНА-идентификаторы в URI-идентификаторы, как это определено в параграфе 3.1 стандарта RFC-3987, с учётом следующих изменений:

  • На первой итерации, формируем последовательность UCS-символов из оригинального ИРНА-формата в соответствие с NFC-формой, как это определено Вариантом «b» в «Форматах нормирования Юникода».

  • Выполняем вторую итерацию, использую выходные данные первой итерации.

Прикладные системы и ИТС обязаны не преобразовывать компонент «ireg-name» до выполнения второй итерации.

Прежде чем URI-идентификаторы будут сравниваться, прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны провести комбинацию процедур по их нормированию на основе правил синтаксиса и схемы построения, которые установлены стандартом RFC-3987. А именно, прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны подготовить URI-идентификаторы для их сравнения следующим образом:

  • Первая итерация. Там, где ИРНА-идентификаторы позволяют использовать ИСНА, следует, в обязательном порядке, преобразовать такие наименования в последовательность ACE-маркеров, как это определено в 7.2.

  • Вторая итерация. Схема построения и наименование IP-узла нормируются в нижний регистр, как это определено в параграфе 5.3.2.1 стандарта RFC-3987.

  • Третья итерация. Производим перекодировку октетов в шестнадцатеричный код, как это определено в параграфе 5.3.2.3 стандарта RFC-3987.

  • Четвёртая итерация. Производим нормирование (удаление) сегмента маршрута, разделённого точками («.» и «..»), как это определено в параграфе 5.3.2.3 стандарта RFC-3987.

  • Пятая итерация. Если URI-идентификаторы установлены (определены их схемы построения), то прикладной процесс обязан провести их нормирование по правилам схемы построения таких идентификаторов, как это определено в параграфе 5.3.3 стандарта RFC-3987.

Прикладные системы и ИТС, придерживающиеся данного стандарта, обязаны распознавать и нормировать на основе правил построения схемы идентификации следующие схемы: «LDAP», «HTTP», «HTTPS» и «FTP». Если схема не распознана, то пятая итерация исключается.

Если проводится сравнение эквивалентных URI-идентификаторов, то целесообразно, чтобы прикладные системы и ИТС, придерживающиеся данного стандарта, осуществляли сравнение в режиме игнорирования регистра написания символов.

Целесообразно, чтобы прикладные системы и ИТС осуществляли преобразование URI-идентификаторов в Юникод, перед их отображением на дисплее. В частности, целесообразно, чтобы прикладные системы и ИТС, придерживающиеся данного стандарта, осуществляли такое преобразование в соответствие с правилами, представленными в параграфе 3.2 стандарта RFC-3987.

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