Recommendations for the implementation
of encryption and digital signatures in the
European energy sector
Recommendations to market participants
Status:
Version/release:
Revision:
Date:
ebIX
Request for comments
0.3
none
February 15, 2016
May 16, 2006
Use of encryption and digital signatures in the European energy sector
2
CONTENTS
0
MANAGEMENT SUMMARY .................................................................................................... 3
0.1
0.2
1
BACKGROUND ......................................................................................................................... 3
KEY RECOMMENDATIONS ........................................................................................................ 4
INTRODUCTION ......................................................................................................................... 5
1.1
1.2
1.3
1.4
1.5
2
ABOUT THIS DOCUMENT .......................................................................................................... 5
SCOPE OF PROJECT ................................................................................................................... 5
PARTICIPANTS IN THE PROJECT ............................................................................................... 5
REFERENCES ............................................................................................................................ 6
CHANGE LOG ........................................................................................................................... 6
BACKGROUND............................................................................................................................ 7
2.1
2.2
2.3
2.4
3
SECURITY OBJECTIVES............................................................................................................. 7
AIM OF THE DOCUMENT........................................................................................................... 8
ADDITIONAL REQUIREMENTS UPON BACK-UP PROCESSES ...................................................... 8
KEY STATEMENTS ON RECOMMENDATIONS FOR IMPLEMENTATION ..................................... 10
RECOMMENDATIONS FOR SHORT-TERM IMPLEMENTATION ............................... 11
3.1
3.2
3.3
3.4
3.5
3.6
REMARKS ON E-MAILING AND RECEIPTS ............................................................................... 11
CERTIFICATES ........................................................................................................................ 12
“VIRTUAL POST OFFICE” KEY INFRASTRUCTURE .................................................................. 13
EDI SERVER ........................................................................................................................... 13
REQUIREMENTS REGARDING ELECTRONIC INVOICING .......................................................... 14
APPLICATION IN BUSINESS PROCESSES CONCERNING METERED VALUES, MASTER DATA,
SCHEDULES ........................................................................................................................................ 16
3.7
ADDITIONAL ASPECTS OF THE SYSTEM ACCESS INVOICING BUSINESS PROCESS ................... 16
3.8
PUBLICATION OF CERTIFICATES AND REVOCATION INFORMATION ....................................... 17
4
MEDIUM-TERM RECOMMENDATIONS ............................................................................ 18
4.1
LEGAL AND TECHNICAL DIFFERENTIATIONS REGARDING ELECTRONIC SIGNATURES ........... 18
4.2
END-TO-END-SECURITY ........................................................................................................ 18
4.3
DIGITAL SIGNATURE IN E-MAILS ........................................................................................... 19
4.4
ELECTRONIC SIGNATURE OF DOCUMENTS ............................................................................. 20
4.4.1
Utilization scenarios and file formats ........................................................................... 20
4.4.2
PDF format.................................................................................................................... 20
4.4.3
MS-Office formats ......................................................................................................... 21
4.5
ASPECTS OF LONG-TERM ARCHIVING OF ELECTRONICALLY SIGNED DOCUMENTS ............... 22
4.6
WEB-SIGNING ........................................................................................................................ 23
4.7
PROJECT CONTEXT FOR THE INTRODUCTION OF THE RECOMMENDED MEASURES ................ 23
4.8
UTILIZATION IN MICROSOFT ENVIRONMENTS ....................................................................... 24
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
3
0 MANAGEMENT SUMMARY
This document is the second in a series of publications from the ebIX project “DigSig” regarding the
use of encryption and digital signatures within the European energy sector. Being defined in a general
manner, the organizational parts aim at ensuring a uniform organizational security level with regard to
electronic signature and encryption of transactions between market participants across company
boundaries.
The technical parts of the documents, defined as well in a general manner, are to ensure interoperability at a technical level even where different products or services are utilized. The political,
organizational and technical statements represent recommendations which are to enable a reliable
trustworthy infrastructure to be set up among market participants along the lines of solidarity.
These measures shall serve as a guide for implementation within companies and for subsequent
application at market interfaces. However, procedures other than proposed in the recommendations
need to be justifiable and must not impair the general level of security.
For economic reasons, market participants should be interested in making sure that the infrastructure
of confidence is not undermined. This is the only way to guarantee secure handling of electronic
business in the medium term, and to ensure that further automation steps can be managed in the light
of future developments.
0.1
Background
The energy branch as a whole is facing this next important automation step that should be
implemented multilaterally, whenever possible. Pioneer work is not required to this end; other
branches like the automobile industry have shown that automation can be realized at a reasonable
expenditure.
The liberalized energy market has created new challenges in terms of logistics, in particular with
regard to mutual billing. Rapidly organizing electronic handling of this process will generate large
synergies for all market participants. According to a study of the EU Commission, companies can rely
on cost savings of up to 72 % through pure electronic invoicing with digital signature.
In legal terms, electronic invoicing without accompanying paper documents has, for example, been
possible in Germany since 1 January 2002; when verified with a so-called qualified digital signature,
the electronic transaction is recognized as a voucher for income tax deduction. Thus, the ground has
been prepared for exploiting a considerable rationalization potential.
As a result of the development of markets, on the one hand, and of the possibilities of information
technology, on the other hand, market participants agree that secure electronic transmission of
additional market data (such as metered values, schedules and customer data) is important. A modern,
secure Business Partner Network needs to be established which organizes Electronic Data Interchange
(EDI) between market participants, and which ensures conformity with the law, interoperability,
efficiency and liability. This system, if it is to be successful, must be based on mutual confidence and
uniform rules and procedures in terms of IT security which also guarantee minimum complexity and
thus maximum economic efficiency. This can be achieved through the use of digital signatures and
encryption in communication processes.
The necessary contractual elements can be laid down in interchange agreements governing electronic
business transactions. The necessary technology has been available in the market for a long time and
quick access is possible by means of secured e-mail technology. In order to define equal security
criteria within the area of confidence going across association boundaries, and to optimally support
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
4
companies with regard to implementation, it is advisable in economic terms to define a common
security policy (PKI-Policy – Public Key Infrastructure Policy) at market interfaces.
0.2
Key recommendations
The Implementation Recommendations distinguish between short-term and medium-term
recommendations.
The recommendations concern security at the content level only (e. g. email encryption, electronic
document signatures etc.). Securing the transport level (e. g. VPN, SSL encryption etc.) is not the
subject of this document.
In all events, a Public Key procedure is recommended for cost-benefit reasons to ensure key
management at a reasonable cost.
On a short-term basis, the route between two market participants (or further partners) should be
secured. The term “virtual post office” has become established in this context although this principle is
not limited to the exchange of emails. The security level achieved this way is called “site-to-site
security”.
The benefit of a “virtual post office” is that no cryptographic infrastructure or content security
infrastructure is required at the individual workplace. Commercial products permit the use of company
keys, and provide consistent transparency of encryptions and electronic signatures for the end user.
Major applications include the exchange of metering data, bills, master data and generation schedules.
This short-term measure should be implemented by all market participants to guarantee secure
electronic data exchange between corporate partners, and to conform to data protection requirements.
Further functionalities may additionally be made available at selected, eligible workplaces in the
medium term. Rather than bilateral communication between market participants, ordering applications
(e-procurement) or electronic management of permission procedures with authorities (e-government)
will here be key drivers.
This security level is characterised by the term “end-to-end security”. Cryptographic infrastructures
(e. g. chip card/chip card readers) and/or content-security measures (e. g. virus scanners) at the
workplace are prerequisites.
Where invoices are dispatched without accompanying hard-copy documentation and the legislator
demands a qualified electronic signature as a condition for the right to deduct input tax, the “Principles
of access to data and the audit ability of digital documents” define, from a tax law perspective, the
requirements for archiving relevant in a tax investigation. Together with financial data and appropriate
sorting data (e. g. invoice number), an audit trail must be given for cryptographic key material. The
auxiliary process of archiving is therefore of special importance in these Implementation
Recommendations.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
5
1 INTRODUCTION
1.1
About this document
Within the European energy sector, electronic data interchange (EDI) using a variety of methods has
become a core business enabler over the last few years. It is no longer possible to imagine how
liberalised energy markets would function without EDI; rapid and automatic interchange and
processing of business transactions, as far as possible without human intervention, is organisationally
and economically necessary for all participants at all levels. Whether the transactions contain metering
data, invoices, customer switching information or schedules: automation brings benefits through
process optimisation. Nevertheless, there are further, fundamental considerations – political,
organisational and technical – to bear in mind, which influence implementation.
Core processes with a high-volume character require supporting processes within the organisation.
Securing EDI transactions is one such supporting process, especially in connection with transparency
and integrity of the data involved. Just as a signature gives a piece of paper legal character – e. g. from
an offer to a contract – EDI requires the same legal status for security and non-repudiation. To this
end, it is essential that a secure business partner network be established, within which electronic
business transactions for all participants are made possible. Therefore we need to promote an
infrastructure which can be trusted both by larger corporations (with their own certification
authorities) and smaller companies (who buy-in from service providers).
This can only be guaranteed by verification and confidentiality mechanisms directly associated with
the information exchanged. These mechanisms need to cover the whole range of the logical
transactions consistently. This is necessary to be able to carry out transactions in the new deregulated
market between market participants in a legally correct and clear-cut manner in terms of liability law,
and not least in an inexpensive way under technical and organisational aspects.
This document makes both short and medium-term recommendations for the implementation of digital
signature and encryption at the information level within communication processes between market
participants via Electronic Data Interchange (EDIFACT or XML). These recommendations are largely
on an organizational level, further documents will detail the technical aspects of implementation.
1.2
Scope of project
In the light of these requirements, a small project (“DigSig”) was established within the ebIX structure
to generate appropriate documentation which can then be used as a basis for implementation scenarios
on a national and/or international level. The intention is to describe the overall harmonisation
requirements for the use of encryption and digital signatures for electronic transactions within the
European energy sector; also being compatible with the following overall ebIX objectives:
1) Make recommendations of common procedures that facilitate the common open European energy
market
2) Make common standards for secure data interchange that can automate the process to reduce the
costs for the parties involved.
1.3
Participants in the project
The project is based on documents produced within the German national group (under the able
tutoring of Dr. Willi Kafitz, Siemens AG, Frankfurt) and has been coordinated for ebIX by Carl W.
Major. The following participants provided intellectual and/or financial support to the project:
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
Country
DE
DE
DK
BE
SE
NL
FI
NO
NO
SE
SE
CH
1.4
Name
Carl W. Major
Dr. Konstantin Staschus
Erik Hartwell
Hugo Dekeyser
Joachim Abrahmsén
Lodewijk ter Haar
Matti Vasara
Per M. Breistein
Ole Jacob Høyland
Oscar Ludwigs
Robert Lundin
Rudolf Baumann
6
Company
E.ON Netz
VDN
Energinet.dk
Eandis
Steria
Tennet
Fingrid
Statkraft
Statnett
Svenska Kraftnät
Steria
ETRANS
References
[1] Original project proposal, see http://www.ebix.org/
1.5
Ver.
0
0
0
0
0
ebIX
Change log
Rel.
1
1
1
2
3
Rev.
none
A
B
none
none
Date
2005-12-06
2005-12-07
2005-12-13
2006-02-28
2006-05-16
Changes
Document generated
Corrections and restructure
Further textual corrections
Comments incorporated
Publication as ebIX RFC
May 16, 2006
Use of encryption and digital signatures in the European energy sector
7
2 BACKGROUND
2.1
Security objectives
The work of the project “DigSig” is intended to gradually provide security to the branch’s business
transactions.
Accordingly, security requirements for business-to-business data interchange between market
participants are a subject-matter of this recommendation.
The authors consider that there are strong tendencies which, for security reasons, call for a response.
The main tendencies emerging are


