CEN/ISSS WS/BII-2
Application of Electronic Signatures
Technical Guideline
Version: 0.3
Released: 2012-05-07
Date of approval:
Page 2
BII xxx
TABLE OF CONTENTS
1 Preamble .................................................................................................................................... 3
2 Introduction ................................................................................................................................ 4
3 Electronic signatures .................................................................................................................. 5
3.1 What is an electronic signature? ............................................................................................ 5
3.2 Uses of electronic signatures ................................................................................................. 8
3.3 Advanced electronic signatures.............................................................................................. 9
3.4 Qualified signatures ............................................................................................................... 9
3.5 Categories of XML electronic signatures ................................................................................ 9
3.6 XML Signature Standards .................................................................................................... 10
4 Requirements for applying electronic signatures ...................................................................... 12
5 Recommendations for applying electronic signatures ............................................................... 13
Page 3
BII xxx
1 Preamble
The objective of the second phase of the CEN Workshop on Business Interoperability
Interfaces for public procurement in Europe – CEN WS/BII2 – is to provide a framework for
interoperability in pan-European electronic procurement transactions, expressed as a set
of technical specifications that cross-refer to relevant activities, and in particular are
compatible with UN/CEFACT - in order to ensure global interoperability. The workshop is
focusing on implementation facilitations and co-ordinating pilots implementing the technical
specifications output. The requirements and final specifications are input into UN/CEFACT.
The original CEN ISSS BII workshop was concluded in December 2009, and its results
were issued as CWA 16073:2010. In early 2010, a second Workshop – CEN BII2 – was
initiated to follow up on and improve the work created in the first workshop. The purpose of
the second phase of the workshop on Business Interoperability Interfaces for public
procurement in Europe is to establish a forum for development and governance, by:

Providing technical support for adopters and implementers of the BII
deliverables;

Providing a forum for governance, life cycle management and further
refinements of the CWA published by CEN WS/BII;

Contributing to coordination and harmonization amongst European initiatives
addressing various aspects of e-procurement;

Actively cooperating with the relevant organisations to ensure that European
requirements are catered for in international standards and initiatives.
Page 4
BII xxx
2 Introduction
The purpose of this document is to provide a technical guidance on how to apply electronic
signatures in business documents when needed. It is not the purpose of this document to
define the situations where economic operators or contracting authorities have to apply
electronic signatures. This is a legal issue that has to be further developed at legal level.
Nevertheless, even using paper, some documents exchanged during public procurement
processes require the signature of the issuer. A signed document is used to commit the
signatory to the contents of the exchanged document. There are several documents in
public procurement that can potentially require a signature: A tender document, a
certificate or a notification of awarding requires the signature of a relevant person.
Sometimes a signature is used to commit an organization to deliver the offered products or
services following the conditions stated in a tender, other times the signature is a proof of
authenticity, to ensure the issuer has enough rights to issue it.
Guaranteeing the authenticity of the issuer, the integrity of the message and avoiding
repudiation of its contents by the submitter are requirements that must be preserved when
moving from paper to electronic processes.
There are several technical tools and standards that allow XML documents to be digitally
signed. This report will focus on XML standards for electronic signatures and will explain
the way they can be applied to CEN BII2 conformant document instances.
CEN BII2 is syntax neutral and the application of electronic signatures is syntax-specific,
therefore this report will define of a set of high-level requirements and a brief
recommendation on how to apply these electronic signatures to XML-based documents.
The type of signature and its format to be used when signing XML documents must be
based on recommendations from the European Commision to leverage interoperability.
Page 5
BII xxx
3 Electronic signatures
3.1 What is an electronic signature?
An electronic signature is a mathematical scheme for demonstrating the authenticity of a
digital message or document. The EU Directive1 describes the electronic signature as
“data in electronic form which are attached to or logically associated with other electronic
data and which serve as a method of authentication.”
A valid electronic signature gives a recipient a reason to believe that a known sender
created the message, and that it was not altered while exchanged.
There are several ways of digitally signing an electronic message. All of them are based
on a key, a digest of the message and an encryption algorithm to encrypt the digest.
The encrypted digest is the electronic signature.
Mathematically, signing a message is the result of applying an encryption algorithm with a
key to the message digest. The message digest is the product of applying a hash function
to the message.
Figure 1 Signature process
To verify an electronic signature, the receiver has to calculate the message digest again,
and compare it to the result of decrypting the electronic signature.
1 EU DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 13 December 1999
Page 6
BII xxx
Figure 2 Verification process
3.1.1 Message digest
The sender creates a digest of the document using a mathematical algorithm. These
mathematical algorithms are known as hash functions, and they take a message of any
length as input, and output a short, fixed length digest or hash.
For good hash functions, it is almost impossible to find two messages that produce the
same hash.
The result of applying a hash function to a file has several features:
1. If the content of the file changes, the resulting hash is different.
2. It is impossible to recover the file contents from the hash. There is not an inverse
hash function.
3. Applying the same hash function to the same message will always result in the
same hash.
Page 7
BII xxx
These features allow preserving the integrity of a message: If a signed message is
modified, when the receiver calculates the hash to verify the signature, he will get a hash
different from the hash decrypted using the signature algorithm and the private key.
3.1.2 Private key
A private key is a token used to encrypt the message hash using an encryption algorithm.
Binding the private key to a particular user is the base for authenticating the identity of the
signer and for avoiding repudiation of his authory; both features implicit in electronic
signatures.
If this key is bound to a person and no one else can get access to it, the receiver will trust
the signer has issued the signed document.
As described above, the receiver has to decrypt the encrypted hash in order to verify the
signature. To decrypt the encrypted hash, the receiver needs to get a decryption key. This
key allows the receiver:

