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

Уведомление

Icon
Error

19 Страницы«<1415161718>»
Опции
К последнему сообщению К первому непрочитанному
Offline migel  
#151 Оставлено : 5 февраля 2020 г. 9:37:37(UTC)
migel

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

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

Сказал(а) «Спасибо»: 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)
Сообщений: 43
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 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)
Offline two_oceans  
#153 Оставлено : 6 февраля 2020 г. 9:18:23(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Спасибо за цитаты. Общая мысль выходит правильно мной понята - до 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)
Сообщений: 43
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 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)
Сообщений: 43
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 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>

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

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Похоже я невнимательно читал это примечение про 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)
Сообщений: 43
Российская Федерация
Откуда: Москва

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

О, тогда это повод посмотреть еще и определение 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)  | Причина: Не указана

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

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Ну... все логично тогда. Майкрософт использует 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)
Сообщений: 43
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 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)  | Причина: Не указана

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

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

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

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

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

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