increasing number of transactions
more open transaction paths
As a result of the increasing number of transactions, all systems (safety features and equipment
included) need to be automated to keep them controllable. This is done best within the company
concerned.
More open transaction paths are attributable to the general transition from public network
infrastructures (e. g. X.400-Box for EDI message exchanges) to Internet-based e-mail communication.
But requirements upon safeguarding the transaction range can also arise from the user perspective’s
non-transparent network infrastructures within its own company or company association. In this
context, end-to-end security is of the essence, which is generally in contradiction to centralized
solutions. This contradiction is intentional and indispensable, but from the perspective of the work
presented here it can be resolved.
Any pragmatic amelioration of the current situation is desirable.
Therefore, the steps of a gradually secure solution should in particular extend from site-to-site security
in the short term to the end-to-end security in the medium term.
Site-to-site security means that a relatively simple and cost-efficient central safeguarding entity is to
be built up first at company or division level (metered data office, accounting office, etc.) which
secures data transfer between two market participants through the public network but which, for
instance, does not yet enable signed, legally binding contractual documents to be exchanged between
two users in two different companies.
This entity, charged to guarantee site-to-site security, is referred to as a “virtual post office”.
“Virtual post offices” were publicly mentioned for the first time in a cabinet decision of 16 January
2002 specifying the application of public key infrastructures within the German federal administration,
and describing their utilization in cooperation with external bodies (authorities of the German Federal
States, companies, etc.). “Virtual post offices“ are used within public authorities, for the time being
mainly in federal authorities, in areas where confidential matters which do not fall under the category
of documents of higher security level, like “top secret“ are to be protected.
As a result of the modified utilization scenario in the electricity industry, requirements upon the
technology used have changed to an extent that would actually call for the definition of a new term. In
the context of this paper, we speak of the “virtual post office” principle in order to stick to this
expressive term without assuming the same applications and technology.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
8
Utilization of the “Virtual post office” principle