To get the original hash of the document, and compare it to the calculated hash to
ensure they are equal, verifying the document integrity,

To ensure the private key owner issued the signature, proving his identity as the
signer and preventing repudiation.
To enable encryption and decryption of a hash, there are different types of cryptography:

Symmetric-key cryptography: The same key is used to encrypt and to decrypt the
digest; hence issuer and receiver need to share the key to sign and verify the
signature.

Asymmetric (or public key) cryptography: Uses pairs of keys, one is kept secret and
is used to encrypt a hash (sign), while the other is made public and is used to
decrypt the hash (verify the signature).
Asymmetric cryptography is being widely adopted because the signer can keep the private
key to create electronic signatures whilst publishing the public key for others to verify. A
significant disadvantage of symmetric ciphers is the key management necessary to use
them securely. It is easier to publish a public key than sharing a private key as required in
the symmetric cryptography.
In asymmetric cryptography, the way a user publishes his public key can be done in
different ways:

Peer to peer, directly sharing public keys among a community of users. The trust is
built due to personal relationships; it is based on the fact you trust on your peer.
Trust relationships have a network effect.

Public Key Infrastructure, where a third party acts as a trust maker. The third party
is known as Certification Authority and issues a certificate. A certificate is the public
key of a user signed by the Certification Authority that has proven the identity of the
owner of the private key associated with the signed public key. Trust is created as a
chain. A receiver trusts in the Certification Authority so it trusts on all the users that
have a certificate issued by them.
Page 8
BII xxx
As this token is secret and only known by the issuer of the signature, the recipient of the
signed message can believe on the authenticity of the origin of the signature if he can
decrypt it.
But the token, the private key, is a string of bits stored in a file. Even if it can be protected
with a password, to ensure that a private key is only used by its owner is one of the most
important challenges in electronic signature processes. Storing the private key in a
cryptographic hardware device such as an smartcard or a USB cryptographic token are
common ways to securely bind the user with his private key, nevertheless, even in these
cases there are possibilities of loss of the device and impersonation.
3.1.3 Signature algorithms
There are two main algorithms related with electronic signatures:

A signing algorithm that, given a message and a private key, produces a signature
(see figure 1 above).

A signature verifying algorithm that, given a message, public key and a signature,
either accepts or rejects the message's claim to authenticity (see figure 2 above).
Two main properties are required for these two algorithm types:
1. First, a signature generated from a fixed message and fixed private key should
verify the authenticity of that message by using the corresponding public key.
2. Secondly, it should be computationally infeasible to generate a valid signature for a
party who does not possess the private key.
3.2 Uses of electronic signatures
Electronic signatures in public procurement have different uses. When moving away from
paper documents with ink signatures or authenticity stamps, electronic signatures can
provide added assurances such as identity, evidence of provenance, acknowledgment or
consent and approval.
Common reasons for applying a electronic signature to electronic documents are
described below.
3.2.1 Authentication
Although messages may often include information about the entity sending a message,
that information may not be accurate. Electronic signatures can be used to authenticate
the source of a message. When ownership of an electronic signature private key is bound
to a specific user as explained above, a valid signature shows that the message was sent
by that user.
3.2.2 Integrity
In public procurement business processes, it is important to ensure that the exchanged
message has not been altered during transmission. When a message is electronically
signed, any change in the message after signature will invalidate the signature.
Furthermore, there is no efficient way to modify a message and regenerate the signature if
the attacker does not have access to the private key of the original issuer.
Page 9
BII xxx
3.2.3 Non-repudiation
Non-repudiation of origin is an important feature of electronic signatures. By this property
an entity that has signed some information cannot at a later time deny having signed it.
3.3 Advanced electronic signatures
The European Directive 1999/93/EC defines four technology-neutral requirements that an
electronic signature must meet to be considered an Advanced Electronic Signature (AdES)
and have legal validity:

The signature has to be uniquely linked to the signatory;

It must be capable of identifying the signatory;

It must be created using means that the signatory can maintain under his sole
control; and

It must be linked to the data to which it relates in such a manner that any
subsequent change of the data is detectable.
3.4 Qualified signatures
A Qualified Signature is defined as an AdES based on a Qualified Certificate and issued
using a Secure Signature Creation Device (SSCD).
Qualified Certificates are certificates issued by accredited Certificate Service Providers.
An SSCD is defined by European Directive 1999/93/EC as a device that must, by
appropriate technical and procedural means, ensure:

