GetInfo.Ru – Компьютерная библиотека
Последние поступления
Как выбрать систему управления базы данных
Базы данных03/09/14
Этапы загрузки UNIX (в схеме)
Unix27/03/12
Gatewall Antispam: тотальный контроль электронной почты
Спам21/04/11
Мастер-класс: создаем Интернет-магазин (Часть 1)
Обзоры ПО20/04/11
CorelDRAW Graphics Suite X5: Что нового?
Обзоры ПО20/07/10
Добавить статью
Самые читаемые материалы
DOM для Web-сервисов, часть 1(11620)
XML-формат обмена данными Сбалансированной системы показателей: практический пример (часть II)(10296)
XML и базы данных? Доверьтесь своей интуиции(10272)
XML Viewer (IBM alphaWorks)(9475)
Обзор XML-стандартов, часть 2(9165)
Всего статей: 793Всего авторов: 364Подразделов: 47Добавлено за сутки: 0
Статьи  СТАТЬИ Форум  ФОРУМ Рейтинг  РЕЙТИНГ Поиск  ПОИСК Контакты  КОНТАКТЫ
» Главная » XML » Канонизация XML (Часть 1)

Канонизация XML (Часть 1)


Intersoft Lab
market@iso.ru
http://www.iso.ru/

Эта статья открывает серию публикаций, рассказывающих о Рекомендациях международного консорциума W3C: "Канонический XML" (Canonical XML) и "Исключительная канонизация XML" (Exclusive XML Canonicalization). В первой статье описывается процесс канонизации XML, то есть то, как, согласно соответствующей спецификации, устанавливается упрощенная форма XML-документа. Вначале давайте рассмотрим, когда и почему может оказаться необходимым канонизировать XML-документ.

Введение
Для того, чтобы общающиеся стороны могли обмениваться значащей информацией, XML определяет формат структурирования данных. Гибкость правил составления XML означает, что одна и та же структура документа и одна и та же часть информации могут быть представлены различными XML-документами. Рассмотрим Листинги 1 и 2, которые логически равнозначны, то есть придерживаются одинаковой структуры документа (одинаковой схемы XML) и предназначены для передачи одинаковой информации. Несмотря на то, что указанные листинги являются логическими эквивалентами, XML-файлы этих листингов не содержат одну и ту же последовательность символов (либо последовательность байтов или октетов).

В этом случае различие между последовательностями символов и октетов в этих двух XML-файлах объясняется разным расположением атрибутов в элементе room. Несовпадение в потоках октетов для логически эквивалентных XML-документов может быть вызвано и другими причинами. Цель нахождения канонической (или упрощенной) формы XML-документа - установить логическую равноценность между XML-документами. Согласно правилам канонизации, определенным Консорциумом W3C, каноническая форма двух XML-документов будет одинаковой, если они логически эквивалентны.

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

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

Причины определения логической равноценности между XML-документами
Электронные XML-подписи - это рекомендация консорциума W3C, которая определяет XML- формат для подписания XML-документов (а также документов, не являющихся XML). Можно сказать, что образование электронной подписи напоминает подписание обычных бумажных документов. Если подпись на документах (например, незаполненных чеках) являются неизменным атрибутом традиционного бизнеса, то ведение электронного бизнеса через Интернет, вероятно, потребует умения подписывать электронные документы.

Давайте рассмотрим, процесс подписания пустого чека. Незаполненный чек является частью системы, которая призвана отвечать двум основным требованиям:

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

К электронным XML-подписям предъявляются точно такие же требования. Так, штамп, напечатанный на банковском чеке, аналогичен алгоритму получения профиля сообщения (Message Digest), а роль образцов подписи, хранящихся в банке, выполняет криптографическая пара закрытый-открытый ключ (private-public key pair) в сервисе доверия (trust service) инфраструктуры открытых ключей (Public Key Infrastructure, PKI).

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

Профиль сообщения
Алгоритмы получения профилей действуют в соответствии с октетами сообщения и классифицирует (используют) их для вычисления значения профиля. Значения профиля зависят от алгоритма получения профиля и самого сообщения. Если сообщение будет модифицировано посторонним лицом, значение профиля можно использовать для того, чтобы обнаружить это изменение. Следовательно, профиль сообщения являются электронным способ обеспечения целостности.

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

