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

Уведомление

Icon
Error

9 Страницы«<6789>
Опции
К последнему сообщению К первому непрочитанному
Online two_oceans  
#141 Оставлено : 4 декабря 2019 г. 5:55:15(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 228 раз в 214 постах
Автор: Dmitriy_Zh Перейти к цитате
Служебный данные из трейса SignedXml
Преобразованный контент ссылки:
У этого фрагмента хэш совпадает с указанным в Reference, но у меня получилось другое значение с хэшем YEwZ+QB5G+8QrPaN1AqOXcyey1ky5dYNNyJX+XFJ+0w=.
Навскидку отличается тем что сам SenderProvidedRequestData у меня попал под смэвовский трансформ, а в Вашем примере не попал под трансформ.
Автор: Dmitriy_Zh Перейти к цитате
Выходные данные преобразования канонизации:
SignedInfo совпадает при проверке SignatureValue и с тем что получилось у меня.
Автор: Dmitriy_Zh Перейти к цитате
Данные которые сформировал клиент WCF для отправки:
Тут вообще невалидный xml - нет объявления префикса для Body (или просто Envelope куда-то делся, хотя вроде не нужны Body с Envelope). В целом, после добавления объявления, SignatureValue сошлось, а DigestValue нет.

Отредактировано пользователем 4 декабря 2019 г. 6:07:34(UTC)  | Причина: Не указана

Offline Dmitriy_Zh  
#142 Оставлено : 4 декабря 2019 г. 8:55:22(UTC)
Dmitriy_Zh

Статус: Участник

Группы: Участники
Зарегистрирован: 25.09.2019(UTC)
Сообщений: 12

Автор: two_oceans Перейти к цитате
Автор: Dmitriy_Zh Перейти к цитате
Служебный данные из трейса SignedXml
Преобразованный контент ссылки:
У этого фрагмента хэш совпадает с указанным в Reference, но у меня получилось другое значение с хэшем YEwZ+QB5G+8QrPaN1AqOXcyey1ky5dYNNyJX+XFJ+0w=.
Навскидку отличается тем что сам SenderProvidedRequestData у меня попал под смэвовский трансформ, а в Вашем примере не попал под трансформ.
Автор: Dmitriy_Zh Перейти к цитате
Выходные данные преобразования канонизации:
SignedInfo совпадает при проверке SignatureValue и с тем что получилось у меня.
Автор: Dmitriy_Zh Перейти к цитате
Данные которые сформировал клиент WCF для отправки:
Тут вообще невалидный xml - нет объявления префикса для Body (или просто Envelope куда-то делся, хотя вроде не нужны Body с Envelope). В целом, после добавления объявления, SignatureValue сошлось, а DigestValue нет.


Данные от WCF клиента я выбирал из трейса, там есть обёртка Envelope и Body. Просто их не стал добавлять.
По поводу трансформации не очень понятно, т.к передаю SenderProvidedRequestData на подпись.
Так же не понятно, по какой причине DigestValue может отличаться...
Сегодня сделаю формирование запроса в файл, чтобы WCF не влиял на конечный результат. Т.к пока не могу понять на этапе формирования данных ошибка или на этапе отправки данных.
По результатам отпишусь.

Online two_oceans  
#143 Оставлено : 4 декабря 2019 г. 10:06:34(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 228 раз в 214 постах
Автор: Dmitriy_Zh Перейти к цитате
По поводу трансформации не очень понятно, т.к передаю SenderProvidedRequestData на подпись.
Так же не понятно, по какой причине DigestValue может отличаться...
Хэш в Reference в итоговом файле совпадает с хэшем результата трансформации из SignedXml, то есть похоже после трансформации был верно посчитан хэш (но от другого результата трансформации и потому отличается) и без критических искажений как SignedInfo, так и подписанный фрагмент перешел в итоговый файл. Полагаю, это указывает именно на неправильный трансформ, далее сборка без искажений.

Отредактировано пользователем 4 декабря 2019 г. 10:18:08(UTC)  | Причина: P.S. приходится сохранять пустое сообщение и править чтобы форум не вылетал каждые несколько секунд

