XML Signature Syntax and Processing Version 2.0 XML Signature Syntax and Processing Version 2.0 W3C Working Group Note 11 April 2013 This version: Latest published version: Latest editor's draft: Previous version: Editors: Donald Eastlake d3e3e3@gmail.com Joseph Reagle reagle@mit.edu David Solo dsolo@alum.mit.edu Frederick Hirsch frederick.hirsch@nokia.com (2nd edition, 1.1, 2.0) Thomas Roessler tlr@w3.org (2nd edition, 1.1) Kelvin Yiu kelviny@microsoft.com (1.1) Pratik Datta pratik.datta@oracle.com (2.0) Scott Cantor cantor.2@osu.edu (2.0) Authors: Mark Bartel mbartel@adobe.com John Boyer boyerj@ca.ibm.com Barb Fox bfox@Exchange.Microsoft.com Brian LaMacchia bal@microsoft.com Ed Simon edsimon@xmlsec.com 2013 The IETF Trust W3C MIT ERCIM Keio Beihang ), All Rights Reserved. W3C liability trademark and document use rules apply. Abstract This informative W3C Working Group Note describes XML digital signature processing rules and syntax. XML Signatures provide integrity message authentication , and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere. XML Signature 2.0 includes a new Reference processing model designed to address additional requirements including performance, simplicity and streamability. This "2.0 mode" model is significantly different than the XML Signature 1.x model in that it explicitly defines selection, canonicalization and verification steps for data processing and disallows generic transforms. XML Signature 2.0 is designed to be backward compatible through the inclusion of a "Compatibility Mode" which enables the XML Signature 1.x model to be used where necessary. Status of This Document This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. Note : On 23 April 2013, the reference to the "Additional XML Security URIs" RFC was updated. The Director previously authorized the publication knowing that the reference would be updated in a near future. The XML Security Working Group has agreed not to progress this XML Signature Syntax and Processing Version 2.0 specification further as a Recommendation track document, electing to publish it as an informative Working Group Note. The Working Group has not performed interop testing on the material in this document. Since the last publication as a Candidate Recommendation the following changes in XML Signature 1.1 have been also incorporated into this specification: Removed the OCSPResponse element originally proposed to be part of XML Signature 1.1 for optional inclusion in the X509Data element. Changed the references and language related to the use of Elliptic Curve algorithms in line with the XML Security Patent Advisory Group report . In conjunction with these changes, removed warning notes related to the use of Elliptic Curve algorithms, Added algorithm identifiers and information related to additional OPTIONAL algorithms: SHA-224 ECDSA-SHA224 RSAwithSHA224 and HMAC-SHA224 Updated the security considerations text related to key lengths for the DSA and RSA algorithms. Changed DSA 1024 bit verification from REQUIRED to MAY Added the Exclusive C14N omits comments algorithm as REQUIRED to implement, reflecting existing practice, and Updated the KeyInfoReference implementation requirement to SHOULD instead of RetrievalMethod Corrected minor errors in examples (e.g. ECDSAKeyValue ), Updated the formatting of examples and schema samples, Clarified the text in the bullet for the library of functions in section B.7.3 XPath Filtering , in response to Last Call issue LC-2721 Referenced the XML Signature Best Practices Note XMLDSIG-BESTPRACTICES ] from the introduction Additional changes for this publication include the following: Changing the status to W3C Working Group Note, updating the abstract, status section and title page material accordingly. Updating the references, including replacing RFC 4051 with RFC 6931 which updates it. diff showing changes since the previous Candidate Recommendation is available. Additional information related to the IPR status of XML Signature 2.0 related to Elliptic Curve algorithms is available at This document was published by the XML Security Working Group as a Working Group Note.
If you wish to make comments regarding this document, please send them to public-xmlsec@w3.org archives ).
All comments are welcome. Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. This document was produced by a group operating under the 5 February 2004 W3C Patent Policy W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy Table of Contents 1. Introduction 1.1 XML Signature 2.0 and 1.x compatibility 1.2 Editorial and Conformance Conventions 1.3 Design Philosophy 1.4 Versions Namespaces and Identifiers 1.5 Acknowledgements 2. Signature Overview and Examples 2.1 Simple XML Signature 2.0 Example 2.2 Detailed XML Signature 2.0 Example Using Ids 2.3 Detailed XML Signature 2.0 Example using XPath 3. Conformance 3.1 Common Conformance Requirements 3.1.1 General Algorithm Identifier and Implementation Requirements 3.2 XML Signature 2.0 Conformance 3.2.1 XML Signature 2.0 Algorithm Identifiers and Implementation Requirements 3.3 Compatibility Mode Conformance 3.3.1 Compatibility Mode Algorithm Identifiers and Implementation Requirements 4. Processing Rules 4.1 Signature Generation 4.2 Reference Generation 4.3 Core Validation 4.4 Reference Check 4.5 Reference Validation 4.6 Signature Validation 5. Core Signature Syntax 5.1 The ds:CryptoBinary Simple Type 5.2 The Signature element 5.3 The SignatureValue Element 5.4 The SignedInfo Element 5.4.1 The CanonicalizationMethod Element 5.4.2 The SignatureMethod Element 5.4.3 The DigestMethod Element 5.4.4 The DigestValue Element 6. Referencing Content 6.1 The Reference Element 6.1.1 The URI Attribute 6.2 The Transforms Element 6.3 The dsig2:Selection Element 6.3.1 Subtrees with Optional Exclusions 6.4 The dsig2:Verifications Element 7. The KeyInfo Element 7.1 The KeyName Element 7.2 The KeyValue Element 7.2.1 The DSAKeyValue Element 7.2.2 The RSAKeyValue Element 7.2.3 The dsig11:ECKeyValue Element 7.2.3.1 Explicit Curve Parameters 7.2.3.2 Compatibility with RFC 4050 7.3 The RetrievalMethod Element 7.4 The X509Data Element 7.4.1 Distinguished Name Encoding Rules 7.5 The PGPData Element 7.6 The SPKIData Element 7.7 The MgmtData Element 7.8 XML Encryption EncryptedKey and DerivedKey Elements 7.9 The dsig11:DEREncodedKeyValue Element 7.10 The dsig11:KeyInfoReference Element 8. The Object Element 9. Additional Signature Syntax 9.1 The Manifest Element 9.2 The SignatureProperties Element 9.3 Processing Instructions in Signature Elements 9.4 Comments in Signature Elements 10. Algorithms 10.1 Message Digests 10.1.1 SHA-1 10.1.2 SHA-224 10.1.3 SHA-256 10.1.4 SHA-384 10.1.5 SHA-512 10.2 Message Authentication Codes 10.2.1 HMAC 10.3 Signature Algorithms 10.3.1 DSA 10.3.2 RSA (PKCS#1 v1.5) 10.3.3 ECDSA 10.4 Canonicalization Algorithms 10.4.1 Canonical XML 2.0 10.5 The Transform Algorithm 10.6 dsig2:Selection Algorithms 10.6.1 Selection of XML Documents or Fragments 10.6.1.1 The dsig2:IncludedXPath Element 10.6.1.2 The dsig2:ExcludedXPath Element 10.6.1.3 The dsig2:ByteRange Element 10.6.2 Selection of External Binary Data 10.6.3 Selection of Binary Data within XML 10.7 The dsig2:Verification Types 10.7.1 DigestDataLength 10.7.2 PositionAssertion 10.7.3 IDAttributes 11. XML Canonicalization and Syntax Constraint Considerations 11.1 XML 1.0 Syntax Constraints, and Canonicalization 11.2 DOM/SAX Processing and Canonicalization 12. Security Considerations 12.1 Transforms 12.1.1 Only What is Signed is Secure 12.1.2 Only What is "Seen" Should be Signed 12.1.3 "See" What is Signed 12.2 Check the Security Model 12.3 Algorithms, Key Lengths, Certificates, Etc. 13. Schema 13.1 XSD Schema A. Definitions B. Compatibility Mode B.1 "Compatibility Mode" Examples B.1.1 Simple Example in "Compatibility Mode" B.1.2 More on Reference B.1.3 Extended Example ( Object and SignatureProperty B.1.4 Extended Example ( Object and Manifest B.2 Compatibility Mode Processing B.2.1 Reference Generation in "Compatibility Mode" B.2.2 Reference check in "Compatibility Mode" B.2.3 Signature Validation in "Compatibility Mode" B.2.4 Reference Validation in "Compatibility Mode" B.3 Use of CanonicalizationMethod in "Compatibility Mode" B.4 The URI Attribute in "Compatibility Mode" B.4.1 The "Compatibility Mode" Reference Processing Model B.4.2 "Compatibility Mode" Same-Document URI-References B.5 "Compatibility Mode" Transforms and Processing Model B.6 "Compatibility Mode" Canonicalization Algorithms B.6.1 Canonical XML 1.0 B.6.2 Canonical XML 1.1 B.6.3 Exclusive XML Canonicalization 1.0 B.7 "Compatibility Mode" Transform Algorithms B.7.1 Canonicalization B.7.2 Base64 B.7.3 XPath Filtering B.7.4 Signature Transform B.7.5 XSLT Transform B.8 Namespace Context and Portable Signatures C. References C.1 Normative references C.2 Informative references 1. Introduction This section is non-normative. This document specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object) , including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, this specification defines an XML signature element type and an XML signature application ; conformance requirements for each are specified by way of schema definitions and prose respectively. This specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information. The XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements. For further information, please see section 12. Security Considerations XML Signature 2.0 includes a new Reference processing model designed to address additional requirements including performance, simplicity and streamability. This "2.0 mode" model is significantly different than the XML Signature 1.x model in that it explicitly defines selection, canonicalization and verification steps for data processing and disallows generic transforms. XML Signature 2.0 is designed to be backward compatible through the inclusion of a "Compatibility Mode" which enables the XML Signature 1.x model to be used where necessary. The Working Group encourages implementers and developers to read XML Signature Best Practices XMLDSIG-BESTPRACTICES ]. It contains a number of best practices related to the use of XML Signature, including implementation considerations and practical ways of improving security. 1.1 XML Signature 2.0 and 1.x compatibility This section is non-normative. This specification defines XML Signature 2.0 which differs from XML Signature 1.x in some specific areas, in particular the use of various transform algorithms versus a fixed 2.0 transform that implies the use of Selection and Verification steps in conjunction with ds:Reference processing, the corresponding disuse of the URI ds:Reference attribute, the use of Canonical XML 2.0 [ XML-C14N20 ] in place of other canonicalization algorithms, and updates to the required algorithms and other changes. This specification defines a "Compatibility Mode" that supports an XML Signature 1.x mode of operation. Compliance and other aspects unique to "Compatibility Mode" are outlined in section B. Compatibility Mode The body of the document refers to the syntax and processing model for the new 2.0 mode of operation, referred to as "XML Signature 2.0" in the document. Use of the "Compatibility Mode" is noted explicitly when required. 1.2 Editorial and Conformance Conventions For readability, brevity, and historic reasons this document uses the term "signature" to generally refer to digital authentication values of all types. Obviously, the term is also strictly used to refer to authentication values that are based on public keys and that provide signer authentication. When specifically discussing authentication values based on symmetric secret key codes we use the terms authenticators or authentication codes. (See section 12.2 Check the Security Model .) This specification provides normative XML Schemas [ XMLSCHEMA-1 ], XMLSCHEMA-2 ]. The full normative grammar is defined by the XSD schemas and the normative text in this specification. The standalone XSD schema files are authoritative in case there is any disagreement between them and the XSD schema portions in this specification. The key words " MUST ", " MUST NOT ", " REQUIRED ", " SHALL ", " SHALL NOT ", SHOULD ", " SHOULD NOT ", " RECOMMENDED ", " MAY ", and " OPTIONAL " in this specification are to be interpreted as described in [ RFC2119 ]. "They MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)" Consequently, we use these capitalized key words to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the Namespaces in XML specification [ XML-NAMES ] is described as " REQUIRED ." 1.3 Design Philosophy The design philosophy and requirements of this specification are addressed in the original XML-Signature Requirements document XMLDSIG-REQUIREMENTS ], the XML Security 1.1 Requirements document XMLSEC11-REQS ], and the XML Security 2.0 Requirements document [ XMLSEC2-REQS ]. 1.4 Versions Namespaces and Identifiers This specification makes use of XML namespaces, and uses Uniform Resource Identifiers [ URI ] to identify resources, algorithms, and semantics. Implementations of this specification MUST use the following XML namespace URIs URI namespace prefix XML internal entity default namespace ds: dsig: "http://www.w3.org/2000/09/xmldsig#"> dsig11: "http://www.w3.org/2009/xmldsig11#"> dsig2: "http://www.w3.org/2010/xmldsig2#"> While implementations MUST support XML and XML namespaces, and while use of the above namespace URIs is REQUIRED , the namespace prefixes and entity declarations given are merely editorial conventions used in this document. Their use by implementations is OPTIONAL These namespace URIs are also used as the prefix for algorithm identifiers that are under control of this specification. For resources not under the control of this specification, we use the designated Uniform Resource Names [ URN ], [ RFC3406 ] or Uniform Resource Identifiers [ URI ] defined by the relevant normative external specification. The dsig: namespace was introduced in the first edition of this specification, and dsig11: namespace was introduced in 1.1. This version does not coin any new elements or algorithm identifiers in those namespaces; instead, the dsig2: namespace is used. This specification uses algorithm identifiers in the namespace that were originally coined in [ RFC6931 ]. RFC 6931 associates these identifiers with specific algorithms. Implementations of this specification MUST be fully interoperable with the algorithms specified in RFC6931 ], but MAY compute the requisite values through any technique that leads to the same output. Examples of items in various namespaces include: SignatureProperties is identified and defined by the disg: namespace ECKeyValue is identified and defined by the dsig11: namespace XSLT is identified and defined by an external URI SHA1 is identified via this specification's namespace and defined via a normative reference FIPS-180-3 FIPS PUB 180-3. Secure Hash Standard. U.S. Department of Commerce/National Institute of Standards and Technology. Selection is identified and defined by the dsig2: namespace No provision is made for an explicit version number in this syntax. If a future version of this specification requires explicit versioning of the document format, a different namespace will be used. 1.5 Acknowledgements The contributions of the members of the XML Signature Working Group to the first edition specification are gratefully acknowledged: Mark Bartel, Adobe, was Accelio (Author); John Boyer, IBM (Author); Mariano P. Consens, University of Waterloo; John Cowan, Reuters Health; Donald Eastlake 3rd, Motorola; (Chair, Author/Editor); Barb Fox, Microsoft (Author); Christian Geuer-Pollmann, University Siegen; Tom Gindin, IBM; Phillip Hallam-Baker, VeriSign Inc; Richard Himes, US Courts; Merlin Hughes, Baltimore; Gregor Karlinger, IAIK TU Graz; Brian LaMacchia, Microsoft (Author); Peter Lipp, IAIK TU Graz; Joseph Reagle, NYU, was W3C (Chair, Author/Editor); Ed Simon, XMLsec (Author); David Solo, Citigroup (Author/Editor); Petteri Stenius, Capslock; Raghavan Srinivas, Sun; Kent Tamura, IBM; Winchel Todd Vincent III, GSU; Carl Wallace, Corsec Security, Inc.; Greg Whitehead, Signio Inc. As are the first edition Last Call comments from the following: Dan Connolly, W3C Paul Biron, Kaiser Permanente, on behalf of the XML Schema WG Martin J. Duerst, W3C ; and Masahiro Sekiguchi, Fujitsu; on behalf of the Internationalization WG/IG Jonathan Marsh, Microsoft, on behalf of the Extensible Stylesheet Language WG 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, Applied Information processing and Kommunications (IAIK); 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. Contributions for version 1.1 were received from the members of the XML Security Working Group: Scott Cantor, Juan Carlos Cruellas, Pratik Datta, Gerald Edgar, Ken Graf, Phillip Hallam-Baker, Brad Hill, Frederick Hirsch (Chair, Editor), Brian LaMacchia, Konrad Lanz, Hal Lockhart, Cynthia Martin, Rob Miller, Sean Mullan, Shivaram Mysore, Magnus Nyström, Bruce Rich, Thomas Roessler, Ed Simon, Chris Solc, John Wray, Kelvin Yiu. 2. Signature Overview and Examples This section is non-normative. This section provides an overview and examples of XML digital signature syntax. The specific processing is given in section 4. Processing Rules . The formal syntax is found in section 5. Core Signature Syntax and section 9. Additional Signature Syntax In this section, an informal representation and examples are used to describe the structure of the XML signature syntax. This representation and examples may omit attributes, details and potential features that are fully explained later. XML Signatures are applied to arbitrary digital content (data objects) via an indirection. Data objects are digested, the resulting value is placed in an element (with other information) and that element is then digested and cryptographically signed. XML digital signatures are represented by the Signature element which has the following structure (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; and "*" denotes zero or more occurrences): Example 1 ID /> /> URI )?
)+
)? ID )*
Signatures are related to data objects via URIs [ URI ]. 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. Detached signatures are over external network resources or local data objects that reside within the same XML document as sibling elements; in this case, the signature is neither enveloping (signature is parent) nor enveloped (signature is child). Since a Signature element (and its Id attribute value/name) may co-exist or be combined with other elements (and their IDs) within a single XML document, care should be taken in choosing names such that there are no subsequent collisions that violate the ID uniqueness validity constraint XML10 ]. 2.1 Simple XML Signature 2.0 Example This section is non-normative. This is the same example an as provided for the XML Signature 1.x , but for XML Signature 2.0. The only differences are in the CanonicalizationMethod and Reference portions. The line numbers in this example match up with the line numbers in the "Compatibility Mode" example. Example 2 s01 Signature Id "MyFirstSignature" xmlns "http://www.w3.org/2000/09/xmldsig#" s02 SignedInfo s03 CanonicalizationMethod Algorithm "http://www.w3.org/2010/xml-c14n2" /> s04 SignatureMethod Algorithm "http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /> s05 Reference s06 Transforms s07 Transform Algorithm "http://www.w3.org/2010/xmldsig2#transform" s07a dsig2 Selection Algorithm "http://www.w3.org/2010/xmldsig2#xml" xmlns dsig2 "http://www.w3.org/2010/xmldsig2#" URI "http://www.w3.org/TR/2000/REC-xhtml1-20000126" s07b /dsig2:Selection> [s07c] [s07d] [s08] [s09] s10 DigestValue dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK ...DigestValue s11 /Reference> [s12] SignedInfo s13 SignatureValue >...SignatureValue s14 KeyInfo s15a KeyValue s15b DSAKeyValue s15c >...>< >...>< >...>< >...s15d /DSAKeyValue> [s15e] KeyValue s16 /KeyInfo> [s17] Signature [s03] In XML Signature 2.0 the Canonicalization Method URI should be Canonical XML 2.0 (or a later version) and all the parameters for Canonical XML 2.0 should be present as subelements of this element XML-C14N20 ]. [s05-s08] Note XML Signature 2.0 does not use various transforms, instead each reference object has two parts - dsig2:Selection element to choose the data object to be signed, and Canonicalization element to convert the data object to a canonicalized octet stream. To fit in these two elements, without breaking backwards compatibility with the 1.0 schema, these elements have been put inside a special Transform with URI In XML Signature 2.0 the Transforms element will contain only this particular fixed Transform [s05] In XML Signature 2.0, the URI attribute is omitted from the Reference . Instead it can be found in the dsig2:Selection [s07a-s07b] The dsig2:Selection element identifies the data object to be signed. This specification identifies only two types, "xml" and "binary", but user specified types are also possible. For example a new type "database-rows" could be defined to select rows from a database for signing. Usually a URI and a few other bits of information are used to identify the data object, but the URI is not required; for example, the "xml" type can identify a local document subset by using an XPath. [s07c] The CanonicalizationMethod element provides the mechanism to convert the data object into a canonicalized octet stream. This specification addresses only canonicalization for xml data. Other forms of canonicalization can be defined - e.g. a scheme for signing mime attachments could define a canonicalization for mime headers and data. The output of the canonicalization is digested. 2.2 Detailed XML Signature 2.0 Example Using Ids The followed detailed example shows XML Signature 2.0 in the context of Web Services Security [ WS-SECURITY11 ], showing how the SOAP body can be referenced using an Id in XML Signature 2.0. This example shows more detail than the previous Simple XML Signature 2.0 Example Note: This example (and the next example using XPath ) show the use of XML Signature 2.0 in the context of Web Services Security. This is illustrative of how a 2.0 signature could be substituted for an 1.x Signature, but has not been standardized in Web Services Security so should only be considered illustrative. Example 3 i01 xml version "1.0" encoding "UTF-8" ?> i02 soap Envelope xmlns soap "http://schemas.xmlsoap.org/soap/envelope/" xmlns wsu "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" i03 soap Header i04 wsse Security xmlns wsse "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" i05 wsse BinarySecurityToken wsu Id "MyID" i06 ValueType "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" i07 EncodingType "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#Base64Binary" i08 MIIEZzCCA9CgAwIBAgIQEmtJZc0 .. i09 /wsse:BinarySecurityToken> [ i10 ] i11 ds SignedInfo i12 ds CanonicalizationMethod Algorithm "http://www.w3.org/2010/xml-c14n2" i13 xmlns c14n2 "http://www.w3.org/2010/xml-c14n2" i14 c14n2 IgnoreComments true /c14n2:IgnoreComments> [ i15 ] falsec14n2 TrimTextNodes i16 c14n2 PrefixRewrite none /c14n2:PrefixRewrite> [ i17 ] i18 /ds:CanonicalizationMethod> [ i19 ] i20 ds Reference i21 ds Transforms i22 ds Transform Algorithm "http://www.w3.org/2010/xmldsig2#newTransformModel" xmlns dsig2 "http://www.w3.org/2010/xmldsig2#" i23 dsig2 Selection Algorithm "http://www.w3.org/2010/xmldsig2#xml" URI "#MsgBody" /> i24 dsig2 Canonicalization i25 c14n2 IgnoreComments true /c14n2:IgnoreComments> [ i26 ] truec14n2 TrimTextNodes i27 c14n2 PrefixRewrite sequential /c14n2:PrefixRewrite> [ i28 ] i29 /dsig2:Canonicalization> [ i30 ] [ i31 ] i32 /dsig2:Verifications> [ i33 ] ds Transform i34 /ds:Transforms> [ i35 ] i36 ds DigestValue dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK ...ds DigestValue i37 /ds:Reference> [ i38 ] ds SignedInfo i39 ds SignatureValue kdutrEsAEw56Sefgs34 ...ds SignatureValue i40 ds KeyInfo i41 ds KeyValue i42 wsse SecurityTokenReference i43 wsse Reference URI "#MyID" /> i44 /wsse:SecurityTokenReference> [ i45 ] ds KeyValue i46 /ds:KeyInfo> [ i47 ] ds Signature i48 /wsse:Security> [ i49 ] soap Header i50 soap Body wsu Id "MsgBody" i51 ex operation xmlns ex "http://www.example.com/" i52 ex param1 42 /ex:param1> [ i53 ] 43ex param2 i54 /ex:operation> [ i55 ] soap Body i56 soap Envelope [ i05-i09 ] The wsse:BinarySecurityToken is a Web Services Security mechanism to convey key information needed for signature processing, in this case an X.509v3 certificate. [ i12-i18 ] This example shows explicit choices for parameters of the ds:CanonicalizationMethod rather than relying on implicit defaults. These canonicalization choices are for the canonicalization of ds:SignedInfo using Canonical XML 2.0 [ XML-C14N20 ]. [ i14 ] The c14n2:IgnoreComments parameter is set to true , the default, meaning that comments will be ignored. [ i15 ] The c14n2:TrimTextNodes parameter is set to false , so white space will be preserved. [ i16 ] The c14n2:PrefixRewrite parameter is set to none , the default, meaning that no prefixes will be rewritten. [ i17 ] The c14n2:QNameAware parameter is set to the empty set, the default, meaning that no QNames require special processing. [ i23 ] The dsig2:Selection URI parameter is set to #MsgBody meaning that the element with the corresponding Id (in this case wsu:Id ) will be selected. [ i24-i29 ] The dsig2:Canonicalization element again has parameters set explicitly for ds:Reference canonicalization. [ i30-i33 ] This example uses the new ability in XML Signature 2.0 for a verifier to receive constraint information that can be used to verify correctness of the information received, to mitigate against attacks. The dsig2:Verifications element contains this verification information. In this case the length of the ds:Reference data that was digested is conveyed. [ i42-i44 ] Web Services Security uses its SecurityTokenReference mechanism to reference key information conveyed in tokens, such as an X.509 certificate. In this example this mechanism is used to reference the binary security token at using the MyID Id. [ i50 ] The soapBody has wsu:Id attribute which is used by the ds:Reference URI attribute to reference the element. 2.3 Detailed XML Signature 2.0 Example using XPath The followed detailed example shows use of XML Signature 2.0 in a Web Services Security example similar to the previous example using an Id reference , but here uses an XPath expression to help mitigate the possibility of wrapping attacks. In this case the soap:Body is signed, but the ex:param2 is omitted from the signature. This could correspond to a case where the the first parameter is known to be invariant end-end while the second parameter might be expected to change as the SOAP message traverses SOAP intermediaries, so is omitted from the signature. Example 4 p01 xml version "1.0" encoding "UTF-8" ?> p02 soap Envelope xmlns soap "http://schemas.xmlsoap.org/soap/envelope/" xmlns ex "http://www.example.com/" p03 soap Header p04 wsse Security xmlns wsse "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" p05 xmlns wsu "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" p06 wsse BinarySecurityToken wsu Id "MyID" p07 ValueType "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" p08 EncodingType "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#Base64Binary" p09 MIIEZzCCA9CgAwIBAgIQEmtJZc0 .. p10 /wsse:BinarySecurityToken> [ p11 ] p12 ds SignedInfo p13 ds CanonicalizationMethod Algorithm "http://www.w3.org/2010/xml-c14n2" p14 xmlns c14n2 "http://www.w3.org/2010/xml-c14n2" p15 c14n2 IgnoreComments true /c14n2:IgnoreComments> [ p16 ] falsec14n2 TrimTextNodes p17 c14n2 PrefixRewrite none /c14n2:PrefixRewrite> [ p18 ] p19 /ds:CanonicalizationMethod> [ p20 ] p21 ds Reference p22 ds Transforms p23 ds Transform Algorithm "http://www.w3.org/2010/xmldsig2#newTransformModel" xmlns dsig2 "http://www.w3.org/2010/xmldsig2#" p24 dsig2 Selection Algorithm "http://www.w3.org/2010/xmldsig2#xml" URI "" p25 dsig2 IncludedXPath /soap:Envelope/ soap Body ]dsig2 IncludedXPath p26 dsig2 ExcludedXPath p27 soap Envelope soap Body ]/ ex operation ]/ ex param2 p28 /dsig2:ExcludedXPath> [ p29 ] dsig2 Selection p30 dsig2 Canonicalization p31 c14n2 IgnoreComments true /c14n2:IgnoreComments> [ p32 ] truec14n2 TrimTextNodes p33 c14n2 PrefixRewrite sequential /c14n2:PrefixRewrite> [ p34 ] p35 /dsig2:Canonicalization> [ p36 ] [ p37 ] p38 /dsig2:Verifications> [ p39 ] ds Transform p40 /ds:Transforms> [ p41 ] p42 ds DigestValue dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK ...ds DigestValue p43 /ds:Reference> [ p44 ] ds SignedInfo p45 ds SignatureValue kdutrEsAEw56Sefgs34 ...ds SignatureValue p46 ds KeyInfo p47 ds KeyValue p48 wsse SecurityTokenReference p49 wsse Reference URI "#MyID" /> p50 /wsse:SecurityTokenReference> [ p51 ] ds KeyValue p52 /ds:KeyInfo> [ p53 ] ds Signature p54 /wsse:Security> [ p55 ] soap Header p56 soap Body p57 ex operation p58 ex param1 42 /ex:param1> [ p59 ] 43ex param2 p60 /ex:operation> [ p61 ] soap Body p62 soap Envelope [ p24 ] In this case the URI attribute of the Reference element is "" as XPath is used rather than an Id based reference. [ p25 ] The dsig2:IncludedXPath element includes an XPath expression to reference the soap:Body element. Note that this expression is written to reference the specific soap:Body to mitigate wrapping attacks. The XPath expression is an XML Security 2.0 profile of XPath 1.0 [ XMLDSIG-XPATH ]. [ p26 ] The dsig2:ExcludedXPath element specifies that the ex:operation[1]/ex:param2[1] child of the soap:Body not be included in the signature. The XPath expression specifies the exact instance to avoid wrapping attacks. 3. Conformance This entire document is informative, published as a W3C Working Group Note. Thus this section should only be considered indicative as to how the material in this document could be interpreted. An implementation that conforms to this specification MUST be conformant to XML Signature 2.0 mode, and MAY be conformant to XML Signature 1.1 Compatibility Mode. 3.1 Common Conformance Requirements The following conformance requirements must be met by all implementations, including those in compatibility mode. 3.1.1 General Algorithm Identifier and Implementation Requirements This section identifies algorithm conformance requirements applicable to both 2.0 and compatibility mode. Algorithms are identified by URIs that appear as an attribute to the element that identifies the algorithms' role ( DigestMethod Transform SignatureMethod , or CanonicalizationMethod ). All algorithms used herein take parameters but in many cases the parameters are implicit. For example, a SignatureMethod is implicitly given two parameters: the keying info and the output of 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. This specification defines a set of algorithms, their URIs, and requirements for implementation. Requirements are specified over implementation, not over requirements for signature use. Furthermore, the mechanism is extensible; alternative algorithms may be used by signature applications. Digest Required SHA1 (Use is DISCOURAGED; see SHA-1 Warning SHA256 Optional SHA224 SHA384 SHA512 Encoding Required base64 ( *note base64 MAC Required HMAC-SHA1 (Use is DISCOURAGED; see SHA-1 Warning HMAC-SHA256 Recommended HMAC-SHA384 HMAC-SHA512 Optional HMAC-SHA224 Signature Required RSAwithSHA256 RFC6931 ECDSAwithSHA256 RFC6931 DSAwithSHA1
signature verification ; use for signature generation is DISCOURAGED; see SHA-1 Warning rsa-sha1 Optional RSAwithSHA224 section 10.3.2 RSA (PKCS#1 v1.5) RSAwithSHA384 section 10.3.2 RSA (PKCS#1 v1.5) RSAwithSHA512 ECDSAwithSHA1 (Use is DISCOURAGED; see SHA-1 Warning section 10.3.3 ECDSA ECDSAwithSHA224 section 10.3.3 ECDSA ECDSAwithSHA384 section 10.3.3 ECDSA ECDSAwithSHA512 section 10.3.3 ECDSA DSAwithSHA1
signature generation DSAwithSHA256 *note: Note that the same URI is used to identify base64 both in "encoding" context (e.g. within the Object element) as well as in "transform" context (when identifying a base64 transform). 3.2 XML Signature 2.0 Conformance An implementation that conforms to this specification MUST support XML Signature 2.0 operation and conform to the following features when not operating in compatibility mode: MUST support the required steps of Signature generation, including the generation of Reference elements and the SignatureValue over SignedInfo as outlined in section 4.1 Signature Generation MUST support the required steps of core validation as outlined in section 4.3 Core Validation MUST support required XML Signature 2.0 Reference generation as outlined in section Not found 'sec-ReferenceGeneration-2.0' MUST conform to the syntax as outlined in text of this specification MUST NOT have a URI attribute in a Reference element Every Reference element MUST have a single Transforms element and that element MUST contain exactly one Transform element with an Algorithm of "http://www.w3.org/2010/xmldsig2#transform" The result of processing each Reference MUST be an octet stream with the digest algorithm applied to the resulting data octets RetrievalMethod SHOULD NOT be used; dsig11:KeyInfoReference SHOULD be used instead. 3.2.1 XML Signature 2.0 Algorithm Identifiers and Implementation Requirements This section identifies algorithms used with the XML digital signature specification. Entries contain the identifier to be used in Signature elements, a reference to the formal specification, and definitions, where applicable, for the representation of keys and the results of cryptographic operations. Note that the algorithms required for 2.0 conformance are fewer than for compatibility mode, and that some algorithms required or optional are disallowed in 2.0. Canonicalization Required Canonical XML 2.0 Transform Required XML Signature 2.0 Transform - Selection Required XML Documents or Fragments - External Binary Data - Selection of Binary Data within XML - Verification Optional DigestDataLength - PositionAssertion - IDAttributes - 3.3 Compatibility Mode Conformance An implementation that conforms to this specification MAY be conformant to Compatibility Mode. To conform to compatibility mode conformance with the following is required as well as conformance to common conformance requirements described in section 3.1 Common Conformance Requirements 3.3.1 Compatibility Mode Algorithm Identifiers and Implementation Requirements The following algorithm support is required for compatibility mode (in addition to those required for all modes). Canonicalization Required Canonical XML 1.0 (omits comments) Canonical XML 1.1 (omits comments) Exclusive XML Canonicalization 1.0 (omits comments) Recommended Canonical XML 1.0 with Comments Canonical XML 1.1 with Comments Exclusive XML Canonicalization 1.0 with Comments Transform Required base64 ( *note base64 Enveloped Signature ( **note Recommended XPath XPath Filter 2.0 Optional XSLT **note: The Enveloped Signature transform removes the Signature element from the calculation of the signature when the signature is within the content that it is being signed. This MAY be implemented via the XPath specification specified in 6.6.4: Enveloped Signature Transform ; it MUST have the same effect as that specified by the XPath Transform. When using transforms, we RECOMMEND selecting the least expressive choice that still accomplishes the needs of the use case at hand: Use of XPath filter 2.0 is recommended over use of XPath filter. Use of XPath filter is recommended over use of XSLT. Note: Implementation requirements for the XPath transform may be downgraded to OPTIONAL in a future version of this specification. 4. Processing Rules The sections below describe the operations to be performed as part of signature generation and validation. 4.1 Signature Generation The REQUIRED steps include the generation of Reference elements and the SignatureValue over SignedInfo Create SignedInfo element with SignatureMethod CanonicalizationMethod and Reference (s). Canonicalize and then calculate the SignatureValue over SignedInfo based on algorithms specified in SignedInfo For XML Signature 2.0 signatures (i.e. not XML Signature 1.x or "Compatibility Mode" signatures), canonicalization in this step MUST use a canonicalization algorithm designated as compatible with XML Signature 2.0. This canonicalization algorithm SHOULD be the same as that used for Reference canonicalization. Construct the Signature element that includes SignedInfo Object (s) (if desired, encoding may be different than that used for signing), KeyInfo (if required), and SignatureValue Note, if the Signature includes same-document references, [ XML10 ] or [ XMLSCHEMA-1 ] ,[ XMLSCHEMA-2 ] validation of the document might introduce changes that break the signature. Consequently, applications should be careful to consistently process the document or refrain from using external contributions (e.g., defaults and entities). 4.2 Reference Generation For each Reference: Decide how to represent the data object as a dsig2:Selection Use Canonicalization to convert the data object into an octet stream. This is not required for binary data. Calculate the digest value over the resulting data object. Create a Reference element, including the dsig2:Selection element, Canonicalization element, the digest algorithm and the DigestValue (Note, it is the canonical form of these references that are signed in section 4.1 Signature Generation and validated in section Not found 'sec-ReferenceCheck-2.0' .) XML data objects MUST be canonicalized using Canonical XML 2.0 [ XML-C14N20 ] or an alternative algorithm that is compliant with its interface. 4.3 Core Validation The REQUIRED steps of core validation include establishing trust in the signing key mentioned in the KeyInfo
(Note in some environments, the signing key is implicitly known, and KeyInfo is not used at all). Checking each Reference to to see if the data object matches with the expected data object. the cryptographic signature validation of the signature calculated over SignedInfo reference validation , the verification of the digest contained in each Reference in SignedInfo These steps are present in ascending order of complexity, which ensures that the verifier rejects invalid signatures as quickly as possible. Note, there may be valid signatures that some signature applications are unable to validate. Reasons for this include failure to implement optional parts of this specification, inability or unwillingness to execute specified algorithms, or inability or unwillingness to dereference specified URIs (some URI schemes may cause undesirable side effects), etc. Comparison of each value in reference and signature validation is 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. But if one uses numeric or octet comparison (choose one) on both the stated and computed values these problems are eliminated. 4.4 Reference Check The absence of arbitrary transforms makes reference checking simpler in XML Signature 2.0. Implementations process the dsig2:Selection in each Reference to return a list of data objects that are included in the signature. For example each reference in a signature may point to a different part of the same document. The signature implementation should return all these parts (possibly as DOM elements) to the calling application, which can then compare them against its policy to make sure what was expected to be signed is actually signed. 4.5 Reference Validation Reference Validation is very similar to that in XML Signature 1.x, except that SignedInfo need not be canonicalized, there are no arbitrary transforms to execute, and there is an optional dsig2:Verifications step. For each Reference in SignedInfo Obtain the data object to be digested using the dsig2:Selection Optional : If the selection relies on an ID-based reference, and there is a dsig2:Verification element with Type="http://www.w3.org/2010/xmldsig2#IDAttributes" , then its content may assist in obtaining the intended data object by identifying an ID attribute that the verifier may not otherwise recognize. Optional : If the selection relies on an ID-based reference, and there is a dsig2:Verification element with Type="http://www.w3.org/2010/xmldsig2#PositionAssertion" , then the verifier may confirm that the data object obtained is the same as that which would be obtained by resolving the XPath expression in the PositionAssertion attribute. Perform the Canonicalization to compute an octet stream. Optional : If there is a dsig2:Verification element with Type="http://www.w3.org/2010/xmldsig2#DigestDataLength" , then verify that the length of the octet stream computed above is the same as the length specified in the DigestDataLength attribute. Digest the resulting data object using the DigestMethod specified in its Reference specification. The canonicalization and digesting can be combined in one step for efficiency. Compare the generated digest value against DigestValue in the SignedInfo Reference ; if there is any mismatch, validation fails. 4.6 Signature Validation Signature Validation in XML Signature 2.0 is very similar to XML Signature 1.x, except that KeyInfo cannot contain any transforms, and the canonicalization of SignatureMethod is not required. These are the steps. Obtain the keying information from KeyInfo or from an external source. Using the CanonicalizationMethod (which must be Canonical XML 2.0 or an alternative algorithm that is compliant with its interface) and use the result (and previously obtained KeyInfo to confirm the SignatureValue over the SignedInfo element. 5. Core Signature Syntax The general structure of an XML Signature is described in section 2. Signature Overview and Examples . This section provides detailed syntax of the core signature features. Features described in this section are mandatory to implement unless otherwise indicated. The syntax is defined via an XML Schema XMLSCHEMA-1 ][ XMLSCHEMA-2 ] with the following XML preamble, declaration, and internal entity. Schema Definition xml version "1.0" encoding "utf-8" ?> xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#">
]> xmlns "http://www.w3.org/2001/XMLSchema" xmlns:ds "http://www.w3.org/2000/09/xmldsig#" targetNamespace "http://www.w3.org/2000/09/xmldsig#" version "0.1" elementFormDefault "qualified" Additional markup defined in version 1.1 of this specification uses the dsig11: namespace. The syntax is defined in an XML schema with the following preamble: Schema Definition xml version "1.0" encoding "utf-8" ?>
]> xmlns "http://www.w3.org/2001/XMLSchema" xmlns:ds "http://www.w3.org/2000/09/xmldsig#" xmlns:dsig11 "http://www.w3.org/2009/xmldsig11#" targetNamespace "http://www.w3.org/2009/xmldsig11#" version "0.1" elementFormDefault "qualified" Finally, markup defined by version 2.0 of this specification uses the dsig2: namespace. The syntax is defined in an XML schema with the following preamble: Notwithstanding the presence of a mixed content model (via mixed="true" declarations) in the definitions of various elements that follow, use of mixed content in conjunction with any elements defined by this specification is NOT RECOMMENDED When these elements are used in conjunction with XML Signature 2.0 signatures, mixed content MUST NOT be used. 5.1 The ds:CryptoBinary Simple Type This specification defines the ds:CryptoBinary simple type for representing arbitrary-length integers (e.g. "bignums") in XML as octet strings. The integer value is first converted to a "big endian" bitstring. The bitstring is then padded with leading zero bits so that the total number of bits == 0 mod 8 (so that there are an integral number of octets). If the bitstring contains entire leading octets that are zero, these are removed (so the high-order octet is always non-zero). This octet string is then base64 [ RFC2045 encoded. (The conversion from integer to octet string is equivalent to IEEE 1363's I2OSP IEEE1363 ] with minimal length). This type is used by "bignum" values such as RSAKeyValue and DSAKeyValue . If a value can be of type base64Binary or ds:CryptoBinary they are defined as base64Binary For example, if the signature algorithm is RSA or DSA then SignatureValue represents a bignum and would be ds:CryptoBinary However, if HMAC-SHA1 is the signature algorithm then SignatureValue could have leading zero octets that must be preserved. Thus SignatureValue is generically defined as of type base64Binary Schema Definition name "CryptoBinary" base "base64Binary" />
5.2 The Signature element The Signature element is the root element of an XML Signature. Implementation MUST generate laxly schema valid XMLSCHEMA-1 ][ XMLSCHEMA-2 Signature elements as specified by the following schema: Schema Definition name "Signature" type "ds:SignatureType" /> name "SignatureType" ref "ds:SignedInfo" /> ref "ds:SignatureValue" /> ref "ds:KeyInfo" minOccurs "0" /> ref "ds:Object" minOccurs "0" maxOccurs "unbounded" />
name "Id" type "ID" use "optional" />
5.3 The SignatureValue Element The SignatureValue element contains the actual value of the digital signature; it is always encoded using base64 RFC2045 ]. Schema Definition name "SignatureValue" type "ds:SignatureValueType" /> name "SignatureValueType" base "base64Binary" name "Id" type "ID" use "optional" />
5.4 The SignedInfo Element The structure of SignedInfo includes a canonicalization algorithm, a signature algorithm, and one or more references. Given the importance of reference processing, this is described separately in section 6. Referencing Content The SignedInfo element may contain an optional ID attribute allowing it to be referenced by other signatures and objects. SignedInfo does not include explicit signature or digest properties (such as calculation time, cryptographic device serial number, etc.). If an application needs to associate properties with the signature or digest, it may include such information in a SignatureProperties element within an Object element. Schema Definition name "SignedInfo" type "ds:SignedInfoType" /> name "SignedInfoType" ref "ds:CanonicalizationMethod" /> ref "ds:SignatureMethod" /> ref "ds:Reference" maxOccurs "unbounded" />
name "Id" type "ID" use "optional" />
5.4.1 The CanonicalizationMethod Element CanonicalizationMethod is a required element that specifies the canonicalization algorithm applied to the SignedInfo element prior to performing signature calculations. This element uses the general structure for algorithms described in section 3.2.1 XML Signature 2.0 Algorithm Identifiers and Implementation Requirements . Implementations MUST support the REQUIRED canonicalization algorithms Schema Definition name "CanonicalizationMethod" type "ds:CanonicalizationMethodType" /> name "CanonicalizationMethodType" mixed "true" namespace "##any" minOccurs "0" maxOccurs "unbounded" />
name "Algorithm" type "anyURI" use "required" />
In XML Signature 2.0, the SignedInfo element is presented as a single subtree with no exclusions to the Canonicalization 2.0 [ XML-C14N20 algorithm. Parameters to that algorithm are represented as subelements of the Canonicalization element. XML Signature 2.0 signatures use the CanonicalizationMethod element to express the canonicalization of each Reference 5.4.2 The SignatureMethod Element SignatureMethod is a required element that specifies the algorithm used for signature generation and validation. This algorithm identifies all cryptographic functions involved in the signature operation (e.g. hashing, public key algorithms, MACs, padding, etc.). This element uses the general structure here for algorithms described in section 3.2.1 XML Signature 2.0 Algorithm Identifiers and Implementation Requirements . While there is a single identifier, that identifier may specify a format containing multiple distinct signature values. Schema Definition name "SignatureMethod" type "ds:SignatureMethodType" /> name "SignatureMethodType" mixed "true" name "HMACOutputLength" minOccurs "0" type "ds:HMACOutputLengthType" /> namespace "##other" minOccurs "0" maxOccurs "unbounded" />
name "Algorithm" type "anyURI" use "required" />
The ds:HMACOutputLength parameter is used for HMAC HMAC ] algorithms. The parameter specifies a truncation length in bits. If this parameter is trusted without further verification, then this can lead to a security bypass CVE-2009-0217 ]. Signatures MUST be deemed invalid if the truncation length is below the larger of (a) half the underlying hash algorithm's output length, and (b) 80 bits. Note that some implementations are known to not accept truncation lengths that are lower than the underlying hash algorithm's output length. 5.4.3 The DigestMethod Element DigestMethod is a required element that identifies the digest algorithm to be applied to the signed object. This element uses the general structure here for algorithms specified in section 3.2.1 XML Signature 2.0 Algorithm Identifiers and Implementation Requirements For "Compatibility Mode" signatures, if the result of the URI dereference and application of Transforms is an XPath node-set (or sufficiently functional replacement implemented by the application) then it must be converted as described in section B.4.1 The "Compatibility Mode" Reference Processing Model . If the result of URI dereference and application of Transforms is an octet stream, then no conversion occurs (comments might be present if Canonical XML with Comments was specified in the Transforms ). The digest algorithm is applied to the data octets of the resulting octet stream. For XML Signature 2.0 signatures, the result of processing the Reference is an octet stream, and the digest algorithm is applied to the resulting data octets. Schema Definition name "DigestMethod" type "ds:DigestMethodType" /> name "DigestMethodType" mixed "true" namespace "##other" processContents "lax" minOccurs "0" maxOccurs "unbounded" />
name "Algorithm" type "anyURI" use "required" />
5.4.4 The DigestValue Element DigestValue is an element that contains the encoded value of the digest. The digest is always encoded using base64 [ RFC2045 ]. Schema Definition name "DigestValue" type "ds:DigestValueType" /> name "DigestValueType" base "base64Binary" />
6. Referencing Content The XML Signature 2.0 specification is designed to support a new, simplified processing model while remaining backwardly-compatible with the older 1.x processing model through optional support of a "Compatibility Mode" defined in a separate section of this document, section B. Compatibility Mode A generic signature processor can determine the mode of a signature by examining the Reference element's attributes and the child element(s) of the Transforms element (if any). If the URI attributes is present, "Compatibility Mode" can be assumed. If the URI attribute is not present, and the Transforms element contains exactly one Transform element with an Algorithm of "http://www.w3.org/2010/xmldsig2#transform" then XML Signature 2.0 processing can be assumed. Otherwise, "Compatibility Mode" is applied. All the references of a signature SHOULD have the same mode; i.e. all XML Signature 2.0, or all "Compatibility Mode". 6.1 The Reference Element Reference is an element that may occur one or more times. It specifies a digest algorithm and digest value, and optionally an identifier of the object being signed, the type of the object, and/or a list of transforms to be applied prior to digesting. The identification (URI) and transforms describe how the digested content (i.e., the input to the digest method) was created. The Type attribute facilitates the processing of referenced data. For example, while this specification makes no requirements over external data, an application may wish to signal that the referent is a Manifest An optional ID attribute permits a Reference to be referenced from elsewhere. Schema Definition name "Reference" type "ds:ReferenceType" /> name "ReferenceType" ref "ds:Transforms" minOccurs "0" /> ref "ds:DigestMethod" /> ref "ds:DigestValue" />
name "Id" type "ID" use "optional" /> name "URI" type "anyURI" use "optional" /> name "Type" type "anyURI" use "optional" />
6.1.1 The URI Attribute The URI attribute MUST be omitted for XML Signature 2.0 signatures. 6.2 The Transforms Element Each Reference MUST contain the Transforms element, and this MUST contain one and only one Transform element with an Algorithm of "http://www.w3.org/2010/xmldsig2#transform" . This signals the 2.0 syntax and processing (Compatibility mode transforms are described in section B.5 "Compatibility Mode" Transforms and Processing Model ). Schema Definition name "Transforms" type "ds:TransformsType" /> name "TransformsType" ref "ds:Transform" maxOccurs "unbounded" />
name "Transform" type "ds:TransformType" /> name "TransformType" mixed "true" minOccurs "0" maxOccurs "unbounded" namespace "##other" processContents "lax" />
name "XPath" type "string" />
name "Algorithm" type "anyURI" use "required" />
The semantics of the Transform element in XML Signature 2.0 is that its input is determined solely from within the Transform itself rather than via the surrounding Reference . The output is guaranteed to be an octet stream. The detailed definition of the XML Signature 2.0 Transform algorithm definitions can be found in section Not found 'sec-Transforms-2.0' A difference from XML Signature 1.x (and the corresponding "Compatibility Mode") is that the use of extensible Transform algorithms is replaced with an extensible syntax for reference and selection processing. This construct is modeled as a fixed Transform, for compatibility with the original schema, and to ensure predictable failure modes for older implementations. Legacy implementations should react to this as an undefined Transform and report failure in the fashion that is normal for them in such a case. 6.3 The dsig2:Selection Element The dsig2:Selection element describes the data being signed for a "2.0 Mode" signature Reference . The content and processing model for this element depends on the value of the required Algorithm attribute, which identifies the selection algorithm/syntax in use. The required URI attribute and any child elements are passed to that algorithm as parameters to selection processing. The Algorithm attribute is an extensibility point enabling application-specific content selection approaches. Each Algorithm must define the parameters expected, how they are expressed within the dsig2:Selection element, how to process the selection, what user-defined object the selection produces, and what canonicalization algorithm(s) to allow for unambiguous conversation of the data into an octet stream. The result of processing the dsig2:Selection element MUST be one of the following: one or more subtrees with optional exclusions (see Subtrees with Exclusions an octet stream any user-defined object In the first case, the current Signature node is implicitly added as an exclusion, and then a "2.0 Mode" canonicalization algorithm (one compatible with these inputs) MUST be applied to produce an octet stream for the digest algorithm. The contents of the sibling CanonicalizationMethod element, if present, will specify the algorithm to use, and supply any non-default parameters to that algorithm. If no sibling CanonicalizationMethod element is present, then the XML Canonicalization 2.0 Algorithm [ XML-C14N20 MUST be applied with no non-default parameters. For an octet stream, no further processing is applied, and the octets are supplied directly to the digest algorithm. For a user-defined object (the result of a user-defined selection process), processing is subject to the definition of that process. 6.3.1 Subtrees with Optional Exclusions Signatures in "2.0 Mode" do not deal with XML content to be signed in terms of an XPath nodeset. Instead, the following interface is used: An XML fragment to be signed is represented as one or more "inclusion" subtrees, and a set of zero or more "exclusions" consisting of subtrees and/or attribute nodes. Exclusions override inclusions; i.e., the selection contains all the nodes in the inclusion subtrees minus all the nodes in the exclusion subtrees. A "subtree" is the portion of an XML document consisting of all the descendants of a particular element node (inclusive), or the document root node. The subtree is identified by the element node/document root node. If, in the inclusion list, one subtree is included in another, the included one is effectively ignored (the two are simply unioned). Each subtree (except when the subtree is of a complete document) must be accompanied by the set of namespace declarations in scope (i.e., inherited from the ancestors of the subtree). 6.4 The dsig2:Verifications Element dsig2:Verifications is an optional element containing information that aids in signature verification. It contains one or more dsig2:Verification elements identifying the type(s) of verification information available. Use of the dsig2:Verifications element by validators is optional, even if the element is present. For example, validators may ignore a dsig2:Verification element of Type "http://www.w3.org/2010/xmldsig2#PositionAssertion" and rely on ID-based referencing (with the risk of being vulnerable to signature wrapping attacks unless other steps are taken) for simplicity. 7. The KeyInfo Element KeyInfo is an optional element that enables the recipient(s) to obtain the key needed to validate the signature. KeyInfo may contain keys, names, certificates and other public key management information, such as in-band key distribution or key agreement data. This specification defines a few simple types but applications may extend those types or all together replace them with their own key identification and exchange semantics using the XML namespace facility XML-NAMES ]. However, questions of trust of such key information (e.g., its authenticity or strength) are out of scope of this specification and left to the application. Details of the structure and usage of element children of KeyInfo other than simple types described in this specification are out of scope. For example, the definition of PKI certificate contents, certificate ordering, certificate revocation and CRL management are out of scope. If KeyInfo is omitted, the recipient is expected to be able to identify the key based on application context. Multiple declarations within KeyInfo refer to the same key. While applications may define and use any mechanism they choose through inclusion of elements from a different namespace, compliant versions MUST implement KeyValue section 7.2 The KeyValue Element ) and SHOULD implement KeyInfoReference section 7.10 The dsig11:KeyInfoReference Element ). KeyInfoReference is preferred over use of RetrievalMethod as it avoids use of Transform child elements that introduce security risk and implementation challenges. Support for other children of KeyInfo is OPTIONAL The schema specification of many of KeyInfo 's children (e.g., PGPData SPKIData X509Data permit their content to be extended/complemented with elements from another namespace. This may be done only if it is safe to ignore these extension elements while claiming support for the types defined in this specification. Otherwise, external elements, including alternative structures to those defined by this specification, MUST be a child of KeyInfo For example, should a complete XML-PGP standard be defined, its root element MUST be a child of KeyInfo . (Of course, new structures from external namespaces can incorporate elements from the dsig: namespace via features of the type definition language. For instance, they can create a schema that permits, includes, imports, or derives new types based on dsig: elements.) The following list summarizes the KeyInfo types that are allocated an identifier in the dsig: namespace; these can be used within the RetrievalMethod Type attribute to describe a remote KeyInfo structure. The following list summarizes the additional KeyInfo types that are allocated an identifier in the dsig11: namespace. In addition to the types above for which we define an XML structure, we specify one additional type to indicate a binary (ASN.1 DER) X.509 Certificate Schema Definition name "KeyInfo" type "ds:KeyInfoType" /> name "KeyInfoType" mixed "true" maxOccurs "unbounded" ref "ds:KeyName" /> ref "ds:KeyValue" /> ref "ds:RetrievalMethod" /> ref "ds:X509Data" /> ref "ds:PGPData" /> ref "ds:SPKIData" /> ref "ds:MgmtData" />
processContents "lax" namespace "##other" />
name "Id" type "ID" use "optional" />
7.1 The KeyName Element The KeyName element contains a string value (in which white space is significant) which may be used by the signer to communicate a key identifier to the recipient. Typically, KeyName contains an identifier related to the key pair used to sign the message, but it may contain other protocol-related information that indirectly identifies a key pair. (Common uses of KeyName include simple string names for keys, a key index, a distinguished name (DN), an email address, etc.) Schema Definition name "KeyName" type "string" /> 7.2 The KeyValue Element The KeyValue element contains a single public key that may be useful in validating the signature. Structured formats for defining DSA ( REQUIRED ), RSA ( REQUIRED ) and ECDSA ( REQUIRED ) public keys are defined in section 10.3 Signature Algorithms . The KeyValue element may include externally defined public keys values represented as PCDATA or element types from an external namespace. Schema Definition name "KeyValue" type "ds:KeyValueType" /> name "KeyValueType" mixed "true" ref "ds:DSAKeyValue" /> ref "ds:RSAKeyValue" />
namespace "##other" processContents "lax" />
7.2.1 The DSAKeyValue Element Identifier Type=" (this can be used within a RetrievalMethod or Reference element to identify the referent's type) DSA keys and the DSA signature algorithm are specified in FIPS-186-3 ]. DSA public key values can have the following fields: a prime modulus meeting the [ FIPS-186-3 ] requirements an integer in the range 2**159 < Q < 2**160 which is a prime divisor of P-1 an integer with certain properties with respect to P and Q G**X mod P (where X is part of the private key and not made public) (P - 1) / Q seed a DSA prime generation seed pgenCounter a DSA prime generation counter Parameter J is available for inclusion solely for efficiency as it can be calculated from P and Q. Parameters seed and pgenCounter are used in the DSA prime number generation algorithm specified in FIPS-186-3 ]. As such, they are optional but must either both be present or both be absent. This prime generation algorithm is designed to provide assurance that a weak prime is not being used and it yields a P and Q value. Parameters P, Q, and G can be public and common to a group of users. They might be known from application context. As such, they are optional but P and Q must either both appear or both be absent. If all of seed and pgenCounter are present, implementations are not required to check if they are consistent and are free to use either and or seed and pgenCounter All parameters are encoded as base64 RFC2045 ] values. Arbitrary-length integers (e.g. "bignums" such as RSA moduli) are represented in XML as octet strings as defined by the ds:CryptoBinary type Schema Definition name "DSAKeyValue" type "ds:DSAKeyValueType" /> name "DSAKeyValueType" minOccurs "0" name "P" type "ds:CryptoBinary" /> name "Q" type "ds:CryptoBinary" />
name "G" type "ds:CryptoBinary" minOccurs "0" /> name "Y" type "ds:CryptoBinary" /> name "J" type "ds:CryptoBinary" minOccurs "0" /> minOccurs "0" name "Seed" type "ds:CryptoBinary" /> name "PgenCounter" type "ds:CryptoBinary" />
7.2.2 The RSAKeyValue Element Identifier Type=" (this can be used within a RetrievalMethod or Reference element to identify the referent's type) RSA key values have two fields: Modulus and Exponent. Arbitrary-length integers (e.g. "bignums" such as RSA moduli) are represented in XML as octet strings as defined by the ds:CryptoBinary type Example 5 xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV 5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
AQAB
7.2.3 The dsig11:ECKeyValue Element Identifier Type=" (this can be used within a RetrievalMethod or Reference element to identify the referent's type) The dsig11:ECKeyValue element is defined in the EC public key values consists of two sub components: Domain parameters and dsig11:PublicKey Example 6 xmlns "http://www.w3.org/2009/xmldsig11#" URI "urn:oid:1.2.840.10045.3.1.7" /> vWccUP6Jp3pcaMCGIcAh3YOev4gaa2ukOANC7Ufg Cf8KDO7AtTOsGJK7/TA8IC3vZoCy9I5oPjRhyTBulBnj7Y
Note - A line break has been added to the dsig11:PublicKey content to preserve printed page width. Domain parameters can be encoded explicitly using the dsig11:ECParameters element or by reference using the dsig11:NamedCurve element. A named curve is specified through the URI attribute. For named curves that are identified by OIDs, such as those defined in RFC3279 ] and [ RFC4055 ], the OID SHOULD be encoded according to [ URN-OID ]. Conformant applications MUST support the dsig11:NamedCurve element and the 256-bit prime field curve as identified by the OID 1.2.840.10045.3.1.7 The dsig11:PublicKey element contains the base64 encoding of a binary representation of the x and y coordinates of the point. Its value is computed as follows: Convert the elliptic curve point (x,y) to an octet string by first converting the field elements x and y to octet strings as specified in Section 6.2 of [ ECC-ALGS note ), and then prepend the concatenated result of the conversion with 0x04. Support for Elliptic-Curve-Point-to-Octet-String conversion without point compression is REQUIRED Base64 encode the octet string resulting from the conversion in Step 1. Schema Definition
name "ECKeyValue" type "dsig11:ECKeyValueType" /> name "ECKeyValueType" name "ECParameters" type "dsig11:ECParametersType" /> name "NamedCurve" type "dsig11:NamedCurveType" />
name "PublicKey" type "dsig11:ECPointType" />
name "Id" type "ID" use "optional" />
name "NamedCurveType" name "URI" type "anyURI" use "required" />
name "ECPointType" base "ds:CryptoBinary" />
7.2.3.1 Explicit Curve Parameters The dsig11:ECParameters element consists of the following subelements. Note these definitions are based on the those described in [ RFC3279 ]. The dsig11:FieldID element identifies the finite field over which the elliptic curve is defined. Additional details on the structures for defining prime and characteristic two fields is provided below. The dsig11:Curve element specifies the coefficients a and b of the elliptic curve E. Each coefficient is first converted from a field element to an octet string as specified in section 6.2 of [ ECC-ALGS ], then the resultant octet string is encoded in base64. The dsig11:Base element specifies the base point P on the elliptic curve. The base point is represented as a value of type dsig11:ECPointType The dsig11:Order element specifies the order n of the base point and is encoded as a positiveInteger The dsig11:Cofactor element is an optional element that specifies the integer h = #E(Fq)/n. The cofactor is not required to support ECDSA, except in parameter validation. The cofactor MAY be included to support parameter validation for ECDSA keys. Parameter validation is not required by this specification. The cofactor is required in ECDH public key parameters. The dsig11:ValidationData element is an optional element that specifies the hash algorithm used to generate the elliptic curve E and the base point G verifiably at random. It also specifies the seed that was used to generate the curve and the base point. Schema Definition
name "ECParametersType" name "FieldID" type "dsig11:FieldIDType" /> name "Curve" type "dsig11:CurveType" /> name "Base" type "dsig11:ECPointType" /> name "Order" type "ds:CryptoBinary" /> name "CoFactor" type "integer" minOccurs "0" /> name "ValidationData" type "dsig11:ECValidationDataType" minOccurs "0" />
name "CurveType" name "A" type "ds:CryptoBinary" /> name "B" type "ds:CryptoBinary" />
name "ECValidationDataType" name "seed" type "ds:CryptoBinary" />
name "hashAlgorithm" type "anyURI" use "required" />
dsig11:Prime fields are described by a single subelement dsig11:P which represents the field size in bits. It is encoded as a positiveInteger Schema Definition
name "Prime" type "dsig11:PrimeFieldParamsType" /> name "PrimeFieldParamsType" name "P" type "ds:CryptoBinary" />
Structures are defined for three types of characteristic two fields: gaussian normal basis, pentanomial basis and trinomial basis. Schema Definition
name "GnB" type "dsig11:CharTwoFieldParamsType" /> name "CharTwoFieldParamsType" name "M" type "positiveInteger" />
name "TnB" type "dsig11:TnBFieldParamsType" /> name "TnBFieldParamsType" base "dsig11:CharTwoFieldParamsType" name "K" type "positiveInteger" />
name "PnB" type "dsig11:PnBFieldParamsType" /> name "PnBFieldParamsType" base "dsig11:CharTwoFieldParamsType" name "K1" type "positiveInteger" /> name "K2" type "positiveInteger" /> name "K3" type "positiveInteger" />
7.2.3.2 Compatibility with RFC 4050 Implementations that need to support the [ RFC4050 ] format for ECDSA keys can avoid known interoperability problems with that specification by adhering to the following profile: Avoid validating the ECDSAKeyValue element against the [ RFC4050 ] schema. XML Schema validators may not support integer types with decimal data exceeding 18 decimal digits. XMLSCHEMA-1 ][ XMLSCHEMA-2 ]. Support only the NamedCurve element. Support the 256-bit prime field curve, as identified by the URN urn:oid:1.2.840.10045.3.1.7 The following is an example of a ECDSAKeyValue element that meets the profile described in this section. Example 7 xmlns "http://www.w3.org/2001/04/xmldsig-more#" URN "urn:oid:1.2.840.10045.3.1.7" />
Value "5851106065380174439324917904648283332 0204931884267326155134056258624064349885" /> Value "1024033521368277752409102672177795083 59028642524881540878079119895764161434936" />
Note - A line break has been added to the and Value attribute values to preserve printed page width. 7.3 The RetrievalMethod Element RetrievalMethod element within KeyInfo is used to convey a reference to KeyInfo information that is stored at another location. For example, several signatures in a document might use a key verified by an X.509v3 certificate chain appearing once in the document or remotely outside the document; each signature's KeyInfo can reference this chain using a single RetrievalMethod element instead of including the entire chain with a sequence of X509Certificate elements. RetrievalMethod uses the same syntax and dereferencing behavior as section B.4 The URI Attribute in "Compatibility Mode" and section B.4.1 The "Compatibility Mode" Reference Processing Model except that there are no DigestMethod or DigestValue child elements and presence of the URI attribute is mandatory. Type is an optional identifier for the type of data retrieved after all transforms have been applied. The result of dereferencing a RetrievalMethod Reference for all KeyInfo types defined by this specification ( section 7. The KeyInfo Element 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. Note that when referencing one of the defined KeyInfo types within the same document, or some remote documents, at least one Transform is required to turn an ID-based reference to a KeyInfo element into a child element located inside it. This is due to the lack of an XML ID attribute on the defined KeyInfo types. Transforms in RetrievalMethod are more attack prone, since they need to be evaluated in the first step of the signature validation, where the trust in the key has not yet been established, and the SignedInfo has not yet been verified. As noted in the [ XMLDSIG-BESTPRACTICES ] an attacker can easily causes a Denial of service, by adding a specially crafted transform in the RetrievalMethod without even bothering to have the key validate or the signature match. Note: The KeyInfoReference element is preferred over use of RetrievalMethod as it avoids use of Transform child elements that introduce security risk and implementation challenges. Schema Definition name "RetrievalMethod" type "ds:RetrievalMethodType" /> name "RetrievalMethodType" ref "ds:Transforms" minOccurs "0" />
name "URI" type "anyURI" /> name "Type" type "anyURI" use "optional" />
Note: The schema for the URI attribute of RetrievalMethod erroneously omitted the attribute: use="required" 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. 7.4 The X509Data Element Identifier Type=" (this can be used within a RetrievalMethod or Reference element to identify the referent's type) An X509Data element within KeyInfo contains one or more identifiers of keys or X509 certificates (or certificates' identifiers or a revocation list). The content of X509Data is at least one element, from the following set of element types; any of these may appear together or more than once iff (if and only if) each instance describes or is related to the same certificate: The deprecated X509IssuerSerial 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 RFC4514 [ LDAP-DN ], to be generated according to the Distinguished Name Encoding Rules section below, The X509SubjectName element, which contains an X.509 subject distinguished name that SHOULD be represented as a string that complies with section 3 of RFC4514 [ LDAP-DN ], to be generated according to the Distinguished Name Encoding Rules section below, The X509SKI element, which contains the base64 encoded plain (i.e. non-DER-encoded) value of a X509 V.3 SubjectKeyIdentifier extension, The X509Certificate element, which contains a base64-encoded [ X509V3 ] certificate, and The X509CRL element, which contains a base64-encoded certificate revocation list (CRL) [ X509V3 ]. The dsig11:X509Digest element contains a base64-encoded digest of a certificate. The digest algorithm URI is identified with a required Algorithm attribute. The input to the digest MUST be the raw octets that would be base64-encoded were the same certificate to appear in the X509Certificate element. Elements from an external namespace which accompanies/complements any of the elements above. Any X509IssuerSerial X509SKI X509SubjectName and dsig11:X509Digest elements that appear MUST refer to the certificate or certificates containing the validation key. All such elements that refer to a particular individual certificate MUST be grouped inside a single X509Data element and if the certificate to which they refer appears, it MUST also be in that X509Data element. Any X509IssuerSerial X509SKI X509SubjectName and dsig11:X509Digest elements that relate to the same key but different certificates MUST be grouped within a single KeyInfo but MAY occur in multiple X509Data elements. Note that if X509Data child elements are used to identify a trusted certificate (rather than solely as an untrusted hint supplemented by validation by policy), the complete set of such elements that are intended to identify a certificate SHOULD be integrity protected, typically by signing an entire X509Data or KeyInfo element. All certificates appearing in an X509Data element MUST relate to the validation key by either containing it or being part of a certification chain that terminates in a certificate containing the validation key. No ordering is implied by the above constraints. The comments in the following instance demonstrate these constraints: Example 8
Note, there is no direct provision for a PKCS#7 encoded "bag" of certificates or CRLs. However, a set of certificates and CRLs can occur within an X509Data element and multiple X509Data elements can occur in a KeyInfo . Whenever multiple certificates occur in an X509Data element, at least one such certificate must contain the public key which verifies the signature. While in principle many certificate encodings are possible, it is RECOMMENDED that certificates appearing in an X509Certificate element be limited to an encoding of BER or its DER subset, allowing that within the certificate other content may be present. The use of other encodings may lead to interoperability issues. In any case, XML Signature implementations SHOULD NOT alter or re-encode certificates, as doing so could invalidate their signatures. Deployments that expect to make use of the X509IssuerSerial element should be aware that many Certificate Authorities issue certificates with large, random serial numbers. XML Schema validators may not support integer types with decimal data exceeding 18 decimal digits [XML-schema]. Therefore such deployments should avoid schema-validating the X509IssuerSerial element, or make use of a local copy of the schema that adjusts the data type of the X509SerialNumber child element from "integer" to "string" 7.4.1 Distinguished Name Encoding Rules To encode a distinguished name ( X509IssuerSerial X509SubjectName and KeyName if appropriate), the encoding rules in section 2 of RFC 4514 [ LDAP-DN SHOULD be applied, except that the character escaping rules in section 2.4 of RFC 4514 [ LDAP-DN MAY be augmented as follows: Escape all occurrences of ASCII control characters (Unicode range \x00 - \x1f) by replacing them with "\" followed by a two digit hex number showing its Unicode number. Escape any trailing space characters (Unicode \x20) by replacing them with "\20", instead of using the escape sequence "\ ". Since an 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. Schema Definition name "X509Data" type "ds:X509DataType" /> name "X509DataType" maxOccurs "unbounded" name "X509IssuerSerial" type "ds:X509IssuerSerialType" /> name "X509SKI" type "base64Binary" /> name "X509SubjectName" type "string" /> name "X509Certificate" type "base64Binary" /> name "X509CRL" type "base64Binary" />
namespace "##other" processContents "lax" />
name "X509IssuerSerialType" name "X509IssuerName" type "string" /> name "X509SerialNumber" type "integer" />
name "X509Digest" type "dsig11:X509DigestType" /> name "X509DigestType" base "base64Binary" name "Algorithm" type "anyURI" use "required" />
7.5 The PGPData Element Identifier Type="
(this can be used within a RetrievalMethod or Reference element to identify the referent's type) The PGPData element within KeyInfo is used to convey information related to PGP public key pairs and signatures on such keys. The PGPKeyID 's value is a base64Binary sequence containing a standard PGP public key identifier as defined in [ PGP ] section 11.2]. The PGPKeyPacket contains a base64-encoded Key Material Packet as defined in [ PGP section 5.5]. These children element types can be complemented/extended by siblings from an external namespace within PGPData , or PGPData can be replaced all together with an alternative PGP XML structure as a child of KeyInfo PGPData must contain one PGPKeyID and/or one PGPKeyPacket and 0 or more elements from an external namespace. Schema Definition name "PGPData" type "ds:PGPDataType" /> name "PGPDataType" name "PGPKeyID" type "base64Binary" /> name "PGPKeyPacket" type "base64Binary" minOccurs "0" /> namespace "##other" processContents "lax" minOccurs "0" maxOccurs "unbounded" />
name "PGPKeyPacket" type "base64Binary" /> namespace "##other" processContents "lax" minOccurs "0" maxOccurs "unbounded" />
7.6 The SPKIData Element Identifier Type="
(this can be used within a RetrievalMethod or Reference element to identify the referent's type) The SPKIData element within KeyInfo is used to convey information related to SPKI public key pairs, certificates and other SPKI data. SPKISexp is the base64 encoding of a SPKI canonical S-expression. SPKIData must have at least one SPKISexp SPKISexp can be complemented/extended by siblings from an external namespace within SPKIData or SPKIData can be entirely replaced with an alternative SPKI XML structure as a child of KeyInfo Schema Definition name "SPKIData" type "ds:SPKIDataType" /> name "SPKIDataType" maxOccurs "unbounded" name "SPKISexp" type "base64Binary" /> namespace "##other" processContents "lax" minOccurs "0" />
7.7 The MgmtData Element Identifier Type="
(this can be used within a RetrievalMethod or Reference element to identify the referent's type) The MgmtData element within KeyInfo is a string value used to convey in-band key distribution or agreement data. However, use of this element is NOT RECOMMENDED and SHOULD NOT be used. The section 7.8 XML Encryption EncryptedKey and DerivedKey Elements describes new KeyInfo types for conveying key information. 7.8 XML Encryption EncryptedKey and DerivedKey Elements The and elements defined in XMLENC-CORE1 ] as children of ds:KeyInfo can be used to convey in-band encrypted or derived key material. In particular, the xenc:DerivedKey > element may be present when the key used in calculating a Message Authentication Code is derived from a shared secret. 7.9 The dsig11:DEREncodedKeyValue Element Identifier Type=" (this can be used within a RetrievalMethod or Reference element to identify the referent's type) The public key algorithm and value are DER-encoded in accordance with the value that would be used in the Subject Public Key Info field of an X.509 certificate, per section 4.1.2.7 of [ RFC5280 ]. The DER-encoded value is then base64-encoded. For the key value types supported in this specification, refer to the following for normative references on the format of Subject Public Key Info and the relevant OID values that identify the key/algorithm type: RSA See section 2.3.1 of [ RFC3279 DSA See section 2.3.2 of [ RFC3279 EC See section 2 of [ RFC5480 Specifications that define additional key types should provide such a normative reference for their own key types where possible. Schema Definition
name "DEREncodedKeyValue" type "dsig11:DEREncodedKeyValueType" /> name "DEREncodedKeyValueType" base "base64Binary" name "Id" type "ID" use "optional" />
Historical note: The dsig11:DEREncodedKeyValue element was added to XML Signature 1.1 in order to support certain interoperability scenarios where at least one of signer and/or verifier are not able to serialize keys in the XML formats described in section 7.2 The KeyValue Element above. The KeyValue element is to be used for "bare" XML key representations (not XML wrappings around other binary encodings like ASN.1 DER); for this reason the dsig11:DEREncodedKeyValue element is not a child of KeyValue . The dsig11:DEREncodedKeyValue element is also not a child of the X509Data element, as the keys represented by dsig11:DEREncodedKeyValue may not have X.509 certificates associated with them (a requirement for X509Data ). 7.10 The dsig11:KeyInfoReference Element dsig11:KeyInfoReference element within KeyInfo is used to convey a reference to a KeyInfo element at another location in the same or different document. For example, several signatures in a document might use a key verified by an X.509v3 certificate chain appearing once in the document or remotely outside the document; each signature's KeyInfo can reference this chain using a single dsig11:KeyInfoReference element instead of including the entire chain with a sequence of X509Certificate elements repeated in multiple places. dsig11:KeyInfoReference uses the same syntax and dereferencing behavior as Reference 's URI section B.4 The URI Attribute in "Compatibility Mode" ) and the Reference Processing Model section B.4.1 The "Compatibility Mode" Reference Processing Model except that there are no child elements and the presence of the URI attribute is mandatory. The result of dereferencing a dsig11:KeyInfoReference MUST be KeyInfo element, or an XML document with a KeyInfo element as the root. Note: The KeyInfoReference element is a desirable alternative to the use of RetrievalMethod when the data being referred to is KeyInfo element and the use of RetrievalMethod would require one or more Transform child elements, which introduce security risk and implementation challenges. Schema Definition
name "KeyInfoReference" type "dsig11:KeyInfoReferenceType" /> name "KeyInfoReferenceType" name "URI" type "anyURI" use "required" /> name "Id" type "ID" use "optional" />
8. The Object Element Identifier Type= "http://www.w3.org/2000/09/xmldsig#Object" (this can be used within a Reference element to identify the referent's type) Object is an optional element that may occur one or more times. When present, this element may contain any data. The Object element may include optional MIME type, ID, and encoding attributes. The Object 's Encoding attributed may be used to provide a URI that identifies the method by which the object is encoded (e.g., a binary file). 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 [ RFC2045 ]. For example, if the Object contains base64 encoded PNG , the Encoding may be specified as 'http://www.w3.org/2000/09/xmldsig#base64' and the MimeType as 'image/png'. This attribute is purely advisory; no validation of the MimeType information is required by this specification. Applications that require normative type and encoding information for signature validation should rely on Algorithm in the dsig2:Selection element ("2.0 Mode") or specify Transforms with well defined resulting types and/or encodings ("Compatibility Mode"). The Object 's Id is commonly referenced from a Reference in SignedInfo , or Manifest This element is typically used for enveloping signatures where the object being signed is to be included in the signature element. The digest is calculated over the entire Object element including start and end tags. Note, if the application wishes to exclude the