“Virtual post office” means a central solution securing data transfer between market participants
at the information level without a need for breaking this process down to individual staff
members or workstations.
Matters like liability, confidentiality, authenticity and integrity are secured on the basis of
certificates. A certificate, though being formally assigned to a natural person in a position of
responsibility, serves the proof of identity of the source, i.e. the proof of authenticity at company
level.
The transport of encrypted and/or signed data can but must not necessarily (where data are e. g.
files in a CSV format, EDIFACT messages) be carried out by e-mail (SMTP).
Electronic signatures at e-mail level are primarily considered as a proof of identity and integrity,
i.e. they are to provide security to the partner that the e-mail was not modified.
End-to-end security means here user-to-user security. End-to-end security is frequently used in
connection with network gateways (e. g. Web-WAP) where decryption and re-encryption are to be
avoided. For application examples see Chapter 4 of this document.
2.2
Aim of the document
The present document provides substantial recommendations for implementation which take account
of different company sizes and different needs, but which are to ensure similar security levels and
interoperability throughout the branch with regard to the application of security mechanisms.
At the same time it is advisable to keep track of implementations desirable for the medium term. On
the one hand, branch requirements upon security in business-to-business transactions will increase; on
the other hand, technological trends which can be utilized to meet these requirements in a costefficient manner are becoming increasingly available.
2.3
Additional requirements upon back-up processes
Encryption and electronic signatures, i.e. IT security aspects, are relatively simple security measures
which can be implemented at relatively low cost. They have the lowest share in percent in the total
expenditure assessment (“80:20 rule”).
The most important item is the organizational security that is in the broadest sense security in terms of
audit requirements in online business transactions. In this context, a distinction should be made
between aspects relating to commercial law and to tax law.
In many cases, the e-mail communication path has been used for a long time for business transactions
without taking on an audit-proof concept additionally as a basis for filing user data or at least for
logging data. Where e-mail is used as a platform for online transactions, the e-mail procedure must
satisfy the requirements of verifiability, provability, audit ability, data security and internal control, as
well as the needs of documentation and statutory periods of data retention (archiving). This applies as
well to logging data. All business processes between market participants considered in this paper
(master file data, metered data, invoices, etc.) already in the focus of the first implementation step are
relevant data according to the principles of adequate and orderly accounting or the principles of data
access and verifiability of digital documents.
It is to be expected that a higher expenditure is required for the back-up archiving process mainly in
connection with data relevant to invoices. This expenditure is particularly determined by the
requirements resulting from turnover tax legislation (including eligibility for turnover tax deduction)
and from the requirements of archiving pursuant to the “principles of data access and verifiability of
digital documents, e. g. in the context of a periodic tax examination.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
9
Apart from referencing in the archive according to commercial items (e. g. invoice number),
cryptographic data (encrypted and signed documents, keys, certificates, validation information, etc.)
need to be stored as well according to these guidelines, and to be made available “immediately” (not
within a “reasonable time”, as previously stipulated) in the case of audit. Documents in business
accounting usually need to be retained for 6 or 10 years, respectively; but as the cryptographic key
length is rated as being unsafe at an earlier stage due to technological progress, a data medium
possibly needs to be re-signed. Practicable procedures which do not require re-signature on the basis
of individual documents (e. g. “hash trees”) are being developed. Relevant products taking account of
this requirement in electronic archives are becoming available in the market.
In spite of these uncustomary and thus new requirements, efficiency analyses carried out by supply
utilities show that electronic data interchange, in particular electronic billing implies a particularly
high rationalization potential, both on the invoice issuer’s and recipient’s side.
Recommendations





Re-evaluation of data security in terms of audit security and IT security is needed prior to the
extension of electronic data interchange.
Meanwhile, e-mail has become a suitable communication means and, due to its service quality,
also a suitable transaction medium (and is already utilized today for this purpose).
Where e-mail is used as a platform for online transactions, the entire system (with the inclusion of
the e-mail system) should meet the requirements upon truth and fairness in terms of commercial
and/or tax law provisions.
The first step towards the introduction of electronic billing (of network access charges) without
accompanying paper documents should focus on the obligations to preserve books of account and
other records for a specified period according to tax law. This concerns in particular a long-term
archiving concept in accordance with the principles of data access and verifiability of digital
documents and the functions (reading, filtering, sorting) and formats (translated, encrypted,
signed) accordingly required.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
2.4


10
Key statements on recommendations for implementation
A benchmark used as a basis for the recommendations was that a minimum set of interoperability
requirements is to be met by the communication partners concerned. Non-fulfilment of these
minimum requirements may lead to technical problems. Requirements do not imply any “nice-tohaves”.
As a first step, it should be made sure that requirements concerning “site-to-site” security can be
satisfied, i.e. that the connection between communicating companies or departments is to be
protected in terms of basic commercial values like
o liability,
o authenticity,
o integrity and
o confidentiality.
This does not imply a cryptographic infrastructure (e. g. cards, readers) or content security
infrastructure (e. g. virus scanner) at staff or workstation level.

Exchanges concern
o metered data
o master file data
o invoices (on network access charges)
o schedules
through the formats EDIFACT, CSV and XML (SAP, where required, in individual cases).

