XML Signatures: Behind the Curtain - An Example to Mull Over (Page 7 of 9 )
Consider a simple example with some real data. The following is the detached signature of the content of the HTML4 in XML specification. The XML is given first, followed by the annotations for each individually listed line of code. It's also assumed in this discussion that you've had some experience with private/public key cryptologic methods and are comfortable with the concepts. If not, there are excellent introductory articles here on developerWorks that can be perused. (See Resources.)
[s02-12] The required SignedInfo element is the information that is actually signed. Core validation of SignedInfo consists of two mandatory processes: validation of the signature over SignedInfo and validation of each Reference digest within SignedInfo. The algorithms used in calculating the SignatureValue are also included in the signed information while the SignatureValue element is outside SignedInfo.
[s03] The CanonicalizationMethod identifies the algorithm that is used to canonicalize the SignedInfo element before it is digested as part of the signature operation. Canonicalization is how the process deals with differing data streams that can be contained inside the same data element For instance, two differing ways can be contained to represent text. Canonicalization is the method in which raw data is interpreted to have spaces displayed as spaces and not as ASCII code.
[s04] The SignatureMethod is the algorithm that is used to convert the canonicalized SignedInfo into the SignatureValue. It is a combination of a digest algorithm, a key dependent algorithm, and possibly other algorithms. The algorithm names are signed to resist attacks based on the substitution of a weaker algorithm. To promote application interoperability, the candidate specifies a set of signature algorithms that are required to be implemented, though their use is at the discretion of the signature creator.
[s05-11] Each Reference element includes the digest method and resulting digest value calculated over the identified data object. It also may include transformations that produced the input to the digest operation. A data object is signed by computing its digest value and a signature over that value. The signature is later checked via reference and signature validation that recreates the digest value and makes sure that it matches what is held in the data object.
[s05] The optional URI attribute of Reference identifies the data object to be signed. This attribute may be omitted on at most one Reference in a Signature. (This limitation is imposed in order to ensure that references and objects may be matched unambiguously.)
[s05-08] This identification, along with the transforms, is a description provided by the signer on how they obtained the signed data object in the form it was digested (that is, the digested content). The verifier may also obtain the digested content in another method so long as the digest verifies it.
[s06-08] Transforms is an optional ordered list of processing steps that were applied to the resource's content before it was digested. This is the trail that needs to be followed for decryption. Transforms can include operations such as canonicalization, encoding/decoding (including compression/inflation), XSLT, and XPath. XPath transforms are a little tricky because they permit the signer to derive an XML document that omits portions of the source document, limiting the XML tree, as it were. The excluded portions can therefore change without affecting the signature validity. If no Transforms element is present, the resource's content is digested directly. It should be remembered that user-specified transforms are permitted even though a basic default set is specified in the candidate.
[s09-10] DigestMethod is the algorithm applied to the data after Transforms is applied (if it has been specified) to yield the DigestValue. The signing of the DigestValue is the mechanism that binds a resource's content to the signer's key.
[s14-16] KeyInfo indicates the key to be used to validate the signature. Identification mechanisms can include certificates, key names, and key agreement algorithms. KeyInfo is optional for two reasons. First, the signer may not wish to reveal any key information to all of the document processing parties. Why tell the world all the time? Second, the information may be known within the application's context and need not be represented explicitly. Since KeyInfo is outside of SignedInfo, if the signer wishes to bind the keying information to the signature, a Reference can easily identify and include the KeyInfo as part of the signature.