Offline Dmitriy_Zh  
#144 Оставлено : 4 декабря 2019 г. 10:44:29(UTC)
Dmitriy_Zh

Статус: Участник

Группы: Участники
Зарегистрирован: 25.09.2019(UTC)
Сообщений: 12

Автор: two_oceans Перейти к цитате
Автор: Dmitriy_Zh Перейти к цитате
По поводу трансформации не очень понятно, т.к передаю SenderProvidedRequestData на подпись.
Так же не понятно, по какой причине DigestValue может отличаться...
Хэш в Reference в итоговом файле совпадает с хэшем результата трансформации из SignedXml, то есть похоже после трансформации был верно посчитан хэш (но от другого результата трансформации и потому отличается) и без критических искажений как SignedInfo, так и подписанный фрагмент перешел в итоговый файл. Полагаю, это указывает именно на неправильный трансформ, далее сборка без искажений.


Мне удалось добиться прохождения проверки. Для этого полностью отказался от использования сгенерированных классов и написал всё руками.
Буду делать свою библиотеку для решения взаимодействия со СМЭВ. Из коробки не работает :(
Online two_oceans  
#145 Оставлено : 4 декабря 2019 г. 11:23:42(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 228 раз в 214 постах
В этой теме пару страниц назад вроде бы скидывали ссылку на один из проектов.

В целом да, вручную наше все, я в другой среде, но тоже пишу сам - сейчас вот думаю свой генератор сделать, чтобы не выписывать для каждой схемы элементы вручную. Один раз прочитать схему, сделать дамп в своем формате и по нему работать.
Offline Dmitriy_Zh  
#146 Оставлено : 4 декабря 2019 г. 12:13:54(UTC)
Dmitriy_Zh

Статус: Участник

Группы: Участники
Зарегистрирован: 25.09.2019(UTC)
Сообщений: 12

Автор: two_oceans Перейти к цитате
В этой теме пару страниц назад вроде бы скидывали ссылку на один из проектов.

В целом да, вручную наше все, я в другой среде, но тоже пишу сам - сейчас вот думаю свой генератор сделать, чтобы не выписывать для каждой схемы элементы вручную. Один раз прочитать схему, сделать дамп в своем формате и по нему работать.


У меня получилось выполнить в итоге эталонные запросы. Тестовый проект смотрел))) Но он реализован очень запутанно. Я для наших проектов буду делать библиотеку свою.
Самое сложное - подписать данные в правильном виде. Сейчас сделал это с помощью костылей. Хочу в ближайшие дни заставить работать автосгенерированный код
Online two_oceans  
#147 Оставлено : 4 декабря 2019 г. 12:41:16(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 228 раз в 214 постах

Отредактировано пользователем 4 декабря 2019 г. 13:02:57(UTC)  | Причина: Не указана

Offline HF_HF  
#148 Оставлено : 3 февраля 2020 г. 11:55:40(UTC)
HF_HF

Статус: Новичок

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

Сказал «Спасибо»: 5 раз
Поблагодарили: 1 раз в 1 постах
Автор: Dmitriy_Zh Перейти к цитате
Автор: two_oceans Перейти к цитате
В этой теме пару страниц назад вроде бы скидывали ссылку на один из проектов.

В целом да, вручную наше все, я в другой среде, но тоже пишу сам - сейчас вот думаю свой генератор сделать, чтобы не выписывать для каждой схемы элементы вручную. Один раз прочитать схему, сделать дамп в своем формате и по нему работать.


У меня получилось выполнить в итоге эталонные запросы. Тестовый проект смотрел))) Но он реализован очень запутанно. Я для наших проектов буду делать библиотеку свою.
Самое сложное - подписать данные в правильном виде. Сейчас сделал это с помощью костылей. Хочу в ближайшие дни заставить работать автосгенерированный код