In the medium term, end-to-end security requirements should be adequately taken into
consideration, i.e. protection of the aforementioned basic values is to be ensured at user-to-user
level in areas where this is appropriate under business aspects.
This requires cryptographic or content security infrastructures at the workstation of the staff member
concerned.
Focus of this implementation step is no longer only on Electronic Data Interchange but on the
exchange of particularly sensitive documents (e. g. contracts).
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
11
3 RECOMMENDATIONS FOR SHORT-TERM IMPLEMENTATION
3.1
Remarks on e-mailing and receipts
Security in electronic data interchange does not only imply cryptographic security. For instance,
invoices must have been “delivered” to make sure that further legal claims, like time limits for
payment, can be made valid. Today, conventional mail is considered to be sufficiently secure. For this
reason, particular acknowledgement procedures, like registered letter with acknowledgement of
receipt, are usually not applied for normal mailing of invoices.
In the past, e-mail delivery within a defined time frame was not necessarily reliable. However, service
quality has been considerably improved. As a consequence, electronic transmission of EDI messages,
for instance, through mandatory but somewhat cost-intensive procedures, like X.400 is decreasing.
Due to the better cost-benefit ratio, the e-mail exchange medium in the form of Simple Message
Transfer Protocols (SMTP) is being utilized increasingly. Though the SMTP protocol defines the
dialogue between the e-mail client and a receiving server, it does not define the complete e-mail
transport up to the recipient (target client). A receipt on the delivery of the mail to the recipient is not
provided for in the SMTP standard.1.
However, delivery at the company boundary, i.e. at the SMTP server is sufficient in business-tobusiness transactions and, although safe mechanisms of acknowledgement were lacking here,
procedures have now been defined on national and European levels (see documentation regarding
error and acknowledgment procedures).
The store-and-forward principle can be used on the Internet as before, if an e-mail is to be forwarded
for instance into another provider domain. To this end, the Domain Name Service (DNS) is frequently
used for the determination of the target IP address.
This principle shall not be applied in electronic data interchange at TCP/IP basis2.
These technical recommendations on parameterization of the mail system allow us to take account of
the legal requirements in terms of “delivery”. However, abuse (e. g. through “spoofing”) is still
possible.
This abuse can be excluded only by means of an acknowledgement and further means within e-mail
systems at the application level. These facilities are often switched off externally. It is recommended
here to activiate these acknowledgements in a domain-related manner for mails from the domains of
market participants. In common mail systems (such as MS-Exchange, Lotus Notes) this progress
monitoring can also be preset and adjusted by appropriate templates in such a way that automation is
possible3.
1
Here recipient means a mail user agent accessing his local or relocated mailbox. The user-specific e-mail is put
into this mailbox by the upstream mail server (mail transfer agent) or cached in a mail queue in case of
temporary unavailability of the mailbox.
2
It is rather advisable to set up a direct session between the SMTP client (sending instance) and SMTP server
(receiving instance) through the TCP-Port 25. Officially allocated IP addresses need to be used for this purpose.
3
Naturally, e-mailed user data and their protocol information give rise to new requirements in terms of
archiving. Correct e-mail archiving is often underestimated, as is shown, for instance, by the case of a German
bank which had to pay a penalty of 1.65 million US Dollars imposed by the American Securities and Exchange
Commission (SEC). Deleted e-mails had prevented investigations on investment recommendations.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
12
It is recommended replacing the open MIME format used to date by S/MIME (Secure Multipurpose
Internet Mail Extension) independently of further security mechanisms offered for instance by
EDIFACT in the form of the AUTACK signature message type.4.
It is recommended




to set up a direct SMTP connection with the server of the market participant (not via DNS), and
archiving log files;
to activate a follow-up control element “transmission confirmation” unless appropriate EDI
message types (CONTRL, APERAK, Application Error and Acknowledgement Message) are
used;
to use S/MIME independently of further security mechanisms (e. g. EDIFACT signatures through
AUTACK, XML-DSig, etc.);
to implement an archiving and logging concept which complies with adequate and orderly
accounting for business transactions via e-mail.
3.2
Certificates
A necessary prerequisite for encryption, electronic signature and authentication is certified
cryptographic key material which can be generated5 and certified through one’s own trust centre or
procured in the market (public trust centres). Currently, external procurement is the most common
solution.
Key material and certification services which can be used on condition that policy requirements are
met are also offered by companies not accredited according to Digital Signature legislation. There is
an enormous dynamic force in the market in this field so that examples are not given here. These
providers can issue X.509 certificates which meet the requirements of the electricity branch.
According to the document on technical PKI interoperability and recommendations on the certificate
structure in this series, it is currently advisable to use 1024-bit RSA keys. It is recommended to use
one pair of keys for authentication, encryption and electronic signature, respectively.
For qualified signatures (with provider accreditation) the certified cryptographic key material is
normally delivered on a secure chip card (the combination of microcontroller and chip card operating
system is certified at the E4 level) and operated with a licensed chip card reader.
On principle, software keys („soft tokens“) can also be utilized for advanced signatures.
For encryption keys, a key backup should be organized in the company concerned; signature keys are
not to be stored several times.
The application scenario should at least meet the security requirements of the Bridge-CA-initiative6.
Careful handling of this key material is dealt with in a further paper in this series. It has a substantial
influence on the security level and thus on the communication partner’s trustworthiness. Users are to
be aware of the importance of this aspect in organizational (but not in technical) terms.
4
It is true that interactive control is then also performed on the basis of superior protocol elements defined in
RFC2821; but in this way contents and protocol are no longer subject to open transmission due to encryption and
possibilities of manipulation at the transfer interface (particularly for MAIL, RCPT commands) through diverted
protocol elements are excluded.
5
see also PKI-Policy documents
6
see www.bridge-ca.org , Participation requirements
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
13
Apart from technical and organizational aspects, acceptance on the user side plays an important role.
This applies in particular to “end-to-end-security”. Particularly for end users, security should be
realized in a simple, automatic, transparent and high-performance manner.
Recommendations




Different keys for encryption and electronic signature
1024-bit RSA key with X.509 certificates
Bridge-CA minimum security requirements
At least 80 % of the security level is achieved through organizational and 20% through technical
measures.
“Virtual post office” key infrastructure
3.3
Initially, in order not to have to install cryptographic infrastructures (software or cards and readers) for
all end-user workstations, a central solution can be rapidly and efficiently established. Reasonably, the
“virtual post office” principle can be technically realized through a proxy/gateway solution. Here,
mainly messages on an e-mail transport basis are encoded or signed by a central instance (proxy or
gateway).
This does not affect the personal assignment, i.e. a personal certificate (e. g. head of the accounting
division) is to be acquired according to the registration specifications of the certification service
provider. The digital signature of this person is equivalent to a manual signature. De facto, a
comparison with a company/division stamp suggests itself – de jure it is a fully valid signature.
When applying for a certificate, it is recommended having it provided with an attribute restricting the
purpose (e. g. “only for network usage invoices”).
Several products are available in the market regarding the “virtual post office”. For German readers,
some of these products are published on a separate Internet site7.
Recommendations

Implementation of the “virtual post office” principle by means of a central solution at company
level or at the business process level (e. g. metered data department, network usage billing
department, etc.).
Formally, the certificate used is assigned to a particular person (e. g. head of the accounting
department), but its use is restricted (e. g. for invoices only). De facto the electronic signature is
like a company stamp.

