XmlDSig: эталонная модель обработки (набор узлов и поток октетов)

Я изучаю расширенные электронные подписи XML .

Для создания «ArchiveTimeStamp» (стр. 58) в Спецификации указано:

Обработайте полученный элемент ds:Reference в соответствии с эталонной моделью обработки XMLDSIG.

Если результатом является набор узлов XML, канонизируйте его. (...)

Эталонная модель обработки завершена:

<ds:Reference Id="myId" URI="http://fakefile.xml">
    <ds:Transforms>
        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    </ds:Transforms>
    <ds:DigestMethod/>
    <ds:DigestValue/>
</ds:Reference>

Процесс использует "URI=..." и "ds:Transforms" для извлечения данных.

Ниже приведены некоторые части, извлеченные из (4.3.3.2 Эталонная модель обработки ):

Типом данных результата разыменования URI или последующих преобразований является либо поток октетов, либо набор узлов XPath. (...)

В этой спецификации ссылка на тот же документ определяется как ссылка URI, которая состоит из знака решетки ('#'), за которым следует фрагмент, или, альтернативно, состоит из пустого URI (...)

Если URI-Reference не является такой ссылкой на тот же документ, результатом разыменования URI-Reference ДОЛЖЕН быть поток октетов. В частности, документ XML, идентифицированный URI, не анализируется приложением подписи, если URI не является ссылкой на тот же документ или если не применяется преобразование, требующее анализа XML.

В следующих примерах показано, что идентифицирует атрибут URI и как он разыменовывается:

URI="http://example.com/bar.xml"
Идентифицирует октеты (...)

URI="http://example.com/bar.xml#chapter1"
Идентифицирует элемент со значением атрибута ID 'chapter1' внешнего ресурса XML (...), предоставленного в виде потока октетов. (...)

URI=""
Идентифицирует набор узлов (...)

URI="#chapter1"
Идентифицирует набор узлов, содержащий (...)

Вопрос.

Для этих ссылок:

<ds:Reference Id="myId" URI="http://fakefile.xml">
...
(empty transform list)
...
</ds:Reference>

Результат 1#: ( <file> ... childs ... <file> ). Без применения дайджест-преобразования

<ds:Reference Id="myId" URI="http://fakefile.xml">
...
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
...
</ds:Reference>

Результат 2#: (xml with exc-c14n). Без применения дайджест-преобразования

<ds:Reference Id="myId" URI="http://fakefile.xml">
...
<ds:Transform "fake_Xpath_transform_to_get_all_childs"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
...
</ds:Reference>

Результат 3#: (только дочерние элементы с exc-c14n <child_1/>...<child_x/>) Без применения преобразования дайджеста. Это недопустимый XML-файл для анализа, не имеет единого корня. Но может быть «набор узлов» в контексте fakefile.xml.

Являются ли результаты (1#, 2# и 3#) "потоком октетов"?

Потому что: Если URI-Reference не является ссылкой на тот же документ, результатом разыменования URI-Reference ДОЛЖЕН быть поток октетов.

Или они являются "набором узлов XML", требуемым расширенными электронными подписями XML для канонизации?

Потому что: (...) В частности, XML-документ, идентифицированный URI, не анализируется приложением подписи, если URI не является ссылкой на тот же документ или если не применяется преобразование, требующее анализа XML.

Или (если не применяется преобразование, требующее синтаксического анализа XML) допустимо только в контексте ссылки, а результаты представляют собой поток октетов?

Статьи приветствуются.


xml cryptography xml-signature xml-dsig xades4j
person Cobaia    schedule 29.08.2013    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Все они представляют собой потоки октетов, т. е. двоичные, но обработка отличается.

Помимо раздела Эталонная модель обработки, также рассмотрите раздел Преобразование элемента для следующего объяснения.

1: поскольку http://fakefile.xml не является ссылкой на один и тот же документ и:

Если URI-Reference не является такой ссылкой на тот же документ, результатом разыменования URI-Reference ДОЛЖЕН быть поток октетов.

Поскольку преобразований нет, этот поток октетов является входом для вычисления дайджеста.

2: как указано в 1 http://fakefile.xml. не является одной и той же ссылкой на документ, поэтому входными данными для преобразований является поток октетов.

Поскольку преобразование канонизации работает с узлами XML, его ввод необходимо преобразовать в узел XML. set, как указано в разделе Эталонная модель обработки:

Если объект данных представляет собой поток октетов, а для следующего преобразования требуется набор узлов, приложение подписи ДОЛЖНО попытаться разобрать октеты, получив требуемый набор узлов, посредством корректной обработки [XML].

Выходом преобразования канонизации является поток октетов по определению.

3: как указано в 1 http://fakefile.xml. не является одной и той же ссылкой на документ, поэтому входными данными для преобразований является поток октетов.

Преобразование XPath работает с узлами XML, что означает, что поток октетов должен быть преобразован в набор узлов (снова указано в разделе Фильтрация XPath). Результатом преобразования XPath также является набор узлов.

Следующее преобразование — это канонизация, для которой в качестве входных данных требуется заданный узел XML. Поскольку входы/выходы объединены в цепочку (раздел Transforms element), а предыдущий вывод уже был набором узлов, преобразование не требуется.

Наконец, выходом преобразования канонизации является поток октетов по определению.

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

Надеюсь это поможет.

person lgoncalves    schedule 30.08.2013
comment
Вы говорите, что: (Первый случай) Если у меня есть внешний URI fakefile.xml без преобразований, это поток октетов в ArchiveTimeStamp. (второй случай) Тот же самый первый случай с одним преобразованием XPath, это набор узлов. Но если ArchiveTimeStamp имеет преобразование exc-c14n, может ли быть установлен первый узел case? - person Cobaia; 03.09.2013
comment
Преобразование канонизации, указанное в ArchiveTimeStamp, применяется только в том случае, если входные данные представляют собой набор узлов (при создании входной метки времени). Это не имеет ничего общего с самой обработкой ссылок. - person lgoncalves; 03.09.2013
comment
Пример модели обработки ссылок URI=example.com/bar.xml#chapter1 Идентифицирует элемент со значением атрибута ID 'chapter1' внешнего XML-ресурса 'example.com/bar.xml', предоставляется как поток октетов. Предоставляется ли глава 1 в виде потока октетов? Может ли быть указана только ссылка на тот же документ? - person Cobaia; 03.09.2013
comment
Я думаю, что это будет элемент с идентификатором #chapter1, представленный в виде потока октетов. Если URI-Reference не является такой ссылкой на тот же документ, результатом разыменования URI-Reference ДОЛЖЕН быть поток октетов. Это означает, что наборы узлов получаются только из ссылок на один и тот же документ. Другой способ получить наборы узлов — анализ потоков октетов для ввода преобразования. Обратите внимание, что спецификация не рекомендует использовать фрагменты ради совместимости, поскольку это зависит от MIME-типа ресурса, а реализации могут различаться. - person lgoncalves; 04.09.2013
comment
Итак, внешний URI с потоком октетов преобразования или без него? Или внешний URI=fakefile.xml#child1 результирующий поток октетов и внешний URI=fakefile.xml с преобразованием Xpath для получения набора результирующих узлов child1? - person Cobaia; 06.09.2013