The signature-creation data used for signature generation can occur only once, and
that its secrecy is reasonably assured.

The signature-creation data used for signature generation cannot, with reasonable
assurance, be derived and the signature is protected against forgery using currently
available technology.

The signature-creation data used for signature generation can be reliably protected
by the legitimate signatory against the use of others.

Secure signature-creation devices must not alter data to be signed or prevent such
data from being presented to the signatory prior to the signature process.
European legislation makes Qualified Signatures equivalent to handwritten signatures.
3.5 Categories of XML electronic signatures
An XML signature may be described as detached, enveloping, or enveloped.

Detached. The signature applies to an external XML document that can be
identified via a URI or transform. Consequently, the signature is "detached" from the
content it signs. This definition typically applies to separate data objects.
Page 10
BII xxx
Figure 3 Detached signature

Enveloping. The signature applies to content found within an element of the
signature itself.
Figure 4 Enveloping signature

Enveloped. The signature applied to the XML document is contained in the XML
document itself. Implementations of enveloped signatures must take care not to
include the signature in the calculation of the signature value.
Figure 5 Enveloped signature
3.6 XML Signature Standards
3.6.1 XMLDSig
XMLDSig is a W3C standard that defines basic rules for creating and processing electronic
signatures of XML documents.
Page 11
BII xxx
The XMLDSig standard defines the XML structure for expressing the signature and related
data, the processes for signature creation and verification, as well as the accepted
algorithms for canonicalization and transformation of data allowed.
The structure of an XMLDSig is as follows:
<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms>
<DigestMethod>
<DigestValue>
</Reference>
<Reference /> etc.
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>
Where:
The SignedInfo element contains or references the signed data and specifies what
algorithms are used when the signature has been created.
The CanonicalizationMethod and SignatureMethod elements are used to create
the SignatureValue element (the actual signature) and are included in SignedInfo to
protect them from tampering.
Within the SignedInfo element, one or more Reference elements can be defined to
specify the resource being signed by URI reference; and any Transforms to be applied
to the resource prior to signing.
DigestMethod specifies the hash algorithm that was applied to the document.
DigestValue contains the result of applying the hash algorithm to the transformed
resource.
The SignatureValue element contains the Base64 encoded signature result - the
signature generated with the parameters specified in the SignatureMethod element - of
the SignedInfo after applying the algorithm specified by the
CanonicalizationMethod.
KeyInfo element optionally allows the signer to provide recipients with the key that
validates the signature, usually in the form of one or more X.509 digital certificates.
The Object element is optional and contains the signed data if this is an enveloping
signature
Page 12
BII xxx
4 Requirements for applying electronic signatures
High-level requirements for applying electronic signatures to CEN BII2 conformant XML
document instances:
DS-1
An electronic signature must be applied to the whole XML document instance
(excluding the signature itself when using enveloped signature).
DS-2
The presence of an electronic signature in a XML document instance should not
add any constraints on processing document content.
DS-3
Whether an electronic signature exists in an XML document instance, personal
signatory data contained in the electronic signature will override signatory
metadata in the document instance, if any.
DS-4
Documents and their electronic signatures should be kept together, ideally in a
single file, therefore enveloped signatures are recommended.
DS-5
Commission Decision on Signature Formats from February 2011: http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:053:0066:0072:EN:PDF
for XADES-BES/EPES must be followed. ETSI ESI Technical Specifications
“Baseline Profiles” for XAdES2 must be followed.
2
ETSI TS 103 17
Page 13
BII xxx
5 Recommendations for applying electronic signatures
As per the requirements above, when applying electronic signatures to XML instances, the
following recommendations should be followed:
Specification /
method
Recommendation
Supported Rational
requireme
nt
Method of applying
a signature
Enveloped
DS-1
DS-2
DS-4
DS-5
Validation process
The placeholder for
DS-2
electronic signatures
DS-2
should have an attribute DS-4
processContents="
skip"
The XSD schema validator
for the document must be
able to skip structure
validation of the electronic
signature.
Signature format
Follow EC and ETSI
recommendations
XAdES-BES/EPES3
Refer to CEN-ETSI specific
standards and
recommendations.4
3
DS-3
DS-5
A detached signature could
fulfil most of the
requirements except DS-4.
An enveloping signature
mandates the processing of
a signature object to extract
the document.
http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2011:053:0066:0072:EN:PDF
4 ETSI ESI is currently working on the EC standardisation Mandate 460 "Rationalised
framework for electronic signature" to end up creating European Norms to harmonize the
use of electronic signatures in cross-border scenarios. As per Mandate 460, ETSI ESI is
describing the technical specifications fulfilling the EC Decision as “Baseline Profiles” for
all AdES signatures, and XAdES among them. http://www.e-signatures-standards.eu/