Лістинг 3

<?xml version=”1.0”?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>

<SOAP-ENV:Header>
<ds:Signature>
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#GetSpecialDiscountedBookingForPartners">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>
BIUddkjKKo2...
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
</ds:SignatureValue>
<ds:KeyInfo>
</ds:KeyInfo>
</ds:Signature>
</SOAP-ENV:Header>

<SOAP-ENV:Body>
<s:GetSpecialDiscountedBookingForPartners
xmlns:s=“http://www.MyHotel.com/partnerservice/”
ID="GetSpecialDiscountedBookingForPartners">
<!--Parameters passed with the method call-->
</s:GetSpecialDiscountedBookingForPartners>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

CanonicalizationMethod - це обов'язковий елемент, який ідентифікує алгоритм канонізації, вживаної до елементу SignedInfo до створення підпису.

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

Алгоритми канонізації призначені для генерації двійкових потоків для логічно еквівалентних даних XML. Щоб бути упевненим, що логічно еквівалентні XML-документи створюють один і той же дайджест (і однаковий підпис), необхідно канонізувати ресурс XML до створення дайджеста потоку даних.

Елемент CanonicalizationMethod в Лістингу 3 містить атрибут Algorithm, значенням якого є рядок URI (http://www.w3.org/2001/10/xml-exc-c14n#). Цей рядок URI указує алгоритм, описаний специфікацією W3C, – “Виняткова канонізація XML” (Exclusive XML Canonicalization).

На даному етапі просто створюється елемент CanonicalizationMethod - а алгоритм канонізації поки не використовується. Він застосовуватиметься до елементу SignedInfo після того, як будуть сформовані всі його нащадки.

Наступний нащадок елементу SignedInfo - це елемент SignatureMethod, атрибут Algorithm якого указує алгоритм, використовуваний для створення криптографічного підпису.

Третій нащадок елементу SignedInfo - елемент Reference. У елементу SignedInfo повинен бути хоч би один елемент Reference. Цей елемент використовується для зберігання інформації, яка включає:

1. Вказівка даних, які підлягають підписанню. Для цього використовується атрибут URI елементу Reference. Підписувані дані можуть бути як усередині XML-документа, так і поза ним. Якщо дані і підпис знаходяться в одному і тому ж XML-документі, для їх вказівки використовується ідентифікатор фрагмента у вигляді значення атрибуту URI елементу Reference. Так, в Лістингу 3 значення атрибуту URI указує на елемент GetSpecialDiscountedBookingForPartners. Якщо ж дані є зовнішніми по відношенню до файлу з цифровим підписом XML, посилатися на них необхідно за допомогою URI як значення атрибуту URI елементу Reference. Цифровий підпис XML дозволяє виконувати ряд операцій даними перш, ніж профілювати і підписувати їх. Наприклад, до того, як підписувати дані, їх можна канонізувати, або до їх профілізації до них можна застосувати які-небудь перетворення XSL. Так, якщо дані про ціни представлені в табличній формі, їх можна перетворити, отримавши звичайний рахунок. Для цього можна скористатися перетворенням XSL як шаблоном цього рахунку. Це означає, що підписуватиметься весь рахунок, а не тільки необроблені дані, включені у файл з цифровим підписом XML. Елемент Transforms містить інформацію про те, які операції виконуються на даних до їх підписання. У елементу Transforms в Лістингу 3 є один дочірній елемент Transform. Таких елементів може бути будь-яка кількість. Кожен елемент Transform указує алгоритм перетворення. Якщо перетворювати дані до їх підписання, необхідно включити вказівку про те, що було зроблене, додавши елемент Transform. Завдяки цьому одержувач підписаного файлу зможе виконати таке ж перетворення до того, як спробувати перевірити підпис. У даному прикладі була виконана тільки одна операція - алгоритм канонізації, вказаний за допомогою атрибуту Algorithm елементу Transform. В тому разі якщо елемент Transforms містить більш за один елемент Transform, необхідно враховувати їх порядок проходження. Перетворення виконуються в тому порядку, в якому вони з'являються в елементі Transforms. Всі вони проводяться до профілізації даних. Отже, вихідні дані останнього елементу Transform є вхідними даними для алгоритму профілю повідомлення.

2. Алгоритм, використовуваний для створення дайджеста. Специфікація “Цифровий підпис XML” рекомендує використовувати алгоритм профілю SHA-1. Ця інформація знаходиться в елементі DigestMethod, нащадку елементу Reference - в значенні його атрибуту Algorithm (http://www.w3.org/2000/09/xmldsig#sha1).

3. Значення дайджеста. Елемент DigestValue в Лістингу 3 містить дійсне значення дайджеста, отримане застосуванням алгоритму дайджеста до канонічної форми елементу GetSpecialDiscountedBookingForPartners. Необхідно відзначити, що бінарні дані в необробленому вигляді (такі як потік, створений алгоритмами дайджеста повідомлення, підпису і шифрування) не можуть бути загорнуті в розмітку XML - це може ускладнити розбір XML. Перш ніж обертати їх в розмітку XML, такі дані представляються в кодуванні base-64. В результаті, зашифровані дані не містять бітів, які могли б конфліктувати з правилом обробки XML.

Після того, як SignedInfo і його дочірні елементи сформовані, необхідно провести канонізацію всього елементу SignedInfo по алгоритму, вказаному в елементі CanonicalizationMethod. Після цього слід набути значення дайджеста і обернути це значення в елемент SignatureValue, як показано в Лістингу 4. Під час підписання канонічна форма елементу SignedInfo використовується як даних, що підлягають підписанню. У неї входять всі дочірні елементи елементу SignedInfo.