Можно конечно было по проще написать, но тема сама по себе не простая. Рад если кому то помог пример кода. Ели бы еще где брали код поставили лайк. Было бы приятно и видно что код кому то помог)
Offline migel  
#149 Оставлено : 4 февраля 2020 г. 16:22:56(UTC)
migel

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Добрый день.
Продолжается наше хождение по граблям XML signing.
На днях при работе со СМЭВ 3 на некоторых документах начали получать ошибку проверки ЭОП.
Разбирательство с данными вывело нас на следующее.
1. В документе присутствует атрибут в значении которого есть символы < 0x20 (всеми любимые символы возврата каретки и перевода строки)
2. Доступные нам онлайн сервисы проверки GOST XmlDSig работают все по разному
а) КриптоПро - вставляет в смэв трансформеры бинарные символы 0x0d 0x0а (согласно поведению MS.NET XmlWriter) документ валидируется.
б) Тестовый контур GisGMP (https://smev3.gosuslugi.ru/portal/checkxmlform.jsp)занимается непонятно чем и не валидирует документ.
в) Реализация https://www.securitycode.ru/products/jinn-server/ при трансформации вставляет XML Entity reference (&#xD;&#xA;) и при соответствующих правках нашего трансформера документ тоже валидирует.

Возникает вопрос как поступать в этом случае. Как мне кажется правильный вариант - в по крайней мере каноникализация по C14N работает именно так.
Пример ИСХОДНОГО документа
SendRequestRequestNoAttach.xml (2kb) загружен 3 раз(а).
Пример подписанного документа со вставкой XmlEntity.
signed.xml (4kb) загружен 4 раз(а).
С уважением
Online two_oceans  
#150 Оставлено : 5 февраля 2020 г. 7:38:00(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 228 раз в 214 постах
Добрый день!
Немного странно, что форму проверки для СМЭВ 3 назвали как форму гис гмп. Все зависит от того, какие стандарты применены к документу. Общая мысль: C14N почти нигде не применяется в чистом виде, везде с дополнительными оговорками, подготовками или постобработками.

Для справки: из символов с кодом ниже пробела (32 или 0x20) в XML в принципе разрешены только символы с кодами 9, 10, 13 и никакие более. Если речь идет о нормализованном (в плане переводов строк) документе/фрагменте, то только символы 10 остаются в роли переводов строки. Сочетание 13+10 заменяется на 10, потом одиночные 13 заменяются на 10. Стандарт проверки электронной подписи подчеркивает, что фрагмент документа должен быть нормализован по переводам строк до передачи в C14N. Чистый алгоритм C14N действительно выдает &#xD; как каноническую форму символа с кодом 13, однако в случае электронной подписи 13 убираются в документе до C14N. Это совершенно точно касается всех текстовых узлов: кодов 13 нет ни в каком виде; коды 9,10, лишние пробелы - их обработка зависит от параметра PreserveWhitespace (причем не фигурирующего в подписи, только подбирать нужное значение методом тыка). Про значения атрибутов надо перечитать (там вообще головоломная система нормализации whitespace, возможно представление как &#x9; и так далее), все места кроме значений атрибутов и текстовых узлов "оптимизируются" в C14N - символов 9,10,13 не остается ни в каком представлении.

Аналогично стандарту подписи стандарт SOAP также отменяет часть возможностей XML и упрощает документ, поэтому соответствующие выкинутым возможностям пункты C14N даже теоретически не применяются. Переводов строк они не касаются, расписывать не буду.

Далее, в СМЭВ 3 создателям надоело маяться с 9,10,13 и после C14N введен обязательный дополнительный трансформ до вычисления хэша. Один из пунктов обязательного трансформа: любые текстовые узлы состоящие только из символов 9,10,13 удаляются, то есть неопределенность с PreserveWhitespace почти обнулена. Почти - потому что любое значение можно обрамить 9,10,13, но это можно окончательно запретить благонамеренной схемой пространства имен. Другой пункт требований СМЭВ 3 гласит, что в самом фрагменте документа соответствующем SignedInfo и его потомкам переводы строк запрещены. Поэтому конечно без выполнения трансформа и требований проверить подпись не получится.

Отредактировано пользователем 5 февраля 2020 г. 8:58:06(UTC)  | Причина: Не указана

thanks 1 пользователь поблагодарил two_oceans за этот пост.
migel оставлено 05.02.2020(UTC)
Offline migel  
#151 Оставлено : 5 февраля 2020 г. 9:37:37(UTC)
migel

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате
Добрый день!

Для справки: из символов с кодом ниже пробела (32 или 0x20) в XML в принципе разрешены только символы с кодами 9, 10, 13 и никакие более.


