Addison wesley secure XML the new syntax for signatures and encryption jul 2002 ISBN 0201756056

6.2 Data Model The XPath data model is relatively simple Any XML document or object is a set of nodes of one of seven types (listed below) These nodes are organized into a hierarchical tree In addition to this tree structure, a linear ordering of the nodes is maintained; this ordering is called "document order." The document order of nodes matches the order in which the first character of that node appears in the document character string form Thus an element node precedes all of its children, because the element start tag's opening left angle bracket occurs before all element content, attributes, or namespace declarations By convention, the root node, which has no character representation, comes first in document order: Root node Element nodes Attribute nodes Namespace nodes Text nodes Processing instruction nodes Comment nodes Note that no provision is made for DTDs or the XML declaration In effect, XPath takes the point of view that DTDs and the XML declaration are part of the external form of XML After reading XML into an application, the DTD and declaration have already been taken into account and are no longer useful Similarly, the parsing of characters into an XPath node-set removes external artifacts such as CDATA sections and character references Example 6-1 and Figure 6-2 provide an example of some XML and the resulting XPath data model Figure 6-2 Xpath data model Example 6-1 External XML qwert yuiop&" appears as a text node with content ">"" Thus has a null string value, whereas has the string value "Bokm 42 yZgv" Note that any processing instructions in the DTD and the XML declaration do not appear as nodes of any sort in the corresponding XPath node-set Other than that, a processing instruction node corresponds to each processing instruction in the external XML (Although the XML declaration looks like a processing instruction, it is defined not to be one.) 6.2.7 Comment Nodes A comment node does not have an extended name The string value of a comment comprises everything between the opening "" For example, the string value of > is null, whereas that of is "Four score and Seven." 7.3 XPointer XPointer is the syntax you use for the most general addressing of parts of an XML object [XPointer] When an HTTP URI references XML, any fragment specifier to select a portion of the XML is written in XPointer syntax XPointer can also be called explicitly to extract a subset of data (see Chapter 19) Note that XPointer does not include any way to point into the DTD or XML declaration for a document XPointer extends XPath so that you can use it in the following ways: As a fragment identifier in a URI reference To locate information by string matching To address points and ranges within XML In XML Security URIs, you should rarely encounter anything other than very simple XPointers The implementation might delegate URI retrieval and fragment specifier processing to separate code with somewhat unpredictable results For this reason, the XML Security standards discourage use of XPointer fragment specifiers in favor of using the explicit "Transforms" mechanism provided (While you can invoke the full power of XPointer in such transforms, full support for it is optional Even full support of XPath, on which XPointer builds, is merely recommended, not mandatory.) XPointer Encoding When an XPointer contains special characters that have significance to XPointer but that should be treated as data, a circumflex ("^") prefixes the special characters One example would be an unbalanced parenthesis—either "(" or ")"— appearing in a literal string Due to this use, circumflex itself must be considered a special character and occurrences of a literal circumflex doubled ("^^") For example, xpointer( string-range ( /., "f)^" ) ) would be encoded as follows: xpointer( string-range ( /., "f^)^^") ) The preceding rule applies only to general XPointer encoding An XPointer must also be URI encoded (see Section 7.1.4) if it is used in a URI and XML encoded if it appears in XML So, for example, xpointer(string-range(//example,"André :-)")) would always be XPointer encoded for the unbalanced parenthesis in the "smiley" as follows: xpointer(string-range(//example,"André :-^)")) If it appeared as such in an XML attribute value delimited by double quotes and encoded in US-ASCII, you would escape the double quotes and the accented "é": xpointer(string-range(//example,"André :-^)&q If it appeared generally as a URI reference fragment specifier, you would encode the space, double quotes, circumflex, and accented "é": xpointer(string-range(//example,%22Andr%C3%A9%20:-%5E)% 7.3.1 Forms of XPointer XPointer has three possible forms: Full XPointers Bare names Child sequences Full XPointers A full XPointer can be complicated, but you will rarely encounter the full form It consists of a sequence of one or more parts that can optionally be separated by white space Each part has the following format: scheme(string-with-balanced-parentheses) The "xpointer" and "xmlns" schemes are defined below The "string-with-balanced-parentheses" means any string where all parentheses—both "(" and ")"—are properly nested, except for those escaped with the circumflex ("^"), as described earlier Full XPointer parts end with a close parenthesis that matches the open parenthesis after the scheme name If multiple parts are present, they are evaluated from left to right until one succeeds If all parts fail, then the full XPointer fails As yet undefined schemes are permitted for future expansion Encountering a scheme you do not understand is equivalent to a failure of that part (This scheme-based system allows other data types than general XML to define their own schemes.) You use the "xmlns" scheme to set up the namespace context By converting the document to Canonical XML before the XPath transform, to physically remove the comments and concatenate resulting adjacent text By matching the node based on the parent element's string value For example, using the expression self::text()[string(parent::e)="Hello, world!"] would work XPath Function "here( )" The function "here( )" is defined as follows: node-set here( ) The "here( )" function returns a node-set containing the attribute or processing instruction node or the parent element of the text node that directly bears the XPath expression This expression results in an error if the containing XPath expression does not appear in the same XML document against which the XPath expression is being evaluated It works in the same way as the "here( )" function added by XPointer (see Chapter 7) XPath Transform Example As an example, consider the creation of an enveloped signature (a Signature element that is a descendant of an element being signed) Although the signed content should not change after signing, the elements within the Signature element do change (e.g., the digest value must be put inside the DigestValue and the SignatureValue must be subsequently calculated) One way to prevent these changes from invalidating the digest value in DigestValue is to add an XPath transform that omits all Signature elements and their descendants For example: xpointer(id("foo")) xmlns(bar=urn:baz) xpointer(//bar:Zab[@Tag="foo"]) The DTD for the XPointer element follows: In schema notation, it has the following form: Input to this transform consists of an octet stream (which is then parsed into XML) Output from this transform is a nodeset; the results of the XPointer are processed as defined in Chapter 6 for a same-document XPointer 19.2.7 XML Schema Validation Schema Validation Identifier: http://www.w3.org/TR/2001/09/Validate# The XML schema validation transform was temporarily included in an intermediate draft of XMLDSIG but currently has its own separate informal document This transform provides control over schema validation [Schema] If no explicit parameters are provided, it indicates that the schema validation must be applied to the implicit input data according to the schema information within that data If the Transform element has as its sole child a namespacequalified "schema" element, that element contains the schema to use for validation The [Schema] processing model determines whether it causes in-line processing of local schema declarations in the input Applying multiple schemas successively may require multiple Transform elements You can invoke a remote schema by using the [Schema] "include" or "import" features within the schema child element of the Transform element While most of the changes made by [Schema] are additions that are outside the XPath data model, schema validation can affect default attribute values and element content When this possibility can occur, both the signer and the verifier must do the same schema validation for a signature to be meaningful 19.2.8 Decryption Transform Refer back to Chapter 16 for information on the decryption transform 2.10 Randomness The keys used in digital security must be generated "randomly." For our purposes, "random" is defined as hard to guess, so this makes it more difficult to guess the key This goal turns out to be surprisingly challenging to achieve on a computer One strategy is to use true physical randomness such as thermal noise or radioactive decay, but it requires special hardware and usually produces random bits fairly slowly More commonly, systems use algorithmic "pseudo-random" number generators Unfortunately, to be unguessable, they initially require some sort of strong random seed value Frequently such a seed can be derived from some hardware source of randomness Many real-world systems that did almost everything else right have been broken due to weak random numbers Perhaps they based their random number generation on a seed that uses only the time and date As a result, anyone with a general idea of when the seed was generated will have an embarrassingly small space to search through to find the key—possibly only a few dozen values—even if the key is 128 bits and should have 2128 equally probable values For a deeper and more detailed discussion of these issues, see [RFC 1750] and [Schneier] Early versions of Netscape Navigator, although they did most everything else correctly in terms of security, depended (as have other security critical software products) on a library "random" number generator for SSL keys On some platforms, this generator used the time of day and process ID as a seed Its output was relatively easy to guess This problem has, of course, been fixed Because it drew a bit of attention, people have become more cautious about this issue But give it a few years and likely someone will make the same mistake again It's very easy to put in a "temporary" weak random number generator while developing a system and never get around to upgrading it Appendix D The NIST and NIST Documents The U.S National Institute of Science and Technology (NIST) has been in existence for more than 100 years under a variety of names For some time now, it has been part of the U.S Department of Commerce and, until recently, was called the National Bureau of Standards (NBS) NIST's purpose is "to develop and promote measurement, standards, and technology to enhance productivity, facilitate trade, and improve the quality of life" [NIST] The aspect of NIST of interest to us is its publication of Federal Information Processing Standards (FIPS) In principle, FIPS are binding only on agencies and other parts of the U.S government In practice, they are very influential and commonly become the definitive description of an algorithm or security practice At the same time, NIST is mandated to work with private industry in the development of national and international voluntary standards, some of which then become FIPS Amazingly, the rules of some international standards bodies prohibit them from making normative references to NIST documents but permit them to make normative references to IETF RFCs This situation arises because NIST FIPS are "national" documents describing U.S standards but these international bodies have recognized the IETF as a competent "international" organization (This restriction may apply even where the IETF document is an Informational RFC that effectively restates a NIST FIPS!) This stance seems curious but makes political sense, even though NIST documents tend to be more solid, polished and formal than the average IETF RFC Note the following: NIST and other parts of the U.S government chose and refined the Data Encryption Standard, DES [FIPS 46-3, 81], from industry proposals The government generated the Digital Signature Algorithm/Standa The government generated the Digital Signature Algorithm/Standard, DSA/DSS [FIPS 186-2] and related Secure Hash Standard, SHA-1 [FIPS 180-1] and upcoming extensions [FIPS 180-2] NIST chose the Advanced Encryption Standard [AES] in a contest generally recognized as fair, open, and international You can find more general information at [NIST] Chapter 12 ETSI "Advanced" XML Signatures The European Telecommunications Standards Institute (ETSI) is developing extensions to the XML Digital Signature Recommendation (see Chapter 10) so that the resulting extended signatures will meet the European Directive requirements for valid electronic signatures for electronic commerce purposes [Directive] This chapter describes the extensions as an example of one way to build a higher-level "trust" structure on the basic XMLDSIG structure The discussion in this chapter is based on ETSI's July 2001 draft, XML Advanced Electronic Signatures [XAdES], which uses the following namespace: http://www.etsi.org/names/TS/101903/v1.1.1# I don't know about you, but I'm always suspicious of things called "new" or "advanced." What will they call the next, more advanced version? ETSI assumes the existence of trusted service providers, including time stamping services and certificate authorities Another assumption relates to the existence of signature policy issuers The ETSI draft is aimed, to a great extent, at convincing an independent arbiter of the validity of a signature It assumes that all signatures with which it deals will be public key signatures with keying material in X.509 [ISO 9594] certificates The sheer size and complexity of the ETSI draft should give pause to those who think it should be easy to establish "trust" and "meaning" from a document (see Appendix E) point of view The schema information given is this chapter assumes the following preface: Chapter 16 Combining Encryption and Signature It is common to have data that must be authenticated to one or more recipients, for which all or parts of the data must remain confidential While it is difficult to formulate general rules that always apply to such cases, Section 16.1 gives some of the general considerations Section 16.2 describes a special Decryption Transform that makes it easier to determine which cipher text to decrypt before verifying a signature Chapter 13 The KeyInfo Element Both XMLDSIG and XML Encryption use the KeyInfo element It appears as the child of a SignedInfo, EncryptedData, or EncryptedKey element and provides information to a recipient about what keying material to use in validating a signature or decrypting encrypted data (This element is also used in XKMS, as described in Chapter 14.) In both signature and encryption, the KeyInfo element is optional, because the recipient may be able to determine the right key to use from the application context For example, in a protocol application, the channel over which the recipient gets the message or some other name, index, or data in the message may signal the recipient about which key or keys to use Each KeyInfo element can have zero or more child elements that give the value of or refer in various ways to the keying material A KeyInfo with no content is about as useful as no KeyInfo at all Even so, the standards include this option, as it may be easier for applications that dynamically calculate the KeyInfo content It might not be convenient, at the time that the application outputs the KeyInfo start tag, to know whether it will have content All child elements of a KeyInfo element must refer to the same key You might want multiple child elements because different recipients understand different forms You might even want multiple child elements for a single recipient, if you were not sure which form of key reference they could use In retrospect, because KeyInfo is a major shared element between XMLDSIG and XML Encryption that had to be substantially augmented for encryption, it would have been better if this element had its own namespace and was defined in a separate document Appendix E The Paper and Protocol Points of View This appendix contrasts two points of view: The "paper" point of view, where digital objects of interest are like pieces of paper written and viewed by people The "protocol" point of view, where objects of interest are dynamic composite protocol messages XML is a very flexible technology You can use it effectively for purposes that fit either of these points of view, even though its origin was in the paper (i.e., document) world However, people accustomed to taking one point of view sometimes experience great difficulty in grasping the other Even after they understand the other viewpoint, they tend to initially consider things from their accustomed point of view and assume that most of the universe of interest is best viewed from that perspective Much of the IETF's traditional work has concerned low-level binary protocol constructs These constructs are almost always viewed from the protocol point of view The W3C, in contrast, has concentrated on human presentation syntaxes and higherlevel application constructs that tend more toward the paper point of view Protocol design by those who take the paper point of view can be problematical This appendix defines and contrasts these two points of view Each viewpoint is exaggerated for effect The exaggerated paper point of view is given in paragraphs headed PAPER The exaggerated protocol point of view is given in paragraphs headed PROTOCOL This entire appendix can be considered a soapbox ... starting and ending with that point For the root node, the start and end points of the covering range have the root node as their container The index of the start point is zero, and the index of the end point is the. .. point is zero, and the index of the end point is the length of the string value of the attribute or namespace node For all other kinds of nodes, the start and end points of the covering range have the parent of that node as their... (If both the preceding node and the indices of the points are equal, they are the same.) The document order of a point and a range matches the document order of that point and the start point of the