Закрытые ключи являются конфиденциальной информацией, то есть только сервис доверия и пользователь (имеющий полномочие ставить подпись) знают значение личного ключа. С другой стороны, открытые ключи доступны каждому. Лицо, ставящее подпись, использует свой закрытый ключ, чтобы в электронном виде подписать сообщение вместе со значением профиля сообщения. Любой человек может воспользоваться открытым ключом, чтобы проверить подлинность этой подписи и профиля сообщения. Открытые ключи можно использовать только для проверки подписей; они не могут использоваться для создания подписей. Следовательно, до тех пор, пока сохраняется конфиденциальность вашего закрытого ключа, вы застрахованы от "подделки" своей подписи.

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

Проверка подлинности подписей
Приложение, которое получает подписанное сообщение, будет устанавливать достоверность подписанного сообщения с помощью открытого ключа, которое принадлежит лицу, поставившему это сообщение, а также контролировать целостность сообщения посредством проверки профиля сообщения. Процесс классифицирования XML-сообщения опирается на последовательность байтов, которые представляет XML- сообщение. Фактически, это последовательность байтов, которая образуют подпись и значение профиля сообщения. А это значит, что Листинги 1 и 2, хотя и представляют одну и ту же информацию, не синтезируют одинаковое значение профиля. Если вы подпишите Листинг 1, а получающая сторона попытается проверить Листинг 2, опираясь на вашу подпись (что более чем разумно, поскольку эти оба документа несут одинаковую информацию), процесс верификации потерпит неудачу.

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

Канонизация XML-документа
Спецификация канонического XML определяет алгоритм составления канонической формы XML-документов. Для того, чтобы канонизировать XML-документ, необходимо выполнить следующую последовательность действий:

1. Схема кодирования (Encoding Scheme)
Все XML-документы состоят из текста, который может быть прочитан человеком и которой является последовательностью символов. Схемы кодирования предназначены для обозначения символом с помощью октетов. Следовательно, если изменить кодировку XML-файла, то один и тот же XML-файл может быть представлен совершенно различным потоком октетов.

Спецификация канонического XML требует, чтобы каноническая форма XML-документов была в кодировке UTF-8. Следовательно, если XML-файл, подлежащий канонизации, имеет любую другую кодировку, ее необходимо изменить на UTF-8.

2. Обрывы строк
Обычно обрывы строк изображаются в текстовых файлах с помощью шестнадцатиричного А (десятичное 10) или шестнадцатиричного D (десятичное 13), либо комбинации этих двух октетов. Поскольку XML-файлы являются простыми текстовыми файлами, во всех XML-файлах в качестве разрывов строк используются #xA и #xD.

