Сергей Муругов
В разделе 7.3 RFC 3281 указано: "В некоторых случаях может потребоваться, чтобы атрибутный сертификат (АС) не был привязан ни к личности владельца, ни к сертификату открытого ключа. В таком случае возможно использование варианта objectDigestInfo поля holder... Смысл данного варианта поля holder в том, чтобы обеспечить связь АС и некоторого объекта, которому он "принадлежит" посредством указания значения хэшфункции от данного объекта. Такой подход, например, позволяет связывать АС с исполняемыми объектами, такими, как Java-класс".
Постановка задачи
Исходящая и соответственно входящая информация для информационных систем организаций представляет собой более сложную структуру, нежели просто электронный документ, пусть даже с ЭЦП. В соответствии с действующим ГОСТ Р ИСО 15489-1–2007, помимо содержания документ должен иметь соотнесенные с контентом метаданные, отражающие операции деловой деятельности, и быть постоянно связанным или объединенным с ними. Такого рода метаданные, сопровождающие документ, должны содержать указания, обеспечивающие пригодность документа для последующего его использования, отражающие возможность локализации и поиска документа, воспроизводимости электронного документа техническими средствами визуализации.
Еще одна очень важная отличительная особенность обращения электронных документов – это то, что в ряде случаев документ имеет период действительности, то есть информация, содержащаяся в документе, может потерять свою актуальность, к тому же часто возникает потребность, вызванная спецификой деловой активности, в преждевременном отзыве документа. Наиболее яркий пример таких документов – различного рода разрешения.
Все сказанное, безусловно, накладывает определенные требования на техническую реализацию информационного контейнера электронного документа, который был бы способен к аудиту и документированию и являлся бы защищенной транспортной оболочкой для исходящей/входящей документации юридического лица во взаимодействии разнородных информационных систем, автоматизирующих процессы деловой активности. Очевидно, что фактический состав, структура контейнера будет отражать специфику прикладной области, но можно выделить некоторые общие правила при выборе технической реализации контейнера:
- Контейнер должен иметь механизмы защиты целостности данных и идентификации источника данных.
- Язык описания и правил кодирования контейнера должен быть в достаточной степени универсальным, чтобы описывать сложные структуры и типы данных. В качестве примера такого языка может выступать XML (при выборе языка следует иметь в виду, что в РФ (насколько известно) отсутствует государственный стандарт на XML) или ASN.1 (существует целое семейство действующих стандартов).
- Контейнер должен иметь признак, по которому содержащуюся в нем информацию (включая и метаданные) можно было бы ассоциировать с событием или информацией (например, серийный номер события в системе, наименование события, свертка от конкретного исходного документа и т.п.).
- В целом ряде случаев характеристики деловой активности требуют возможность указания периода действительности информации в контейнере, а также возможность преждевременного вывода его из документального обращения.
Очевидно, что привычный всем формат ЭЦП в виде CMS или PKCS#7 или "подпись с расширенными данными для проверки" по ETSI TS 101 733 в явном виде не сможет обеспечить все вышеперечисленные требования.
Одним из вариантов решения данной задачи может выступать использование в качестве такого рода контейнера атрибутного сертификата в соответствии с международными рекомендациями RFC 3281, допускающими такой режим использования атрибутного сертификата.
Возможные области применения По предварительному анализу некоторых видов деловой активности можно явно выделить приложения использования такого рода контейнера ("удостоверяющего свидетельства"):
1. ............