Пожалуйста не надо справочной информации из стандатров XML Processing и C14N к ним вопросов нет
Автор: two_oceans Перейти к цитате

Про значения атрибутов надо перечитать (там вообще головоломная система нормализации whitespace, возможно представление как &#x9; и так далее), все места кроме значений атрибутов и текстовых узлов "оптимизируются" в C14N - символов 9,10,13 не остается ни в каком представлении.

Если Вы заметили речь идет именно о значении атрибута про текстовые узлы вопросов нет - в методических рекомендациях про них написано все достаточно конкретно.

Автор: two_oceans Перейти к цитате

Другой пункт требований СМЭВ 3 гласит, что в самом фрагменте документа соответствующем SignedInfo и его потомкам переводы строк запрещены. Поэтому конечно без
выполнения трансформа и требований проверить подпись не получится.

Applause
Спасибо за пересказ методических рекомендаций пIV приложение А методических рекомендаций.
Ну а теперь по пунктам
1. В каком конкретно пункте введен запрет на перевод строки в значении атрибута?
2. Трансформ согласно тому же приложению применяется к нужному узлу.
3. В тексте было приведено три реализации по разному обрабатывающие один и тот же документ и если А и В понять можно и можно даже добиться того что они пораздельно будут валидировать документ с указанным значением атрибута то с п Б (https://smev3.gosuslugi.ru/portal/checkxmlform.jsp)
вообще непонятно какие трансформации нужно проводить со значением атрибута.
Не работает:
1 Простое выкидывание таких символов
2 замена 0x13 на 0x10
3 замена 0x13 на &#A;
Собственно вопрос состоит в том что делать то?
Особо драматически выглядит сценарий когда документ передается по цепочке обработчиков:
например Московское правительство использует JINI-SERVER (Тип В моего сообщения) и далее передает это сообщение в федеральные структуры (Тип Б)

Отредактировано пользователем 5 февраля 2020 г. 9:38:31(UTC)  | Причина: Не указана

Offline migel  
#152 Оставлено : 5 февраля 2020 г. 16:12:27(UTC)
migel

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Согласно стандарту процессинга XML
https://www.w3.org/TR/2008/REC-xml-20081126/ пп 3.3.3

Цитата:

3.3.3 Attribute-Value Normalization

Before the value of an attribute is passed to the application or checked for validity, the XML processor MUST normalize the attribute value by applying the algorithm below, or by using some other method such that the value passed to the application is the same as that produced by the algorithm.

All line breaks MUST have been normalized on input to #xA as described in 2.11 End-of-Line Handling, so the rest of this algorithm operates on text normalized in this way.

Begin with a normalized value consisting of the empty string.

For each character, entity reference, or character reference in the unnormalized attribute value, beginning with the first and continuing to the last, do the following:

1. For a character reference, append the referenced character to the normalized value.
2. For an entity reference, recursively apply step 3 of this algorithm to the replacement text of the entity.
3. For a white space character (#x20, #xD, #xA, #x9), append a space character (#x20) to the normalized value.
4. For another character, append the character to the normalized value.


и https://www.w3.org/TR/xmldsig-core1/#sec-ReferenceGeneration
пп 7.1
Цитата:

XML 1.0 defines an interface where a conformant application reading XML is given certain information from that XML and not other information. In particular,

1. line endings are normalized to the single character #xA by dropping #xD characters if they are immediately followed by a #xA and replacing them with #xA in all other cases,
2. missing attributes declared to have default values are provided to the application as if present with the default value,
3. character references are replaced with the corresponding character,
4. entity references are replaced with the corresponding declared entity,
5. attribute values are normalized by
5.1 replacing character and entity references as above,
5.2 replacing occurrences of #x9, #xA, and #xD with #x20 (space) except that the sequence #xD#xA is replaced by a single space, and
5.3 if the attribute is not declared to be CDATA, stripping all leading and trailing spaces and replacing all interior runs of spaces with a single space.

Note that items (2), (4), and (5.3) depend on the presence of a schema, DTD or similar declarations. The Signature element type is laxly schema valid [XMLSCHEMA-1][XMLSCHEMA-2], consequently external XML or even XML within the same document as the signature may be (only) well-formed or from another namespace (where permitted by the signature schema); the noted items may not be present. Thus, a signature with such content will only be verifiable by other signature applications if the following syntax constraints are observed when generating any signed material including the SignedInfo element:

attributes having default values be explicitly present,
all entity references (except "amp", "lt", "gt", "apos", "quot", and other character entities not representable in the encoding chosen) be expanded,
attribute value white space be normalized

Получается что мы вступили в несовместимость реализации процессоров XML.
Майкрософтовский ридер XML не выполняет п 3 нормализации атрибутов.

Исходя из всего получается что для совместимости нужно корежить исходные данные.
thanks 1 пользователь поблагодарил migel за этот пост.
two_oceans оставлено 06.02.2020(UTC)
Online two_oceans  
#153 Оставлено : 6 февраля 2020 г. 9:18:23(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 228 раз в 214 постах
Спасибо за цитаты. Общая мысль выходит правильно мной понята - до C14N символы 13 просто не доходят.
Цитата:
это можно окончательно запретить благонамеренной схемой пространства имен.
Мне очень интересно какая схема пространства имен (совместимого со СМЭВ 3) вообще Вам разрешает добавлять символы перевода строки в атрибуты. Если даже взять пример из Вашего сообщения выше: добавили атрибут к тегу TestMessage, однако насколько я помню этот элемент вообще без атрибутов, то есть даже если пройдете этап контроля подписи, то асинхронная проверка СМЭВ (не через тестовый автоответчик) даст ошибку ФЛК.
Цитата:
Получается что мы вступили в несовместимость реализации процессоров XML.
Майкрософтовский ридер XML не выполняет п 3 нормализации атрибутов.

Исходя из всего получается что для совместимости нужно корежить исходные данные.
Думаю, тут Вы правы. У всех процессоров есть несоответствия стандарту, просто потому что некоторые пункты стандарта в реальности встречаются очень редко (мало кому нужно в атрибуте передать многострочное стихотворение) и некому сообщить авторам о баге. Да и Майкрософт редко к кому прислушивается (вот если бы Вы предложили путь как с помощью перевода строки получить удаленный контроль над системой, тогда возможно).

К слову, какая версия .NET? Как я слышал, в 4.5 было много исправлений C14N, а более ранние вообще давали много несоответствий стандарту.
Цитата:
Особо драматически выглядит сценарий когда документ передается по цепочке обработчиков:
например Московское правительство использует JINI-SERVER (Тип В моего сообщения) и далее передает это сообщение в федеральные структуры (Тип Б)
В таком случае общая практика наседать на региональное правительство, чтобы обработка была по федеральным стандартам (даже если им придется вставлять костыли). В моей области я как правило нахожу общий язык с министерством, курирующим Р-СМЭВ.

Отредактировано пользователем 6 февраля 2020 г. 9:37:27(UTC)  | Причина: Не указана

Offline migel  
#154 Оставлено : 6 февраля 2020 г. 9:37:28(UTC)
migel

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате
Если даже взять пример из Вашего сообщения выше: добавили атрибут к тегу TestMessage, однако насколько я помню этот элемент вообще без атрибутов, то есть даже если пройдете этап контроля подписи, то асинхронная проверка СМЭВ (не через тестовый автоответчик) даст ошибку ФЛК.

Это чисто синтетический пример для экспериментов с трансформером.
Автор: two_oceans Перейти к цитате

К слову, какая версия .NET? Как я слышал, в 4.5 было много исправлений C14N, а более ранние вообще давали много несоответствий стандарту.

мнээээ Think
переписано врукопашную под 3.5-4+,mono .core валидировали по набору данных w3c (http://www.w3.org/TR/xmldsig2ed-tests).

P.S. насчет символа 0x13 кстати стандарт (https://www.w3.org/TR/xml11/#NT-Char)говорит прямо (для XML 1.0
написано тоже самое https://www.w3.org/TR/REC-xml/)
Цитата:

2.3 Common Syntactic Constructs

This section defines some symbols used widely in the grammar.

S (white space) consists of one or more space (#x20) characters, carriage returns, line feeds, or tabs.
White Space
[3] S ::= (#x20 | #x9 | #xD | #xA)+

Note:

The presence of #xD in the above production is maintained purely for backward compatibility with the First Edition. As explained in 2.11 End-of-Line Handling, all #xD characters literally present in an XML document are either removed or replaced by #xA characters before any other processing is done. The only way to get a #xD character to match this production is to use a character reference in an entity value literal.

Отредактировано пользователем 6 февраля 2020 г. 10:07:41(UTC)  | Причина: Добавлена ссылка на стандарт XML 1.0

thanks 1 пользователь поблагодарил migel за этот пост.
two_oceans оставлено 06.02.2020(UTC)
Offline migel  
#155 Оставлено : 6 февраля 2020 г. 10:39:11(UTC)
migel

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате
Мне очень интересно какая схема пространства имен (совместимого со СМЭВ 3) вообще Вам разрешает добавлять символы перевода строки в атрибуты.

http://rnip.mos.ru/xsd/Common/2.0.1
Цитата:

<xsd:attribute name="name" type="xsd:string" use="required">
<xsd:annotation>
<xsd:documentation>Наименование</xsd:documentation>
</xsd:annotation>

Насколько я понял из стандарта оно не запрещает задание пробельных символов через ссылки на них.
Online two_oceans  
#156 Оставлено : 6 февраля 2020 г. 11:16:24(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 228 раз в 214 постах
Похоже я невнимательно читал это примечение про 13.
Автор: migel Перейти к цитате
http://rnip.mos.ru/xsd/Common/2.0.1
мне выдает 403 Forbidden но нашлась в яндексе методичка
Автор: migel Перейти к цитате
Цитата:

<xsd:attribute name="name" type="xsd:string" use="required">
<xsd:annotation>
<xsd:documentation>Наименование</xsd:documentation>
</xsd:annotation>
Насколько я понял из стандарта оно не запрещает задание пробельных символов через ссылки на них.
О, тогда это повод посмотреть еще и определение xsd:string. Хотя наверное и правда не запрещает раз уже не рекомендовано в XML 1.1. С другой стороны, почему в наименовании переводы строки? С третьей, почему не использовать переводы строк в стиле Linux (только 10 без 13)?

Отредактировано пользователем 6 февраля 2020 г. 11:37:20(UTC)  | Причина: Не указана

Offline migel  
#157 Оставлено : 6 февраля 2020 г. 11:28:27(UTC)
migel

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате
xsd.zip (52kb) загружен 1 раз(а).

О, тогда это повод посмотреть еще и определение xsd:string. Хотя наверное и правда не запрещает раз уже не рекомендовано в XML 1.1. С другой стороны, почему в наименовании переводы строки? С третьей, почему не использовать переводы строк в стиле Linux (только 10 без 13)?


да не вопрос
https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/datatypes.html#string
Цитата:

The ·value space· of string is the set of finite-length sequences of zero or more characters (as defined in [XML]) that ·match· the Char production from [XML]. A character is an atomic unit of communication; it is not further specified except to note that every character has a corresponding Universal Character Set (UCS) code point, which is an integer.

It is ·implementation-defined· whether an implementation of this specification supports the Char production from [XML], or that from [XML 1.0], or both. See Dependencies on Other Specifications (§1.3).

Equality for string is identity. No order is prescribed.
Note: As noted in ordered, the fact that this specification does not specify an order relation for ·string· does not preclude other applications from treating strings as being ordered.

дополнительно
https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/datatypes.html#rf-whiteSpace
Цитата:

4.3.6 whiteSpace

[Definition:] whiteSpace constrains the ·value space· of types ·derived· from string such that the various behaviors specified in Attribute Value Normalization in [XML] are realized. The value of whiteSpace must be one of {preserve, replace, collapse}.
1 preserve
No normalization is done, the value is not changed (this is the behavior required by [XML] for element content)
2 replace
All occurrences of #x9 (tab), #xA (line feed) and #xD (carriage return) are replaced with #x20 (space)
3 collapse
After the processing implied by replace, contiguous sequences of #x20's are collapsed to a single #x20, and any #x20 at the start or end of the string is then removed.
Note: The notation #xA used here (and elsewhere in this specification) represents the Universal Character Set (UCS) code point hexadecimal A (line feed), which is denoted by U+000A. This notation is to be distinguished from &#xA;, which is the XML character reference to that same UCS code point.

whiteSpace is applicable to all ·atomic· and ·list· datatypes. For all ·atomic· datatypes other than string (and types ·derived· by ·facet-based restriction· from it) the value of whiteSpace is collapse and cannot be changed by a schema author; for string the value of whiteSpace is preserve; for any type ·derived· by ·facet-based restriction· from string the value of whiteSpace can be any of the three legal values (as long as the value is at least as restrictive as the value of the ·base type·; see Constraints on whiteSpace Schema Components (§4.3.6.4)). For all datatypes ·constructed· by ·list· the value of whiteSpace is collapse and cannot be changed by a schema author. For all datatypes ·constructed· by ·union· whiteSpace does not apply directly; however, the normalization behavior of ·union· types is controlled by the value of whiteSpace on that one of the ·basic members· against which the ·union· is successfully validated.
Note: For more information on whiteSpace, see the discussion on white space normalization in Schema Component Details in [XSD 1.1 Part 1: Structures].

·whiteSpace· provides for:

Замечательно "for string the value of whiteSpace is preserve;"

то есть все таки референсы на переводы строки допустимы.

Отредактировано пользователем 6 февраля 2020 г. 11:31:55(UTC)  | Причина: Не указана

Online two_oceans  
#158 Оставлено : 6 февраля 2020 г. 12:04:02(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 228 раз в 214 постах
Ну... все логично тогда. Майкрософт использует preserve потому что значение конкретного атрибута это xsd:string. XMLDSIG же требует collapse для всех атрибутов перед C14N. То есть майкрософт не учитывает что на ее нормализацию будут полагаться при проверке подписи.

СМЭВ скорее всего учитывает XMLDSIG и делает collapse. Джинн похоже вообще не читали половину стандартов и шпарят чистый C14N. Полагаю, будет правильно обратиться к региональной ИС или разработчикам Джинн чтобы добавили collapse перед передачей в C14N. И самим добавить collapse после майкрософтовской нормализации. Или согласовать с Криптопро этот нюанс. Так выполнится большее число стандартов.

Отредактировано пользователем 6 февраля 2020 г. 12:17:31(UTC)  | Причина: Не указана

Offline migel  
#159 Оставлено : 6 февраля 2020 г. 12:57:17(UTC)
migel

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате

СМЭВ скорее всего учитывает XMLDSIG и делает collapse.

Не подтверждается (модификацией трансформа смыва)
тестовый прогон с collapse поведением - то есть заменой [0x10,0x13]->0x20
и уборкой лидирующих/завершающих пробелов
документ не валидируется
Цитата:

ЭП-ОВ не подтверждена: #SIGNED_BY_CONSUMER Ошибка проверки ЭП: Нарушена целостность ЭП

при замене 0xd->0xa результат аналогичный

Похоже я всех обманул (включая самого себя)Liar
В общем да СМЭВ collapse traits для xsd:string
замена на пробелы работает

Отредактировано пользователем 6 февраля 2020 г. 13:38:50(UTC)  | Причина: Не указана

Online two_oceans  
#160 Оставлено : 6 февраля 2020 г. 13:20:09(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 63 раз
Поблагодарили: 228 раз в 214 постах
Автор: migel Перейти к цитате
Не подтверждается (модификацией трансформа смыва)
тестовый прогон с collapse поведением - то есть заменой [0x10,0x13]->0x20
и уборкой лидирующих/завершающих пробелов
документ не валидируется
Там еще и замена подряд идущих на один пробел. Мне кажется что может быть проблема с порядком действий, трансформ смэва выполняется после каноникализации, то есть до него тем более 13 не дойдут. Вообще я предполагаю, что смэв валидирует через Джаву с применением КриптоПро, то есть чем гадать все варианты можно как первое приближение посмотреть поведение адаптера на Джаве. Я тоже попробую варианты на тестовой форме смэв 3.

Отредактировано пользователем 6 февраля 2020 г. 13:21:04(UTC)  | Причина: Не указана

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