10.4 XML Digital Signatures (XMLDSIG)
| The XML Signature technology was developed by the IETF/W3C XMLDSIG group chartered in response to the June 16, 2000 E-Sign act, which made digital signatures legally binding. Under the act, online and electronic contracts signed in the private sector with an electronic signature have the same legal force as paper contracts. Agencies already are using electronic signatures under the authority of the Government Paperwork Elimination Act of 1999. The first operational certificate was used by President Clinton and issued on the General Service Administration (GSA) access certificates for electronic services contract. That contract is intended to provide a government-wide vehicle for agencies to use and implement digital certificates for their online services. Digital signatures can be applied to any digital content (data object), for example, audio, HTML, and GIF files. Unlike non-XML digital signatures, XML signatures include processing information such as the name of the algorithm that was used to generate the signature. Further, XML signatures allow signing only specified sections of a document or resources referenced by that document. As such, XML digital signatures are useful for documents that have to be signed by multiple users, as each contribution and annotation on a document could be signed by its author separately. XMLDSIG, supports the following signature types [XMLDSIG]:
XMLDSIG does not address mechanisms for making statements or assertions. Instead, it defines what it means for something to be signed by an XML Signature: it enables ensuring content integrity and performing author authentication. XMLDSIG is a method of associating a key with referenced data (octets). It does not dictate how keys are associated with people or institutions, or the meaning of the data being referenced and signed. Consequently, although XMLDSIG is an important component of any security framework, it is not sufficient by itself to address all application security and trust concerns. Such an application must specify additional key, algorithm, processing and rendering requirements. 10.4.1 Verifying IntegrityTo check the integrity of a document, using an XML signature, a digest is created for the document. This digest is then compared with the digest that was included in the XML signature. Integrity is confirmed if the two digests match. Different XML applications may have slightly different XML representations of their data. For example, one XML application may place all elements in the same line whereas another application may break lines at arbitrary places. The digest calculation is sensitive to changes to the exact XML representation. Different digests may be generated for two documents with identical content that have been represented in a slightly different but equivalent fashion. When two applications use slightly different XML representation of the same data, data integrity appears to have been compromised when, in fact, the content of the received document is exactly the same as the content of the original. To solve this problem, canonical XML has been developed. Canonical XML normalizes the physical representation of XML, creating a standard for signature processing. Before the signature digest is created for a document, it is transformed to canonical XML. Subsequently, when the received document is checked for data integrity, it is transformed to canonical XML before a digest is created for it. 10.4.2 Signature StructureObjects being signed are digested, and the resulting value is placed in an element along with other information about that object. That element is then digested and cryptographically signed by producing a digital signature. Digital signatures are represented by the <Signature/> element that has the structure presented in Figure 10.2. Figure 10.2 illustrates a detached signature example found in the W3C XMLDSIG standard specification [XMLDSIG]. Figure 10.2. The structure of an XML Digital Signature. The descriptions of the XMLDSIG elements is given in Table 10.1. The <Signature/> element has an optional ID attribute, two required child elements of <SignedInfo/> and <SignatureValue/> , and optional child element of <KeyInfo/> and zero or more <object/> elements, each having an optional ID attribute. The <SignedInfo/> element has the child elements of <SignatureMethod/> , <CannonicalizationMethod/> and one or more <Reference/> elements, each having an optional URI attribute. The <Reference/> element has as children the <DigestMethod/> , <DigestValue/> and, optionally , the <Transforms/> element. Signatures are associated with data objects via the URI attributes of <Reference/> elements (see Example 10.1). Within an XML document, signatures are related to local data objects via fragment identifiers. Such local data can be included within an enveloping signature or can enclose an enveloped signature. A <Signature/> element may coexist or combine with other elements, therefore unique names must be selected. Example 10.1 A detached signature.<Signature id="MySig" xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/> <Reference uri="http://www.w3.org/TR/2000/REC-xhtml1-20000126"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> </SignedInfo> <SignatureValue>KDSLdsDGKfg#%JDF@...</SignatureValue> <KeyInfo><KeyValue><DSAKeyValue> <P>...</P><Q>...</Q><G>...</G><Y>...</Y> </DSAKeyValue></KeyValue></KeyInfo> </Signature> A <SignatureProperties/> element is provided as the location in which all information about the signature could be added (e.g., signature semantics, the time of signing or the serial number of hardware used in cryptographic processes). Such information is signed if a <Reference/> is listed pointing to the id attribute of the <SignatureProperties/> in <SignedInfo/> . The mandatory target attribute references the <Signature/> element to which the property applies. Whereas the signing application should be very careful about what it signs, and should probably understand what is in the <SignatureProperty/ >, a receiving application has no obligation to understand that semantic. The <Reference/> element may contain an optional <Transforms/> element containing an ordered list of processing steps that were applied to the resource's content before it was digested. Transforms can include operations such as canonicalization, encoding and decoding (including compression and decompression ), XSLT, XPath, XML schema validation, or XML Include (XInclude). These reference methods allow signatures to be scoped to a portion of the XML document, allowing changing of unsigned portions without affecting the validity of the signature on the signed portions. For example, if the resource being signed encloses the signature itself, such a transform must be used to exclude the signature value from its own computation. If no Transforms element is present, the resource's content is digested directly. Although the W3C working group has specified mandatory (and optional) canonicalization and decoding algorithms, user specified transforms are permitted. The <DigestMethod/> is applied to the data after <Transforms/> is applied (if specified) to yield the <DigestValue/> . The signing of the <DigestValue/> is what binds a resources content to the signer's key. Table 10.1. A Description of the XMLDSIG Elements
Data objects can be carried within the signature element or elsewhere, using the (optional) <Object/> element, which can be optionally typed and encoded. Consider the preceding example with an additional reference to a local <Object/> that includes a <SignatureProperty/> element, as illustrated in Example 10.2. The optional attribute <Reference/@Type/> can indicate that it is either an #Object , #SignatureProperty , or #Manifest element, possibly initiating special processing of some <Reference/> elements. References to an XML data element within an <Object/> element identify the actual element pointed to. Where the element content is not XML (e.g., GIF or JPG images) the reference should identify the <Object/> and the corresponding <Reference/@Type/> should be #Object . 10.4.3 The ManifestThe <Manifest/> element is both a feature and a security hole. It is provided for efficiency and extensibility beyond what is provided by XMLDSIG. Example 10.3 illustrates a <Reference/> that signs a <Manifest/> found within the <Object/> element. Essentially, <Manifest/> places the burden of correctly verifying a signature on the application rather than on the XMLDSIG implementation. Example 10.2 Adding and signing properties of signatures.<Signature Id="NewSig" ...> <SignedInfo> <Reference uri="#Sometime-stamp" Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>djfkS=GDdjh+2346skS^#$D/DigestValue> </Reference> </SignedInfo> ... <Object> <SignatureProperties> <SignatureProperty Id="Sometime-stamp" Target="#mySignature"> <time-stamp xmlns="http://www.xyz.com/timeformat"> <date>19990908</date> <time>14:34:34:34</time> </time-stamp> </SignatureProperty> </SignatureProperties> </Object> </Signature> Example 10.3 Use of the <Manifest/> element.... <Reference uri="#MyFirstManifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest"> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>345x3rvEPO0vKtMup4NbeVu8nk=</DigestValue> </Reference> ... <Object> <Manifest Id="MyFirstManifest"> <Reference> ... </Reference> <Reference> ... </Reference> </Manifest> </Object> The <Manifest/> element was introduced as part of an efficient method for signing multiple data objects even where the signature operation itself is an expensive public key signature. Efficiency can be achieved through the use of references, namely through the inclusion of multiple <Reference/> elements within <SignedInfo/> . However, for some applications the core validation behavior associated with this approach may not be desired because it requires every <Reference/> within <SignedInfo/> to undergo reference validation. These applications may wish to overwrite the reference validation decision logic. For example, if a single <Reference/> fails (i.e., the identified data object when digested does not yield the specified <DigestValue/> ) the signature would fail. The application may wish to skip the failed signature or take different actions depending on which reference fails. To accomplish this, <SignedInfo/> would reference a <Manifest/> element that contains one or more <Reference/> elements with the same structure as those in <SignedInfo/> . In this case, reference validation of the <Manifest/> is under application control. Consider an application where many signatures (using different keys) are applied to a large number of documents. An inefficient solution is to have a separate signature (per key) repeatedly applied to a large <SignedInfo/> element with possibly many <Reference/> elements; this is wasteful and redundant. A more efficient solution is to include the numerous references in a single <Manifest/> that is then referenced from multiple <Signature/> elements. 10.4.4 Processing RulesThe required steps of core validation include (a) reference validation, the verification of the digest contained in each <Reference/> in <SignedInfo/> , and (b) the cryptographic signature validation of the signature calculated over <SignedInfo/> . The complete signing process includes the following steps:
There may be valid signatures that some applications are unable to validate. To facilitate toubleshooting and decrease the probability of such occurrences, one should ensure that all references specified are accessible and all algorithms specified are supported. Comparison of values in reference and signature validation are over the numeric (e.g., integer) or decoded octet sequence of the value. Different implementations may produce different encoded digest and signature values when processing the same resources because of variances in their encoding, such as accidental white space. However, if one consistently uses either numeric or octet comparison on both the stated and computed values, these problems are eliminated. To validate references, an application must canonicalize the <SignedInfo/> element before any processing using the <CanonicalizationMethod/> in <SignedInfo/> . For each <Reference/> in <SignedInfo/> :
The developer of the validating application must ensure that the <CanonicalizationMethod/> does not have dangerous side affects such as rewriting URIs. To perform signature validation, one needs to perform two steps:
10.4.5 Signature AlgorithmsSignature algorithms are identified by URIs that appear as an attribute to the element that identifies the algorithms' role All XMLDSIG algorithms take parameters that may be implicit. For example, a <SignatureMethod/> is implicitly given two parameters: the keying info and the <CanonicalizationMethod/> . Explicit additional parameters to an algorithm appear as content elements within the algorithm role element. Such parameter elements have a descriptive element name, which is frequently algorithm specific, and must be in the XML Signature namespace or an algorithm specific namespace. Table 10.2. List of Algorithms Where rq = 'Y' Indicates Required
|
EAN: 2147483647
Pages: 170
- Structures, Processes and Relational Mechanisms for IT Governance
- Integration Strategies and Tactics for Information Technology Governance
- Assessing Business-IT Alignment Maturity
- A View on Knowledge Management: Utilizing a Balanced Scorecard Methodology for Analyzing Knowledge Metrics
- The Evolution of IT Governance at NB Power