XML is a kind of markup language for documents containing structured information [NW98]. Structured information contains content likes words, pictures or binary data. A markup language is a mechanism to identify structures and what it stands for in a document.
The XML specification defines a standard way to add markup to documents. XML is also a plentifully structured document and that could be used over the web. The HTML and SGML, the other kinds of markup language, are not practical for this thesis.
HTML comes bound with a set of semantics and does not provide arbitrary structure. It can not extend some feature for use in some purpose. Although SGML provides arbitrary structure, it is too difficult to implement just for a web browser. Full SGML systems are quite large, complex problems that justify their expense. Viewing structured documents sent over the web rarely carries such justification. But XML is not expected to completely replace SGML, it is designed to deliver structured content over the web, some of the very features it lacks to make this practical, make SGML a more satisfactory solution for the creation and long-time storage of complex documents. Simplifying SGML to XML will be, in many institutions, the standard procedure for web delivery. The figure will expound the scope of these three markup languages we discuss above:
SGML XML
HTML
Figure 3.1 The scope of three markup languages
HTML and XML are derived from SGML, but HTML has no flexible. XML gets together the benefits from SGML but keeping flexibility. That’s why we adopt XML to be the basis of proxy signature for network data exchange.
3.1 XML Namespaces
We didn’t discuss much of XML but only mention some concept related to the thesis.
Let’s talk directly to the topic of namespaces in XML. The purposes of a namespace when used in an XML document is to prevent the collision of semantically different elements and attributes that happen to have the same name [BD 02]. For example, 1 if someone wants to use the specific tag which is called <CrucialMessage>. This element can refer to the word for commercial use, or it can refer to the secure message for military or national security. Still more problems occurred if this element is created by two different authors. Clearly, the meaning of the element is ambiguous and it is unreasonable to expect any sort of application to be able to make the distinction between the different elements without some other qualifying information.
The problem is solved with the use of a namespace in XML. A namespace in the context of XML is a collection of element or tag names identified by a URI Reference. The usage of an XML namespace is to provide a globally unique name for each tag. A URI Reference is a URI that is used as a string identifier to point to a place providing several tags name. The example we used more often is the namespace used for XML Signature. The URI Reference is like as below:
http://www.w3.org/2000/09/xmldsig#
TThe collections of element and tag names that are associated with this string identifier include the elements and attributes that help defining an XML Signature. This namespace includes a lot of the tag names for signature algorithms used likes MD5, SHA-1, RSA and so on. More detail of the examples are shown in Chapter 6.
3.2 XML Signature
XML Signature is a rich, complex object. XML Signatures depend on a large number of disparate XML and cryptographic technologies [BD202]. The XML Signature syntax is for a high degree of extensibility and flexibility; these notions add to the abstract nature of the syntax itself, but provide a signature syntax that is beneficial to almost any signature operation.
The W3C Recommendation, XML-Signature Syntax and Processing, defined the XML Signature syntax and its related processing. This recommendation can be found at the World Wide Web Consortium Web site. The XML Signature Recommendation will likely change in subtle ways as XML Signatures becomes more pervasive. We are, nevertheless, not concerned with the nooks and crannies of the specification, but instead with the basic reason for its existence, examples, and the fundamental properties that define an XML Signature. One
might question why we need such a rich signature syntax that differs markedly with our existing signature infrastructure. If we compared an existing messaging syntax, such as PKCS#7, to XML Signatures, we would see so many differences in the intent and implementation of the syntax.
We have to realize some tag used in XML Signature first and list the functions of the tags as below:
Table 3.2.1 XML Signature tags list
Tag Name Description
<SignedInfo>
The tag <SignedInfo> is the information that is actually signed. It consists of two mandatory processes: validation of the signature over <SignedInfo> block and validation of each Reference digest within <SignedInfo> block.
<Transform>
The optional tag <Transforms> contains one or an list of
<Transform> blocks, and all of the <Transform> describe how to figure out the signer data object that being digested.
<CanonicalizationMethod>
The tag <CanonicalizationMethod> is the algorithm used to canonicalize the <SignedInfo> block before digested as part of the signature operation.
<SignatureMethod>
<SignatureMethod> is the algorithm used to convert the canonicalized <SignedInfo> block into the
<SignatureValue>. It is a combination of a digest and key dependent algorithm and possibly other algorithms such as padding, for example RSA-SHA1 or DSA-SHA1. The algorithm names are signed to resist attacks based on substituting a weaker algorithm.
< DigestMethod>
<DigestValue>
<DigestMethod> object is the algorithm applied to the data after Transforms is applied (if specified) to yield the
<DigestValue> block. The signing of the <DigestValue> is an object binding resources content to the signer's key.
<KeyInfo>
<KeyInfo> block indicates the key to be used to verify the signature from signer signed. The existed forms for identification include certificates, key names, and key agreement algorithms. This tag may not available if the signer does not wish to reveal any key information or the information may be known within the application's context and don’t need to be represented in XML.
The frequent uses of these tags are listed above and most of all detail information related to XML signature is available in W3C web pages or related publications.
3.3 XML Signature using DSA
W3C organization proposed a standard structure and we can use easily the standard structure for XML signature in DSA. The DSA signature scheme can only be used for signing, and it cannot perform encryption or decryption. So the functions of DSA signature include parameter generation, key generation, and then the signing and verifying operations.
The overall structure uses tags we have mentioned before and we discuss a sort of DSA algorithm. DSA, most of the same way as an RSA signature, uses a public key and private key.
The private key is used for generating signature and the public key is used for verifying signature. Because of these computationally expensive tasks, most applications, as matter of
fact, use pre-generated DSA parameters or use the DSA pre-assigned key pair under X.509.
The XML Signature Recommendation from W3C has supported for DSA via the URI identifier like this:
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
We know the XML Signature have two kinds of signature algorithms, and the only difference between these two is the <KeyValue> object. It is designed to hold a raw RSA or DSA public key with child object, tag <RSAKeyValue> and <DSAKeyValue>, respectively. Public keys inside <KeyValue> are represented by their Base64 encoding algorithm. But only we interested this time is <DSAKeyValue> and it has following parameters:
<DSAKeyValue>
<P>…</P>
<Q>…</Q>
<G>…</G>
<Y>…</Y>
</DSAKeyValue>
Where <P> and <Q> is for <G> generation; and <Y> is signer’s public key for verification.
We don’t need, by the way, the value y if in proxy signature processing. More explicit content about proxy signature in XML will be discussed in Section 6.3.