In the European Union the following legislation have had a considerable impact on the topic of electronic and digital signatures:
-
the Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures (cf. [R07]);
-
Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC (cf. [R12]).
The eIDAS Regulation repealed Directive 1999 and became official on July 1, 2016. A Regulation is a law that applies across all EU Member States (MS). eIDAS aims for interoperability between the EU MS, among others in the field of the electronic signature, by building compatible trust service frameworks.
One of the main aspects of the eIDAS Regulation, is that where the Directive mainly covered Certificate Service Providers, the eIDAS Regulation expands on that concept and introduces the new concepts of trust services and trust service providers which is detailed in the next subsection.
A Trust Service Provider (TSP) is a natural or legal person who provides one or more trust services. A trust service is an electronic service related, among others, to the creation, validation and preservation of electronic signatures, timestamps, and certificates.
Given that a TSP can provide a combination of trust services, a TSP can take one or more of the following roles
-
a certificate issuer (CA);
-
a time-stamp issuer (TSA);
-
a signature verifier (VA);
-
…
A TSP can be either a qualified or non-qualified trust service provider. All TSPs no matter if qualified or not have the following obligations and requirements
-
Processing of personal data;
-
Notification of security and personal data breaches;
-
Keeping an up-to-date termination plan;
-
Meeting requirements on employed staff and subcontractors (e.g. trainings);
-
Keeping sufficient financial resources and/or liability insurance;
-
Recording and keeping activities related to data accessible;
-
…
This ensures the validity and security of the trust services that TSPs provide, such as the integrity of the data that was used for certificate and signature creation as well as the security of the signing keys.
A qualified trust service provider (QTSP) is a TSP that provides one or more qualified trust services and is included in a Trusted List (cf. [TrustedLists]).
Some aspects are specific to QTSPs and follow from the requirements of eIDAS
-
Undergoing a pre-authorization scheme;
-
Being actively supervised;
-
Undergoing regular audits;
-
Presumption of intention or negligence in case of damage due to failure to comply to the law;
-
Providing a high level of security;
-
Providing legal certainty;
-
Presumption of the integrity of the data;
-
…
The terms “Electronic Signature” and “Digital Signature” are often used interchangeably however they are very distinct concepts as "electronic signature" is a legal concept, whereas "digital signature" is a technical concept that is used to provide a concrete instance of electronic signatures.
In the eIDAS Regulation, and electronic signature is defined (legally) as "data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign".
An electronic signature does not necessarily guarantee that the signature process is secure nor that it is possible to track the changes that have been brought to the content of a document after it was signed. This depends on the category of the electronic signature. Indeed, beyond the concept of "simple" electronic signatures (SES) the Regulation further defines Advanced Electronic Signatures (AdES) and Qualified Electronic Signatures (QES).
A Simple Electronic Signature can cover a very broad range of data, such as a name written at the end of an email or an image added to a document.
An Advanced Electronic Signature is an electronic signature that has the following properties:
-
It is uniquely linked to the signatory.
-
It is capable of identifying the signatory.
-
The signatory has the sole control over the data used for the creating signatures.
-
It can detect whether the signed data has been modified since the signature.
A Qualified Electronic Signature is an AdES that is based on a qualified certificate for electronic signatures (cf. Digital certificate) and that has been generated by a qualified signature creation device (QSCD). QES have the same legal value as handwritten signatures. When an electronic signature is a QES, there is a reversal of the burden of proof. There is a presumption that a person has signed until a proof is given that the person did not sign.
A digital signature is a technical concept that is based on a Public Key Infrastructure (PKI, cf.Simplified PKI model) and involves, among others, public key cryptography and public key certificates (cf. Digital certificate).
Digital signatures can be used to ensure the unique identification of the signer, the authenticity of the signature and the integrity of the data. The identification of the signer as well as the authenticity of the signature are guaranteed by decrypting the digital signature value using a public key attested by a public key certificate (cf. Digital certificate). The component of the digital signature that allows detecting whether signed data has been tampered with is a cryptographic function called a hash function.
"AdES digital signatures" are digital signature formats that have been developped by ETSI to support the eIDAS Regulation and provide a way to create digital signatures that can meet the legal requirements for AdES and QES.
This section aims to briefly introduce PKI-based digital signature concepts, more specifically concepts related to digital signatures supported by X.509 digital certificates issued by Certification Authorities (CA), and making use of asymmetric cryptography. Such signatures are the kind of signatures that are handled in DSS.
For the rest of this section, the creation of a digital signature value is assumed to be the encryption of the digest of a data object using a private key for which there exists a corresponding X.509 public key certificate issued by a CA.
For the purpose of introducing those concepts, we will first provide a simplified description of the PKI model in which digital signatures are created. The goal of this model is not to provide an accurate and exhaustive description and definition of a PKI but to provide a basis for introducing the main PKI concepts that are useful to DSS users. Suggestions for improvement are welcomed and can be proposed via PRs in the DSS GitHub.
A (simplified) description of the PKI model and where DSS is involved in that model is given in the figure below.
In this simplified model, a PKI is composed of:
-
Certificates;
-
Certification Authorities (CA) issuing the certificates;
-
Certificate Revocation Lists (CRL) issued by CAs; and
-
OCSP responders providing information on the status of certificates.
In turn, DSS within that model, can be used to implement Signature creation applications (SCA) and/or Signature Validation Applications (SVA)
Each of those concepts are further detailed in the next sections.
As mentioned before, in the present context, digital signatures are supported by public key certificates. Public key certificates are data structures that binds an entity to a public key and that are signed by a third party, they provide a proof of authenticity of the public key.
The ITU-T X.509 Recommendation is a standard describing (among others) such a data structure, and public key certificates structured as per the specifications provided in that standard are commonly referred to as “X.509 public key certificates”.
Furthermore, the IETF published the RFC 5280 ([R24]) which specifies a profile for X.509 public key certificates (and certificate revocation lists). For the remainder of this document, X.509 public key certificates are assumed to be profiled as per RFC 5280.
Certificates can be end-entity certificates or CA certificates:
-
End-entity certificates are certificates issued to entities that are not authorized to issue certificates, for instance a natural person;
-
CA certificates are certificates issued to entities authorized to issue certificates, also known as Certification Authorities (CA).
Certificates have a defined validity period during which the CA having issued the certificate guarantees the correctness of its content. During that validity period, they may however be revoked or suspended, for instance when the entity to which the certificate has been issued has lost control of the corresponding private key.
A certificate contains among other things information on:
-
The entity to which the certificate has been issued, also referred to as the Subject;
-
The public key which is bound to the Subject;
-
The entity having issued the certificate (the CA), also referred to as the Issuer;
-
The validity period of the certificate;
-
The location where information on the revocation status of the certificate can be found;
-
Restriction applying to the usage of the public key contained in the certificate;
-
A digital signature created by the issuer of the certificate;
-
…
As previously mentionned, a certificate can be revoked or suspended. This information is usually provided in the form of a Certificate Revocation List (CRL), or through the Online Certificate Status Protocol (OCSP).
A CRL is a list of revoked (and/or suspended) certificates that is digitally signed and published by a CRL issuer. This issuer can be the CA having issued the certificates listed in the CRL, or it can be another CA in which case the CRL is called an “indirect CRL”. RFC 5280 ([R24]) provides a profile for X.509 CRLs.
The OCSP is a protocol defined in RFC 6960 ([R25]) that enables the determination of the (revocation) status of a certificate without the use of a CRL. An OCSP request, containing (among other things) information on the certificate for which the (revocation) status is requested, is sent to a server and a response, containing information of that (revocation) status, is provided by an OCSP responder. OCSP responses are signed by the OCSP responder, and the OCSP responder can be the CA having issued the certificate or another CA in which case the OCSP responder is called a “delegated OCSP responder”.
RFC 5280 section 6.3 describes an algorithm for the validation of CRLs, while Common PKI v2.0 part 5 section 2.3 ([R26]) describes an algorithm for checking the revocation status of a certificate using CRLs and OCSP responses.
Certification Authorities are entities issuing certificates and guaranteeing the correctness of their content. They manage the whole lifecycle of the certificates they issue, including the revocation services. Throughout this document, they will be denominated as:
-
Issuing CA for the CAs that issue end-entity certificates:
-
Intermediate CA for CAs that issue certificates to other CAs and are not root CAs;
-
Root CA for the CAs that have at least one self-signed certificate.
Without going into the details and inner workings of the hierarchical trust model (this document does not intend to discuss the soundness of this model, the soundness of transitivity of trust, etc.), when a user is looking to validate a certificate, that is the user’s need to decide whether they can trust the binding between the public key and the subject of that certificate, they will make use of so called “trust anchors”.
A trust anchor, in the context of certificate validation, is a CA that is trusted by the user in such a way that if there exists a valid chain of certificate from that CA to a certificate, the user trusts the correctness of the information contained in that certificate taking into consideration the (revocation) status of that certificate.
The wording “valid chain of certificate” used above is voluntarily informal, but it can be more formally defined as meaning that there exists a prospective certification path such that the output of the certification validation path algorithm (see Certificate Chain and Certification Path Validation) provided with, as inputs, that prospective certification path, the trust anchor information and possibly other inputs, is a success indication.
Trust anchor information can be, and is often, provided as a (potentially self-signed) public key certificate.
A trust store is, in turn, a list of trust anchor information that can be, and is often, a list of directly trusted public key certificates.
Trusted lists, as they are used in the EU/EEA, are a legal instrument used to provide, among other things, information on the qualified status of trust services.
Technically, they take the form of an XML structure formatted as specified in the standard ETSI TS 119 612 ([R11]).
Trusted lists can be used in a similar way to trust stores in that one can use, for instance, the public key certificates that are listed as the digital identity of qualified trust services issuing qualified certificates as trust anchors for the purpose of validating certificates, however there are significant differences between the usage of trusted lists and the usage of classic trust stores. Below is a non-exhaustive list of such differences:
-
Trusted lists can be used to determine/confirm the legal type of certificate i.e. verifying that a certificate is a certificate for electronic signature, for electronic seal or for website authentication, whereas trust store typically do not allow such determination.
-
Trusted list can be used to determine/confirm the qualified status of a certificate;
-
Trusted lists contain the status history of trust services, meaning that they allow the determination/confirmation of whether a certificate was qualified and of a particular type at a time in the past. Trust service entries are never removed from a trusted list whereas compromise of a trust anchor is usually reflected by the removal of the corresponding trust anchor information from a trust store (in a trusted list, this would be reflected by changing the current status of the corresponding trust service, while keeping the status history);
-
Trusted lists frequently (one might argue ‘mostly’) identify trust services issuing certificates through the certificates of issuing CAs, whereas trust store usually contain mostly root CAs.
A List of Trusted Lists (LOTL) is a list that contains:
-
links towards all the published EU MS Trusted Lists;
-
the certificates used to verify the signatures of these trusted lists.
In the EU/EEA context, a LOTL is published by the European Commission at a secure location that is made publicly available on the Official Journal of the European Commission (OJEU). It is available in an XML format which is suitable for automated processing. This format of the LOTL is digitally signed/sealed, which allows to assure authenticity and integrity of the LOTL. The signing certificates of the LOTL are also made publicly available in the OJEU.
The LOTL is used to authenticate EU MS Trusted Lists and to provide an easy and trustworthy way to access these TLs.
When the LOTL-signing certificates or the location of the LOTL changes, the modification needs to be published by the Commission. The update is done in the form of a “pivot LOTL”, which is a specific instance of a LOTL. Each new modification will create a new pivot LOTL. The pivot LOTLs are grouped in the current LOTL itself, under the < SchemeInformationURI> field. Consulting all the pivot LOTL from the most recent to the oldest gives a trace of all the signing certificates and locations of the LOTL back to the initial ones.
The certificate path validation is an algorithm that seeks to verify the binding between the public key and the subject of a certificate, using trust anchor information. The complete processing is described in RFC 5280 section 6.1, and as stated there, it verifies among other things that a prospective certification path (a sequence of n certificates) satisfies the following conditions:
-
for all x in {1, …, n-1}, the subject of certificate x is the issuer of certificate x+1;
-
certificate 1 is issued by the trust anchor;
-
certificate n is the certificate to be validated (i.e., the target certificate); and
-
for all x in {1, …, n}, the certificate was valid at the time in question.
Although RFC 5280 states that procedures performed to obtain the sequence of certificate that is provided to the certification path validation is outside its scope, Common PKI v2.0 part 5 section 2.1 ([R26]) provides one such possible procedure.
An intuitive approach to build a prospective certification path is to start by looking at the “Authority Information Access” (AIA) extension of the target certificate (see RFC 5280 section 4.2.2.1) which, if present, frequently includes information on how to retrieve the certificate of the issuer of that certificate. Repeating this action on the certificate retrieved can then allow to build a prospective certification path.
The wording "certificate chain" is often used interchangeably with "certification path".
In ETSI EN 319 102-1 ([R09]) however, a prospective certificate chain is defined as a sequence of certificate that satisfies the conditions a. to c. above and for which the trust anchor is trusted according the validation policy in use.
An illustration of different certificate chains/certification paths is provided in the figure below.
Although other schemes exist, we assume here that creating a digital signature value consists in the encryption of a hash computed on the signed data.
The standard ETSI EN 319 102-1 clause 4 ([R09]) provides a complete conceptual model for the creation of “AdES digital signatures”, but for the sake of simplicity we can extract from this model the following steps:
-
Receiving a (set of) document(s) or a (set of) hash(es) representing those documents, together with other inputs (such as so-called “signed attribute” values e.g. signer’s location, and constraints driving the creation of the signature such as the cryptographic algorithms to be used for the creation of the signature value);
-
Composing the “data to be signed” (DTBS) which is the data object that will be covered by the signature value (including thus the document(s) and attributes to be signed), and the associated “data to be signed formatted” (DTBSF) which can be taken as the format-specific byte-stream on which the signature value will be computed;
-
Creating the “data to be signed representation” (DTBSR) by applying the appropriate hash algorithm on the DTBSF obtained in the previous step;
-
Computing the signature value by encrypting the DTBSR using the appropriate algorithm (this is usually done by activating the private key within a “Signature creation device” (SCDev), that will perform the operation);
-
Formatting the result into a “signed data object” (SDO) complying with the desired signature format (e.g. XAdES, PAdES, etc).
As mentioned above, the activation of the private key and the operation of creating the signature value is assumed to be performed by a specific device. It is in general desirable that this device is a secure (e.g. tamper-proof) device that requires authentication for the activation of the key (e.g. using PIN codes).
When the private key contained in that device is controlled by an end-entity, this device is usually called a “signature creation device” or SCDev. This can be a local SCDev such as a smartcard, but it can also be a remote SCDev managed by a CA or TSP.
When the private key is used by a CA for signing certificates, this device is usually called a “hardware security module” or HSM.
Frequently, when the private key is under the control of a legal entity (such as when the key is used to create electronic seals) the device is also called an HSM.
Taking a very (or over) simplified model, validating a digital signature can be seen as:
-
On one hand, verifying the cryptographic validity of the digital signature value (part of it consisting in decrypting the digital signature value and comparing the decrypted value with the hash of the signed data).
-
On the other hand, verifying the validity of the signing certificate (see certification path validation).
We’ll see that even such a simplified model is useful for the purpose of introducing common concepts in digital signature validation.
Let’s imagine that we want to validate a digital signature and the time when this validation occur is denoted as Tval.
If the signing certificate successfully passes the certification path validation at Tval, and the digital signature value is cryptographically valid, one can then say that the digital signature is valid at Tval.
Now, if computing the hash of the signed data does not yield the same value as the decryption of the signature value, one can then say that the digital signature is invalid.
Beyond valid and invalid digital signature however, there are a lot of cases when one cannot determine the validity of a digital signature. Below are some examples where one cannot conclude that a digital signature is valid or invalid, in which case the validity status of the signature is indeterminate.
Let’s imagine that at Tval, when we are trying to access the certification status information, that information is unavailable (e.g. the CRL cannot be downloaded, the OCSP responder is unavailable). Then it is not possible, at Tval, to determine whether the signing certificate is valid or not because at that time we are lacking information to conclude on that validity status. Because the validity of the signing certificate cannot be determined, the validity of the overall signature cannot be determined either and the validity of the signature is indeterminate. However, this status is only indeterminate because we do not have the information that would allow us to conclude, retrying to validate the signature with more information (e.g. at a time when the CRLs can be downloaded) could result in a definite valid or invalid status.
A more complex example is when, at Tval, revocation information indicates that the signing certificate is revoked since a time indicated as Trev (which is thus < Tval).
Then at Tval, we can only conclude that the signing certificate is revoked and thus the signature cannot be determined as valid at Tval. However, this does not mean necessarily that the signature was created when the signing certificate was revoked, it may very well be that the signature was created at a time prior to Trev and that, should we have validated the signature at that time, the validation would have been successful. Therefore, we cannot conclude that the signature is invalid because we do not know in a definite manner if the signature was created before the revocation of the signing certificate.
For instance, if we had a proof that the signature existed before Trev, such as a signature timestamp indicating a time Tpoe < Trev, then using that proof of existence (POE) we can conclude that the signature was created before the signing certificate was revoked and this could allow us to produce a definite conclusion.
On the other hand, if we had a proof that the signature could not have existed before Trev, such as a content timestamp indicating a time Tcnt > Trev (a content timestamp is necessarily created before the digital signature value), then we could definitely conclude that the signing certificate was revoked when the digital signature was created and thus that the digital signature is invalid.
Another issue that can be illustrated here is when one creates a digital signature using cryptographic algorithms that are not considered secure: In such a case, it may be possible for an malicious actor to create counterfeited signed documents.
When validating a signature, it is therefore necessary to verify that the signature was created using cryptographic algorithms and parameters that are considered as secure. This is usually done by comparing a POE of the digital signature value with a sunset date for the cryptographic algorithms and parameters involved. A sunset date for a cryptographic algorithm and/or parameter is called a cryptographic constraint, and the application validating the signature usually keeps a set of such dates and cryptographic algorithms and parameters; this set is what is called the set of cryptographic constraints.
In general, the validation of a signature is made against a set of constraints, which the cryptographic constraints are a part of, that is also sometimes referred to as a signature validation policy.
The standard ETSI EN 319 102-1 specifies a complete validation model and procedures for the validation of “AdES digital signatures”, which are implemented in DSS. The result of a validation process performed according to those procedures is a validation report and an indication which can be:
-
TOTAL-PASSEDindicating that the signature has passed verification and it complies with the signature validation policy. -
INDETERMINATEindicating that the format and digital signature verifications have not failed but there is insufficient information to determine if the electronic signature is valid. -
TOTAL_FAILEDindicating that either the signature format is incorrect or that the digital signature value fails the verification.
For each of the validation checks/constraint (e.g. signature format, signing certificate validity), the validation process must provide information justifying the reasons for the resulting status indication as a result of the check against the applicable constraints. In addition, the ETSI standard defines a consistent and accurate way for justifying statuses under a set of sub-indications. This allows the user to determine whether the signature validation has succeeded and the reason in case of a failure.
The following table presents the indications and sub-indications that can be encountered at completion of a signature validation process. For a detailed description of their meaning, refer to ETSI EN 319 102-1 ([R09]).
| Indication | Sub-indication |
|---|---|
TOTAL-PASSED |
- |
TOTAL-FAILED |
FORMAT_FAILURE |
HASH_FAILURE |
|
SIG_CRYPTO_FAILURE |
|
REVOKED |
|
EXPIRED |
|
NOT_YET_VALID |
|
INDETERMINATE |
SIG_CONSTRAINTS_FAILURE |
CHAIN_CONSTRAINTS_FAILURE |
|
CERTIFICATE_CHAIN_GENERAL_FAILURE |
|
CRYPTO_CONSTRAINTS_FAILURE |
|
POLICY_PROCESSING_ERROR |
|
SIGNATURE_POLICY_NOT_AVAILABLE |
|
TIMESTAMP_ORDER_FAILURE |
|
NO_SIGNING_CERTIFICATE_FOUND |
|
NO_CERTIFICATE_CHAIN_FOUND |
|
REVOKED_NO_POE |
|
REVOKED_CA_NO_POE |
|
OUT_OF_BOUNDS_NOT_REVOKED |
|
OUT_OF_BOUNDS_NO_POE |
|
REVOCATION_OUT_OF_BOUNDS_NO_POE |
|
CRYPTO_CONSTRAINTS_FAILURE_NO_POE |
|
NO_POE |
|
TRY_LATER |
|
SIGNED_DATA_NOT_FOUND |
|
CUSTOM |
As illustrated in Signature validation (introduction), validating a signature sometimes require a proof of existence of that signature at a given time.
Such proof of existence can be given in the form of a timestamp.
A digital timestamp is an assertion of proof that a data object existed at particular time. This usually takes the form of a binding between a hash of a data object and a date and time issued and signed by a trustworthy timestamping authority.
When signing digitally, a date and time can be already included into the signature, but it corresponds to the signer computer’s local time. The latter can easily be modified prior to signing so that the time of signing is not the actual one. Thus, this signing time cannot be trusted. A trustworthy digital timestamp shall be used to prove existence of the signature (and its associated data) at a certain point in time.
This principle exists for handwritten signatures too. When a document is signed manually, it is done in the presence of a trustworthy notary, who verifies not only the identity of the signer but also the date and time of the signature.
Before explaining the timestamping process, let us define some concepts that are involved in this process
-
A Timestamp Authority (TSA) is a Trust Service Provider (cf. Trust Service Provider) that creates timestamp tokens using one or more Timestamping Units. The TSA must comply with the IETF RFC 3161 specifications (cf. [R08]).
-
A Timestamping Unit (TU) is a set of hardware and software that contains a single signing key used by a TSA.
Furthermore, in the context of digital signatures, we usually distinguish timestamps depending on the data for which they provide a proof of existence:
-
A content timestamp is a timestamp that is computed on the original data that is signed by a signature. It provides a proof of existence of the original data but not of the signature.
-
A signature timestamp is a timestamp that is computed on the digital signature value (in some case on the whole signed data object). It provides a proof of existence of the signature value.
-
An archive timestamp is a timestamp that is computed on the validation material of a signature (that is, the data necessary to validate a signature such as CRLs, OCSP responses, certificate chain, etc). They at least provide a proof of existence of that validation material, but as they are frequently in fact computed on the whole signed data object in which that validation material has been added, they often provide a proof of existence of the original data, signature value, signature timestamp, validation material, and possible other archive timestamps that are covered by them
Timestamping, the process of adding a timestamp to a signature, can be broken down into the following steps:
-
The user creates a hash of the data for which a timestamp assertion is required (e.g. signature value for a signature timestamp).
-
The user sends the hash and the digest algorithm to a TSA.
-
The TSA groups the hash, the time of stamping (current date and time) and the identity of the TSA and signs it with a private key contained in a TU.
-
The timestamp token resulting from the previous step is returned to the client.
-
The timestamp token is added to the signature of the data that was sent as a hash in the first step.
An illustration of that process for the creation of a signature timestamp is provided below:
The timestamp token created by a TSA can be considered as trustworthy because
-
the TSA is independent from the signing process;
-
the clock of the TSA is synchronized with an authoritative time source;
-
the timestamp is digitally signed by the TSA;
-
the TSA shall follow strict specifications.
Up until now, only creation of a single signature have been covered. However, in most cases multiple signatures need to be created (e.g. a contract signing by multiple parties). In such cases, it is useful to note that multiple signatures can be created in parallel or in a sequential order.
Parallel signatures are stand-alone, mutually independent signatures where the ordering of the signatures is not important. All the involved parties can receive the data at the same time and sign in any order. The computation of these signatures is performed on exactly the same hash data but using different private keys associated to the different signers. Parallel signatures can be validated independently to verify whether the associated data is validly signed.
The following schema illustrates the creation of parallel signatures:
Sequential signatures are mutually dependent signatures where the ordering of the signatures is important. A fixed signing order is defined and the next signer in the chain shall not sign before the preceding signers have signed the data. The computation of these signatures is not performed on the same data. A signer that is further in the signing chain will sign the initial data previously signed by the signers preceding him in the chain. Each signer uses his own private key to sign.
The following schema illustrates the creation of sequential signatures:
A counter signature is an additional signature applied on data that has already been signed previously. This type of signature is used to show approval of the data and signature, to confirm the authenticity of the data. The computation of a counter signature is performed on the signed data, and it is added to the signature as an unsigned attribute, i.e. after initial signature creation.
Counter signatures are often created by trustworthy entities such as notaries, doctors or attorneys. Possible use cases are rental and mortgage applications, health documents, passports and visas.
The following schema illustrates the creation of counter signatures:
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:
-
Signature Creation Policy: requirements for the signer in creating a signature;
-
Signature Validation Policy: requirements for the verifier when validating a signature;
-
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:
-
Signer: creates an electronic signature.
-
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]).
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.
Certain resources have been developed to improve the adoption of the eIDAS Regulation as well as improve information sharing about the eIDAS Regulation and related concepts.
The EU Trust Services Dashboard (EU TSD) is such a resource. It "proposes a centralized platform that enables interested parties and Digital Single Market players to easily and transparently access information and tools related to the trust services chapter of eIDAS".
It contains among others a Trusted List Browser to browse through the trusted lists of the different EU Member States.
eIDAS implementing acts have been issued and adopted by the Commission:
-
Commission Implementing Decision (EU) 2015/296: procedural arrangements for cooperation between Member States on electronic identification.
-
Commission Implementing Decision (EU) 2015/1501: on the interoperability framework.
-
Commission Implementing Decision (EU) 2015/1502: on setting out minimum technical specifications and procedures for assurance levels for electronic identification means.
-
Commission Implementing Decision (EU) 2015/1984: circumstances, formats and procedures of notification.
-
Commission Implementing Regulation (EU) 2015/806: specifications relating to the form of the EU trust mark for qualified trust services.
-
Commission Implementing Decision (EU) 2015/1505: technical specifications and formats relating to trusted lists.
-
Commission Implementing Decision (EU) 2015/1506: specifications relating to formats of advanced electronic signatures and advanced seals to be recognised by public sector bodies.
-
Commission Implementing Decision (EU) 2016/650: standards for the security assessment of qualified signature and seal creation devices.
ETSI has developed standards that can be followed to be compliant with the eIDAS Regulation.
The Token class is the base class for the different types of tokens used in the process of signature validation which are certificates, OCSPs, CRLs and timestamps. These tokens can be described as follows:
-
CertificateToken: Whenever the signature validation process encounters an X509Certificate a certificateToken is created. This class encapsulates some frequently used information: a certificate comes from a certain context (Trusted List, CertStore, Signature), has revocation data, etc. To expedite the processing of such information, they are kept in cache.
-
RevocationToken: Represents a revocation data token. It can be a CRLToken or an OCSPToken:
-
CRLToken: Represents a CRL and provides the information about its validity.
-
OCSPToken: OCSP Signed Token which encapsulate BasicOCSPResp (BC).
-
-
TimestampToken: SignedToken containing a TimeStamp.
-
PdfTimestampToken: Specific class for a PDF Document TimestampToken.
-
DSS implements the following ETSI standards for various signature forms:
-
XAdES digital signatures are compliant with ETSI EN 319 132 part 1-2 ([R01]);
-
CAdES digital signatures are compliant with ETSI EN 319 122 part 1-2 ([R02]);
-
PAdES digital signatures are compliant with ETSI EN 319 142 part 1-2 ([R03]);
-
JAdES digital signatures are compliant with ETSI TS 119 182 part 1 ([R05]);
-
ASiC signature containers are compliant with ETSI EN 319 162 part 1-2 ([R04]).
but also claims:
-
Creation and validation of AdES digital signatures are compliant with ETSI EN 319 102-1 ([R09]) and ETSI TS 119 102-2 ([R13]).
-
The determination of the certificate qualification is compliant with ETSI TS 119 172-4 ([R10]).
-
Trusted lists processes are compliant with ETSI TS 119 612 ([R11]).
-
Procedures for using and interpreting EU Member States national trusted lists, such as determining the qualified status of a timestamp or of an SSL certificate, are compliant with ETSI TS 119 615 ([R14]).
DSS is not limited to EU contexts. It can be used in non-EU contexts with all its basic functions, i.e. signing, augmentation, validation, etc.
An example would be the configuration of trust anchors (see section [TrustAnchorConfiguration]). The certificate sources can be configured from a TrustStore (kind of keystore which only contains certificates), a trusted list and/or a list of trusted lists. In case of an EU context you could use any of these three trust anchors. For a non-EU context you could use a trust store or a non-EU trusted list. However, non-EU TLs are supported by DSS only if they have the same XML structure as EU TLs, i.e. if they are compliant with the XSD schema. Another constraint is that there is no guarantee for a proper qualification determination as the non-EU TL shall also be compliant with EU regulations.