XML- Signature Syntax and Processing (Second Edition)

Abstract

Status of this document

Table of Contents

1. 1. 1. Canonical XML 1.0
      2. Canonical XML 1.1

1.0 Introduction

1.1 Editorial and Conformance Conventions

1.2 Design Philosophy

1.3 Versions, Namespaces and Identifiers

FIPS PUB 180-1FIPS PUB 180-2. U.S. Department of Commerce/National Institute of Standards and Technology.

1.4 Acknowledgements

• Mark Bartel, Adobe, was Accelio (Author)
• John Boyer, IBMPureEdge (Author)
• Joseph Reagle, NYU, was W3C (Chair, Author/Editor)

The following members of the XML Security Specification Maintenance Working Group contributed to the second edition:

• Juan Carlos Cruellas, Universitat Politècnica de Catalunya
• Pratik Datta, Oracle Corporation
• Phillip Hallam-Baker, VeriSign, Inc.
• Frederick Hirsch, Nokia, (Chair, Editor)
• Konrad Lanz, A-SIT
• Hal Lockhart, BEA Systems, Inc.
• Robert Miller, MITRE Corporation
• Sean Mullan, Sun Microsystems, Inc.
• Bruce Rich, IBM Corporation
• Thomas Roessler, W3C/ERCIM, (Staff contact, Editor)
• Ed Simon, W3C Invited Expert
• Greg Whitehead, HP

2.0 Signature Overview and Examples

