Об использовании национальных криптоалгоритмов в Office 2010

В январе этого года, я написал небольшую заметку по мотивам блога Digital Signatures in Office 2010 - О цифровых подписях в Office 2010 (в ней давался небольшой экскурс в организацию ЭЦП в документах OpenXML). На тот момент для меня оставлся неясным вопрос о поддержке Office 2010 малораспространенных в мире криптоалгоритмов, таких, например, наш ГОСТ (на самом деле, это целая серия алгоритмов, но для цифровой подписи используется традиционно только ГОСТ Р 34.10-2001). Именно его я задал в исходном блоге, но ответа так и не дождался, хотя периодически мониторил исходный блог на протяжении еще примерно двух месяцев. Не привнес ясности и ответ Максима Коллегина, который написал, что пока с поддержкой Office 2010 в том же КриптоПро никакой ясности нет.

Каково же было мое удивление, когда пересматривая накопившиеся за несколько неделе записи в RSS-ленте я наткнулся в блоге David LeBlanc на пост DSig Q & A, посвященный как раз ответам на вопросы блога "Digital Signatures in Office 2010", оставшихся без ответа. Что особенно приятно - бы там ответ и на мой вопрос. Однако сам ответ назвать обнадеживающим, увы нельзя.

Итак, в двух словах о том, что написал Девид...

В Office 2010 для хранения используется стандарт XML-DSig, который позволяет указывать используемый криптоалгоритм. Например, вот так указывается алгоритм хэширования:

<DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1"/>

Для ссылки на алгоритм применяется строка URI, полный список которых можно найти в RFC 4051. Так вот, ни о каком алгоритме ГОСТ, данный стандарт ничего не знает. Более того, в нем не предусмотрено механизмов для простого (т.е. без доработки самого стандарта) механизма для расширения списка поддерживаемых криптоалгоритмов.

В принципе, можно реализовать обходное решение, в котором, используя стороннюю/собственную библиотеку формирования ГОСТ-совместимой подписи, и сгенерирова свой URI (OID) для указания алгоритма, внедрять ее (подпись) в документ самостоятельно, благо все форматы и протоколы известны. Однако проблем у такого решения будет больше, чем положительных сторон:

• не известно поведет себя сторонее ПО (в первую очередь сам Office), встретив сформированную не по стандарту ЭЦП. В самом простом случае - посчитает ее недействительной, в плохом - посчитает ошибочным весь документ.
• даже если стороннее ПО в вопросах криптозащиты будет полагаться на некое универсальное API (например, CriptoAPI или CNG), которое в свою очередь, будет использовать URI, полученные от установленных криптопровайдеров, вам все равно нужно будет гарантировать наличие одинаковых (т.е., как минимум, от одного производителя!) криптопровайдеров с поддержкой ГОСТ у каждой стороны.

Только ли в Office проблема?

Увы, далеко нет. Проблемы с использованием национальных (и просто неупомянутых в RFC 4051) алгоритмов будут иметь любые приложения, использующие XML-DSig. На вскидку:

• все приложения, использующие Open Packaging Conventions. А это форматы .docx, .xlsx, .pptx, .xps, ...
• приложения, работающие с форматами OpenDocument, т.е. с .odt, .ods, .odp, ...
• любые web-сервисы, работающие по стеку протоколов WS-*, в частности с WS-Security

И если необходимость использования ГОСТ-криптографии для web-сервисов, пока из области общих теоретизирований (тем более, что всегда можно использовать шифрование на уровне транспорта, а там уже давно проблем нет), то подписание электронных документов - проблема насущная.