Согласно канонической форме XML, все разрывы строк (#xD или комбинация #xA и #xD) должны быть заменены на #xA. Это требование должно быть выполнено до начала обработки XML-файла.

3. Нормализация значений атрибутов
Необходимо, чтобы все атрибуты были нормализованы в канонической форме, как если бы это выполнил верификационный XML-парсер. Процесс нормализации значений атрибутов изложен в рекомендации W3C XML 1.0 (см. Ресурсы).

Простой пример нормализации значений атрибутов - Листинг 3 и 4. Листинг 3 - это исходный XML-файл до нормализации значений атрибутов; в Листинг 4 значения всех атрибутов представлены в нормализованном виде.

Все атрибуты в Листинге 3 относятся к строчному типу без каких-либо ссылок на раздел (entity) и символ. В этом случае нормализация значения атрибута просто подразумевает нормализацию свободного места (все типы свободного места [white space], то есть символы табуляции, разрывы строк и неразрывные пробелы, должны быть преобразованы в #x20, который является октетом, представляющим неразрывные пробелы). Все атрибуты id в Листинге 3 имеют в них два символа табуляции. Каждый символ табуляции в атрибуте id в Листинге 3 был заменен в Листинге 4 на пробел.

4. Двойные кавычки для значений атрибутов
В канонической форме для изложения (encapsulate) значений атрибута могут использоваться только двойные кавычки. Взгляните на Листинг 4, где атрибут name элемента product заключен в одинарные кавычки. В Листинге 5 одинарные кавычки вокруг атрибута name заменены на двойные.

5. Специальные символы в значениях атрибутов и содержании символов
Однако, замена одинарных кавычек на двойные в Листинге 5 привела к возникновению следующей проблемы. Этот листинг больше не является правильно оформленным XML-файлом, поскольку строка, представляющая значение атрибута name, уже содержит двойные кавычки, являющиеся частью значения строки. Для разрешения этой проблемы, согласно спецификации канонического XML, необходимо заменить все специальные символы (например, двойные кавычки) в значениях атрибутов и содержании элементов на символьные разделы (например, " для двойных кавычек). Листинг 6 - результат применения этого правила к Листингу 5.

6. Ссылки на раздел
Листинг 6 содержит декларацию DTD (Описание шаблона документа), которая описывает раздел, называемый testhistory (история тестирования). На этот раздел testhistory ссылается содержание элемента comments.

Канонический XML требует, чтобы все ссылки на раздел были заменены на содержание, представленное разделом (например, в Листинге 6 раздел testhistory представляет строку "Part has been tested according to the standards" ("Часть была оттестирована согласно указанным стандартам")). Листинг 7 - результат замены ссылок на раздел в Листинге 6.

Декларация DTD в Листинге 7 определяет атрибут по умолчанию, называемый >approvedpart. Ни один из тегов part в Листинге 7 не содержит этого атрибута.

Канонический XML требует, чтобы атрибуты по умолчанию были включены в каноническую XML-форму. Листинг 8 - результат добавления атрибута approved со значением по умолчанию в Листинге 7.

8. Декларации XML и DTD
Канонический XML не требует деклараций XML и DTD. Следовательно, декларации XML и DTD должны отсутствовать в канонической форме. Несмотря на то, что мы использовали декларацию DTD при замене ссылок на раздел и добавлении атрибутов по умолчанию, имеющиеся декларации XML и DTD должны быть удалены, как показано в Листинге 9.

9. Свободное место в элементе документа
Канонический XML-документ начинается с символа '<'. Это означает, что перед первым узлом не должно быть свободного места.

10. Свободное место в начальных и конечных элементах
В канонической форме начальные и конечные элементы должны иметь нормализованное свободное место. Это означает, что должны выполняться следующие требования:

  • Между левой угловой скобкой ('<') и именем первого элемента не должно быть свободного места. Аналогично, свободное место должно отсутствовать между косой чертой ('/') и именем конечного элемента.
  • Между именем элемента и именем первого атрибута, если таковой имеется, должен присутствовать единственный символ #x20.
  • До и после знака равенства в парах атрибут-значение не должно быть свободного места.
  • Между парами атрибут-значение должен быть символ #x20.
  • За закрывающей кавычкой значения последнего атрибута не должно быть свободного места.
  • В случае отсутствия атрибутов, между именем элемента и правой угловой скобкой ('>') не должно быть свободного места.

Листинг 10 - .результат нормализации свободного места в начальных и конечных элементах Листинга 9.

11. Пустые элементы
Канонический XML требует наличия начального и конечного тегов для всех элементов, в том числе и для пустых элементов. Следовательно, все пустые элементы в виде <emptyElement/> должны быть преобразованы к <emptyElement></emptyElement>. Листинг 11 - результат применения этого правила к Листингу 10.

12. Декларация пространства имен
В Листинге 11 присутствуют три декларации пространств имен, два в элементе product и одна во втором элементе part. Канонический XML требует сохранения всех деклараций самих пространств имен (вместе с префиксами пространства имен) кроме деклараций избыточных пространств имен (такие декларации не влияют на контекст пространства имен в любом узле XML-файла).

Пространство имен, объявленное во втором элементе в product Листинга 11, является избыточным. Его удаление из этого элемента не повлияет на контекст пространства имен в любом узле этого файла. Вот почему Листинг 12 не включает именно эту декларацию пространства имен, оставив остальную часть Листинг 11 без изменений.

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

Листинг 13 - это окончательная каноническая форма всех листингов, начиная с 3-го и заканчивая 12-м.

Исключительно ради разнообразия рассмотрим еще один пример - Листинг 14 и 15. (Листинг 15 - каноническая форма Листинга 14.) Листинг 15 не был выполнен в ручную - он был сгенерирован с помощью разработки Canonical XML группы программистов IBM alphaWorks; этот проект является частью их XML Security Suite (см. Ресурсы). Однако, любознательный читатель может получить из Листинга 14 Листинг 15 , выполнив последовательно все изложенных выше тринадцать пунктов.

Обратите внимание, что в Листинге 14 нет декларации DOCTYPE. Следовательно, в данном случае некоторые шаги, как, например, замена ссылок на раздел и добавление атрибутов по умолчанию, необязательны.

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

Ресурсы

Оригинальный текст статьи можно посмотреть здесь:
XML Canonicalization, Part 1

 
17.02.2003
Версия для печати Версия для печати Запомнить ссылку Запомнить ссылку
Ваша оценка:  1   2   3   4   5     

 О проектеПерепечаткаАвторамПартнерыО нас пишут
Наверх
©2003—2007. GETINFO.RU. ВСЕ ПРАВА ЗАЩИЩЕНЫ.