ДСТУ ETSI TR 102 045 Электронные подписи и инфраструктуры (ESI). Политика подписей для расширенной бизнес-модели

Предисловие

Этот стандарт разработал Технический комитет ETSIпо электронным подписям и инфраструктурам (ESI).

Введение

Работы ETSI-TC ESI и CEN/ISSS обращены к проблеме единичных подписей, но достаточно часто документы требуют более одной подписи для юридической валидности или эффективности транзакций. Они могут быть параллельными независимыми подписями, как у покупателя и продавца по контракту; или вложенными контрподписями, когда контрподпись наложена на такую первичную подпись, как подпись свидетеля, или подпись вышестоящего валидатора на подпись нижестояшего. До настоящего времени политику подписания определяли только для валидации одной электронной подписи (TS 101 733 [1]), однако все больше бумажных процессов перемещается в электронную среду, поэтому есть потребность расширить эту политику для поддержки множественных подписей. Это подтверждает медленное продвижение более сложных бизнес-транзакций, требующих заверения или имеющих строгие требования формы в бумажном мире. Они включают потребительские финансовые или кредитные транзакции, транзакции со структурированными сроками оплаты/поставки. Для перевода в электронную форму необходим некоторый способ сообщения/выражения цели и контекста, в котором применена подпись(и), чтобы это было юридически осуществимо в любом государстве-члене ( идеально в любой другой юрисдикции).

Этот стандарт предназначен дополнить TS101 733 [1] и TR102 038 [2], исследуя бизнес-потребности и предоставляя основания для дальнейшей работы по технической реализации политики подписания, управляющей множественными подписями. Его цель – предоставить общее руководство по методологии валидации множественных подписей. Предполагается, что каждая подпись проходит процесс валидации под политикой подписания для таких единственных подписей, как TS101 733 [1] или TR102 038 [2]. Поэтому остается провести валидацию отношений между подписями. Этот стандарт служит основой определения требования высокого уровня для принятия бизнесом электронных подписей. Затем рассмотрен ряд правил использования подписи для многих аспектов бизнес-требований, которые можно использовать для информирования реализаций политики подписания. Правила этого стандарта не организованы в модель политики. Этот стандарт служит основой для развития таких правил.

Имеем бизнес-потребность перемещения всех свойств рукописной подписи в виртуальный мир и развития эквивалентного доверия к электронным подписям, особенно если они задают юридически легальное обязательство. Директива 1999/93/EC [5] предусматривает эквивалентность рукописным подписям, когда электронная подпись поддержана усиленными техническими мерами безопасности (статья 5.1). Однако много аспектов "реального мира" вводят характеристики подписей, не предусмотренные в Директиве. Их удобно покрыть политикой подписания.

Значение подписи неявно отражено в непосредственно подписи и это готов понять даже обычный человек. Обычно такое понимание выведено из контекста, в котором сделана подпись. В этом стандарте сделана попытка проанализировать значение и подразумеваемые последствия подписи "реального мира" во многих бизнес-контекстах. Какое обязательство подразумевает подпись? Каковы бизнес-цели использованных подписей? Каковы последствия подписи? Каково ее очевидное значение в процессуальных действиях? Каковы релевантные факторы относительно создания подписи? Как эти факторы можно переместить в виртуальный мир? Во многих бизне- ситуациях требуется более одной подпись для придания эффекта документу или транзакции. Самый очевидный пример — контракт, где и покупатель и продавец подписываются для указания принятия ими положений контракта и их желания или намерения, которые будут юридически связаны с ними. В этом случае подразумеваемые подписью обязательства и последствия ее создания выражены прямо. Более сложно проанализировать сценарии, когда необходима контрподпись, т.е. подпись одного человека, подписанная другим. Значение таких подписей и обязательства, принимаемые контрподписывающим лицом, часто неясны без тщательного исследования основного бизнес-процесса. Даже тогда в исследованных сценариях остается много двусмысленности, окружающей контрподписи.

Поэтому в этом стандарте принято расширенное толкование политики подписания, а политика подписания может быть полезным инструментом для определения средств создания и верификации всех типичных качеств рукописной подписи. Политика подписания может включать средства воспроизведения церемоний "реального мира" или формальности подписания. Она также может устанавливать, кто может подписаться, в каком объеме, что должно быть подписано и при каких обстоятельствах. Определяя область и/или применение, к которому применима политика подписания, можно воспроизвести часть контекстной информации, которая относится к интерпретации обязательства подписи как в бумажном мире. Поскольку эти факторы изменятся согласно обстоятельствам, при которых необходимо использовать подпись, то из этого следует, что невозможно определить единственную, модельную политику для покрытия всех сценариев. В этом стандарте проанализированы некоторые факторы, общие для многих ситуаций, в стремлинии предоставить "стандартные блоки", которые могут быть собраны ("LegoTM"-способом) для создания политики подписания, относимой к конкретной бизнес-потребности.

Политика подписания можно (на самом деле необходимо) создать на основе конкретного бизнес-приложения. Это не игнорирует факт наличия бизнес-потребностей в руководстве или наборе правил, которые могут определить две стороны без предыдущих отношений при желании подписать единственный контракт в электронной форме. Маловероятно, что они проведут техническую экспертизу для реализации политики подписания, реализованную, согласно этому стандарту и/или что эта реализация будет эффективна относительно затрат для единственной транзакции. Также маловероятно, что политику подписания прочитают или поймут потенциальные підписувачі. Понятно, что принципиальное использование политики подписания должно сообщить бизнес-требования и контекст подписи для улучшения интероперабельности системы/приложения от разных разработчиков приложений уровня предприятия (таких, как модули, разработанные JDEdwardsи SAP) или таких, основанные на XML разработок, как SterlingCommerce, Documentum, Webmethods, TibcoandBEASystems. Правила использования подписи должны учитывать интерфейс между операторами и компьютерной системой. Только человек может принять решение о применении подписи. Это верно даже, когда подпись исходит от юридического лица. Даже, когда подписи созданы как часть автоматизированного процесса, на некоторой ступени человек должен принять решение сконфигурировать систему для выполнения этой задачи. С другой стороны, приемлемо проведение человека по политике подписания через интерфейс приложения.

Этот стандарт служит основой определения требования высокого уровня для принятия бизнесом электронных подписей. В нем затем рассмотрен ряд правил использования подписи для многих аспектов бизнес-требований, которые можно использовать для информирования реализаций о политике подписания. Правила не организованы в модель политики в этом стандарте, скорее раздел 10 служит основой для таких правил.