3.4
EDI server
After their translation, EDI files can be signed by an EDI translator and sent in an encrypted manner.
Vice versa, signed or encrypted data can be received.
The signature is standardized both in EDIFACT and XML.
EDIFACT allows the use of the AUTACK message type which has been available since early 2003 as
DIN standard but not as an international standard. For the use of this message type, requirements in
7
http://www.virtuelle-poststelle.info/Produkte/produkte.html
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
14
terms of syntax versions have to be taken into account. DIN 16560-15 describes the signature of user
data; DIN 16560-16 describes the signature of key data (KEYMAN). Due to the restriction to the
ASCII character set, EDIFACT immanent encryption is not possible.
Both XML signatures (RFC 3075) and XML encryption are internationally standardized.
The signature and the validation can be realized automatically through the batch procedure; errors like
“invalid certificate” can be notified in an appropriate form depending on the valuation. It is possible to
combine several/many individual messages (e. g. invoices of the INVOIC message type) by means of
a collective signature. The available time frame prior to new PIN entry through an authorized staff
member should not be more than some hours, i.e. it should comprise a billing run.
Back-up processes like archiving, appropriate visualization of converted and signed data or subsequent
validation (e. g. in the case of verifications) are also important here. This applies in particular to tax
law requirements for invoices.
3.5
Requirements regarding electronic invoicing
This section explains a little more the principal technical processes behind the use of electronic
signatures (generally, signatures and encryption processes are relatively invisible to the user as far as
applications available in the market are concerned – however, an appreciation of what is going on
“behind the scenes” is beneficial). Encryption is not subject to any statutory provisions. Technically,
all cryptographic operations can be carried out on a host computer. Signatures, on the other hand, are
stipulated by law in such a way that the technical implementation is affected.
The rules for electronic signatures were laid down for the first time worldwide in the first German
Digital Signature Act of 1997. An EU Directive led to an amendment of this Act in 2001. Within the
energy industry, parity of manual and qualified electronic signatures within private law is not of
importance for a first implementation step. However, there are provisions in tax law which are
important, particularly with regard to invoicing (esp. turnover-tax relevant invoices) between market
participants, as they open up rationalization possibilities within the sector.
In Germany, for instance, legal extension of the turnover tax law has enabled electronic invoicing to
be carried out without accompanying paper documents since 1st January 2001. With a view to
restricting abuse (turnover tax evasion), only electronic invoices must be signed. Today, legislation
requires a qualified electronic signature with provider accreditation or a qualified electronic signature.
This requirement means that (according to the definition in section 2 of the Digital Signature Act) the
signature
a)
b)
must be based on a certificate valid at the time of signing and
must be generated on a secure signature generation unit.
A secure signature generation unit can be one or several chip cards (termed “personal security
environment, PSE) or a hardware security module (HSM).
The law does not require a user to enter the PIN for every signature if it is generally guaranteed, e. g.
in organizational terms, that the key holder is exclusively authorized to utilize the signature key.
Furthermore, not every invoice needs to be signed individually, but the signature can apply to a
complete invoicing sequence during an invoice run. Mass signature processes, e. g. formally signed by
the head of the accounting department, are supported in this way.
As chip cards can cope with only limited data volumes, it is important that processes which require
processing steps both on the computer and on the cryptographic micro processor be parallelized.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
15
The following example serves to assess the performance in terms of the invoice volume that is to be
coped with by the invoicing party or by the invoice recipient:








The ERP system (e. g. SAP) generates consecutively numbered invoices in the inhouse format
(e. g. IDOC).
These invoices are forwarded to an EDIFACT translator.
The translator sorts invoices according to recipients; it receives an invoice sequence of 1 to N
invoices and converts them into the EDIFACT format in the INVOIC message type.
On the same computer, the total invoice sequence is hashed by means of the secure hash
algorithm (SHA-1), i.e. a unique profile of data is set up in the form of a 160 bit number. This
process is almost independent of the data volume as it takes place within the computer. The
mean size of an EDIFACT invoice is approx. 1.5 KByte; an analogous XML format is approx.
12-15 times larger.
This number, the hash value, is sent to the signature creation unit (first I/O-operation)
Signing means encrypting this number within the chip by means of the private signature key
using the RSA algorithm (RSA Encrypt, block encryption) leading to the creation of a number
with a length of 1024 bit (signature).
This number is returned from the chip to the computer (second I/O operation).
Validation means the comparison of the newly generated hash value on the invoice recipient’s
side with the attached hash value decrypted by means of the signer’s public key. The
validation operation (public key operation) does not need to take place on the chip but can be
carried out on the computer.
The following scenario (also approved for signatures consistent with the German Digital Signature
Act) was used as an example to carry out tests (Source: Siemens Information & Communication
Networks, Trusted Networks and Applications Division, February 2003):
Infineon-Chip SLE 66CX322P
SmartCard reader Omnikey CardMan 1010 (115 Kbaud, PPS requestable)
A chip card operating system CardOS M4.01A of Siemens certified at the E4 level
With a key length of 1024 bit, a signing process including I/O operations took
0.445 seconds
on average in a test comprising more than 1000 measurements. This enables two calculations to be
processed per second with a card on the sender’s side (signature). The recipient’s side (validation)
does not pose any problems under performance aspects because all operations can take place on the
computer.
It is also possible to use several cards in parallel, as in public trust centres, which enables almost linear
scaling effects to be achieved.
For this scenario, the following general conditions need to be taken into consideration:
During the card initialization process, the operating system generates a pair of keys (here: signature
keys) on the chip. For card personalization or in the registration and certification process, the key
material is assigned uniquely to a natural person. This procedure supports a substantial security
benefit, in that the private key never leaves the secure hardware of the crypto chip. However, two
cards thus have basically different keys. For cards used in parallel, this has the effect that different
signature keys are applied in the mass signature procedure. This fact must be known to the validation
side. However, there are no negative effects accruing from this in practice.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
16
The signature release through PIN is either given each time per signature or alternatively infinite times
per session. Timer restrictions or other counting and regulation mechanisms are not provided for as
this would have a negative impact on the I/O performance. If in the case of several invoicing runs, a
PIN entry is required each time per invoice run for the release of mass signature, this needs to be
governed by the application.
Even if several chip cards are not sufficient as signature creation units for the desired performance it is
possible to use hardware security modules. The key material (belonging, e. g. of the head of the
accounting department) can be imported into the HSM by means of a standardized procedure.
NB.: Until fairly recently, hardware security modules have been assessed according to the American
FIPS 140-1 security standard which is a NIST-Standard (National Institute of Standards). On and off,
the FIPS 140 is attributed to the NSA (National Security Agency) sphere of influence. Therefore, in
the European context this standard was replaced by EAL4++.
The use of HSM will be the exception rather than the rule as far as the utilization in the electricity
industry is concerned. To date, despite being applied worldwide in high-security environments, no
HW security module but only chip card solutions have been submitted even to the German
certification procedure under the Digital Signature Act.
Recommendations