2.1 Simple Example (Signature, SignedInfo, Methods, and Reference)s

   [s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> 
   [s02]   <SignedInfo> 
   [s03]   <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315http://www.w3.org/2006/12/xml-c14n11"/> 
   [s04]   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/> 
   [s05]   <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> 
   [s06]     <Transforms> 
   [s07]       <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315http://www.w3.org/2006/12/xml-c14n11"/> 
   [s08]     </Transforms> 
   [s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
   [s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=<dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK.../DigestValue> 
   [s11]   </Reference> 
   [s12] </SignedInfo> 
   [s13]   <SignatureValue>MC0CFFrVLtRlk=......</SignatureValue> 
   [s14]   <KeyInfo> 
   [s15a]    <KeyValue>
   [s15b]      <DSAKeyValue> 
   [s15c]        <P>...</P><Q>...</Q><G>...</G><Y>...</Y> 
   [s15d]      </DSAKeyValue> 
   [s15e]    </KeyValue> 
   [s16]   </KeyInfo> 
   [s17] </Signature>

2.1.1 More on Reference

   [s05]   <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> 
   [s06]     <Transforms> 
   [s07]       <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315http://www.w3.org/2006/12/xml-c14n11"/> 
   [s08]     </Transforms> 
   [s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
   [s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</DigestValue> 
   [s11]   </Reference>

2.2 Extended Example (Object and SignatureProperty)

   [   ]  <Signature Id="MySecondSignature" ...>
   [p01]  <SignedInfo>  
   [   ]   ...  
   [p02]   <Reference URI="http://www.w3.org/TR/xml-stylesheet/">   
   [   ]   ... 
   [p03]   <Reference URI="#AMadeUpTimeStamp"  
   [p04]         Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">
   [p05]    <Transforms> 
   [p06]      <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/> 
   [p07]    </Transforms> 
   [p0508]    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>    
   [p0609]    <DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</DigestValue>
   [p0710]   </Reference>    
   [p0811]  </SignedInfo>  
   [p0912]  ...  
   [p1013]  <Object> 
   [p1114]   <SignatureProperties> 
   [p1215]     <SignatureProperty Id="AMadeUpTimeStamp" Target="#MySecondSignature"> 
   [p1316]        <timestamp xmlns="http://www.ietf.org/rfcXXXX.txt">  
   [p1417]          <date>19990914</date>  
   [p1518]          <time>14:34:34:34</time>  
   [p1619]        </timestamp>  
   [p1720]     </SignatureProperty> 
   [p1821]   </SignatureProperties> 
   [p1922]  </Object>  
   [p2023]</Signature>

[p10p13] Object is an optional element for including data objects within the signature element or elsewhere. The Object can be optionally typed and/or encoded.

[p11-18p14-21] Signature properties, such as time of signing, can be optionally signed by identifying them from within a Reference. (These properties are traditionally called signature "attributes" although that term has no relationship to the XML term "attribute".)

2.3 Extended Example (Object and Manifest)

   [   ] ...
   [m01]   <Reference URI="#MyFirstManifest"
   [m02]     Type="http://www.w3.org/2000/09/xmldsig#Manifest">
   [m03]     <Transforms> 
   [m04]       <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/> 
   [m05]     </Transforms> 
   [m0306]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
   [m0407]     <DigestValue>345x3rvEPO0vKtMup4NbeVu8nkdGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...=</DigestValue> 
   [m0508]   </Reference>  
   [   ] ...
   [m0609] <Object>
   [m0710]   <Manifest Id="MyFirstManifest">
   [m0811]     <Reference>
   [m0912]     ...
   [m1013]     </Reference>   
   [m1114]     <Reference>
   [m1215]     ...
   [m1316]     </Reference>
   [m1417]   </Manifest>
   [m1518] </Object>

3.0 Processing Rules

3.1 Core Generation

3.1.1 Reference Generation

3.1.2 Signature Generation

3.2 Core Validation

3.2.1 Reference Validation

3.2.2 Signature Validation

4.0 Core Signature Syntax

4.0.1 The ds:CryptoBinary Simple Type

4.1 The Signature element

4.2 The SignatureValue Element

4.3 The SignedInfo Element

4.3.1 The CanonicalizationMethod Element

4.3.2 The SignatureMethod Element

4.3.3 The Reference Element

4.3.3.1 The URI Attribute

The URI attribute identifies a data object using a URI-Reference, as specified by RFC 2396 [URI].The set of allowed characters for URI attributes is the same as for XML, namely [Unicode]. However, some Unicode characters are disallowed from URI references including all non-ASCII characters and the excluded characters listed in RFC 2396 [URI, section 2.4]. However, the number sign (#), percent sign (%), and square bracket characters re-allowed in RFC 2732 [URI-Literal] are permitted. Disallowed characters must be escaped as follows:

1. Each disallowed character is converted to [UTF-8] as one or more octets.
2. Any octets corresponding to a disallowed character are escaped with the URI escaping mechanism (that is, converted to %HH, where HH is the hexadecimal notation of the octet value).
3. The original character is replaced by the resulting character sequence.

The mapping from this attribute's value to a URI reference MUST be performed as specified in section 3.2.17 of [XMLSCHEMA Datatypes, 2nd Edition]. Additionally: Some existing implementations are known to verify the value of the URI attribute against the grammar in [URI]. It is therefore safest to perform any necessary escaping while generating the URI attribute.

XML signature applications MUST be able to parse URI syntax. We RECOMMEND theyXML signature applications be able to dereference URIs in the HTTP scheme. Dereferencing a URI in the HTTP scheme MUST comply with the Status Code Definitions of [HTTP] (e.g., 302, 305 and 307 redirects are followed to obtain the entity-body of a 200 status code response). Applications should also be cognizant of the fact that protocol parameter and state information, (such as HTTP cookies, HTML device profiles or content negotiation), may affect the content yielded by dereferencing a URI.

The optional Type attribute contains information about the type of object being signed after all ds:Reference transforms have been applied%% E05 2002-05-08 %%. This is represented as a URI. For example:

The Type attribute applies to the item being pointed at, not its contents. For example, a reference that identifies results in the digesting of %%E05%% an Object element containing a SignatureProperties element is still of type #Object. The type attribute is advisory. No validation of the type information is required by this specification.

4.3.3.2 The Reference Processing Model

Note: The Reference Generation Model (section 3.1.1) includes further restrictions on the reliance upon defined default transformations when applications generate signatures.

In this specification, a 'same-document' reference is defined as a URI-Reference thatdoes not contain a URI. consists of a hash sign ('#') followed by a fragment or alternatively consists of an empty URI [URI].

Unless the URI-Reference is such a 'same-document' reference as defined in [URI, Section 4.2], the result of dereferencing the URI-Reference MUST be an octet stream. In particular, an XML document identified by URI is not parsed by the signature application unless the URI is a same-document reference or unless a transform that requires XML parsing is applied. (See Transforms (section 4.3.3.1).)

When a fragment is preceded by an absolute or relative URI in the URI-Reference, the meaning of the fragment is defined by the resource's MIME type. Even for XML documents, URI dereferencing (including the fragment processing) might be done for the signature application by a proxy. Therefore, reference validation might fail if fragment processing is not performed in a standard way (as defined in the following section for same-document references). Consequently, we RECOMMEND in this case that the URI  attribute not include fragment identifiers and that such processing be specified as an additional XPath Transform.

When a fragment is not preceded by a URI in the URI-Reference, XML sSignature applications MUST support the null URI and barename shortname XPointer [XPointer-Framework]. We RECOMMEND support for the same-document XPointers '#xpointer(/)' and '#xpointer(id('ID'))' if the application also intends to support any canonicalization that preserves comments. (Otherwise URI="#foo" will automatically remove comments before the canonicalization can even be invoked due to the processing defined in Same-Document URI-References (section 4.3.3.3).) All other support for XPointers is OPTIONAL, especially all support for barenameshortname and other XPointers in external resources since the application may not have control over how the fragment is generated (leading to interoperability problems and validation failures).

'#xpointer(/)' MUST be interpreted to identify the root node [XPath] of the document that contains the URI attribute.

'#xpointer(id('ID'))' MUST be interpreted to identify the element node identified by '#element(ID)' [XPointer-Element] when evaluated with respect to the document that contains the URI attribute.

The original edition of this specification [XMLDSIG-2002] referenced the XPointer Candidate Recommendation [XPTR-2001] and some implementations support it optionally. That Candidate Recommendation has been superseded by the [XPointer-Framework], [XPointer-xmlns] and [XPointer-Element] Recommendations, and -- at the time of this edition -- the [XPointer-xpointer] Working Draft. Therefore, the use Support of the xpointer() scheme [XPointer-xpointer] beyond the minimal usage discussed in this section is discouraged.

Identifies the element with ID attribute value 'chapter1' of the external XML resource 'http://example.com/bar.xml', provided as an octet stream. Again, for the sake of interoperability, the element identified as 'chapter1' should be obtained using an XPath transform rather than a URI fragment (barenameshortname XPointer resolution in external resources is not REQUIRED in this specification).

Identifies a node-set containing the element with ID attribute value 'chapter1' of the XML resource containing the signature. XML Signature (and its applications) modify this node-set to include the element plus all descendentsdescendants including namespaces and attributes -- but not comments.

4.3.3.3 Same-Document URI-References

Dereferencing a same-document reference MUST result in an XPath node-set suitable for use by Canonical XML [XML-C14N]. Specifically, dereferencing a null URI (URI="") MUST result in an XPath node-set that includes every non-comment node of the XML document containing the URI attribute. In a fragment URI, the characters after the number sign ('#') character conform to the XPointer syntax [Xptr][XPointer-Framework]. When processing an XPointer, the application MUST behave as if the XPointer was evaluated with respect to theroot node of the XML document containing the URI attribute were used to initialize the XPointer evaluation context. The application MUST behave as if the result of XPointer processing [XPointer-Framework] were a node-set derived from the resultant location-set resultant subresource as follows:

1. discard point nodes
2. replace each range node with all XPath nodes having full or partial content within the range
3. include XPath nodes having full or partial content within the subresource
4. if the URI is not a full XPointerhas no fragment identifier or the fragment identifier is a shortname XPointer, then delete all comment nodes

The last step is performed for null URIs,barename and shortname XPointers and child sequence XPointers. It' is necessary because when [XML-C14N] or [XML-C14N11] is passed a node-set, it processes the node-set as is: with or without comments. Only when it' is called with an octet stream does it invoke its own XPath expressions (default or without comments). Therefore to retain the default behavior of stripping comments when passed a node-set, they are removed in the last step if the URI is not a fullscheme-based XPointer. To retain comments while selecting an element by an identifier ID, use the following fullscheme-based XPointer: URI='#xpointer(id('ID'))'. To retain comments while selecting the entire document, use the following fullscheme-based XPointer: URI='#xpointer(/)'. This XPointer contains a simple XPath expression that includes the root node, which the second to last step above replaces with all nodes of the parse tree (all descendants, plus all attributes, plus all namespaces nodes).

The interpretation of these XPointers is defined in The Reference Processing Model (section 4.3.3.2).

4.3.3.4 The Transforms Element

Examples of transforms include but are not limited to base64 decoding [MIME], canonicalization [XML-C14N], XPath filtering [XPath], and XSLT [XSLT]. The generic definition of the Transform element also allows application-specific transform algorithms. For example, the transform could be a decompression routine given by a Java class appearing as a base64 encoded parameter to a Java Transform algorithm. However, applications should refrain from using application-specific transforms if they wish their signatures to be verifiable outside of their application domain. Transform Algorithms Transform Algorithms (section 6.6) defines the list of standard transformations.

4.3.3.5 The DigestMethod Element

4.3.3.6 The DigestValue Element

4.4 The KeyInfo Element

4.4.1 The KeyName Element

4.4.2 The KeyValue Element

4.4.2.1 The DSAKeyValue Element

4.4.2.2 The RSAKeyValue Element

4.4.3 The RetrievalMethod Element

Type is an optional identifier for the type of data to be retrieved after all transforms have been applied%% E05 2002-05-08 %%. The result of dereferencing a RetrievalMethod Reference for all KeyInfo types defined by this specification (section 4.4) with a corresponding XML structure is an XML element or document with that element as the root. The rawX509Certificate KeyInfo (for which there is no XML structure) returns a binary X509 certificate.

   Schema Definition

   <element name="RetrievalMethod" type="ds:RetrievalMethodType"/> 
   <complexType name="RetrievalMethodType">
     <sequence>
       <element ref="ds:Transforms" minOccurs="0"/> 
     </sequence>  
     <attribute name="URI" type="anyURI" use="required"/>
     <attribute name="Type" type="anyURI" use="optional"/>
   </complexType>

Note: The schema for the URI attribute of RetrievalMethod erroneously omitted the attribute: use="required"

The DTD is correct. However, this error only results in a more lax schema which permits all valid RetrievalMethod elements. Because the existing schema is embedded in many applications, which may include the schema in their signatures, the schema has not been corrected to be more restrictive.

4.4.4 The X509Data Element

1. • The element, which contains an X.509 issuer distinguished name/serial number pair. The distinguished name SHOULD be represented as a string that complies with section 3 of that SHOULD be compliant with RFC22534514 [LDAP-DN] [LDAP-DN], to be generated according to the Distinguished Name Encoding Rules section below,
   • The element, which contains an X.509 subject distinguished name that SHOULD be represented as a string that complies with section 3 of compliant with RFC22534514 [LDAP-DN] [LDAP-DN], to be generated according to the Distinguished Name Encoding Rules section below,

4.4.4.1 Distinguished Name Encoding Rules

Also, strings in DNamesTo encode a distinguished name (X509IssuerSerial,X509SubjectName, and KeyName if approriateappropriate), the encoding rules in section 2 of RFC 2253 4514 [LDAP-DN] [LDAP-DN] SHOULD be applied, except that the string encoding character escaping rules in section 2.4 of RFC 2253 4514 [LDAP-DN] [LDAP-DN] should MAY be encoded augmented as follows:

• Consider the string as consisting of Unicode characters.
• Escape occurrences of the following special characters by prefixing it with the "\" character:
  • a "#" character occurring at the beginning of the string
  • one of the characters ",", "+", """, "\", "<", ">" or ";"
• Escape any trailing white space characters (Unicode \x20) by replacing "\ " with them with "\20", instead of using the escape sequence "\ ".
• Since a XML document logically consists of characters, not octets, the resulting Unicode string is finally encoded according to the character encoding used for producing the physical representation of the XML document.

Since a XML document logically consists of characters, not octets, the resulting Unicode string is finally encoded according to the character encoding used for producing the physical representation of the XML document.

4.4.5 The PGPData Element

4.4.6 The SPKIData Element

4.4.7 The MgmtData Element

4.5 The Object Element

The MimeType attribute is an optional attribute which describes the data within the Object (independent of its encoding). This is a string with values defined by [MIME]. For example, if the Object contains base64 encoded PNG, the Encoding may be specified as 'http://www.w3.org/2000/09/xmldsig#base64' %% E06 2002-06-06 %% and the MimeType as 'image/png'. This attribute is purely advisory; no validation of the MimeType information is required by this specification. Applications which require normative type and encoding information for signature validation should specify Transforms with well defined resulting types and/or encodings.

5.0 Additional Signature Syntax

5.1 The Manifest Element

5.2 The SignatureProperties Element

5.3 Processing Instructions in Signature Elements

5.4 Comments in Signature Elements

6.0 Algorithms

6.1 Algorithm Identifiers and Implementation Requirements

1. Required Canonical XML 1.0(omits comments)
2. Recommended Canonical XML 1.0with Comments
3. Required Canonical XML 1.1 (omits comments)
   http://www.w3.org/2006/12/xml-c14n11
4. Recommended Canonical XML 1.1 with Comments
   http://www.w3.org/2006/12/xml-c14n11#WithComments

6.2 Message Digests

6.2.1 SHA-1

The SHA-1 SHA-1 algorithm [SHA-1] takes no explicit parameters. An example of an SHA-1 DigestAlg element is:

6.3 Message Authentication Codes

6.3.1 HMAC

6.4 Signature Algorithms

6.4.1 DSA

6.4.2 PKCS1 (RSA-SHA1)

The expression "RSA algorithm" as used in this draftspecification%%E07 2003-01-10%% refers to the RSASSA-PKCS1-v1_5 algorithm described in RFC 2437 [PKCS1]. The RSA algorithm takes no explicit parameters. An example of an RSA SignatureMethod element is:

6.5 Canonicalization Algorithms

Various canonicalization algorithms require conversion to [UTF-8].The two algorithms below understand at least [UTF-8] and [UTF-16] as input encodings. We RECOMMEND that externally specified algorithms do the same. Knowledge of other encodings is OPTIONAL.

Various canonicalization algorithms transcode from a non-Unicode encoding to Unicode. The two algorithms below perform text normalization during transcodingThe output of these algorithms will be in NFC [NFC, NFC-Corrigendum]. This is because the XML processor used to prepare the XPath data model input is required (by the Data Model) to use Normalization Form C when converting an XML document to the UCS character domain from any encoding that is not UCS-based. %% E04 2002-03-20 %%

This specification REQUIRES implementation of both Canonical XML 1.0 [XML-C14N] and Canonical XML 1.1 [XML-C14N11]. We RECOMMEND that generators applications that generate signatures choose Canonical XML 1.1 [XML-C14N11] when inclusive canonicalization is desired.

Note: Canonical XML 1.0 [XML-C14N] and Canonical XML 1.1 [XML-C14N11] specifiesy a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and some attributes in the 'xml:' namespace. However, some applications require a method which, to the extent practical, excludes unused ancestor context from a canonicalized subdocument. The Exclusive XML Canonicalization Recommendation [XML-exc-C14N] may be used to address requirements resulting from scenarios where a subdocument is moved between contexts. %%E02 2002-01-29%%

6.5.1 Canonical XML 1.0

Identifier for REQUIRED Canonical XML 1.0 (omits comments):

Identifier for Canonical XML 1.0 with Comments:

The normative specification of Canonical XML1.0 is [XML-C14N]. The algorithm is capable of taking as input either an octet stream or an XPath node-set (or sufficiently functional alternative). The algorithm produces an octet stream as output. Canonical XML is easily parameterized (via an additional URI) to omit or retain comments.

6.5.2 Canonical XML 1.1

Identifier for REQUIRED Canonical XML 1.1 (omits comments):

http://www.w3.org/2006/12/xml-c14n11

Identifier for Canonical XML 1.1 with Comments:

http://www.w3.org/2006/12/xml-c14n11#WithComments

The normative specification of Canonical XML 1.1 is [XML-C14N11]. The algorithm is capable of taking as input either an octet stream or an XPath node-set (or sufficiently functional alternative). The algorithm produces an octet stream as output. Canonical XML 1.1 is easily parameterized (via an additional URI) to omit or retain comments.

6.6 Transform Algorithms

6.6.1 Canonicalization

6.6.2 Base64

This transform requires an octet stream for input. If an XPath node-set (or sufficiently functional alternative) is given as input, then it is converted to an octet stream by performing operations logically equivalent to 1) applying an XPath transform with expression self::text(), then 2) taking the string-value of the node-set. Thus, if an XML element is identified by a barenameshortname XPointer in the Reference URI, and its content consists solely of base64 encoded character data, then this transform automatically strips away the start and end tags of the identified element and any of its descendant elements as well as any descendant comments and processing instructions. The output of this transform is an octet stream.

6.6.3 XPath Filtering

The input required by this transform is an XPath node-set. Note that if the actual input is an XPath node-set resulting from a null URI or barenameshortname XPointer dereference, then comment nodes will have been omitted. If the actual input is an octet stream, then the application MUST convert the octet stream to an XPath node-set suitable for use by Canonical XML with Comments. (A subsequent application of the REQUIRED Canonical XML algorithm would strip away these comments.) In other words, the input node-set should be equivalent to the one that would be created by the following process:

Note that the XML-Signature XPath Filter 2.0 Recommendation [XPath-Filter-2] may be used for this purpose. This recommendation defines an XPath transform that permits the easy specification of subtree selection and omission that can be efficiently implemented. %%E03 2002-01-29%%

6.6.4 Enveloped Signature Transform

6.6.5 XSLT Transform

7.0 XML Canonicalization and Syntax Constraint Considerations

7.1 XML 1.0, Syntax Constraints, and Canonicalization

7.2 DOM/SAX Processing and Canonicalization

7.3 Namespace Context and Portable Signatures

8.0 Security Considerations

8.1 Transforms

8.1.1 Only What is Signed is Secure

8.1.2 Only What is "Seen" Should be Signed

8.1.3 "See" What is Signed

8.2 Check the Security Model

8.3 Algorithms, Key Lengths, Certificates, Etc.

9.0 Schema, DTD, Data Model, and Valid Examples

10.0 Definitions

11.0 References

FIPS PUB 186-2 FIPS PUB 186-2. U.S. Department of Commerce/National Institute of Standards and Technology. http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf

RFC4514 2253. Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. M. Wahl, S. Kille, T. HowesK. Zeilenga, Ed. December 1997 June 2006. http://www.ietf.org/rfc/rfc2253.txthttp://www.ietf.org/rfc/rfc4514.txt

SAX: The Simple API for XMLSAX: The Simple API for XML. D. Megginson, et al. May 1998. http://www.megginson.com/SAX/index.htmlhttp://www.megginson.com/downloads/SAX/

FIPS PUB 180-1 FIPS PUB 180-2. U.S. Department of Commerce/National Institute of Standards and Technology. http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf

Unicode

The Unicode Consortium. The Unicode Standard.
http://www.unicode.org/unicode/standard/standard.html

RFC 2396. RFC 3986. T. Berners-Lee, R. Fielding, L. Masinter. August 1998January 2005. http://www.ietf.org/rfc/rfc2396.txt http://www.ietf.org/rfc/rfc3986.txt

URI-Literal

RFC 2732. Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. December 1999.

http://www.ietf.org/rfc/rfc2732.txt

Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation. T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen. October 2000.Extensible Markup Language (XML) 1.0 (Fourth Edition). W3C Recommendation T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen, F.Yergeau. 16 August 2006, edited in place 29 September 2006.

http://www.w3.org/TR/2000/REC-xml-20001006 http://www.w3.org/TR/2000/REC-xml-20060816/

XML-C14N11

Canonical XML 1.1. W3C Recommendation. J. Boyer, G. Marcy. 2 May 2008.
http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/

XML-exc-C14N

Exclusive XML Canonicalization Version 1.0 W3C Recommendation. J. Boyer, D. Eastlake 3rd., J. Reagle. July 2002.
http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/

Namespaces in XML. W3C Recommendation. T. Bray, D. Hollander, A. Layman. January 1999.Namespaces in XML 1.0 (Second Edition). W3C Recommendation. T. Bray, D. Hollander, A. Layman, R. Tobin. 16 August 2006.

http://www.w3.org/TR/1999/REC-xml-names-19990114http://www.w3.org/TR/2006/REC-xml-names-20060816/

. W3C Recommendation. H. Thompson,D. Beech, M. Maloney, N. Mendelsohn, H. Thompson. May 2001October 2004.

http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ W3C Recommendation. P. Biron, A. Malhotra. May 2001.

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212//

XMLDSIG-2002

XML-Signature Syntax and Processing. D. Eastlake, J. Reagle, and D. Solo. W3C Recommendation, February 2002.

http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

XPath Filter-2

XML-Signature XPath Filter 2.0. W3C Recommendation. J. Boyer, M. Hughes, J. Reagle. November 2002.
http://www.w3.org/TR/2002/REC-xmldsig-filter2-20021108/

XPTR-2001

XML Pointer Language (XPointer). W3C Candidate Recommendation. S. DeRose, R. Daniel, E. Maler. January 2001.

http://www.w3.org/TR/2001/CR-xptr-20010911/

XPointer-Element

XPointer element() Scheme. W3C Recommendation. P. Grosso, E. Maler, J. Marsh, N. Walsh. March 2003.

http://www.w3.org/TR/2003/REC-xptr-element-20030325/

XPointer-Framework

XPointer Framework. W3C Recommendation. P. Grosso, E. Maler, J. Marsh, N. Walsh. March 2003.

http://www.w3.org/TR/2003/REC-xptr-framework-20030325/

XPointer-xpointer

XPointer xpointer() Scheme. W3C Working Draft. S. DeRose, E. Maler, R. Daniel. December 2002.

http://www.w3.org/TR/2002/WD-xptr-xpointer-20021219/

XPointer-xmlns

XPointer xmlns() Scheme. W3C Working Recommendation. S. DeRose, R. Daniel, E. Maler, J. Marsh. March 2003.

http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325/

XSL

Extensible Stylesheet Language (XSL). W3C Recommendation. S. Adler, A. Berglund, J. Caruso, S. Deach, T. Graham, P. Grosso, E. Gutentag, A. Milowski, S. Parnell, J. Richman, S. Zilles. October 2001.

12. Authors' Address

Donald E. Eastlake 3rd
Motorola Laboratories, 20 Forbes Boulevard
111 Locke Drive
Marlborough, MA 01752 USA
Mansfield, MA 02048 USA
Phone: 1-508-261-5434 +1-508-786-7554
Email: Donald.Eastlake@motorola.com d3e3e3@gmail.com

Joseph M. Reagle Jr., W3C
Massachusetts Institute of Technology
Laboratory for Computer Science
NE43-350, 545 Technology Square
Cambridge, MA 02139
Phone: + 1.617.258.7621
Email: reagle@w3.org Joseph M. Reagle Jr.
Department of Media, Culture, and Communication
New York University
Email: reagle@mit.edu