This document provides an overview of basic concepts for the ekoSign senior project. It discusses digital signatures and how XML can be used to achieve success in e-business processes. It describes the business challenges of information flows in a supply chain and how a company's policies can define authorization levels for internal, external, and internal departmental information flows. It also outlines the process for signing documents, including retrieving certificates and submitting signed documents. Finally, it explains the structure of XML documents and how XML digital signatures can provide authentication and integrity for business transactions.
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Basic concepts
1. SENIOR PROJECT 2007-2008
(Basic concepts of the ekoSign project)
3. Basic Concepts
XML Digital Signature:
Use and Adaptation to
Achieve Success in E-business
Processes
Project team members
Hüseyin Çakır, Mehmet Mesut Özışık, Yılmaz Kaya
Abstract:This paper presents basic concepts that are needed during project implementation. At first part of
the document the description of supply chain and it's elements are explained with motivation to the business
challenges, company policies in an organization and some terminologies about XML Signature including
digital signatures.
Keywords:Digital signature, e-business, supply chain, XML signature.
http://groups.google.com/group/digitalsignature
digitalsignature@googlegroups.com
PRINT DATE: 12/25/07
1
2. During 80s business start to be conducted over internet especially after emergence of high speed
communication networks as a result of this a lot of companies try to carry their internal and external
operations using digital rather than traditional manual documentation. Constructing new procedures
in data exchange become highly needed to fulfill e-commerce mechanisms. At this point XML
become the most important source to be used in digital signature processes. XML Signature helps
business actions to be authenticated and made accessible in business processes.
There are also some shortcomings of the current XML signature procedures, first of all current
technology is capable of providing signing capabilities for final document however in business
logic there is a significant need to construct partial document ownership. Signature binding to the
whole document is not a feasible solution in e-business, in fact participants in business need to
make individual modifications on the document.
According to Gupta, partial document ownership involves assigning ownership of the content to an
individual when that individual changes part of a document. Clearly, partial document ownership
requires that a document be recognized as a collection of objects [1].
3.1 Business Challenge
To understand business challenges, initially we had to understand supply chain concept in business.
Supply chain consists of all stages involved directly or indirectly in fulfilling customer requests. As
emphasis is on the customer, companies are reassessing their supply-chain processes. For
companies to succeed, today's supply chains must be quick enough to respond to customer
demands.
In supply chain there are five main stages suppliers, manufacturers, distributors, retailers and
customers. Also there are three types of flows product, information and fund. Information flow is
the main issue to focus in digital signature processing. Information deeply affects every part of the
supply chain. Its impact is easy to underestimate, as information affects a supply chain in many
different ways. Consider the following;
1.Information serves as the connection between various stages of a supply chain, allowing them to
coordinate and maximize total supply chain profitability.
2.Information is also crucial to the daily operations of each stage in supply chain [2].
In business, flows can be classified in two categories as internal flow and external flow. Figure 3.1
is the main motivation of our project which underlies the tree main information flow:
•
•
Information flows inside the company between departments which is called internal flow.
Information flows coming from outside of the company which are called external flow and
information flows inside the departments themselves.
2
3. Figure 3.1 Internal & external information flows.
Our concern is to make information flows more efficient in a business structure by using XML in
work flow applications. In work flows documents are moving around a community of people who
perform particular tasks in business. XML is the best source to use in these application as XML has
a structure like paper documents people are already using.
To analyze work flows more concretely ; we have to think more technically, in traditional way of
handling of information flow, data is kept in a database and when needed ad-hoc queries are used
to get them, but this approach does not support the work flow. Typically in a document-based work
flow, a document goes through a number of iterations as different people add to its content so XML
structure is more effective to manage data on a work flow.
3.2 Company Policy
Policies are high-level documents that represent corporate philosophy of an organization. In
addition to the corporate policies, an organization should also define lower level of policies for
departments and individual divisions. These lower level policies should have aligned philosophies
with corporate level policies. Information system management policy is also one of the lower level
policies that reflect the implementation of policies and procedures developed for various
information system related management activities. Information system management policies will
often set the stage in terms of what tools and procedures are needed for the organization in other
words they are the frameworks for defining how a particular work should be performed.
The project team should set a clear policy direction in line with business objectives and demonstrate
support for, and commitment to, information security through the issue and maintenance of an
information security policy across the organization [3].
Company policy will be constructed according to these three flows; Internal organization flows,
external organization flows and flows inside company's departments.
The XML documents' structure will be used to create policy levels. For instance, a company
maintains it's order records in XML. Each record consist of the order name, order priority, order
time and digital signature.
•
Nodes inside Sales Department of the company (information flow inside department) is
allowed to see the entire order record, and modify order records so will have a most authorized
digital signature.
3
4. •
•
Internal nodes (other department e.g. Warehouse) are allowed to see the order name,order
priority and order time, and only modify order time.
External nodes are only allowed to see the order name, order priority and order time. Cannot
modify any part of the record.
So all these nodes must have different levels of authorization according to their positions at
company policy. Moreover, every nodes has different level of authorization. For instance, Sales
Managers' authorization level is different than Sales Representatives'. While Sales Managers are
allowed to sign documents that has high order costs Sales Representatives cannot sign these type of
documents as a result of company policies defined by the organization.
3.3 Process Flow for Document Signing
Figure 3.2 presents the conceptual diagram of a prototype document signing system. The system
involves an integration of digital signature technology with organizational sign-on initiatives and a
document management system.
Figure 3.2 The process flow for document signing.
The process flow for document signing as follows;
Retrieve certificate: Before starting to sign documents with a digital signature, users need to
download a personal certificate from a certificate server to their PC. This can be done by submitting
on-line authentication to the certificate server or by using plug-in certificate tools (e.g. RSA's web
passport.). Certificate can be stored in user's PC for future use or deleted after signing.
Obtain the document: Users can download document from any file server in use. When user is
checking out a document, other users can be prevented from obtaining that document with write
access. However, many file servers write file information to the documents, which in turn,
invalidates digital signatures.
Signing the document: User can use digital signature plug-in tools that are compatible with
document creation software to sign or validate signatures on document.
Submit the signed document: After signing a document, users can check document back into file
server, which then lets other authorized users have complete access to it.
Locking down the document: When all individuals of the contract process have signed in the
document, the document can be locked down and moved to an access-controlled directory in the
file server [1].
4
5. 3.4 Extensible Markup Language (XML)
XML is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to
meet the challenges of large-scale electronic publishing, XML is also playing an increasingly
important role in the exchange of a wide variety of data on the Web and elsewhere. The XML
standard has been developed and quickly a large number of software vendors have adopted the
standard. XML will be the most common tool for all data manipulation and data transmission.
The features that make XML so powerful for business transactions (e.g. , semantically rich and
structured data, text-based, and Web-ready nature) provide both challenges and opportunities for the
application of encryption and digital signature operations to XML-encoded data. For example, in
many work flow scenarios where an XML document flows stepwise between participants, and
where a digital signature implies some sort of commitment or assertion, each participant may wish
to sign only that portion for which they are responsible and assume a concomitant level of liability.
Older standards for digital signatures provide neither syntax for capturing this sort of highgranularity signature nor mechanisms for expressing which portion a principal wishes to sign.
As XML becomes a vital component of the emerging electronic business infrastructure, we need
reliable, secure XML messages to form the basis of business transactions. One key to enabling
secure transactions is the concept of a digital signature, ensuring the integrity and authenticity of
origin for business documents. XML Signature is an evolving standard for digital signatures that
both addresses the special issues and requirements that XML presents for signing operations and
uses XML syntax for capturing the result, simplifying its integration into XML applications [4].
3.4.1 Layout of an XML Document
XML divides documents into two main parts which are;
•
•
Plain part of document. (Users insert their messages which they need to send.)
XML Signature part. (Signatures that constructs signature process according to polcies.)
A basic example to use of XML for a company can be seen below. The whole document is covered
as a root element "progressReport". In the root element there are two departments "Sales
Department" and "Warehouse" that are communicating with each other through the
"plainPartOfDocument". Security issues can be controlled by "digitalSignature" element. Both two
departments have different signatures related to their part of the document's content (Figure 3.2) .
Figure 3.3 General layout of XML.
5
6. <progressReport>
<salesDepartment>
Plain part of
document
for Sales
Department at
our example
<plainPartOfDocument>
X-product stock out!, new shipment
needed.
</plainPartOfDocument>
Sample Digital
Signature
<digitalSignature>
X6fshSf45ZS63a56ta35
</digitalSignature>
</salesDepartment>
<warehouse>
Plain part of
document
for Warehouse at
our example
<plainPartOfDocument>
Distribution of X- product is waiting
to be approved.
</plainPartOfDocument>
Sample Digital
Signature
<digitalSignature>
sf789HaODh67s8h7shs7
</digitalSignature>
</warehouse>
</progressReport>
Figure 3.4 Detailed document layout.
One of the most important benefits of XML is its extensibility. This feature can be used in our
example by adding another department "management" into the "progressReport". XML is also
platform-independent so that documents can be used on various systems.
<management>
<plainPartOfDocument>
MESSAGE
</plainPartOfDocument>
<digitalSignature>
adgX8d6g686g6A6dgsKCkvm
</digitalSignature>
</management>
6
7. 3.4.2 XML Digital Signature Concept
Digital signatures are important because they provide end-to-end message integrity guarantees, and
can also provide authentication information about the originator of a message. In order to be most
effective, the signature must be part of the application data, so that it is generated at the time the
message is created, and it can be verified at the time the message is ultimately consumed and
processed.
An XML signature would define a series of XML elements that could be embedded in, or otherwise
affiliated with, any XML document. It would allow the receiver to verify that the message has not
been modified from what the sender intended.
The XML-Signature Syntax and Processing specification (abbreviated in this article as XML DSIG)
was a joint effort of the W3C and the IETF. It's been an official W3C Recommendation since
February 2002 [5].
A top-level of XML Signature document is fairly simple. It has information about what is being
signed, the signature, the keys used to create the signature, and a place to store arbitrary
information:
<element name="Signature" type="ds:SignatureType"/>
<complexType name="SignatureType">
<sequence>
<element ref="ds:SignedInfo"/>
<element ref="ds:SignatureValue"/>
<element ref="ds:KeyInfo" minOccurs="0"/>
<element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
There are eight main concepts that is used in the XML layout :
•
•
•
•
•
•
•
•
Id
ds:SignatureValue
ds:Object
ds:SignedInfo
ds:KeyInfo
Reference Element
Transforms Element
Manifest Element
Id
The global Id attribute allows a document to contain multiple signatures, and provides a way to
identify particular instances. Multiple signatures are common in business policies, such as when
both the manager and the Travel Office must approve a trip application.
7
8. ds:Signature Value Element
This element contains the actual signature. As signatures are always binary data, XML DSIG
specifies that the signature value is always a simple element with Base64-encoded content:
<element name="SignatureValue" type="ds:SignatureValueType"/>
<complexType name="SignatureValueType">
<simpleContent>
<extension base="base64Binary">
<attribute name="Id" type="ID" use="optional"/>
</extension>
</simpleContent>
</complexType>
ds:Object Element
An XML DSIG can cover multiple items. An item will often be able to stand on its own, such as a
Web page or XML business document, but sometimes an item is best treated as metadata for the
"true" content being signed. For example, the data might be a "property" of the signature, such as a
time stamp for when the signature was generated.
The ds:Object element can be used to hold such data within the Signature:
<element name="Object" type="ds:ObjectType"/>
<complexType name="ObjectType" mixed="true">
<sequence minOccurs="0" maxOccurs="unbounded">
<any namespace="##any" processContents="lax"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
<attribute name="MimeType" type="string" use="optional"/>
<attribute name="Encoding" type="anyURI" use="optional"/>
</complexType>
ds:SignedInfo Element
The content of ds:SignedInfo can be divided into two parts, information about the SignatureValue,
and information about the application content, as we can see from the following XML Schema
fragment:
<element name="SignedInfo" type="ds:SignedInfoType"/>
<complexType name="SignedInfoType">
<sequence>
<element ref="ds:CanonicalizationMethod"/>
<element ref="ds:SignatureMethod"/>
<element ref="ds:Reference" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
8
9. ds:KeyInfo Element
Recall that content is protected by using indirection: the ds:SignatureValue covers the
ds:SignedInfo, which contains ds:References that contain the digest values of the application data.
Change any of those things, and the chain of math computations is broken, and the signature won't
verify.
The only thing left to do is to identify the signer, or at least the key that generated the signature (or,
more cryptographically, the key that protects the digest from being modified). This is the job of the
ds:KeyInfo element:
<element name="KeyInfo" type="ds:KeyInfoType"/>
<complexType name="KeyInfoType" mixed="true">
<choice maxOccurs="unbounded">
<element ref="ds:KeyName"/>
<element ref="ds:KeyValue"/>
<element ref="ds:RetrievalMethod"/>
<element ref="ds:X509Data"/>
<element ref="ds:PGPData"/>
<element ref="ds:SPKIData"/>
<element ref="ds:MgmtData"/>
<any processContents="lax" namespace="##other"/>
<!-- (1,1) elements from (0,unbounded) namespaces -->
</choice>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
Reference Element
Reference is an element that may occur one or more times. It specifies a digest algorithm and digest
value, and optionally an identifier of the object being signed, the type of the object, and/or a list of
transforms to be applied prior to digesting. The identification (URI) and transforms describe how
the digested content (i.e., the input to the digest method) was created. The Type attribute facilitates
the processing of referenced data. For example, while this specification makes no requirements over
external data, an application may wish to signal that the referent is a Manifest. An optional ID
attribute permits a Reference to be referenced from elsewhere [6].
<element name="Reference" type="ds:ReferenceType"/>
<complexType name="ReferenceType">
<sequence>
<element ref="ds:Transforms" minOccurs="0"/>
<element ref="ds:DigestMethod"/>
<element ref="ds:DigestValue"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
<attribute name="URI" type="anyURI" use="optional"/>
<attribute name="Type" type="anyURI" use="optional"/>
</complexType>
9
10. Transforms Element
The optional Transforms element contains an ordered list of Transform elements; these describe
how the signer obtained the data object that was digested. The output of each Transform serves as
input to the next Transform. Examples of transforms include but are not limited to base64 decoding
[MIME], canonicalization [XML-C14N], XPath filtering [XPath], and XSLT [XSLT] [6].
<element name="Transforms" type="ds:TransformsType"/>
<complexType name="TransformsType">
<sequence>
<element ref="ds:Transform" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="Transform" type="ds:TransformType"/>
<complexType name="TransformType" mixed="true">
<choice minOccurs="0" maxOccurs="unbounded">
<any namespace="##other" processContents="lax"/>
<!-- (1,1) elements from (0,unbounded) namespaces -->
<element name="XPath" type="string"/>
</choice>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
Manifest Element
The Manifest element provides a list of References. The difference from the list in SignedInfo is
that it is application defined which, if any, of the digests are actually checked against the objects
referenced and what to do if the object is inaccessible or the digest compare fails [6].
<element name="Manifest" type="ds:ManifestType"/>
<complexType name="ManifestType">
<sequence>
<element ref="ds:Reference" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
10
11. 3.5 References
[1]. A. Gupta., Y.A. Tung, J.R. Marsten, “Digital signature:use and modification to achieve success
in nextgenerational e-business processes”, Sicience Direct, p.571, June 2003. [Online].
Avaliable:http://www.sciencedirect.com. [Accessed October 17, 2007].
[2].Sunil Chopra,Peter Meindil , “Chapter1, Understanding the supply chain ”, in Supply Chain
Management 3rd edition, pp.3-18.
[3]. “Information technology . Security techniques”, ISO/IEC, p.7, February 2005.
[4].The
World
Wide
Web
Consortium,
“XML
Avaliable:http://www.w3.org/Signature [Accessed October 25, 2007].
Signature”,
[Online].
[5].Microsoft Developer Network, “ Understanding XML Digital Signature”[Online].
Avaliable:http://msdn2.microsoft. com/en-us/library/ms996502.aspx [Accessed November 2007].
[6]. The World Wide Web Consortium , “XML Signature Syntax and Processing”, [Online].
Avaliable: http://www.w3.org/TR/xmldsig-core/#sec [Accessed December 20, 2007].
11