From a volume of approx. 1000 conventionally issued invoices per month, business case invoices
should show significant savings potentials through electronic (network access) invoicing without
accompanying paper documents.
3.6
Application in business processes concerning metered values, master data, schedules
In the aforementioned business processes, files are generated (e. g. EDIFACT, CSV and other formats)
and frequently transmitted by e-mail. The necessary security mechanisms can be immediately applied
on the basis of the “virtual post office” principle.
Signature and/or encryption can be carried out on the computer (advanced signature). Other legal
requirements, like for electronic invoicing, do not exist.
Recommendations



Security recommendations should be immediately implemented, at least on the basis of the
“virtual post office” principle.
Master data are to be encrypted in any case.
Data should be centrally signed to provide evidence of integrity.
3.7
Additional aspects of the system access invoicing business process
Electronic mailing of invoices eligible for input tax deduction without accompanying paper documents
is subject to legal requirements (see above).
This applies to the actual process of invoice signature but also to back-up and/or archiving processes
affecting the principles of adequate and orderly accounting.
The most important requirements are defined in the principles of data access and verifiability of
digital: according to these principles, it must be possible to archive and immediately consolidate the
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
17
data (e. g. for periodic tax examinations) in any form (e. g. SAP-IDOC, translated version, encrypted
version, reference fields like invoice number, cryptographic keys).
Particularly with regard to income tax deduction, it is advisable to have the overall system certified by
a qualified auditor. The total system must satisfy national auditing standards and can then also be used
for purely electronic invoicing (without accompanying paper documents) with income tax deduction.
This type of audit is a well-established measure. It is required for any essential change in financial
accounting systems; the result being generally submitted to the responsible regional taxation office.
Recommendations



Compilation and implementation of an overall concept based on the correlation between the ERP
system (e. g. SAP), the archiving system, EDI translator (where necessary) and “virtual post
office”
Within the framework of a consistent overall concept, signature calculation can be easily shifted
from a SmartCard to the processing computer
Audit according to relevant national auditing standards and registration, where necessary, at the
responsible regional finance office.
3.8
Publication of certificates and revocation information
Public encryption keys or the relevant certificates need to be accessible to communication partners as
the message is encrypted by the sender through these means.
Particularly (or at least) in the case of revocation, public signature keys or the relevant certificates
need to be published in a Certificate Revocation List (CRL) or through the Online Certification Status
Protocol (OCSP). CRLs must be regularly imported in the form of a signed list; the online status can
be queried via an OCSP responder. Query criterion is the certificate number; the answer is also signed
by the certification authority.
These services are also offered by a service provider/certification service provider (BUY model).
If no public certification service providers are involved (MAKE model), the information required for
communication or revocation must be made publicly available by the user himself.
Information on the key material must be accessible outside company firewalls in the so-called
demilitarized zone (DMZ) generally through the LDAP protocol. To this end, the relevant information
in an internal Corporate Directory (e. g. ADS, DIR.X, etc.) needs to be replicated into the LDAP
directory in the demilitarized zone. For this purpose, the Port 389 (LDAP) or the Port 636 (LDAP
through SSL/TLS) needs to be opened on the one hand for LDAP queries of an LDAP-client (e. g. of
another market participant), but to be protected, on the other hand, against abuse.
http access is an alternative which activates an internal LDAP query behind the firewall. First products
for this purpose are available in the market.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
18
Recommendations


An externally accessible LDAP directory needs to be set up for the provision of encryption keys
and for verification of signatures.
The LDAP directory should be accessible to a closed user group only to which the market
participants belong.
4 MEDIUM-TERM RECOMMENDATIONS
4.1
Legal and technical differentiations regarding electronic signatures
A "simple" signature is an electronic signature which is added to other electronic data and serves to
identify the sender (e. g. auto signature in MS Outlook). As it is not possible to identify subsequent
alterations to e-mail contents or to the document, the simple signature is suited only for cases where
oral or telephonic message transmission would also be sufficient. The simple signature should not be
used if security aspects are of importance.
The necessary security for external and internal correspondence is provided by "advanced"
signatures based on a user-individual certificate (cryptographic key for personal identification) and
appropriate software tools. Advanced signatures can be used in EDI transactions or for signing e-mails
and documents. Data and signature are inseparably connected.
However, a disadvantage of e-mail signatures is that multiple signing and formatting of e-mails –
e. g. according to corporate design – is not possible. Therefore, in the majority of cases in legal
transactions with non-formatable contents (non-EDI-compliant), the document signature will be
suitable. For this purpose, a document, e. g. a word file, or better a pdf file, is signed electronically and
sent as an attachment to an e-mail. This form meets the requirements of most of the existing provisions
on signature and of the corporate design for business letters. Furthermore, apart from business letters,
the document signature offers a great variety of possibilities which often can be utilized albeit only in
the medium term within a broader application environment.
A "qualified" signature is always needed where the written form is required by law (e. g. for
contracts or communication with public institutions). Qualified signatures require keys/certificates
issued by special trust centres and, in addition, appropriate smartcards and readers.
4.2
End-to-End-Security
In the medium term, it is recommended taking not only central server solutions (site-to-site) into
consideration but to invest more intensely into “end-to-end-security” at workstations where the need
for communication and data security requires this. In this respect, electronic signatures for the
protection of authenticity and integrity which are indispensable at the information level will be a
driving force. Where confidentiality is required (encryption) there are certain alternatives available at
the transport level through SSL (Secure Session Layer) or VPN (Virtual Private Network). Their
security might however be limited through recoding at gateways (e. g. Web/WAP); thus, they do not
provide end-to-end security. End-to-End-Security cannot be realized by means of gateway solutions; it
requires cryptographic infrastructures at workstations. Also content protection (e. g. virus scanning)
can be guaranteed only through appropriate measures at the workstation system itself.
As mentioned before, this applies mainly to cases where no mass transactions with formated EDIcompliant data are to be covered. End-to-end-security completes site-to-site-security, and does not
necessarily replace it. Investment protection for short-term measures recommended here is thus
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
19
guaranteed. Hybrid forms (“end-to-site security”) are feasible and reasonable in the case of different
protection needs on the recipient’s or sender’s side. First examples are known.
Two main applications need to be taken into consideration here concerning the secured
communication between concrete employees whose work stations require adequate cryptographic
infrastructures:
 e-mail signature and
 document signature.
End-to-end security with recourse to cryptographic key material in an external personal security
environment (PSE) at e-mail level may require a “plug-in” in the e-mail-client supporting the S/MIME
standard. Other solutions (without plug-in) are available.
Regarding document signature, a distinction is also to be made between two cases:
1) End-to-end security at file level (with plug-in in the application, e. g. in Word, Excel, Acrobat,
etc.)
2) End-to-end security at file level (without plug-in in the application, but e. g. at Explorer level)
 The document signature from the relevant processing tools (e. g. MS Office or Adobe
Acrobat) is preferable to the signature of any files (via Explorer).
 If archiving of the business letter and signature verifiability are required later, document
