Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы<12
Опции
К последнему сообщению К первому непрочитанному
Offline migel  
#11 Оставлено : 15 октября 2020 г. 11:10:11(UTC)
migel

Статус: Активный участник

Группы: Участники
Зарегистрирован: 30.01.2019(UTC)
Сообщений: 43
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате
Ну этот пример определенно еще более неудачный - сейчас считанные единицы ПО, которое его сможет валидировать. Проблема даже не в XPath, а в чудесной мысли авторов схемы ПФР, записавших пф.рф и далее кириллицей в объявления пространств имен. Фокус в том, что кириллица в таком месте документа не входит в стандарт RFC, есть примечание в стандарте в духе "если технически сможете использовать национальный алфавит - используйте, но это не регламентируется данным стандартом".

Согласно стандарту rfc3986
1.2. Design Considerations
1.2.1. Transcription
Цитата:

In local or regional contexts and with improving technology, users
might benefit from being able to use a wider range of characters;
such use is not defined by this specification. Percent-encoded
octets (Section 2.1) may be used within a URI to represent characters
outside the range of the US-ASCII coded character set if this
representation is allowed by the scheme or by the protocol element in
which the URI is referenced. Such a definition should specify the
character encoding used to map those characters to octets prior to
being percent-encoded for the URI.

Прямого запрета нет и согласно рекомендациям W3C а так как енкодинг у нас в файле задан то все согласно стандартаThink .
Namespaces in XML 1.0 (Third Edition)
Пространства имен должны быть нормализованы согласно Extensible Markup Language (XML) 1.0 (Fifth Edition)
Libxml в разборе URI (uri.c) жестко завязан на ascii (макро ISA_PCHAR) и не учитывает енкодинг документа вообще.
Можно конечно попробывать все такие ури нормализовать перед подписанием. d'oh!
P.S и да с enveloped трансформом все валидируется...Anxious

Отредактировано пользователем 15 октября 2020 г. 11:17:38(UTC)  | Причина: Не указана

Offline two_oceans  
#12 Оставлено : 16 октября 2020 г. 7:43:07(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Не запрещена, да, просто не регламентирована этим RFC потому какой смысл его цитировать?
Цитата:
users might benefit from being able to use a wider range of characters; such use is not defined by this specification.
Соль в этой фразе (открестились от национальных алфавитов, предложив разработать новый RFC если кто заинтересован). Остальная часть цитаты просто размышления авторов RFC, так как дальше они замечательным образом поясняют, что если использовать Percent-encoded, то использовать вообще везде. Визуально браузер может быть будет заменять по указанной кодировке на кириллицу, но сравниваться при форматно-логическом контроле схемы и фактически быть указаны в документе должны именно процентики (в случае такой выбранной кодировки) без всякой замены на кириллицу. Причина: преобразования перед сравнением запрещены, как есть в документе - так и сравниваются, то есть с процентиками и кириллицей - это две большие разницы.

ПФР никакой кодировки процентами не выбрал, punycode не выбрал, фактически простые парни написали кириллицу Юникодом (так как при подписании все кодировки приводятся к UTF-8, не буду заострять внимание на кодировке именно исходного документа). Поэтому случай с ПФР явно относится к той фразе "such use is not defined by this specification".

Цитата:
Пространства имен должны быть нормализованы согласно Extensible Markup Language (XML) 1.0 (Fifth Edition)
Libxml в разборе URI (uri.c) жестко завязан на ascii (макро ISA_PCHAR) и не учитывает енкодинг документа вообще. Можно конечно попробовать все такие ури нормализовать перед подписанием.
Конечно виртуозно Вы разные редакции приводите, одно из третьей, другое из пятой, сама подпись вообще из первой. Но не суть, нормализация ровно ничего не даст - там в основном меняются переводы строк и мнемоники. Остальные символьные референсы, внешние ссылки, инструкции обработки и т.д. запрещены стандартом SOAP. В остальном "For another character, append the character to the normalized value." Кириллица как раз попадает в "another character", (потому собственно и удалось ее туда вписать) - будет пропущена без изменений.
Цитата:
P.S и да с enveloped трансформом все валидируется
Это уже интереснее, по есть с пф.рф и enveloped все нормально?

Отредактировано пользователем 16 октября 2020 г. 7:47:38(UTC)  | Причина: Не указана

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы<12
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.