Signature Applicability Rules / Signature Policy

The term "signature policy" is often used to refer to "Signature Applicability Rules", that is, a set of rules for the creation, validation and long-term management of one (or more) electronic signature(s).

A Signature Policy, in that meaning, contains general information such as:

  • the identifier of the signature policy;

  • the name of the signature policy issuer;

  • the date of issuance of the signature policy;

  • the signing period;

  • the field of application;

A Signature Policy is composed of three main parts that define technical and procedural requirements:

  1. Signature Creation Policy: requirements for the signer in creating a signature;

  2. Signature Validation Policy: requirements for the verifier when validating a signature;

  3. Signature (LTV) Management Policy: requirements for the long term management and preservation of a signature.

A signature policy is a way of expressing:

  • who may sign;

  • in what capacity an entity may sign;

  • what data is being signed;

  • in what circumstances the data is signed;

  • why the data is being signed (i.e. what are the consequences);

  • the purpose for the signature;

  • the context in which the signature will be used;

  • the means for the creation , verification and long-term management of an electronic signature;

  • the means for reproducing the formalities of signing;

  • the requirements imposed on or committing the involved actors.

The exact information contained in a signature policy will depend on the use cases of the signature and on the involved parties as the signature policy can be negotiated between them. Therefore, it is not possible to define a single template policy to cover all use cases.

Having a signature policy and thus all the above-mentioned information, available in a signature, has several advantages:

  • It allows keeping a trace of the decisions that were made during the analysis of the signatures that will need to be created.

  • It allows a signature to be legally enforceable in any Member State

  • It makes the signature workflow transparent to all involved parties. This enhances trust in electronic signatures that comply with a signature policy.

Parties involved in a signature policy are:

  • The Signature policy issuer: a legal/natural entity that sets the rules that compose the signature policy.

  • Signature policy users: natural persons that can be one of the two following types of entities:

    1. Signer: creates an electronic signature.

    2. Verifier: ensures the authenticity of the policy and decides whether the signed data is valid or not.

  • Trust Service Provider(s).

ETSI ESI has developped several standards to express signature applicability rules or "signature policy" in two forms:

  • In a human-readable form: It can be assessed to meet the requirements of the legal and contractual context in which it is being applied (cf. ETSI TS 119 172-1 [R17]).

  • In a machine processable form (XML or ASN.1): To facilitate its automatic processing using the electronic rules (cf. ETSI TS 119 172-2 [R18] and ETSI TS 119 172-3 [R19]).

Signature policy at creation and validation

During signature creation, a signature creation policy can be added to the signature as a signed attributes of the signature. Signed attributes are information that can only be included upon signature creation and that cannot be added, modified or removed at a later point in the life of the signature. The signature creation policy can be added to the signature indirectly as a reference which is composed of the hash value of the policy and the hash algorithm that was used to hash the policy, or directly when it is in a machine processable form.

During signature validation, a mapping between acceptable signature creation policies and their corresponding signature validation policies can be provided to the signature validation application (SVA). If the signature contains one signature creation policy identifier, which is part of the list of mappings, the SVA can then apply the corresponding validation policy during validation.

Last updated