signature should be implemented in the PDF format by means of the appropriate Acrobat
Signature Plug-in.
In any case, the use of electronic signatures currently still requires that organizational and technical
details be clarified with the business partner concerned (e. g. whether the recipient is able to identify
and verify the signature). The core objective of this series of ebIX documents is to enable such
bilateral clarification processes to be reduced to a minimum in the future.
Recommendations




Signature regulations should remain valid without any changes in case they refer to competences
and not to procedures. In business, electronic signatures should be of the same relevance as
manual signatures.
This applies in particular to the differentiation between essential and unessential contents, to the
requirement of two signatures, and to the designation of employees authorized to sign.
Just as in the case of EDI through e-mail, letters signed electronically are subject to qualifications
as defined by commercial standards including specifications on the legal form, executive bodies
and if necessary entry on the appropriate Commercial Register.
As in the case of EDI, archiving requirements and, in addition, formal archiving duties which
may result from the principles of adequate and orderly accounting, but also from contractual
obligations, need to be taken into consideration.
4.3
Digital signature in e-mails
The use of e-mail signatures in the S/MIME format is limited in principle by the possibilities covered
by this standard. For instance, multiple signatures are not supported: the sender of the message is the
signer. Within the scope of e-mail functions, the message contents can be formatted only to a limited
extent. Formatting of an e-mail in corporate design is not possible. The signature is not immediately
linked with the attachment and it is not stored e. g. when only the attachment is stored (except when it
is stored with the original e-mail). For this reason, chapter 3 underlined that electronic signatures in emails primarily serve as proof of integrity.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
20
To be able to verify a signed e-mail, the recipient needs an S/MIME compatible mail client (e. g. MSOutlook 98/2000 or later, or an S/MIME-Plug-in); in addition, the recipient’s mail server should be
configured for S/MIME.
For business letters or EDI files in Excel format, transmission by means of digitally signed e-mails is
thus sufficient provided that only one signature is needed. The contents of the business letter can be
contained either in the message text itself or, if corporate design is required, in the attached document.
The signature is provided by the sender of the e-mail. In the case of documents attached to the
business letter, the sender must open these documents prior to signing by means of the relevant
processing or display tool and verify the contents.
To enable e-mails also to be represented by mail clients without security functions, it is advisable to
use the S/MIME format of the multipart/signed type.
4.4
Electronic signature of documents
4.4.1
Utilization scenarios and file formats
Irrespective of business relationships between market participants, electronic signing of documents
will continue to gain in importance due to the fact that a change of media required for manual
signatures can be avoided. Projects in the production field, in quality assurance of sensitive plants and
appliances or in the materials flow and logistics field are already known from similar areas within
other sectors. In the production field, applications with rationalization potential may offer themselves
for the exchange of engineering drawings or other frequently changed documents, for asset reviews,
test reports, measurement reports, check lists etc., and for delivery notes in the case of materials flow.
For business letters, it is advisable to sign at tool level as the document contents are displayed during
the process of signing; besides, the electronic signature can be optically represented in the signed
document. The following document formats are recommended for this purpose:


PDF (Adobe Acrobat) or
DOC (Microsoft Word, restrictedly).
Contrary to the S/MIME standard, interoperability standards for e-mails in the field of document
signature have not yet become fully established in the market and standard-conforming signature
products still need to be developed. Therefore, product recommendations are unfortunately still
necessary. The main decision criterion will be the document format. Though there exist wellestablished standards for the signature format (PKCS#7 and 3 XML variants), additive functionalities
like representation of signature fields or linkage of the signature history with the document are more
important with regard to the document signature. Currently, there are no standards available yet for
these functions.
The simple application of document signatures under acceptance aspects is best guaranteed if it can be
realized from the relevant processing tool. Multiple signatures, free formatability of the signature field
and display of contents, e. g. of a business letter, should be possible during the process of signing.
4.4.2
PDF format
A suitable document format that can be recommended with a few restrictions is PDF as the risk of
signing cryptic information is low or even excluded („What you see is what you sign“, WYSIWYS).
Moreover, PDF is a suitable common format over the entire life cycle of the document up to archiving.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
21
As a matter of principle, at least version 4.05 should be utilized as key lengths of 1024 bit are
supported from this version onwards8.
The following formats are recommended for electronic signing of PDF documents:


Adobe Acrobat 5.0 and above with signature Plug-in Mentana M-Doc Signer 2.4 or
Adobe Acrobat Approval 5.0 with signature Plug-in Mentana M-Doc Signer 2.4
Adobe Acrobat 5.0 (full version) enables PDF documents to be generated and electronically signed
from almost all current document formats. The more cost-efficient Adobe Acrobat Approval product
enables PDF forms previously created to be processed and electronic signatures to be generated in predefined signature input fields. In both cases, the electronic signature is displayed in the document. The
Self-Sign-Signature offered by Adobe Acrobat should not be used as it does not offer sufficient
security. Verification of a signed document also requires Adobe Acrobat 5.0 or Adobe Acrobat
Approval 5.0 with Plug-in M-Doc Signer; a signed PDF document can be displayed as before through
the Adobe Acrobat Reader free of charge.
4.4.3
MS-Office formats
The DOC format or the XLS or PPT format applied by Microsoft can also be used as a limited
alternative. In this case, however, it is indispensable to make sure that no cryptic information (e. g.
white text in a white field) is signed as well; this is no trivial requirement in logistic terms.
For electronic signing of DOC-type documents, it is advisable to use at least Microsoft Word 2002
(version Office XP1). The electronic signature is not displayed in the document but through an icon in
the lower status bar of Word or under “options”. The document name contains the information
“signed”. However, in this way there is no tool available at the user interface. An alteration to the
document deletes the signature after a warning sign without possibility of fallback. A history is not
compiled. Multiple signatures are possible.
Verification of a signed Word-type document also requires at least Word 2002; a signed document can
be displayed through Word 2000. It is absolutely necessary to make sure that apart from cryptic
information, non-visible file characteristics like date of creation, author, etc. are signed as well.
Office XP and M-Doc-Signer for MS-Office (and also the Internet Explorer) use the certificates/key
memory contained in the Microsoft Windows 2000/XP operating systems. Additional components are
needed if employee IDs are used as key memory.9
Product evaluation activities have not been completed; Office and Adobe Acrobat refinement is to be
followed. In the next version of its product suite, Adobe intends to support a PKI/Smartcard interface
so that additional Plug-in software will possibly be no longer required in the future.
Where necessary, product recommendations must be adjusted accordingly.
8
Already today there exist “services” which annul safety settings for 40 US-$ and decrypt older documents from previous
versions for 300 US-$.
9
The Microsoft support to the Crypto Service Provider interface (CSP) for the use of SmartCards as carrier of the key
material is achieved e. g. through a component of the Secude company.
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
22
Key statements on document signature



With regard to document signature, especially concerning functions going beyond the original
signature container format, it not yet possible to provide any information about interoperability in
the medium term.
Extensive independent standardization activities are showing in particular in the context of PDF.
Signed PDF is mainly reasonable where aspects of long-term archiving are a matter of priority.
Likewise, signed PDF documents are suitable where a change of media is to be avoided, and
where no unrestricted follow-up processing of the document, as in the Office environment, is
envisaged or where workflow processes are to be performed on the basis of forms.
Through MS-Office XP and third-party suppliers, an industry standard is emerging for Office
formats (in particular MS-WORD) which covers the protection need of rather fast-living
documents. The “final version” should be archived in a PDF format.
4.5
Aspects of long-term archiving of electronically signed documents
The aim of archiving signed documents is to retain documents over a long period, and to be able to
reproduce them as written evidence independently of the tool or operating system development. For
this reason, Office documents should normally be converted into platform-neutral formats. Generally,
these are TIFF, JPEG, ASCII and PDF.
Documents which have to be preserved for a specified period are usually stored in document
management systems, archives or simply through department filing (e. g. drives). Archiving system
und workflows are defined in a process or business-specific manner according to the respective
requirements (retention period, visual reproduction/reproduction of contents, etc.).
In contrast, archiving of electronically signed documents requires a new kind of approach.
a) Archiving system:
If the signature(s) are integrated into the file, the archiving system does not have to meet additional
requirements.
Where separate signature files of the document are to be archived, the document file and the signature
file(s) have to be inseparably linked with one another.
b) File format:
Concerning signed Office or mail files, account has to be taken of the fact that a converted long-term
archive format is not provided with the signature of the original file (which means that verifiability of
authenticity and integrity is lost).
Conclusion: A converted long-term archive format would have to be "certified".
The aforementioned problem also occurs if signed Office or mail files are directly archived. Should
reverse compatibility of tools no longer exist (e. g.: change of the operating system platform or of the
tool providers) documents need to be converted where necessary.
Conclusion: Conversions due to system migrations need to be “certified” as well.
Therefore, the aim should be to sign documents in the file format which permits subsequent
unproblematic long-term archiving and enables follow-up costs to be avoided. Though TIFF and JPEG
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector
23
are standards in terms of archiving, they are scarcely used as document exchange format. This need is
currently satisfied by the industry standard and the PDF ISO standard. “Sub-dialect” archiving is
emerging in terms of standardization.10
Recommendations:


