Приложение 1.
Приложение 1 
Подписание сведений, передающихся в транспортном конверте сообщения с помощью электронной подписи, осуществляется следующим образом (см. рисунок А.1). Для краткости на схеме опущены объявления пространств имен, а значения некоторых атрибутов приведены с сокращениями.
РИСУНОК А.1. СХЕМА ПОДПИСАНИЯ СООБЩЕНИЯ
На 1-м шаге формируется транспортный конверт сообщения (1-й шаг не имеет непосредственного отношения к формированию подписи, однако приводится в настоящем алгоритме как подготовительное мероприятие для создания XML-структур, в которые будут погружены подпись и подписываемые сведения).
На 2-м шаге в элемент soap:Body транспортного конверта помещается бизнес-сообщение. В атрибуте @wsu:ID элемента soap:Body задается идентификатор, который должен быть уникальным в рамках конверта и его содержимого; для идентификации тела сообщения рекомендуется использовать значение "BusinessMessage". Формируемая электронная подпись будет ссылаться по данному идентификатору на подписываемые данные.
На 3-м шаге в заголовке транспортного конверта сообщения формируется блок сведений wsse:Security. У элемента задается атрибут @soap:mustUnderstand со значением "true". Это обязывает получателя сообщения обрабатывать данный блок сведений. В случае если он не сможет обеспечить обработку электронной подписи, то он должен уведомить отправителя соответствующим сообщением об ошибке.
На 4-м шаге в блок сведений wsse:Security включается элемент wsse:BinarySecurityToken, содержащий сертификат ключа проверки электронной подписи. В атрибуте @wsu:Id указывается идентификатор сертификата, который должен быть уникальным в рамках конверта и его содержимого; для идентификации сертификата рекомендуется использовать значение "SigningCertificate". Формируемая электронная подпись будет ссылаться на сертификат по этому идентификатору. Сертификат должен соответствовать стандарту X.509 и кодироваться с использованием стандарта кодирования Base64.
Стандарт сертификата указывается в атрибуте @ValueType со значением "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3". Схема кодирования сертификата указывается в атрибуте @EncodingType со значением "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary".
На 5-м шаге формируется хеш бизнес-сообщения. Для этого в блоке сведений wsse:Security формируется элемент ds:Signature/ds:SignedInfo/ds:Reference. В атрибуте @URI этого элемента указывается ссылка на подписываемое бизнес-сообщение (если на 2-м шаге задан рекомендуемый идентификатор, то в атрибуте @URI должна быть указана ссылка "#BusinessMessage"). Если двоичные вложения передаются в виде MIME, то далее они должны быть перенесены в бизнес-сообщение согласно алгоритму, описанному в спецификации XML-binary Optimized Packaging. После этого бизнес-сообщение приводится к каноническому виду с помощью алгоритма Exclusive XML Canonicalization Version 1.0. Для полученного фрагмента XML-документа в соответствии с ГОСТ Р 34.11-2012 вычисляется 256-битный хеш, который записывается в элемент ds:DigestValue.
Алгоритм каноникализации указывается в атрибуте ds:Transforms/ds:Transform/@Algorithm со значением "http://www.w3.org/2001/10/xml-exc-c14n#". Алгоритм вычисления хеша указывается в атрибуте ds:DigestMethod/@Algorithm со значением "urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256".
На 6-м шаге для хеша бизнес-сообщения формируется электронная подпись. Для этого в элемент ds:Signature/ds:SignedInfo добавляются сведения об алгоритме его каноникализации (Exclusive XML Canonicalization Version 1.0) и алгоритме вычисления электронной подписи (ГОСТ 34.10-2012, 256 бит). Затем с помощью указанных алгоритмов элемент ds:Signature/ds:SignedInfo приводится к каноническому виду и для полученного фрагмента XML-документа вычисляется электронная подпись. Полученное значение записывается в элемент ds:SignatureValue.
Алгоритм каноникализации указывается в атрибуте ds:CanonicalizationMethod/@Algorithm со значением "http://www.w3.org/2001/10/xml-exc-c14n#". Алгоритм вычисления электронной подписи указывается в атрибуте ds:SignatureMethod/@Algorithm со значением "urn:ietf:params:xml:ns:cpxmlsec: algorithms:gostr34102012-gostr34112012-256".
На 7-м шаге в сведениях об электронной подписи в элементе ds:KeyInfo формируется ссылка на сертификат ключа проверки электронной подписи. Для этого используется элемент wsse:SecurityTokenReference. Ссылка на сертификат указывается в атрибуте wsse:Reference/@URI (если на 4-м шаге задан рекомендуемый идентификатор, то в атрибуте @URI должна быть указана ссылка "#SigningCertificate"). Стандарт сертификата указывается в атрибуте wsse:Reference/@ValueType со значением "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3".
Проверка электронной подписи сообщения осуществляется следующим образом (см. рисунок А.2). Для краткости на схеме опущены объявления пространств имен, а значения некоторых атрибутов приведены с сокращениями.
На 1-м шаге в заголовке транспортного конверта сообщения проверяется наличие элемента wsse:Security/ds:Signature. Если элемент присутствует, то сообщение является подписанным и требуется проверка наложенной электронной подписи.
На 2-м шаге проверяется сертификат открытого ключа электронной подписи в элементе wsse:BinarySecurityToken. Сертификат должен быть корректным, а в элементе ds:KeyInfo/wsse:SecurityTokenReference должна присутствовать ссылка на него.
На 3-м шаге проверяется действительность электронной подписи. Для этого элемент ds:SignedInfo приводится к каноническому виду с помощью алгоритма Exclusive XML Canonicalization Version 1.0. Для полученного фрагмента XML-документа вычисляется 256-битное значение электронной подписи в соответствии с ГОСТ 34.10-2012. Если результат совпадает со значением элемента ds:SignatureValue, то подпись является действительной.
Проверяется значение атрибута ds:SignedInfo/ds:CanonicalizationMethod/@Algorithm, оно должно соответствовать используемому методу каноникализации и иметь значение "http://www.w3.org/2001/10/xml-exc-c14n#". Проверяется значение атрибута ds:SignedInfo/ds:SignatureMethod/@Algorithm, оно должно соответствовать используемому алгоритму вычисления электронной подписи и иметь значение "urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256".
На 4-м шаге проверяется целостность бизнес-сообщения. Если двоичные вложения передаются в виде MIME, то перед проверкой целостности они должны быть перенесены в бизнес-сообщение согласно алгоритму, описанному в спецификации XML-binary Optimized Packaging. Затем бизнес-сообщение приводится к каноническому виду с помощью алгоритма Exclusive XML Canonicalization Version 1.0. Для полученного фрагмента XML-документа в соответствии с ГОСТ Р 34.11-2012 вычисляется 256-битный хеш. Если полученное значение совпадает со значением элемента ds:SignedInfo/ds:Reference/ds:DigestValue, то бизнес-сообщение целостно.
Проверяется значение атрибута ds:SignedInfo/ds:Reference/ds:Transforms/ds:Transform/@Algorithm, оно должно соответствовать используемому методу каноникализации и иметь значение "http://www.w3.org/2001/10/xml-exc-c14n#". Проверяется значение атрибута ds:SignedInfo/ds:Reference/ds:DigestMethod/@Algorithm, оно должно соответствовать используемому алгоритму вычисления хеша и иметь значение "urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256".
В случае неудачной проверки электронной подписи формируется сообщение об ошибке в соответствии с требованиями раздела 5.2.5 Стандарта.
РИСУНОК A.2. СХЕМА ПРОВЕРКИ ЭЛЕКТРОННОЙ ПОДПИСИ