Relevance in terms of commercial law: For contractual documents, it is recommended using the
document signature on the basis of PDF.
Relevance in terms of tax law: If the documents to be archived are relevant to taxation, additional
requirements need to be satisfied, where necessary (in particular requirements resulting from the
principles of data access and verifiability of digital documents after filtering and sorting)
4.6
Web-Signing
Web-Signing, i.e. the signature of transactions (for instance in a portal, in order to achieve a high
degree of liability) is still of minor importance within the electricity industry; therefore, this topic is
only briefly dealt with.
Basically, a distinction has to be made between two scenarios: In both cases, safeguarding takes place
at the information level; the transport level is mostly additionally encrypted through SSL in practice.
Original HTML files of a transaction are signed in the case of Native Web-Signing.
As most portal applications are based on forms, the Browser-based Adobe-Integration in conjunction
with Web-Signing is a reasonable additional scenario.
4.7
Project context for the introduction of the recommended measures
The introduction of certificate-based authentication, encryption and electronic signatures at many
workplaces is nearly always realized through introduction of a multifunctional employee ID. Apart
from its traditional function as identity card (name, photo, etc.), the multifunctional employee ID can
imply additional functions which can be distinguished into the following categories:







control of access to rooms and buildings
entrance and exit control for motorcar parking
support to data recording for time management systems
support to accounting systems (canteen, etc.)
control of access to computers, networks and applications
storage medium of cryptographic keys and certificates for the purpose of authentication,
encryption and electronic signature
possibly additional functions
In most cases, the functionalities described are made available through a multifunctional chip card
(SmartCard) which, apart from the plastic corpus, contains further elements, such as


magnetic strips (mainly on account of compatibility with existing applications)
contact chip with cryptographic functions
For long-term archiving of electronic signatures, requirements can be delimited through „key questions“: How
long are items to be archived (e. g. 6 years: invoices without subsequent signature; 10 years: business letters with
subsequent signature; 30 years: contracts with indeterminate subsequent signature)?; is migration required (e. g.
new versions of display tool)?; Is a history needed (new signature to alterations, are previously signed statuses
identifiable)?; are multiple signatures required (e. g. internal administrator, external auditor)?
10
ebIX
May 16, 2006
Use of encryption and digital signatures in the European energy sector

24
contactless chip
Cards with these characteristics are also called hybrid cards. One chip with both contacting and noncontacting access will possibly be available in future.
4.8
Utilization in Microsoft environments
From a strategic perspective, the implementation of this security strategy into concrete product
functionality has been put to the test by the Microsoft initiative “Trustworthy Computing”11 This
initiative stands for interoperability and standards though these standards are not put in concrete terms.
The analysis of PKI functionalities in Windows 2000/2003 and Windows XP and relevant
requirements upon interfaces have shown that Microsoft as industry standard and PKIX as open
standard are not conflicting in essence. This applies today also to standards like S/MIME or ISISMTT.
Naturally, a further refinement cannot be precisely predicted and thus remains to be awaited.
However, it is likely that Microsoft does not want to occupy PKI-markets through proprietary but
through standard-conforming “out-of-the-box” provision in product components, e. g. within the scope
of the .NET strategy.
Vice versa, past experience has shown that especially the refinement of security functionalities at the
Microsoft platform opened up a field of activity to smaller product and solution providers.
An example of ready-made hardware solutions on the Microsoft platform is given below:



ISIS-MTT can be given as an example of practice-oriented interaction of established standards
like PKIX and S/MIME.
Microsoft, as an important platform provider, complies today with these standards and does not
question them in the near future.
Microsoft is registered with TeleTrusT as an ISIS-MTT-application developer.
See e. g. Whitepaper on „Trustworthy Computing“ on http://www.microsoft.com/presspass/exec/craig/1002trustworthywp.asp with additional links.
11
ebIX
May 16, 2006