idnits 2.17.1 

draft-ietf-xmldsig-core-2-00.txt:
-(2854): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** The document seems to lack a 1id_guidelines paragraph about 6 months
     document validity -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  == There is 1 instance of lines with non-ascii characters in the document.

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** The document seems to lack separate sections for Informative/Normative
     References.  All references will be assumed normative when checking for
     downward references.

  ** There are 218 instances of too long lines in the document, the longest
     one being 7 characters in excess of 72.

  == There are 11 instances of lines with non-RFC6890-compliant IPv4
     addresses in the document.  If these are example addresses, they should
     be changed.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords -- however, there's a paragraph with a matching beginning.
     Boilerplate error?

     RFC 2119 keyword, line 212: '...     "they MUST only be used where it ...'
     RFC 2119 keyword, line 237: '...   namespace [XML-ns] URI that MUST be used by implementations of this...'
     RFC 2119 keyword, line 242: '...hile applications MUST support XML and...'
     RFC 2119 keyword, line 413: '... algorithms that MUST be implemented, ...'
     RFC 2119 keyword, line 415: '...   as RECOMMENDED or OPTIONAL for impl...'
     (68 more instances...)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 678 has weird spacing: '...d using  the...'

  -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not
     defined in RFC 2119.  If it is intended as a requirements expression, it
     should be rewritten using one of the combinations defined in RFC 2119;
     otherwise it should not be all-uppercase.

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- Couldn't find a document date in the document -- date freshness check
     skipped.

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Missing reference section? 'XML-schema' on line 2452 looks like a
     reference

  -- Missing reference section? 'XML' on line 2706 looks like a reference

  -- Missing reference section? 'Bourret' on line 204 looks like a reference

  -- Missing reference section? 'KEYWORDS' on line 211 looks like a reference

  -- Missing reference section? 'XML-ns' on line 1289 looks like a reference

  -- Missing reference section? 'XML-Signature-RD' on line 231 looks like a
     reference

  -- Missing reference section? 'URI' on line 2727 looks like a reference

  -- Missing reference section? 'URN' on line 251 looks like a reference

  -- Missing reference section? 'URL' on line 252 looks like a reference

  -- Missing reference section? 'RDF' on line 487 looks like a reference

  -- Missing reference section? 'XML-C14N' on line 2525 looks like a reference

  -- Missing reference section? 'XML-Schema' on line 2650 looks like a
     reference

  -- Missing reference section? 'MIME' on line 2148 looks like a reference

  -- Missing reference section? '1363' on line 758 looks like a reference

  -- Missing reference section? 'Unicode' on line 978 looks like a reference

  -- Missing reference section? 'URI-Literal' on line 982 looks like a
     reference

  -- Missing reference section? 'UTF-8' on line 2094 looks like a reference

  -- Missing reference section? 'HTTP' on line 2701 looks like a reference

  -- Missing reference section? 'XPath' on line 2504 looks like a reference

  -- Missing reference section? 'Xptr' on line 1129 looks like a reference

  -- Missing reference section? 'XSLT' on line 2564 looks like a reference

  -- Missing reference section? 'LDAP-DN' on line 1532 looks like a reference

  -- Missing reference section? 'X509v3' on line 1542 looks like a reference

  -- Missing reference section? 'MD5' on line 1948 looks like a reference

  -- Missing reference section? 'SHA-1' on line 1956 looks like a reference

  -- Missing reference section? 'HMAC' on line 1996 looks like a reference

  -- Missing reference section? 'DSS' on line 2019 looks like a reference

  -- Missing reference section? 'PKCS1' on line 2044 looks like a reference

  -- Missing reference section? 'RFC 2437' on line 2068 looks like a reference

  -- Missing reference section? 'XML-MT' on line 2089 looks like a reference

  -- Missing reference section? 'UTF-16' on line 2094 looks like a reference

  -- Missing reference section? 'NFC' on line 2586 looks like a reference

  -- Missing reference section? 'NFC-Corrigendum' on line 2586 looks like a
     reference

  -- Missing reference section? 'XML-Japanese' on line 2103 looks like a
     reference

  -- Missing reference section? '1' on line 2333 looks like a reference

  -- Missing reference section? 'XHTML' on line 2366 looks like a reference

  -- Missing reference section? 'DOM' on line 2468 looks like a reference

  -- Missing reference section? 'SAX' on line 2469 looks like a reference

  -- Missing reference section? 'RANDOM' on line 2624 looks like a reference


     Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 43 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	XML Digital Signatures Working Group               D. Eastlake,
2	INTERNET-DRAFT                                     Motorola
3	draft-ietf-xmldsig-core-2-00                       J. Reagle,
4	Obsoletes RFC 3075                                 W3C/MIT
5	Expires October 19, 2001                           D. Solo,
6	                                                   Citigroup

8	                    XML-Signature Syntax and Processing

10	Copyright Notice

12	   Copyright (c) 2000 The Internet Society & W3C (MIT, INRIA, Keio), All
13	   Rights Reserved.

15	IETF Status of this Memo

17	   This document is an Internet-Draft and is in full conformance with all
18	   provisions of Section 10 of RFC2026.

20	   Internet-Drafts are working documents of the Internet Engineering Task
21	   Force (IETF), its areas, and its working groups. Note that other
22	   groups may also distribute working documents as Internet-Drafts.

24	   Internet-Drafts are draft documents valid for a maximum of six months
25	   and may be updated, replaced, or obsoleted by other documents at any
26	   time. It is inappropriate to use Internet- Drafts as reference
27	   material or to cite them other than as "work in progress."

29	   The list of current Internet-Drafts can be accessed at
30	   http://www.ietf.org/ietf/1id-abstracts.txt

32	   The list of Internet-Draft Shadow Directories can be accessed at
33	   http://www.ietf.org/shadow.html.

35	W3C Status of this document

37	   This document is a production of the joint IETF/W3C XML Signature
38	   Working Group.

40	   http://www.w3.org/Signature

42	   The comparable html draft of this version may be found at

44	   http://www.w3.org/TR/2001/CR-xmldsig-core-20010419/

46	   This specification from the IETF/W3C XML Signature Working Group (W3C
47	   Activity Statement) is a second Candidate Recommendation of the W3C.

49	   This version contains many bug-fixes, clarifications, and improvements
50	   for DTD/schema extensibility and re-use. It reflects resolution of
51	   recent (and past) issues and the Schema Proposed Recommendation. As
52	   warned in the previous Candidate Recommendation, the minimal
53	   canonicalization algorithm has been removed because the Working Group
54	   could find no implementation. This specification is considered to be
55	   very stable. The W3C Namespace Policy requires that if a change in the
56	   namespace makes previously valid or compliant instances and
57	   implementations invalid, the namespace must also change. Since the
58	   clarifications do not substantively affect valid instance syntax or
59	   implemented features, the namespace has not been changed.

61	   The duration of this Candidate Recommendation will last one month (20-
62	   -May-2001) to ensure we have not introduced any new errors and so as to
63	   coincide with the close of a four week IETF last call. Subsequently,
64	   and assuming no substantive issues are raised, this version will be
65	   proposed as a Proposed Recommendation and Draft Standard. Note, this
66	   specification already has significant implementation experience as
67	   demonstrated by its Interoperability Report.

69	   Please send comments to the editors and cc: the list
70	   <w3c-ietf-xmldsig@w3.org>.

72	   This is still a draft document and may be updated, replaced, or
73	   obsoleted by other documents at any time. It is inappropriate to
74	   cite a W3C Candidate Recommendation as other than "work in progress."
75	   A list of current W3C working drafts can be found at
76	   http://www.w3.org/TR/.

78	   IETF RFCs can be found from
79	   http://www.ietf.org/rfc.html.

81	   Patent disclosures relevant to this specification may be found on the
82	   Working Group's patent disclosure page in conformance with W3C policy,
83	   and the IETF Page of Intellectual Property Rights Notices in
84	   conformance with IETF policy.

86	Abstract

88	   This document specifies XML digital signature processing rules and
89	   syntax. XML Signatures provide integrity, message authentication,
90	   and/or signer authentication services for data of any type, whether
91	   located within the XML that includes the signature or elsewhere.

93	Table of Contents

95	    1. Introduction
96	         1. Editorial Conventions
97	         2. Design Philosophy
98	         3. Versions, Namespaces and Identifiers
99	         4. Acknowledgements
100	    2. Signature Overview and Examples
101	         1. Simple Example (Signature, SignedInfo, Methods, and
102	            References)
103	              1. More on Reference
104	         2. Extended Example (Object and SignatureProperty)
105	         3. Extended Example (Object and Manifest)
106	    3. Processing Rules
107	         1. Signature Generation
108	         2. Signature Validation
109	    4. Core Signature Syntax
110	         1. The Signature element
111	         2. The SignatureValue Element
112	         3. The SignedInfo Element
113	              1. The CanonicalizationMethod Element
114	              2. The SignatureMethod Element
115	              3. The Reference Element
116	                   1. The URI Attribute
117	                   2. The Reference Processing Model
118	                   3. Same-Document URI-References
119	                   4. The Transforms Element
120	                   5. The DigestMethod Element
121	                   6. The DigestValue Element
122	         4. The KeyInfo Element
123	              1. The KeyName Element
124	              2. The KeyValue Element
125	              3. The RetrievalMethod Element
126	              4. The X509Data Element
127	              5. The PGPData Element
128	              6. The SPKIData Element
129	              7. The MgmtData Element
130	         5. The Object Element
131	    5. Additional Signature Syntax
132	         1. The Manifest Element
133	         2. The SignatureProperties Element
134	         3. Processing Instructions
135	         4. Comments in dsig Elements
136	    6. Algorithms
137	         1. Algorithm Identifiers and Implementation Requirements
138	         2. Message Digests
139	         3. Message Authentication Codes
140	         4. Signature Algorithms
141	         5. Canonicalization Algorithms
142	         6. Transform Algorithms
143	              1. Canonicalization
144	              2. Base64
145	              3. XPath Filtering
146	              4. Enveloped Signature Transform
147	              5. XSLT Transform
148	    7. XML Canonicalization and Syntax Constraint Considerations
149	         1. XML 1.0, Syntax Constraints, and Canonicalization
150	         2. DOM/SAX Processing and Canonicalization
151	    8. Security Considerations
152	         1. Transforms
153	              1. Only What is Signed is Secure
154	              2. Only What is "Seen" Should be Signed
155	              3. "See" What is Signed
156	         2. Check the Security Model
157	         3. Algorithms, Key Lengths, Etc.
158	    9. Schema, DTD, Data Model,and Valid Examples
159	   10. Definitions
160	   11. References
161	   12. Authors' Address
162	     _________________________________________________________________

164	1.0 Introduction

166	   This document specifies XML syntax and processing rules for creating
167	   and representing digital signatures. XML Signatures can be applied to
168	   any digital content (data object), including XML. An XML Signature may
169	   be applied to the content of one or more resources. Enveloped or
170	   enveloping signatures are over data within the same XML document as
171	   the signature; detached signatures are over data external to the
172	   signature element. More specifically, this specification defines an
173	   XML signature element type and an XML signature application;
174	   conformance requirements for each are specified by way of schema
175	   definitions and prose respectively. This specification also includes
176	   other useful types that identify methods for referencing collections
177	   of resources, algorithms, and keying and management information.

179	   The XML Signature is a method of associating a key with referenced
180	   data (octets); it does not normatively specify how keys are associated
181	   with persons or institutions, nor the meaning of the data being
182	   referenced and signed. Consequently, while this specification is an
183	   important component of secure XML applications, it itself is not
184	   sufficient to address all application security/trust concerns,
185	   particularly with respect to using signed XML (or other data formats)
186	   as a basis of human-to-human communication and agreement. Such an
187	   application must specify additional key, algorithm, processing and
188	   rendering requirements. For further information, please see Security
189	   Considerations (section 8).

191	  1.1 Editorial and Conformance Conventions

193	   For readability, brevity, and historic reasons this document uses the
194	   term "signature" to generally refer to digital authentication values
195	   of all types.Obviously, the term is also strictly used to refer to
196	   authentication values that are based on public keys and that provide
197	   signer authentication. When specifically discussing authentication
198	   values based on symmetric secret key codes we use the terms
199	   authenticators or authentication codes. (See Check the Security Model,
200	   section 8.3 .)

202	   This specification uses both XML Schemas [XML-schema] and DTDs [XML].
203	   (Readers unfamiliar with DTD syntax may wish to refer to Ron Bourret's
204	   " Declaring Elements and Attributes in an XML DTD" [Bourret].) The
205	   schema definition is presently normative.

207	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
208	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
209	   specification are to be interpreted as described in RFC2119
210	   [KEYWORDS]:

212	     "they MUST only be used where it is actually required for
213	     interoperation or to limit behavior which has potential for causing
214	     harm (e.g., limiting retransmissions)"

216	   Consequently, we use these capitalized keywords to unambiguously
217	   specify requirements over protocol and application features and
218	   behavior that affect the interoperability and security of
219	   implementations. These key words are not used (capitalized) to
220	   describe XML grammar; schema definitions unambiguously describe such
221	   requirements and we wish to reserve the prominence of these terms for
222	   the natural language descriptions of protocols and features. For
223	   instance, an XML attribute might be described as being "optional."
224	   Compliance with the XML-namespace specification [XML-ns] is described
225	   as "REQUIRED."

227	  1.2 Design Philosophy

229	   The design philosophy and requirements of this specification are
230	   addressed in the XML-Signature Requirements document
231	   [XML-Signature-RD].

233	  1.3 Versions, Namespaces and Identifiers

235	   No provision is made for an explicit version number in this syntax. If
236	   a future version is needed, it will use a different namespace. The XML
237	   namespace [XML-ns] URI that MUST be used by implementations of this
238	   (dated) specification is:
239	   xmlns="http://www.w3.org/2000/09/xmldsig#"

241	   This namespace is also used as the prefix for algorithm identifiers
242	   used by this specification. While applications MUST support XML and
243	   XML namespaces, the use of internal entities [XML] or our "dsig" XML
244	   namespace prefix and defaulting/scoping conventions are OPTIONAL; we
245	   use these facilities to provide compact and readable examples.

247	   This specification uses Uniform Resource Identifiers [URI] to identify
248	   resources, algorithms, and semantics. The URI in the namespace
249	   declaration above is also used as a prefix for URIs under the control
250	   of this specification. For resources not under the control of this
251	   specification, we use the designated Uniform Resource Names [URN] or
252	   Uniform Resource Locators [URL] defined by its normative external
253	   specification. If an external specification has not allocated itself a
254	   Uniform Resource Identifier we allocate an identifier under our own
255	   namespace. For instance:

257	   SignatureProperties is identified and defined by this specification's
258	          namespace
259	          http://www.w3.org/2000/09/xmldsig#SignatureProperties

261	   XSLT is identified and defined by an external URI
262	          http://www.w3.org/TR/1999/REC-xslt-19991116

264	   SHA1 is identified via this specification's namespace and defined via
265	          a normative reference
266	          http://www.w3.org/2000/09/xmldsig#sha1
267	          FIPS PUB 180-1. Secure Hash Standard. U.S. Department of
268	          Commerce/National Institute of Standards and Technology.

270	   Finally, in order to provide for terse namespace declarations we
271	   sometimes use XML internal entities [XML] within URIs. For instance:
272	   <?xml version='1.0'?>
273	   <!DOCTYPE Signature SYSTEM
274	     "xmldsig-core-schema.dtd" [ <!ENTITY dsig
275	     "http://www.w3.org/2000/09/xmldsig#"> ]>
276	   <Signature xmlns="&dsig;" Id="MyFirstSignature">
277	     <SignedInfo>
278	     ...

280	  1.4  Acknowledgements

282	   The contributions of the following working group members to this
283	   specification are gratefully acknowledged:
284	     * Mark Bartel, JetForm Corporation (Author)
285	     * John Boyer, PureEdge (Author)
286	     * Mariano P. Consens, University of Waterloo
287	     * John Cowan, Reuters Health
288	     * Donald Eastlake 3rd, Motorola  (Chair, Author/Editor)
289	     * Barb Fox, Microsoft (Author)
290	     * Christian Geuer-Pollmann, University Siegen
291	     * Tom Gindin, IBM
292	     * Phillip Hallam-Baker, VeriSign Inc
293	     * Richard Himes, US Courts
294	     * Merlin Hughes, Baltimore
295	     * Gregor Karlinger, IAIK TU Graz
296	     * Brian LaMacchia, Microsoft (Author)
297	     * Peter Lipp, IAIK TU Graz
298	     * Joseph Reagle, W3C (Chair, Author/Editor)
299	     * Ed Simon, Entrust Technologies Inc. (Author)
300	     * David Solo, Citigroup (Author/Editor)
301	     * Petteri Stenius, DONE Information, Ltd
302	     * Raghavan Srinivas, Sun
303	     * Kent Tamura, IBM
304	     * Winchel Todd Vincent III, GSU
305	     * Carl Wallace, Corsec Security, Inc.
306	     * Greg Whitehead, Signio Inc.

308	   As are the last call comments from the following:
309	     * Dan Connolly, W3C
310	     * Paul Biron, Kaiser Permanente, on behalf of the XML Schema WG.
311	     * Martin J. Duerst, W3C; and Masahiro Sekiguchi, Fujitsu; on behalf
312	       of the Internationalization WG/IG.
313	     * Jonathan Marsh, Microsoft, on behalf of the Extensible Stylesheet
314	       Language WG.

316	2.0 Signature Overview and Examples

318	   This section provides an overview and examples of XML digital
319	   signature syntax. The specific processing is given in Processing Rules
320	   (section 3). The formal syntax is found in Core Signature Syntax
321	   (section 4) and Additional Signature Syntax (section 5).

323	   In this section, an informal representation and examples are used to
324	   describe the structure of the XML signature syntax. This
325	   representation and examples may omit attributes, details and potential
326	   features that are fully explained later.

328	   XML Signatures are applied to arbitrary digital content (data objects)
329	   via an indirection. Data objects are digested, the resulting value is
330	   placed in an element (with other information) and that element is then
331	   digested and cryptographically signed. XML digital signatures are
332	   represented by the Signature element which has the following structure
333	   (where "?" denotes zero or one occurrence; "+" denotes one or more
334	   occurrences; and "*" denotes zero or more occurrences):
335	   <Signature>
336	     <SignedInfo>
337	       (CanonicalizationMethod)
338	       (SignatureMethod)
339	       (<Reference (URI=)? >
340	         (Transforms)?
341	         (DigestMethod)
342	         (DigestValue)
343	       </Reference>)+
344	     </SignedInfo>
345	     (SignatureValue)
346	    (KeyInfo)?
347	    (Object)*
348	   </Signature>

350	   Signatures are related to data objects via URIs [URI]. Within an XML
351	   document, signatures are related to local data objects via fragment
352	   identifiers. Such local data can be included within an enveloping
353	   signature or can enclose an enveloped signature. Detached signatures
354	   are over external network resources or local data objects that reside
355	   within the same XML document as sibling elements; in this case, the
356	   signature is neither enveloping (signature is parent) nor enveloped
357	   (signature is child). Since a Signature element (and its Id attribute
358	   value/name) may co-exist or be combined with other elements (and their
359	   IDs) within a single XML document, care should be taken in choosing
360	   names such that there are no subsequent collisions that violate the ID
361	   uniqueness validity constraint [XML].

363	  2.1 Simple Example (Signature, SignedInfo, Methods, and References)

365	   The following example is a detached signature of the content of the
366	   HTML4 in XML specification.
367	   [s01] <Signature Id="MyFirstSignature"
368	          xmlns="http://www.w3.org/2000/09/xmldsig#">
369	   [s02]   <SignedInfo>
370	   [s03]   <CanonicalizationMethod
371	            Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

373	   [s04]   <SignatureMethod
374	            Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
375	   [s05]   <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
376	   [s06]     <Transforms>
377	   [s07]       <Transform
378	                Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
379	   [s08]     </Transforms>
380	   [s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

382	   [s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
383	   [s11]   </Reference>
384	   [s12] </SignedInfo>
385	   [s13]   <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
386	   [s14]   <KeyInfo>
387	   [s15a]    <KeyValue>
388	   [s15b]      <DSAKeyValue>
389	   [s15c]        <P>...</P><Q>...</Q><G>...</G><Y>...</Y>
390	   [s15d]      </DSAKeyValue>
391	   [s15e]    </KeyValue>
392	   [s16]   </KeyInfo>
393	   [s17] </Signature>

395	   [s02-12] The required SignedInfo element is the information that is
396	   actually signed. Core validation of SignedInfo consists of two
397	   mandatory processes: validation of the signature over SignedInfo and
398	   validation of each Reference digest within SignedInfo. Note that the
399	   algorithms used in calculating the SignatureValue are also included in
400	   the signed information while the SignatureValue element is outside
401	   SignedInfo.

403	   [s03] The CanonicalizationMethod is the algorithm that is used to
404	   canonicalize the SignedInfo element before it is digested as part of
405	   the signature operation.

407	   [s04] The SignatureMethod is the algorithm that is used to convert the
408	   canonicalized SignedInfo into the SignatureValue. It is a combination
409	   of a digest algorithm and a key dependent algorithm and possibly other
410	   algorithms such as padding, for example RSA-SHA1. The algorithm names
411	   are signed to resist attacks based on substituting a weaker algorithm.
412	   To promote application interoperability we specify a set of signature
413	   algorithms that MUST be implemented, though their use is at the
414	   discretion of the signature creator. We specify additional algorithms
415	   as RECOMMENDED or OPTIONAL for implementation and the signature design
416	   permits arbitrary user algorithm specification.

418	   [s05-11] Each Reference element includes the digest method and
419	   resulting digest value calculated over the identified data object. It
420	   also may include transformations that produced the input to the digest
421	   operation. A data object is signed by computing its digest value and a
422	   signature over that value. The signature is later checked via
423	   reference and signature validation.

425	   [s14-16] KeyInfo indicates the key to be used to validate the
426	   signature. Possible forms for identification include certificates, key
427	   names, and key agreement algorithms and information -- we define only
428	   a few. KeyInfo is optional for two reasons. First, the signer may not
429	   wish to reveal key information to all document processing parties.
430	   Second, the information may be known within the application's context
431	   and need not be represented explicitly. Since KeyInfo is outside of
432	   SignedInfo, if the signer wishes to bind the keying information to the
433	   signature, a Reference can easily identify and include the KeyInfo as
434	   part of the signature.

436	  2.1.1 More on Reference

438	   [s05]   <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
439	   [s06]     <Transforms>
440	   [s07]       <Transform
441	                Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
442	   [s08]     </Transforms>
443	   [s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

445	   [s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
446	   [s11]   </Reference>

448	   [s05] The optional URI attribute of Reference identifies the data
449	   object to be signed. This attribute may be omitted on at most one
450	   Reference in a Signature. (This limitation is imposed in order to
451	   ensure that references and objects may be matched unambiguously.)

453	   [s05-08] This identification, along with the transforms, is a
454	   description provided by the signer on how they obtained the signed
455	   data object in the form it was digested (i.e. the digested content).
456	   The verifier may obtain the digested content in another method so long
457	   as the digest verifies. In particular, the verifier may obtain the
458	   content from a different location such as a local store than that
459	   specified in the URI.

461	   [s06-08] Transforms is an optional ordered list of processing steps
462	   that were applied to the resource's content before it was digested.
463	   Transforms can include operations such as canonicalization,
464	   encoding/decoding (including compression/inflation), XSLT and XPath.
465	   XPath transforms permit the signer to derive an XML document that
466	   omits portions of the source document. Consequently those excluded
467	   portions can change without affecting signature validity. For example,
468	   if the resource being signed encloses the signature itself, such a
469	   transform must be used to exclude the signature value from its own
470	   computation. If no Transforms element is present, the resource's
471	   content is digested directly. While we specify mandatory (and
472	   optional) canonicalization and decoding algorithms, user specified
473	   transforms are permitted.

475	   [s09-10] DigestMethod is the algorithm applied to the data after
476	   Transforms is applied (if specified) to yield the DigestValue. The
477	   signing of the DigestValue is what binds a resources content to the
478	   signer's key.

480	  2.2 Extended Example (Object and SignatureProperty)

482	   This specification does not address mechanisms for making statements
483	   or assertions. Instead, this document defines what it means for
484	   something to be signed by an XML Signature (message authentication,
485	   integrity, and/or signer authentication). Applications that wish to
486	   represent other semantics must rely upon other technologies, such as
487	   [XML, RDF]. For instance, an application might use a foo:assuredby
488	   attribute within its own markup to reference a Signature element.
489	   Consequently, it's the application that must understand and know how
490	   to make trust decisions given the validity of the signature and the
491	   meaning of assuredby syntax. We also define a SignatureProperties
492	   element type for the inclusion of assertions about the signature
493	   itself (e.g., signature semantics, the time of signing or the serial
494	   number of hardware used in cryptographic processes). Such assertions
495	   may be signed by including a Reference for the SignatureProperties in
496	   SignedInfo. While the signing application should be very careful about
497	   what it signs (it should understand what is in the SignatureProperty)
498	   a receiving application has no obligation to understand that semantic
499	   (though its parent trust engine may wish to). Any content about the
500	   signature generation may be located within the SignatureProperty
501	   element. The mandatory Target attribute references the Signature
502	   element to which the property applies.

504	   Consider the preceding example with an additional reference to a local
505	   Object that includes a SignatureProperty element. (Such a signature
506	   would not only be detached [p02] but enveloping [p03].)
507	   [   ]  <Signature Id="MySecondSignature" ...>
508	   [p01]  <SignedInfo>
509	   [   ]   ...
510	   [p02]   <Reference URI="http://www.w3.org/TR/xml-stylesheet/">
511	   [   ]   ...
512	   [p03]   <Reference URI="#AMadeUpTimeStamp"
513	   [p04]         Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">

515	   [p05]    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

517	   [p06]    <DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue>
518	   [p07]   </Reference>
519	   [p08]  </SignedInfo>
520	   [p09]  ...
521	   [p10]  <Object>
522	   [p11]   <SignatureProperties>
523	   [p12]     <SignatureProperty Id="AMadeUpTimeStamp"
524	              Target="#MySecondSignature">
525	   [p13]        <timestamp xmlns="http://www.ietf.org/rfcXXXX.txt">
526	   [p14]          <date>19990908</date>
527	   [p15]          <time>14:34:34:34</time>
528	   [p16]        </timestamp>
529	   [p17]     </SignatureProperty>
530	   [p18]   </SignatureProperties>
531	   [p19]  </Object>

533	   [p20]</Signature>

535	   [p04] The optional Type attribute of Reference provides information
536	   about the resource identified by the URI. In particular, it can
537	   indicate that it is an Object, SignatureProperty, or Manifest element.
538	   This can be used by applications to initiate special processing of
539	   some Reference elements. References to an XML data element within an
540	   Object element SHOULD identify the actual element pointed to. Where
541	   the element content is not XML (perhaps it is binary or encoded data)
542	   the reference should identify the Object and the Reference Type, if
543	   given, SHOULD indicate Object. Note that Type is advisory and no
544	   action based on it or checking of its correctness is required by core
545	   behavior.

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

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

556	  2.3 Extended Example (Object and Manifest)

558	   The Manifest element is provided to meet additional requirements not
559	   directly addressed by the mandatory parts of this specification. Two
560	   requirements and the way the Manifest satisfies them follow.

562	   First, applications frequently need to efficiently sign multiple data
563	   objects even where the signature operation itself is an expensive
564	   public key signature. This requirement can be met by including
565	   multiple Reference elements within SignedInfo since the inclusion of
566	   each digest secures the data digested. However, some applications may
567	   not want the core validation behavior associated with this approach
568	   because it requires every Reference within SignedInfo to undergo
569	   reference validation -- the DigestValue elements are checked. These
570	   applications may wish to reserve reference validation decision logic
571	   to themselves. For example, an application might receive a signature
572	   valid SignedInfo element that includes three Reference elements. If a
573	   single Reference fails (the identified data object when digested does
574	   not yield the specified DigestValue) the signature would fail core
575	   validation. However, the application may wish to treat the signature
576	   over the two valid Reference elements as valid or take different
577	   actions depending on which fails.  To accomplish this, SignedInfo
578	   would reference a Manifest element that contains one or more Reference
579	   elements (with the same structure as those in SignedInfo). Then,
580	   reference validation of the Manifest is under application control.

582	   Second, consider an application where many signatures (using different
583	   keys) are applied to a large number of documents. An inefficient
584	   solution is to have a separate signature (per key) repeatedly applied
585	   to a large SignedInfo element (with many References); this is wasteful
586	   and redundant. A more efficient solution is to include many references
587	   in a single Manifest that is then referenced from multiple Signature
588	   elements.

590	   The example below includes a Reference that signs a Manifest found
591	   within the Object element.
592	   [   ] ...
593	   [m01]   <Reference URI="#MyFirstManifest"
594	   [m02]     Type="http://www.w3.org/2000/09/xmldsig#Manifest">
595	   [m03]     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

597	   [m04]     <DigestValue>345x3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
598	   [m05]   </Reference>
599	   [   ] ...
600	   [m06] <Object>
601	   [m07]   <Manifest Id="MyFirstManifest">
602	   [m08]     <Reference>
603	   [m09]     ...
604	   [m10]     </Reference>
605	   [m11]     <Reference>
606	   [m12]     ...
607	   [m13]     </Reference>
608	   [m14]   </Manifest>
609	   [m15] </Object>

611	3.0 Processing Rules

613	   The sections below describe the operations to be performed as part of
614	   signature generation and validation.

616	  3.1 Core Generation

618	   The REQUIRED steps include the generation of Reference elements and
619	   the SignatureValue over SignedInfo.

621	    3.1.1 Reference Generation

623	   For each data object being signed:
624	    1. Apply the Transforms, as determined by the application, to the
625	       data object.
626	    2. Calculate the digest value over the resulting data object.
627	    3. Create a Reference element, including the (optional)
628	       identification of the data object, any (optional) transform
629	       elements, the digest algorithm and the DigestValue.

631	    3.1.2 Signature Generation

633	    1. Create SignedInfo element with SignatureMethod,
634	       CanonicalizationMethod and Reference(s).
635	    2. Canonicalize and then calculate the SignatureValue over SignedInfo
636	       based on algorithms specified in SignedInfo.
637	    3. Construct the Signature element that includes SignedInfo,
638	       Object(s) (if desired, encoding may be different than that used
639	       for signing), KeyInfo (if required), and SignatureValue.

641	  3.2 Core Validation

643	   The REQUIRED steps of core validation include (1) reference
644	   validation, the verification of the digest contained in each Reference
645	   in SignedInfo, and (2) the cryptographic signature validation of the
646	   signature calculated over SignedInfo.

648	   Note, there may be valid signatures that some signature applications
649	   are unable to validate. Reasons for this include failure to implement
650	   optional parts of this specification, inability or unwillingness to
651	   execute specified algorithms, or inability or unwillingness to
652	   dereference specified URIs (some URI schemes may cause undesirable
653	   side effects), etc.

655	    3.2.1 Reference Validation

657	   For each Reference in SignedInfo:
658	    1. Canonicalize the SignedInfo element based on the
659	       CanonicalizationMethod in SignedInfo.
660	    2. Obtain the data object to be digested. (The signature application
661	       may rely upon the identification (URI) and Transforms provided by
662	       the signer in the Reference element, or it may obtain the content
663	       through other means such as a local cache.)
664	    3. Digest the resulting data object using the DigestMethod specified
665	       in its Reference specification.
666	    4. Compare the generated digest value against DigestValue in the
667	       SignedInfo Reference; if there is any mismatch, validation fails.

669	   Note, SignedInfo is canonicalized in step 1 to ensure the application
670	   Sees What is Signed, which is the canonical form. For instance, if the
671	   CanonicalizationMethod rewrote the URIs (e.g., absolutizing relative
672	   URIs) the signature processing must be cognizant of this.

674	    3.2.2 Signature Validation

676	    1. Obtain the keying information from KeyInfo or from an external
677	       source.
678	    2. Obtain the canonical form of the SignatureMethod using  the
679	       CanonicalizationMethod and use the result (and previously obtained
680	       KeyInfo) to validate the SignatureValue over the SignedInfo
681	       element.

683	   Note, KeyInfo (or some transformed version thereof) may be signed via
684	   a Reference element. Transformation and validation of this reference
685	   (3.2.1) is orthogonal to Signature Validation which uses the KeyInfo
686	   as parsed.

688	   Additionally, the SignatureMethod URI may have been altered by the
689	   canonicalization of SignedInfo (e.g., absolutization of relative URIs)
690	   and it is the canonical form that MUST be used. However, the required
691	   canonicalization [XML-C14N] of this specification does not change
692	   URIs.

694	4.0 Core Signature Syntax

696	   The general structure of an XML signature is described in Signature
697	   Overview (section 2). This section provides detailed syntax of the
698	   core signature features. Features described in this section are
699	   mandatory to implement unless otherwise indicated. The syntax is
700	   defined via DTDs and [XML-Schema] with the following XML preamble,
701	   declaration, and internal entity.
702	   Schema Definition:

704	   <?xml version="1.0" encoding="utf-8"?>
705	   <!DOCTYPE schema
706	     PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchem
707	a.dtd"
708	    [
709	      <!ATTLIST schema
710	        xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#">
711	      <!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'>
712	      <!ENTITY % p ''>
713	      <!ENTITY % s ''>
714	     ]>

716	   <schema xmlns="http://www.w3.org/2001/XMLSchema"
717	           xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
718	           targetNamespace="http://www.w3.org/2000/09/xmldsig#"
719	           version="0.1" elementFormDefault="qualified">
720	   DTD:

722	   <!--

724	   The following entity declarations enable external/flexible content in
725	   the Signature content model.

727	   #PCDATA emulates schema:string; when combined with element types it
728	   emulates schema mixed="true".

730	   %foo.ANY permits the user to include their own element types from
731	   other namespaces, for example:
732	     <!ENTITY % KeyValue.ANY '| ecds:ECDSAKeyValue'>
733	     ...
734	     <!ELEMENT ecds:ECDSAKeyValue (#PCDATA)  >

736	   -->

738	   <!ENTITY % Object.ANY ''>
739	   <!ENTITY % Method.ANY ''>
740	   <!ENTITY % Transform.ANY ''>
741	   <!ENTITY % SignatureProperty.ANY ''>
742	   <!ENTITY % KeyInfo.ANY ''>
743	   <!ENTITY % KeyValue.ANY ''>
744	   <!ENTITY % PGPData.ANY ''>
745	   <!ENTITY % X509Data.ANY ''>

747	    4.0.1 The ds:CryptoBinary Simple Type

749	   This specification defines the ds:CryptoBinary simple type for
750	   representing arbitrary-length integers (e.g. "bignums") in XML as
751	   octet strings. The integer value is first converted to a "big endian"
752	   bitstring. The bitstring is then padded with leading zero bits so that
753	   the total number of bits == 0 mod 8 (so that there are an integral
754	   number of octets). If the bitstring contains entire leading octets
755	   that are zero, these are removed (so the high-order octet is always
756	   non-zero). This octet string is then base64 [MIME] encoded. (The
757	   conversion from integer to octet string is equivalent to IEEE 1363's
758	   I2OSP [1363] with minimal length).

760	   This type is used by "bignum" values such as RSAKeyValue and
761	   DSAKeyValue. If a value can be of type base64Binary or ds:CryptoBinary
762	   they are defined as base64Binary. For example, if the signature
763	   algorithm is RSA or DSA then SignatureValue represents a bignum and
764	   could be ds:CryptoBinary. However, if HMAC-SHA1 is the signature
765	   algorithm then SignatureValue could have leading zero octets that must
766	   be preserved. Thus SignatureValue is generically defined as of type
767	   base64Binary.

769	      Schema Definition:
770	      <simpleType name="CryptoBinary">
771	        <restriction base="base64Binary">
772	        </restriction>
773	      </simpleType>

775	  4.1 The Signature element

777	   The Signature element is the root element of an XML Signature.
778	   Signature elements MUST be laxly schema valid [XML-schema] with
779	   respect to the following schema definition:
780	   Schema Definition:

782	   <element name="Signature" type="ds:SignatureType"/>
783	   <complexType name="SignatureType">
784	     <sequence>
785	       <element ref="ds:SignedInfo"/>
786	       <element ref="ds:SignatureValue"/>
787	       <element ref="ds:KeyInfo" minOccurs="0"/>
788	       <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/>
789	     </sequence>
790	     <attribute name="Id" type="ID" use="optional"/>
791	   </complexType>
792	   DTD:

794	   <!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?, Object*)  >
795	   <!ATTLIST Signature
796	    xmlns   CDATA   #FIXED 'http://www.w3.org/2000/09/xmldsig#'
797	    Id      ID  #IMPLIED >

799	  4.2 The SignatureValue Element

801	   The SignatureValue element contains the actual value of the digital
802	   signature; it is always encoded using base64 [MIME]. While we specify
803	   a mandatory and optional to implement SignatureMethod algorithms, user
804	   specified algorithms are permitted.
805	   Schema Definition:

807	   <element name="SignatureValue" type="ds:SignatureValueType"/>
808	   <complexType name="SignatureValueType">
809	     <simpleContent>
810	       <extension base="base64Binary">
811	         <attribute name="Id" type="ID" use="optional"/>
812	       </extension>
813	     </simpleContent>
814	   </complexType>
815	   DTD:

817	   <!ELEMENT SignatureValue (#PCDATA) >
818	   <!ATTLIST SignatureValue
819	             Id  ID      #IMPLIED>

821	  4.3 The SignedInfo Element

823	   The structure of SignedInfo includes the canonicalization algorithm, a
824	   signature algorithm, and one or more references. The SignedInfo
825	   element may contain an optional ID attribute that will allow it to be
826	   referenced by other signatures and objects.

828	   SignedInfo does not include explicit signature or digest properties
829	   (such as calculation time, cryptographic device serial number, etc.).
830	   If an application needs to associate properties with the signature or
831	   digest, it may include such information in a SignatureProperties
832	   element within an Object element.
833	   Schema Definition:

835	   <element name="SignedInfo" type="ds:SignedInfoType"/>
836	   <complexType name="SignedInfoType">
837	     <sequence>
838	       <element ref="ds:CanonicalizationMethod"/>
839	       <element ref="ds:SignatureMethod"/>
840	       <element ref="ds:Reference" maxOccurs="unbounded"/>
841	     </sequence>
842	     <attribute name="Id" type="ID" use="optional"/>
843	   </complexType>
844	   DTD:

846	   <!ELEMENT SignedInfo (CanonicalizationMethod,
847	    SignatureMethod,  Reference+)  >
848	   <!ATTLIST SignedInfo
849	    Id   ID      #IMPLIED
850	    4.3.1 The CanonicalizationMethod Element

852	   CanonicalizationMethod is a required element that specifies the
853	   canonicalization algorithm applied to the SignedInfo element prior to
854	   performing signature calculations. This element uses the general
855	   structure for algorithms described in Algorithm Identifiers and
856	   Implementation Requirements (section 6.1). Implementations MUST
857	   support the REQUIRED Canonical XML [XML-C14N] method.

859	   Alternatives to the REQUIRED Canonical XML algorithm (section 6.5.2),
860	   such as Canonical XML with Comments (section 6.5.2) or a minimal
861	   canonicalization (such as CRLF and charset normalization), may be
862	   explicitly specified but are NOT REQUIRED. Consequently, their use may
863	   not interoperate with other applications that do not support the
864	   specified algorithm (see XML Canonicalization and Syntax Constraint
865	   Considerations, section 7). Security issues may also arise in the
866	   treatment of entity processing and comments if non-XML aware
867	   canonicalization algorithms are not properly constrained (see section
868	   8.2: Only What is "Seen" Should be Signed).

870	   The way in which the SignedInfo element is presented to the
871	   canonicalization method is dependent on that method. The following
872	   applies to the two types of algorithms spoken of by this document:
873	     * Canonical XML [XML-C14N] (with or without comments) implementation
874	       MUST be provided with an XPath node-set originally formed from the
875	       document containing the SignedInfo and currently indicating the
876	       SignedInfo, its descendants, and the attribute and namespace nodes
877	       of SignedInfo and its descendant elements (such that the namespace
878	       context and similar ancestor information of the SignedInfo is
879	       preserved).
880	     * Minimal canonicalization algorithms (such as CRLF and charset
881	       normalization) should be provided with the octets that represent
882	       the well-formed SignedInfo element, from the first character to
883	       the last character of the XML representation, inclusive. This
884	       includes the entire text of the start and end tags of the
885	       SignedInfo element as well as all descendant markup and character
886	       data (i.e., the text) between those tags.

888	   We RECOMMEND that resource constrained applications that do not
889	   implement the Canonical XML [XML-C14N] algorithm and instead choose a
890	   minimal canonicalization are implemented to generate Canonical XML as
891	   their output serialization so as to easily mitigate some of these
892	   interoperability and security concerns. (While a result might not be
893	   the canonical form of the original, it can still be in canonical
894	   form.) For instance, such an implementation SHOULD (at least) generate
895	   standalone XML instances [XML].
896	   Schema Definition:

898	   <element name="CanonicalizationMethod" type="ds:CanonicalizationMethodType"/
899	>
900	   <complexType name="CanonicalizationMethodType" mixed="true">
901	     <sequence>
902	       <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
903	       <!-- (0,unbounded) elements from (1,1) namespace -->
904	     </sequence>
905	     <attribute name="Algorithm" type="anyURI" use="required"/>
906	   </complexType>
907	   DTD:

909	   <!ELEMENT CanonicalizationMethod (#PCDATA %Method.ANY;)* >
910	   <!ATTLIST CanonicalizationMethod
911	    Algorithm CDATA #REQUIRED >

913	    4.3.2 The SignatureMethod Element

915	   SignatureMethod is a required element that specifies the algorithm
916	   used for signature generation and validation. This algorithm
917	   identifies all cryptographic functions involved in the signature
918	   operation (e.g. hashing, public key algorithms, MACs, padding, etc.).
919	   This element uses the general structure here for algorithms described
920	   in section 6.1: Algorithm Identifiers and Implementation Requirements.
921	   While there is a single identifier, that identifier may specify a
922	   format containing multiple distinct signature values.
923	   Schema Definition:

925	   <element name="SignatureMethod" type="ds:SignatureMethodType"/>
926	   <complexType name="SignatureMethodType" mixed="true">
927	     <sequence>
928	       <element name="HMACOutputLength" minOccurs="0" type="ds:HMACOutputLength
929	Type"/>
930	       <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
931	       <!-- (0,unbounded) elements from (1,1) external namespace -->
932	      </sequence>
933	    <attribute name="Algorithm" type="anyURI" use="required"/>
934	   </complexType>
935	   DTD:

937	   <!ELEMENT SignatureMethod (#PCDATA|HMACOutputLength %Method.ANY;)* >
938	   <!ATTLIST SignatureMethod
939	    Algorithm CDATA #REQUIRED >

941	    4.3.3 The Reference Element

943	   Reference is an element that may occur one or more times. It specifies
944	   a digest algorithm and digest value, and optionally an identifier of
945	   the object being signed, the type of the object, and/or a list of
946	   transforms to be applied prior to digesting. The identification (URI)
947	   and transforms describe how the digested content (i.e., the input to
948	   the digest method) was created. The Type attribute facilitates the
949	   processing of referenced data. For example, while this specification
950	   makes no requirements over external data, an application may wish to
951	   signal that the referent is a Manifest. An optional ID attribute
952	   permits a Reference to be referenced from elsewhere.
953	   Schema Definition:

955	   <element name="Reference" type="ds:ReferenceType"/>
956	   <complexType name="ReferenceType">
957	     <sequence>
958	       <element ref="ds:Transforms" minOccurs="0"/>
959	       <element ref="ds:DigestMethod"/>
960	       <element ref="ds:DigestValue"/>
961	     </sequence>
962	     <attribute name="Id" type="ID" use="optional"/>
963	     <attribute name="URI" type="anyURI" use="optional"/>
964	     <attribute name="Type" type="anyURI" use="optional"/>
965	   </complexType>
966	   DTD:

968	   <!ELEMENT Reference (Transforms?, DigestMethod, DigestValue)  >
969	   <!ATTLIST Reference
970	    Id  ID  #IMPLIED
971	    URI CDATA   #IMPLIED
972	    Type    CDATA   #IMPLIED>

974	    4.3.3.1 The URI Attribute

976	   The URI attribute identifies a data object using a URI-Reference, as
977	   specified by RFC2396 [URI]. The set of allowed characters for URI
978	   attributes is the same as for XML, namely [Unicode]. However, some
979	   Unicode characters are disallowed from URI references including all
980	   non-ASCII characters and the excluded characters listed in RFC2396
981	   [URI, section 2.4]. However, the number sign (#), percent sign (%),
982	   and square bracket characters re-allowed in RFC 2732 [URI-Literal] are
983	   permitted. Disallowed characters must be escaped as follows:
984	    1. Each disallowed character is converted to [UTF-8] as one or more
985	       octets.
986	    2. Any octets corresponding to a disallowed character are escaped
987	       with the URI escaping mechanism (that is, converted to %HH, where
988	       HH is the hexadecimal notation of the octet value).
989	    3. The original character is replaced by the resulting character
990	       sequence.

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

1002	   If a resource is identified by more than one URI, the most specific
1003	   should be used (e.g.
1004	   http://www.w3.org/2000/06/interop-pressrelease.html.en instead of
1005	   http://www.w3.org/2000/06/interop-pressrelease). (See the Reference
1006	   Validation (section 3.2.1) for a further information on reference
1007	   processing.)
1008	   If the URI attribute is omitted altogether, the receiving application
1009	   is expected to know the identity of the object. For example, a
1010	   lightweight data protocol might omit this attribute given the identity
1011	   of the object is part of the application context. This attribute may
1012	   be omitted from at most one Reference in any particular SignedInfo, or
1013	   Manifest.

1015	   The optional Type attribute contains information about the type of
1016	   object being signed. This is represented as a URI. For example:

1018	   Type="http://www.w3.org/2000/09/xmldsig#Object"
1019	   Type="http://www.w3.org/2000/09/xmldsig#Manifest"

1021	   The Type attribute applies to the item being pointed at, not its
1022	   contents. For example, a reference that identifies an Object element
1023	   containing a SignatureProperties element is still of type #Object. The
1024	   type attribute is advisory. No validation of the type information is
1025	   required by this specification.

1027	    4.3.3.2 The Reference Processing Model

1029	   Note: XPath is RECOMMENDED. Signature applications need not conform to
1030	   [XPath] specification in order to conform to this specification.
1031	   However, the XPath data model, definitions (e.g., node-sets) and
1032	   syntax is used within this document in order to describe functionality
1033	   for those that want to process XML-as-XML (instead of octets) as part
1034	   of signature generation. For those that want to use these features, a
1035	   conformant [XPath] implementation is one way to implement these
1036	   features, but it is not required. Such applications could use a
1037	   sufficiently functional replacement to a node-set and implement only
1038	   those XPath expression behaviors REQUIRED by this specification.
1039	   However, for simplicity we generally will use XPath terminology
1040	   without including this qualification on every point. Requirements over
1041	   "XPath nodesets" can include a node-set functional equivalent.
1042	   Requirements over XPath processing can include application behaviors
1043	   that are equivalent to the corresponding XPath behavior.

1045	   The data-type of the result of URI dereferencing or subsequent
1046	   Transforms is either an octet stream or an XPath node-set.

1048	   The Transforms specified in this document are defined with respect to
1049	   the input they require. The following is the default signature
1050	   application behavior:
1051	     * If the data object is an octet stream and the next transform
1052	       requires a node-set, the signature application MUST attempt to
1053	       parse the octets.
1054	     * If the data object is a node-set and the next transform requires
1055	       octets, the signature application MUST attempt to convert the
1056	       node-set to an octet stream using the REQUIRED canonicalization
1057	       algorithm [XML-C14N].

1059	   Users may specify alternative transforms that override these defaults
1060	   in transitions between Transforms that expect different inputs. The
1061	   final octet stream contains the data octets being secured. The digest
1062	   algorithm specified by DigestMethod is then applied to these data
1063	   octets, resulting in the DigestValue.

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

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

1082	   When a fragment is not preceded by a URI in the URI-Reference, XML
1083	   signature applications MUST support the null URI and barename
1084	   XPointer. We RECOMMEND support for the same-document XPointers
1085	   '#xpointer(/)' and '#xpointer(id('ID'))' if the application also
1086	   intends to support Canonical XML with Comments or other
1087	   canonicalizations. (Otherwise URI="#foo" will automatically remove
1088	   comments before the Canonical XML with Comments can even be invoked.)
1089	   All other support for XPointers is OPTIONAL, especially all support
1090	   for barename and other XPointers in external resources since the
1091	   application may not have control over how the fragment is generated
1092	   (leading to interoperability problems and validation failures).

1094	   The following examples demonstrate what the URI attribute identifies
1095	   and how it is dereferenced:

1097	   URI="http://example.com/bar.xml"
1098	          Identifies the octets that represent the external resource
1099	          'http//example.com/bar.xml', that is probably XML document
1100	          given its file extension.

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

1111	   URI=""
1112	          Identifies the nodeset (minus any comment nodes) of the XML
1113	          resource containing the signature

1115	   URI="#chapter1"
1116	          Identifies a nodeset containing the element with ID attribute
1117	          value 'chapter1' of the XML resource containing the signature.
1118	          XML Signature (and its applications) modify this nodeset to
1119	          include the element plus all descendents including namespaces
1120	          and attributes -- but not comments.

1122	    4.3.3.3 Same-Document URI-References

1124	   Dereferencing a same-document reference MUST result in an XPath
1125	   node-set suitable for use by Canonical XML. Specifically,
1126	   dereferencing a null URI (URI="") MUST result in an XPath node-set
1127	   that includes every non-comment node of the XML document containing
1128	   the URI attribute. In a fragment URI, the characters after the number
1129	   sign ('#') character conform to the XPointer syntax [Xptr]. When
1130	   processing an XPointer, the application MUST behave as if the root
1131	   node of the XML document containing the URI attribute were used to
1132	   initialize the XPointer evaluation context. The application MUST
1133	   behave as if the result of XPointer processing were a node-set derived
1134	   from the resultant location-set as follows:
1135	    1. discard point nodes
1136	    2. replace each range node with all XPath nodes having full or
1137	       partial content within the range
1138	    3. replace the root node with its children (if it is in the node-set)
1139	    4. replace any element node E with E plus all descendants of E (text,
1140	       comment, PI, element) and all namespace and attribute nodes of E
1141	       and its descendant elements.
1142	    5. if the URI is not a full XPointer, then delete all comment nodes

1144	   The second to last replacement is necessary because XPointer typically
1145	   indicates a subtree of an XML document's parse tree using just the
1146	   element node at the root of the subtree, whereas Canonical XML treats
1147	   a node-set as a set of nodes in which absence of descendant nodes
1148	   results in absence of their representative text from the canonical
1149	   form.

1151	   The last step is performed for null URIs, barename XPointers and child
1152	   sequence XPointers. To retain comments while selecting an element by
1153	   an identifier ID, use the following full XPointer:
1154	   URI='#xpointer(id('ID'))'. To retain comments while selecting the
1155	   entire document, use the following full XPointer: URI='#xpointer(/)'.
1156	   This XPointer contains a simple XPath expression that includes the
1157	   root node, which the second to last step above replaces with all nodes
1158	   of the parse tree (all descendants, plus all attributes, plus all
1159	   namespaces nodes).

1161	    4.3.3.4 The Transforms Element

1163	   The optional Transforms element contains an ordered list of Transform
1164	   elements; these describe how the signer obtained the data object that
1165	   was digested. The output of each Transform serves as input to the next
1166	   Transform. The input to the first Transform is the result of
1167	   dereferencing the URI attribute of the Reference element. The output
1168	   from the last Transform is the input for the DigestMethod algorithm.
1169	   When transforms are applied the signer is not signing the native
1170	   (original) document but the resulting (transformed) document. (See
1171	   Only What is Signed is Secure (section 8.1).)

1173	   Each Transform consists of an Algorithm attribute and content
1174	   parameters, if any, appropriate for the given algorithm. The Algorithm
1175	   attribute value specifies the name of the algorithm to be performed,
1176	   and the Transform content provides additional data to govern the
1177	   algorithm's processing of the transform input. (See Algorithm
1178	   Identifiers and Implementation Requirements (section 6).)

1180	   As described in The Reference Processing Model (section  4.3.3.2),
1181	   some transforms take an XPath node-set as input, while others require
1182	   an octet stream. If the actual input matches the input needs of the
1183	   transform, then the transform operates on the unaltered input. If the
1184	   transform input requirement differs from the format of the actual
1185	   input, then the input must be converted.

1187	   Some Transforms may require explicit MIME type, charset (IANA
1188	   registered "character set"), or other such information concerning the
1189	   data they are receiving from an earlier Transform or the source data,
1190	   although no Transform algorithm specified in this document needs such
1191	   explicit information. Such data characteristics are provided as
1192	   parameters to the Transform algorithm and should be described in the
1193	   specification for the algorithm.

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

1207	   <element name="Transforms" type="ds:TransformsType"/>
1208	   <complexType name="TransformsType">
1209	     <sequence>
1210	       <element ref="ds:Transform" maxOccurs="unbounded"/>
1211	     </sequence>
1212	   </complexType>

1214	   <element name="Transform" type="ds:TransformType"/>
1215	   <complexType name="TransformType" mixed="true">
1216	     <choice minOccurs="0" maxOccurs="unbounded">
1217	       <any namespace="##other" processContents="lax"/>
1218	       <!-- (1,1) elements from (0,unbounded) namespaces -->
1219	       <element name="XPath" type="string"/>

1221	     </choice>
1222	     <attribute name="Algorithm" type="anyURI" use="required"/>
1223	   </complexType>
1224	   DTD:

1226	   <!ELEMENT Transforms (Transform+)>

1228	   <!ELEMENT Transform (#PCDATA|XPath %Transform.ANY;)* >
1229	   <!ATTLIST Transform
1230	    Algorithm    CDATA    #REQUIRED >

1232	   <!ELEMENT XPath (#PCDATA) >

1234	    4.3.3.5 The DigestMethod Element

1236	   DigestMethod is a required element that identifies the digest
1237	   algorithm to be applied to the signed object. This element uses the
1238	   general structure here for algorithms specified in Algorithm
1239	   Identifiers and Implementation Requirements (section 6.1).

1241	   If the result of the URI dereference and application of Transforms is
1242	   an XPath node-set (or sufficiently functional replacement implemented
1243	   by the application) then it must be converted as described in the
1244	   Reference Processing Model (section  4.3.3.2). If the result of URI
1245	   dereference and application of Transforms is an octet stream, then no
1246	   conversion occurs (comments might be present if the Canonical XML with
1247	   Comments was specified in the Transforms). The digest algorithm is
1248	   applied to the data octets of the resulting octet stream.
1249	   Schema Definition:

1251	   <element name="DigestMethod" type="ds:DigestMethodType"/>
1252	   <complexType name="DigestMethodType" mixed="true">
1253	     <sequence>
1254	       <any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="
1255	unbounded"/>
1256	     </sequence>
1257	     <attribute name="Algorithm" type="anyURI" use="required"/>
1258	   </complexType>
1259	   DTD:

1261	   <!ELEMENT DigestMethod (#PCDATA %Method.ANY;)* >
1262	   <!ATTLIST DigestMethod
1263	    Algorithm       CDATA   #REQUIRED >

1265	    4.3.3.6 The DigestValue Element

1267	   DigestValue is an element that contains the encoded value of the
1268	   digest. The digest is always encoded using base64 [MIME].
1269	   Schema Definition:

1271	   <element name="DigestValue" type="ds:DigestValueType"/>
1272	   <simpleType name="DigestValueType">
1273	     <restriction base="base64Binary"/>

1275	   </simpleType>
1276	   DTD:

1278	   <!ELEMENT DigestValue  (#PCDATA)  >
1279	   <!-- base64 encoded digest value -->

1281	  4.4 The KeyInfo Element

1283	   KeyInfo is an optional element that enables the recipient(s) to obtain
1284	   the key needed to validate the signature. KeyInfo may contain keys,
1285	   names, certificates and other public key management information, such
1286	   as in-band key distribution or key agreement data. This specification
1287	   defines a few simple types but applications may extend those types or
1288	   all-together replace them with their own key identification and
1289	   exchange semantics using the XML namespace facility. [XML-ns]

1291	   If KeyInfo is omitted, the recipient is expected to be able to
1292	   identify the key based on application context. Multiple declarations
1293	   within KeyInfo refer to the same key. While applications may define
1294	   and use any mechanism they choose through inclusion of elements from a
1295	   different namespace, compliant versions MUST implement KeyValue
1296	   (section 4.4.2) and SHOULD implement RetrievalMethod (section 4.4.3).

1298	   The schema/DTD specifications of many of KeyInfo's children (e.g.,
1299	   PGPData, SPKIData, X509Data) permit their content to be
1300	   extended/complemented with elements from another namespace. This may
1301	   be done only if it is safe to ignore these extension elements while
1302	   claiming support for the types defined in this specification.
1303	   Otherwise, external elements, including alternative structures to
1304	   those defined by this specification, MUST be a child of KeyInfo. For
1305	   example, should a complete XML-PGP standard be defined, it's root
1306	   element MUST be a child of KeyInfo. (Of course, new structures from
1307	   external namespaces can incorporate elements from the &dsig; namespace
1308	   via features of the type definition language. For instance, they can
1309	   create a DTD that mixes their own and dsig qualified elements, or a
1310	   schema that permits, includes, imports, or derives new types based on
1311	   &dsig; elements.)

1313	   The following list summarizes the KeyInfo types that are allocated an
1314	   identifier in the &dsig; namespace; these can be used within the
1315	   RetrievalMethod Type attribute to describe a remote KeyInfo structure.
1316	     * http//www.w3.org/2000/09/xmldsig#DSAKeyValue
1317	     * http//www.w3.org/2000/09/xmldsig#RSAKeyValue
1318	     * http://www.w3.org/2000/09/xmldsig#X509Data
1319	     * http://www.w3.org/2000/09/xmldsig#PGPData
1320	     * http://www.w3.org/2000/09/xmldsig#SPKIData
1321	     * http://www.w3.org/2000/09/xmldsig#MgmtData

1323	   In addition to the types above for which we define an XML structure,
1324	   we specify one additional type to indicate a binary (ASN.1 DER) X.509
1325	   Certificate.
1326	     * http://www.w3.org/2000/09/xmldsig#rawX509Certificate

1328	   Schema Definition:

1330	   <element name="KeyInfo" type="ds:KeyInfoType"/>
1331	   <complexType name="KeyInfoType" mixed="true">
1332	     <choice maxOccurs="unbounded">
1333	       <element ref="ds:KeyName"/>
1334	       <element ref="ds:KeyValue"/>
1335	       <element ref="ds:RetrievalMethod"/>
1336	       <element ref="ds:X509Data"/>
1337	       <element ref="ds:PGPData"/>
1338	       <element ref="ds:SPKIData"/>
1339	       <element ref="ds:MgmtData"/>
1340	       <any processContents="lax" namespace="##other"/>
1341	       <!-- (1,1) elements from (0,unbounded) namespaces -->
1342	     </choice>
1343	     <attribute name="Id" type="ID" use="optional"/>
1344	   </complexType>
1345	   DTD:

1347	   <!ELEMENT KeyInfo (#PCDATA|KeyName|KeyValue|RetrievalMethod|
1348	               X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY;)* >
1349	   <!ATTLIST KeyInfo
1350	    Id  ID   #IMPLIED >

1352	    4.4.1 The KeyName Element

1354	   The KeyName element contains a string value which may be used by the
1355	   signer to communicate a key identifier to the recipient. Typically,
1356	   KeyName contains an identifier related to the key pair used to sign
1357	   the message, but it may contain other protocol-related information
1358	   that indirectly identifies a key pair. (Common uses of KeyName include
1359	   simple string names for keys, a key index, a distinguished name (DN),
1360	   an email address, etc.)
1361	   Schema Definition:

1363	   <element name="KeyName" type="string"/>
1364	   DTD:

1366	   <!ELEMENT KeyName (#PCDATA) >

1368	    4.4.2 The KeyValue Element

1370	   The KeyValue element contains a single public key that may be useful
1371	   in validating the signature. Structured formats for defining DSA
1372	   (REQUIRED) and RSA (RECOMMENDED) public keys are defined in Signature
1373	   Algorithms (section 6.4). The KeyValue element may include externally
1374	   defined public keys values represented as PCDATA or element types from
1375	   an external namespace.
1376	   Schema Definition:

1378	   <element name="KeyValue" type="ds:KeyValueType"/>
1379	   <complexType name="KeyValueType" mixed="true">
1380	    <choice>
1381	      <element ref="ds:DSAKeyValue"/>
1382	      <element ref="ds:RSAKeyValue"/>
1383	      <any namespace="##other" processContents="lax"/>
1384	    </choice>
1385	   </complexType>
1386	   DTD:

1388	   <!ELEMENT KeyValue (#PCDATA|DSAKeyValue|RSAKeyValue %KeyValue.ANY;)* >

1390	    4.4.2.1 The DSAKeyValue Element

1392	   Identifier
1393	          Type="http//www.w3.org/2000/09/xmldsig#DSAKeyValue"
1394	          (this can be used within a RetrievalMethod or Reference element
1395	          to identify the referent's type)

1397	   DSA key values have the following set of fields: P, Q, G and Y are
1398	   mandatory when appearing as a key value, J, seed and pgenCounter are
1399	   optional but should be present. (The seed and pgenCounter fields must
1400	   appear together or be absent). All parameters are encoded as base64
1401	   [MIME] values.

1403	   Arbitrary-length integers (e.g. "bignums" such as RSA moduli) are
1404	   represented in XML as octet strings as defined by the ds:CryptoBinary
1405	   type.
1406	   Schema:

1408	   <element name="DSAKeyValue" type="ds:DSAKeyValueType"/>
1409	   <complexType name="DSAKeyValueType">
1410	     <sequence>
1411	       <sequence>
1412	         <element name="P" type="ds:CryptoBinary"/>
1413	         <element name="Q" type="ds:CryptoBinary"/>
1414	         <element name="G" type="ds:CryptoBinary"/>
1415	         <element name="Y" type="ds:CryptoBinary"/>
1416	         <element name="J" type="ds:CryptoBinary" minOccurs="0"/>
1417	       </sequence>
1418	       <sequence minOccurs="0">
1419	         <element name="Seed" type="ds:CryptoBinary"/>
1420	         <element name="PgenCounter" type="ds:CryptoBinary"/>
1421	       </sequence>
1422	     </sequence>
1423	   </complexType>
1424	   DTD:

1426	   <!ELEMENT DSAKeyValue (P, Q, G, Y, J?, (Seed, PgenCounter)?) >
1427	   <!ELEMENT P (#PCDATA) >
1428	   <!ELEMENT Q (#PCDATA) >
1429	   <!ELEMENT G (#PCDATA) >
1430	   <!ELEMENT Y (#PCDATA) >
1431	   <!ELEMENT J (#PCDATA) >
1432	   <!ELEMENT Seed (#PCDATA) >
1433	   <!ELEMENT PgenCounter (#PCDATA) >
1434	    4.4.2.2 The RSAKeyValue Element

1436	   Identifier
1437	          Type="http//www.w3.org/2000/09/xmldsig#RSAKeyValue"
1438	          (this can be used within a RetrievalMethod or Reference element
1439	          to identify the referent's type)

1441	   RSA key values have two fields: Modulus and Exponent.

1443	      <RSAKeyValue>

1445	   <Modulus>xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W

1447	   jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
1448	         5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
1449	         </Modulus>
1450	         <Exponent>AQAB</Exponent>
1451	      </RSAKeyValue>

1453	   Arbitrary-length integers (e.g. "bignums" such as RSA moduli) are
1454	   represented in XML as octet strings as defined by the ds:CryptoBinary
1455	   type.
1456	   Schema:

1458	   <element name="RSAKeyValue" type="ds:RSAKeyValueType"/>
1459	   <complexType name="RSAKeyValueType">
1460	     <sequence>
1461	       <element name="Modulus" type="ds:CryptoBinary"/>
1462	       <element name="Exponent" type="ds:CryptoBinary"/>
1463	     </sequence>
1464	   </complexType>
1465	   DTD:

1467	   <!ELEMENT RSAKeyValue (Modulus, Exponent) >
1468	   <!ELEMENT Modulus (#PCDATA) >
1469	   <!ELEMENT Exponent (#PCDATA) >

1471	    4.4.3 The RetrievalMethod Element

1473	   A RetrievalMethod element within KeyInfo is used to convey a reference
1474	   to KeyInfo information that is stored at another location. For
1475	   example, several signatures in a document might use a key verified by
1476	   an X.509v3 certificate chain appearing once in the document or
1477	   remotely outside the document; each signature's KeyInfo can reference
1478	   this chain using a single RetrievalMethod element instead of including
1479	   the entire chain with a sequence of X509Certificate elements.

1481	   RetrievalMethod uses the same syntax and dereferencing behavior as
1482	   Reference's URI (section 4.3.3.1) and The Reference Processing Model
1483	   (section 4.3.3.2) except that there is no DigestMethod or DigestValue
1484	   child elements and presence of the URI is mandatory.

1486	   Type is an optional identifier for the type of data to be retrieved.
1487	   The result of dereferencing a RetrievalMethod Reference for all
1488	   KeyInfo types defined by this specification (section 4.4) with a
1489	   corresponding XML structure is an XML element or document with that
1490	   element as the root. The rawX509Certificate KeyInfo (for which there
1491	   is no XML structure) returns a binary X509 certificate. Note, if the
1492	   result of dereferencing and transforming the specified URI  is a node
1493	   set,  it may need to be canonicalized. Consequently the Signature
1494	   application is expected to attempt to canonicalize the nodeset via the
1495	   The Reference Processing Model (section 4.3.3.2)
1496	   Schema Definition

1498	   <element name="RetrievalMethod" type="ds:RetrievalMethodType"/>
1499	   <complexType name="RetrievalMethodType">
1500	     <sequence>
1501	       <element name="Transforms" type="ds:TransformsType" minOccurs="0"/>
1502	     </sequence>
1503	     <attribute name="URI" type="anyURI"/>
1504	     <attribute name="Type" type="anyURI" use="optional"/>
1505	   </complexType>
1506	   DTD

1508	   <!ELEMENT RetrievalMethod (Transforms?) >
1509	   <!ATTLIST RetrievalMethod
1510	      URI   CDATA #REQUIRED
1511	      Type  CDATA #IMPLIED >

1513	    4.4.4 The X509Data Element

1515	   Identifier
1516	          Type="http://www.w3.org/2000/09/xmldsig#X509Data"
1517	          (this can be used within a RetrievalMethod or Reference element
1518	          to identify the referent's type)

1520	   An X509Data element within KeyInfo contains one or more identifiers of
1521	   keys or X509 certificates (or certificates' identifiers or a
1522	   revocation list). The content of X509Data is:
1523	    1. At least one element, from the following set of element types; any
1524	       of these may appear together or more than once iff each instance
1525	       describes the same certificate:
1526	    2.
1527	          + The X509IssuerSerial element, which contains an X.509 issuer
1528	            distinguished name/serial number pair that SHOULD be
1529	            compliant with RFC2253 [LDAP-DN],
1530	          + The X509SubjectName element, which contains an X.509 subject
1531	            distinguished name that SHOULD be compliant with RFC2253
1532	            [LDAP-DN],
1533	          + The X509SKI element, which contains the base64 encoded plain
1534	            (i.e. non-DER-encoded) value of a X509 V.3
1535	            SubjectKeyIdentifier extension.
1536	          + The X509Certificate element, which contains a base64-encoded
1537	            [X509v3] certificate, and
1538	          + Elements from an external namespace which
1539	            accompanies/complements any of the elements above.
1540	    3. Or a single certificate revocation list:
1541	          + The X509CRL element, which contains a base64-encoded
1542	            certificate revocation list (CRL) [X509v3].

1544	   Any X509IssuerSerial, X509SKI, and X509SubjectName elements that
1545	   appear MUST refer to the certificate or certificates containing the
1546	   validation key. All such elements that refer to a particular
1547	   individual certificate MUST be grouped inside a single X509Data
1548	   element and if the certificate to which they refer appears, it MUST
1549	   also be in that X509Data element.

1551	   Any X509IssuerSerial, X509SKI, and X509SubjectName elements that
1552	   relate to the same key but different certificates MUST be grouped
1553	   within a single KeyInfo but MAY occur in multiple X509Data elements.

1555	   All certificates appearing in an X509Data element MUST relate to the
1556	   validation key by either containing it or being part of a
1557	   certification chain that terminates in a certificate containing the
1558	   validation key.

1560	   No ordering is implied by the above constraints.
1561	   <KeyInfo>
1562	     <X509Data> <!-- two pointers to certificate-A -->
1563	       <X509IssuerSerial>
1564	         <X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
1565	           L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
1566	         <X509SerialNumber>12345678</X509SerialNumber>
1567	       </X509IssuerSerial>
1568	       <X509SKI>31d97bd7</X509SKI>
1569	     </X509Data>
1570	     <X509Data><!-- single pointer to certificate-B -->
1571	       <X509SubjectName>Subject of Certificate B</X509SubjectName>
1572	     </X509Data>
1573	     <X509Data> <!-- certificate chain -->
1574	       <!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->
1575	       <X509Certificate>MIICXTCCA..</X509Certificate>
1576	       <!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=US
1577	            issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
1578	       <X509Certificate>MIICPzCCA...</X509Certificate>
1579	       <!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
1580	       <X509Certificate>MIICSTCCA...</X509Certificate>
1581	     </X509Data>
1582	   </KeyInfo>

1584	   Note, there is no direct provision for a PKCS#7 encoded "bag" of
1585	   certificates or CRLs. However, a set of certificates or a CRL can
1586	   occur within an X509Data element and multiple X509Data elements can
1587	   occur in a KeyInfo. Whenever multiple certificates occur in an
1588	   X509Data element, at least one such certificate must contain the
1589	   public key which verifies the signature.
1590	   Schema Definition
1591	   <element name="X509Data" type="ds:X509DataType"/>
1592	   <complexType name="X509DataType">
1593	     <choice>
1594	       <sequence maxOccurs="unbounded">
1595	         <choice>
1596	           <element name="X509IssuerSerial" type="ds:X509IssuerSerialType"/>
1597	           <element name="X509SKI" type="base64Binary"/>
1598	           <element name="X509SubjectName" type="string"/>
1599	           <element name="X509Certificate" type="base64Binary"/>
1600	           <any namespace="##other" processContents="lax"/>
1601	         </choice>
1602	       </sequence>
1603	       <element name="X509CRL" type="base64Binary"/>
1604	     </choice>
1605	   </complexType>

1607	   <complexType name="X509IssuerSerialType">
1608	     <sequence>
1609	       <element name="X509IssuerName" type="string"/>
1610	       <element name="X509SerialNumber" type="integer"/>
1611	     </sequence>
1612	   </complexType>
1613	   DTD

1615	   <!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName |
1616	                        X509Certificate)+ | X509CRL %X509.ANY;)>
1617	   <!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) >
1618	   <!ELEMENT X509IssuerName (#PCDATA) >
1619	   <!ELEMENT X509SubjectName (#PCDATA) >
1620	   <!ELEMENT X509SerialNumber (#PCDATA) >
1621	   <!ELEMENT X509SKI (#PCDATA) >
1622	   <!ELEMENT X509Certificate (#PCDATA) >
1623	   <!ELEMENT X509CRL (#PCDATA) >
1624	<!-- Note, this DTD and schema permits X509Data to be empty; this is
1625	   precluded by the text in KeyInfo Element (section 4.4) which states
1626	   that at least one element from the dsig namespace should be present
1627	   in the PGP, SPKI, and X509 structures. This is easily expressed for
1628	   the other key types, but not for X509Data because of its rich
1629	   structure. -->

1631	    4.4.5 The PGPData Element

1633	   Identifier
1634	          Type="http://www.w3.org/2000/09/xmldsig#PGPData"
1635	          (this can be used within a RetrievalMethod or Reference element
1636	          to identify the referent's type)

1638	   The PGPData element within KeyInfo is used to convey information
1639	   related to PGP public key pairs and signatures on such keys. The
1640	   PGPKeyID's value is a string containing a standard PGP public key
1641	   identifier as defined in [PGP, section 11.2]. The PGPKeyPacket
1642	   contains a base64-encoded Key Material Packet as defined in [PGP,
1643	   section 5.5]. These children element types can be
1644	   complemented/extended by siblings from an external namespace within
1645	   PGPData, or PGPData can be replaced all-together with an alternative
1646	   PGP XML structure as a child of KeyInfo. PGPData must contain one
1647	   PGPKeyID and/or one PGPKeyPacket and 0 or more elements from an
1648	   external namespace.
1649	   Schema Definition:

1651	   <element name="PGPData" type="ds:PGPDataType"/>
1652	   <complexType name="PGPDataType">
1653	     <choice>
1654	       <sequence>
1655	         <element name="PGPKeyID" type="string"/>
1656	         <element name="PGPKeyPacket" type="base64Binary" minOccurs="0"/>
1657	         <any namespace="##other" processContents="lax" minOccurs="0"
1658	          maxOccurs="unbounded"/>
1659	       </sequence>
1660	       <sequence>
1661	         <element name="PGPKeyPacket" type="base64Binary"/>
1662	         <any namespace="##other" processContents="lax" minOccurs="0"
1663	          maxOccurs="unbounded"/>
1664	       </sequence>
1665	     </choice>
1666	   </complexType>
1667	   DTD:

1669	 <!ELEMENT PGPData ((PGPKeyID, PGPKeyPacket?) | (PGPKeyPacket) %PGPData.ANY;) >
1670	   <!ELEMENT PGPKeyPacket  (#PCDATA)  >
1671	   <!ELEMENT PGPKeyID  (#PCDATA)  >

1673	    4.4.6 The SPKIData Element

1675	   Identifier
1676	          Type="http://www.w3.org/2000/09/xmldsig#SPKIData"
1677	          (this can be used within a RetrievalMethod or Reference element
1678	          to identify the referent's type)

1680	   The SPKIData element within KeyInfo is used to convey information
1681	   related to SPKI public key pairs, certificates and other SPKI data.
1682	   SPKISexp is the base64 encoding of a SPKI canonical S-expression.
1683	   SPKIData must have at least one SPKISexp; SPKISexp can be
1684	   complemented/extended by siblings from an external namespace within
1685	   SPKIData, or SPKIData can be entirely replaced with an alternative
1686	   SPKI XML structure as a child of KeyInfo.
1687	   Schema Definition:

1689	   <element name="SPKIData" type="ds:SPKIDataType"/>
1690	   <complexType name="SPKIDataType">
1691	     <sequence maxOccurs="unbounded">
1692	       <element name="SPKISexp" type="base64Binary"/>
1693	       <any namespace="##other" processContents="lax" minOccurs="0"/>
1694	     </sequence>
1695	   </complexType>
1696	   DTD:

1698	 <!ELEMENT SPKIData (SPKISexp %SPKIData.ANY;)  >
1699	   <!ELEMENT SPKISexp  (#PCDATA)  >

1701	    4.4.7 The MgmtData Element

1703	   Identifier
1704	          Type="http://www.w3.org/2000/09/xmldsig#MgmtData"
1705	          (this can be used within a RetrievalMethod or Reference element
1706	          to identify the referent's type)

1708	   The MgmtData element within KeyInfo is a string value used to convey
1709	   in-band key distribution or agreement data. For example, DH key
1710	   exchange, RSA key encryption, etc.
1711	   Schema Definition:

1713	   <element name="MgmtData" type="string"/>
1714	   DTD:

1716	   <!ELEMENT MgmtData (#PCDATA)>

1718	  4.5 The Object Element

1720	   Identifier
1721	          Type="http://www.w3.org/2000/09/xmldsig#Object"
1722	          (this can be used within a Reference element to identify the
1723	          referent's type)

1725	   Object is an optional element that may occur one or more times. When
1726	   present, this element may contain any data. The Object element may
1727	   include optional MIME type, ID, and encoding attributes.

1729	   The MimeType attribute is an optional attribute which describes the
1730	   data within the Object. This is a string with values defined by
1731	   [MIME]. For example, if the Object contains XML, the MimeType could be
1732	   text/xml. This attribute is purely advisory; no validation of the
1733	   MimeType information is required by this specification.

1735	   The Object's Id is commonly referenced from a Reference in SignedInfo,
1736	   or Manifest. This element is typically used for enveloping signatures
1737	   where the object being signed is to be included in the signature
1738	   element. The digest is calculated over the entire Object element
1739	   including start and end tags.

1741	   The Object's Encoding attributed may be used to provide a URI that
1742	   identifies the method by which the object is encoded (e.g., a binary
1743	   file).

1745	   Note, if the application wishes to exclude the <Object> tags from the
1746	   digest calculation the Reference must identify the actual data object
1747	   (easy for XML documents) or a transform must be used to remove the
1748	   Object tags (likely where the data object is non-XML). Exclusion of
1749	   the object tags may be desired for cases where one wants the signature
1750	   to remain valid if the data object is moved from inside a signature to
1751	   outside the signature (or vice-versa), or where the content of the
1752	   Object is an encoding of an original binary document and it is desired
1753	   to extract and decode so as to sign the original bitwise
1754	   representation.
1755	   Schema Definition:

1757	   <element name="Object" type="ds:ObjectType"/>
1758	   <complexType name="ObjectType" mixed="true">
1759	     <sequence minOccurs="0" maxOccurs="unbounded">
1760	       <any namespace="##any" processContents="lax"/>
1761	     </sequence>
1762	     <attribute name="Id" type="ID" use="optional"/>
1763	     <attribute name="MimeType" type="string" use="optional"/>
1764	     <attribute name="Encoding" type="anyURI" use="optional"/>
1765	   </complexType>
1766	   DTD:

1768	   <!ELEMENT Object (#PCDATA|Signature|SignatureProperties|Manifest %Object.ANY
1769	;)* >
1770	   <!ATTLIST Object
1771	    Id  ID  #IMPLIED
1772	    MimeType    CDATA   #IMPLIED
1773	    Encoding    CDATA   #IMPLIED >

1775	5.0 Additional Signature Syntax

1777	   This section describes the optional to implement Manifest and
1778	   SignatureProperties elements and describes the handling of XML
1779	   processing instructions and comments. With respect to the elements
1780	   Manifest and SignatureProperties this section specifies syntax and
1781	   little behavior -- it is left to the application. These elements can
1782	   appear anywhere the parent's content model permits; the Signature
1783	   content model only permits them within Object.

1785	  5.1 The Manifest Element

1787	   Identifier
1788	          Type="http://www.w3.org/2000/09/xmldsig#Manifest"
1789	          (this can be used within a Reference element to identify the
1790	          referent's type)

1792	   The Manifest element provides a list of References. The difference
1793	   from the list in SignedInfo is that it is application defined which,
1794	   if any, of the digests are actually checked against the objects
1795	   referenced and what to do if the object is inaccessible or the digest
1796	   compare fails. If a Manifest is pointed to from SignedInfo, the digest
1797	   over the Manifest itself will be checked by the core signature
1798	   validation behavior. The digests within such a Manifest are checked at
1799	   the application's discretion. If a Manifest is referenced from another
1800	   Manifest, even the overall digest of this two level deep Manifest
1801	   might not be checked.
1802	   Schema Definition:

1804	   <element name="Manifest" type="ds:ManifestType"/>
1805	   <complexType name="ManifestType">
1806	     <sequence>
1807	       <element ref="ds:Reference" maxOccurs="unbounded"/>
1808	     </sequence>
1809	     <attribute name="Id" type="ID" use="optional"/>
1810	   </complexType>
1811	   DTD:

1813	   <!ELEMENT Manifest (Reference+)  >
1814	   <!ATTLIST Manifest
1815	             Id ID  #IMPLIED >

1817	  5.2 The SignatureProperties Element

1819	   Identifier
1820	          Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"
1821	          (this can be used within a Reference element to identify the
1822	          referent's type)

1824	   Additional information items concerning the generation of the
1825	   signature(s) can be placed in a SignatureProperty element (i.e.,
1826	   date/time stamp or the serial number of cryptographic hardware used in
1827	   signature generation).
1828	   Schema Definition:

1830	   <element name="SignatureProperties" type="ds:SignaturePropertiesType"/>
1831	   <complexType name="SignaturePropertiesType">
1832	     <sequence>
1833	       <element ref="ds:SignatureProperty" maxOccurs="unbounded"/>
1834	     </sequence>
1835	     <attribute name="Id" type="ID" use="optional"/>
1836	   </complexType>

1838	      <element name="SignatureProperty" type="ds:SignaturePropertyType"/>
1839	      <complexType name="SignaturePropertyType" mixed="true">
1840	        <choice maxOccurs="unbounded">
1841	          <any namespace="##other" processContents="lax"/>
1842	          <!-- (1,1) elements from (1,unbounded) namespaces -->
1843	        </choice>
1844	        <attribute name="Target" type="anyURI" use="required"/>
1845	        <attribute name="Id" type="ID" use="optional"/>
1846	      </complexType>
1847	   DTD:

1849	   <!ELEMENT SignatureProperties (SignatureProperty+)  >
1850	   <!ATTLIST SignatureProperties
1851	             Id ID   #IMPLIED  >

1853	   <!ELEMENT SignatureProperty (#PCDATA %SignatureProperty.ANY;)* >
1854	   <!ATTLIST SignatureProperty
1855	    Target  CDATA    #REQUIRED
1856	    Id  ID   #IMPLIED  >

1858	  5.3 Processing Instructions in Signature Elements

1860	   No XML processing instructions (PIs) are used by this specification.

1862	   Note that PIs placed inside SignedInfo by an application will be
1863	   signed unless the CanonicalizationMethod algorithm discards them.
1864	   (This is true for any signed XML content.) All of the
1865	   CanonicalizationMethods specified within this specification retain
1866	   PIs. When a PI is part of content that is signed (e.g., within
1867	   SignedInfo or referenced XML documents) any change to the PI will
1868	   obviously result in a signature failure.

1870	  5.4 Comments in Signature Elements

1872	   XML comments are not used by this specification.

1874	   Note that unless CanonicalizationMethod removes comments within
1875	   SignedInfo or any other referenced XML (which [XML-C14N] does), they
1876	   will be signed. Consequently, if they are retained, a change to the
1877	   comment will cause a signature failure. Similarly, the XML signature
1878	   over any XML data will be sensitive to comment changes unless a
1879	   comment-ignoring canonicalization/transform method, such as the
1880	   Canonical XML [XML-C14N], is specified.

1882	6.0 Algorithms

1884	   This section identifies algorithms used with the XML digital signature
1885	   specification. Entries contain the identifier to be used in Signature
1886	   elements, a reference to the formal specification, and definitions,
1887	   where applicable, for the representation of keys and the results of
1888	   cryptographic operations.

1890	  6.1 Algorithm Identifiers and Implementation Requirements

1892	   Algorithms are identified by URIs that appear as an attribute to the
1893	   element that identifies the algorithms' role (DigestMethod, Transform,
1894	   SignatureMethod, or CanonicalizationMethod). All algorithms used
1895	   herein take parameters but in many cases the parameters are implicit.
1896	   For example, a SignatureMethod is implicitly given two parameters: the
1897	   keying info and the output of CanonicalizationMethod. Explicit
1898	   additional parameters to an algorithm appear as content elements
1899	   within the algorithm role element. Such parameter elements have a
1900	   descriptive element name, which is frequently algorithm specific, and
1901	   MUST be in the XML Signature namespace or an algorithm specific
1902	   namespace.

1904	   This specification defines a set of algorithms, their URIs, and
1905	   requirements for implementation. Requirements are specified over
1906	   implementation, not over requirements for signature use. Furthermore,
1907	   the mechanism is extensible, alternative algorithms may be used by
1908	   signature applications.

1910	   (Note that the normative identifier is the complete URI in the table
1911	   though they are sometimes abbreviated in XML syntax (e.g.,
1912	   "&dsig;base64").)

1914	   Algorithm Type Algorithm Requirements Algorithm URI
1915	   Digest
1916	     SHA1 REQUIRED http://www.w3.org/2000/09/xmldsig#sha1
1917	   Encoding
1918	     base64 REQUIRED http://www.w3.org/2000/09/xmldsig#base64
1919	   MAC
1920	     HMAC-SHA1 REQUIRED http://www.w3.org/2000/09/xmldsig#hmac-sha1
1921	   Signature
1922	     DSAwithSHA1
1923	   (DSS) REQUIRED http://www.w3.org/2000/09/xmldsig#dsa-sha1
1924	     RSAwithSHA1 RECOMMENDED http://www.w3.org/2000/09/xmldsig#rsa-sha1
1925	   Canonicalization
1926	     Canonical XML with Comments RECOMMENDED
1927	   http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
1928	     Canonical XML (omits comments) REQUIRED
1929	   http://www.w3.org/TR/2001/REC-xml-c14n-20010315
1930	   Transform
1931	     XSLT OPTIONAL http://www.w3.org/TR/1999/REC-xslt-19991116
1932	     XPath RECOMMENDED http://www.w3.org/TR/1999/REC-xpath-19991116
1933	     Enveloped Signature* REQUIRED
1934	   http://www.w3.org/2000/09/xmldsig#enveloped-signature

1936	   * The Enveloped Signature transform removes the Signature element from
1937	   the calculation of the signature when the signature is within the
1938	   content that it is being signed. This MAY be implemented via the
1939	   RECOMMENDED XPath specification specified in 6.6.4: Enveloped
1940	   Signature Transform; it MUST have the same effect as that specified by
1941	   the XPath Transform.

1943	  6.2 Message Digests

1945	   Only one digest algorithm is defined herein. However, it is expected
1946	   that one or more additional strong digest algorithms will be developed
1947	   in connection with the US Advanced Encryption Standard effort. Use of
1948	   MD5 [MD5] is NOT RECOMMENDED because recent advances in cryptanalysis
1949	   have cast doubt on its strength.

1951	    6.2.1 SHA-1

1953	   Identifier:
1954	          http://www.w3.org/2000/09/xmldsig#sha1

1956	   The SHA-1 algorithm [SHA-1] takes no explicit parameters. An example
1957	   of an SHA-1 DigestAlg element is:
1958	<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

1960	   A SHA-1 digest is a 160-bit string. The content of the DigestValue
1961	   element shall be the base64 encoding of this bit string viewed as a
1962	   20-octet octet stream. For example, the DigestValue element for the
1963	   message digest:
1964	   A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D

1966	   from Appendix A of the SHA-1 standard would be:
1967	   <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>

1969	  6.3 Message Authentication Codes

1971	   MAC algorithms take two implicit parameters, their keying material
1972	   determined from KeyInfo and the octet stream output by
1973	   CanonicalizationMethod. MACs and signature algorithms are
1974	   syntactically identical but a MAC implies a shared secret key.

1976	    6.3.1 HMAC

1978	   Identifier:
1979	          http://www.w3.org/2000/09/xmldsig#hmac-sha1

1981	   The HMAC algorithm (RFC2104 [HMAC]) takes the truncation length in
1982	   bits as a parameter; if the parameter is not specified then all the
1983	   bits of the hash are output. An example of an HMAC SignatureMethod
1984	   element:
1985	   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
1986	      <HMACOutputLength>128</HMACOutputLength>
1987	   </SignatureMethod>

1989	   The output of the HMAC algorithm is ultimately the output (possibly
1990	   truncated) of the chosen digest algorithm. This value shall be base64
1991	   encoded in the same straightforward fashion as the output of the
1992	   digest algorithms. Example: the SignatureValue element for the
1993	   HMAC-SHA1 digest
1994	   9294727A 3638BB1C 13F48EF8 158BFC9D

1996	   from the test vectors in [HMAC] would be
1997	   <SignatureValue>kpRyejY4uxwT9I74FYv8nQ==</SignatureValue>
1998	   Schema Definition:

2000	   <simpleType name="HMACOutputLengthType">
2001	     <restriction base="integer"/>
2002	   </simpleType>
2003	   DTD:

2005	   <!ELEMENT HMACOutputLength (#PCDATA)>

2007	  6.4 Signature Algorithms

2009	   Signature algorithms take two implicit parameters, their keying
2010	   material determined from KeyInfo and the octet stream output by
2011	   CanonicalizationMethod. Signature and MAC algorithms are syntactically
2012	   identical but a signature implies public key cryptography.

2014	    6.4.1 DSA

2016	   Identifier:
2017	          http://www.w3.org/2000/09/xmldsig#dsa-sha1

2019	   The DSA algorithm [DSS] takes no explicit parameters. An example of a
2020	   DSA SignatureMethod element is:
2021	   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>

2023	   The output of the DSA algorithm consists of a pair of integers usually
2024	   referred by the pair (r, s). The signature value consists of the
2025	   base64 encoding of the concatenation of two octet-streams that
2026	   respectively result from the octet-encoding of the values r and s.
2027	   Integer to octet-stream conversion must be done according to the I2OSP
2028	   operation defined in the RFC 2437 [PKCS1] specification with a k
2029	   parameter equal to 20. For example, the SignatureValue element for a
2030	   DSA signature (r, s) with values specified in hexadecimal:
2031	   r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0
2032	   s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8

2034	   from the example in Appendix 5 of the DSS standard would be
2035	   <SignatureValue>
2036	   i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==</SignatureValue>

2038	    6.4.2 PKCS1 (RSA-SHA1)

2040	   Identifier:
2041	          http://www.w3.org/2000/09/xmldsig#rsa-sha1

2043	   The expression "RSA algorithm" as used in this draft refers to the
2044	   RSASSA-PKCS1-v1_5 algorithm described in RFC 2437 [PKCS1]. The RSA
2045	   algorithm takes no explicit parameters. An example of an RSA
2046	   SignatureMethod element is:
2047	   <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>

2049	   The SignatureValue content for an RSA signature is the base64 [MIME]
2050	   encoding of the octet string computed as per RFC 2437 [PKCS1, section
2051	   8.1.1: Signature generation for the RSASSA-PKCS1-v1_5 signature
2052	   scheme]. As specified in the EMSA-PKCS1-V1_5-ENCODE function RFC 2437
2053	   [PKCS1, section 9.2.1], the value input to the signature function MUST
2054	   contain a pre-pended algorithm object identifier for the hash
2055	   function, but the availability of an ASN.1 parser and recognition of
2056	   OIDs is not required of a signature verifier. The PKCS#1 v1.5
2057	   representation appears as:

2059	      CRYPT (PAD (ASN.1 (OID, DIGEST (data))))

2061	   Note that the padded ASN.1 will be of the following form:

2063	      01 | FF* | 00 | prefix | hash

2065	   where "|" is concatentation, "01", "FF", and "00" are fixed octets of
2066	   the corresponding hexadecimal value, "hash" is the SHA1 digest of the
2067	   data, and "prefix" is the ASN.1 BER SHA1 algorithm designator prefix
2068	   required in PKCS1 [RFC 2437], that is,

2070	      hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14

2072	   This prefix is included to make it easier to use standard
2073	   cryptographic libraries. The FF octet MUST be repeated the maximum
2074	   number of times such that the value of the quantity being CRYPTed is
2075	   one octet shorter than the RSA modulus.

2077	   The resulting base64 [MIME] string is the value of the child text node
2078	   of the SignatureValue element, e.g.

2080	      <SignatureValue>IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4
2081	      t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
2082	      </SignatureValue>

2084	  6.5 Canonicalization Algorithms

2086	   If canonicalization is performed over octets, the canonicalization
2087	   algorithms take two implicit parameter: the content and its charset.
2088	   The charset is derived according to the rules of the transport
2089	   protocols and media types (e.g, RFC2376 [XML-MT] defines the media
2090	   types for XML). This information is necessary to correctly sign and
2091	   verify documents and often requires careful server side configuration.

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

2098	   Various canonicalization algorithms transcode from a non-Unicode
2099	   encoding to Unicode. The two algorithms below perform text
2100	   normalization during transcoding [NFC, NFC-Corrigendum]. We RECOMMEND
2101	   that externally specified canonicalization algorithms do the same.
2102	   (Note, there can be ambiguities in converting existing charsets to
2103	   Unicode, for an example see the XML Japanese Profile [XML-Japanese]
2104	   NOTE.)

2106	    6.5.1 Canonical XML

2108	   Identifier for REQUIRED Canonical XML (omits comments):
2109	          http://www.w3.org/TR/2001/REC-xml-c14n-20010315

2111	   Identifier for Canonical XML with Comments:
2112	          http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments

2114	   An example of an XML canonicalization element is:
2115	   <CanonicalizationMethod
2116	    Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

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

2124	  6.6 Transform Algorithms

2126	   A Transform algorithm has a single implicit parameter: an octet stream
2127	   from the Reference or the output of an earlier Transform.

2129	   Application developers are strongly encouraged to support all
2130	   transforms listed in this section as RECOMMENDED unless the
2131	   application environment has resource constraints that would make such
2132	   support impractical. Compliance with this recommendation will maximize
2133	   application interoperability and libraries should be available to
2134	   enable support of these transforms in applications without extensive
2135	   development.

2137	    6.6.1 Canonicalization

2139	   Any canonicalization algorithm that can be used for
2140	   CanonicalizationMethod (such as those in  Canonicalization Algorithms
2141	   (section 6.5)) can be used as a Transform

2143	    6.6.2 Base64

2145	   Identifiers:
2146	          http://www.w3.org/2000/09/xmldsig#base64

2148	   The normative specification for base64 decoding transforms is [MIME].
2149	   The base64 Transform element has no content. The input is decoded by
2150	   the algorithms. This transform is useful if an application needs to
2151	   sign the raw data associated with the encoded content of an element.

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

2165	    6.6.3 XPath Filtering

2167	   Identifier:
2168	          http://www.w3.org/TR/1999/REC-xpath-19991116

2170	   The normative specification for XPath expression evaluation is
2171	   [XPath]. The XPath expression to be evaluated appears as the character
2172	   content of a transform parameter child element named XPath.

2174	   The input required by this transform is an XPath node-set. Note that
2175	   if the actual input is an XPath node-set resulting from a null URI or
2176	   barename XPointer dereference, then comment nodes will have been
2177	   omitted. If the actual input is an octet stream, then the application
2178	   MUST convert the octet stream to an XPath node-set suitable for use by
2179	   Canonical XML with Comments. (A subsequent application of the REQUIRED
2180	   Canonical XML algorithm would strip away these comments.) In other
2181	   words, the input node-set should be equivalent to the one that would
2182	   be created by the following process:
2183	    1. Initialize an XPath evaluation context by setting the initial node
2184	       equal to the input XML document's root node, and set the context
2185	       position and size to 1.
2186	    2. Evaluate the XPath expression (//. | //@* | //namespace::*)

2188	   The evaluation of this expression includes all of the document's nodes
2189	   (including comments) in the node-set representing the octet stream.

2191	   The transform output is also an XPath node-set. The XPath expression
2192	   appearing in the XPath parameter is evaluated once for each node in
2193	   the input node-set. The result is converted to a boolean. If the
2194	   boolean is true, then the node is included in the output node-set. If
2195	   the boolean is false, then the node is omitted from the output
2196	   node-set.

2198	   Note: Even if the input node-set has had comments removed, the comment
2199	   nodes still exist in the underlying parse tree and can separate text
2200	   nodes. For example, the markup <e>Hello, <!-- comment --> world!</e>
2201	   contains two text nodes. Therefore, the expression
2202	   self::text()[string()="Hello, world!"] would fail. Should this problem
2203	   arise in the application, it can be solved by either canonicalizing
2204	   the document before the XPath transform to physically remove the
2205	   comments or by matching the node based on the parent element's string
2206	   value (e.g. by using the expression
2207	   self::text()[string(parent::e)="Hello, world!"]).

2209	   The primary purpose of this transform is to ensure that only
2210	   specifically defined changes to the input XML document are permitted
2211	   after the signature is affixed. This is done by omitting precisely
2212	   those nodes that are allowed to change once the signature is affixed,
2213	   and including all other input nodes in the output. It is the
2214	   responsibility of the XPath expression author to include all nodes
2215	   whose change could affect the interpretation of the transform output
2216	   in the application context.

2218	   An important scenario would be a document requiring two enveloped
2219	   signatures. Each signature must omit itself from its own digest
2220	   calculations, but it is also necessary to exclude the second signature
2221	   element from the digest calculations of the first signature so that
2222	   adding the second signature does not break the first signature.

2224	   The XPath transform establishes the following evaluation context for
2225	   each node of the input node-set:

2227	     * A context node equal to a node of the input node-set.
2228	     * A context position, initialized to 1.
2229	     * A context size, initialized to 1.
2230	     * A library of functions equal to the function set defined in XPath
2231	       plus a function named here.
2232	     * A set of variable bindings. No means for initializing these is
2233	       defined. Thus, the set of variable bindings used when evaluating
2234	       the XPath expression is empty, and use of a variable reference in
2235	       the XPath expression results in an error.
2236	     * The set of namespace declarations in scope for the XPath
2237	       expression.

2239	   As a result of the context node setting, the XPath expressions
2240	   appearing in this transform will be quite similar to those used in
2241	   used in [XSLT], except that the size and position are always 1 to
2242	   reflect the fact that the transform is automatically visiting every
2243	   node (in XSLT, one recursively calls the command apply-templates to
2244	   visit the nodes of the input tree).

2246	   The function here() is defined as follows:

2248	   Function: node-set here()

2250	   The here function returns a node-set containing the attribute or
2251	   processing instruction node or the parent element of the text node
2252	   that directly bears the XPath expression.  This expression results in
2253	   an error if the containing XPath expression does not appear in the
2254	   same XML document against which the XPath expression is being
2255	   evaluated.

2257	   As an example, consider creating an enveloped signature (a Signature
2258	   element that is a descendant of an element being signed). Although the
2259	   signed content should not be changed after signing, the elements
2260	   within the Signature element are changing (e.g. the digest value must
2261	   be put inside the DigestValue and the SignatureValue must be
2262	   subsequently calculated). One way to prevent these changes from
2263	   invalidating the digest value in DigestValue is to add an XPath
2264	   Transform that omits all Signature elements and their descendants. For
2265	   example,

2267	      <Document>
2268	      ...
2269	      <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
2270	        <SignedInfo>
2271	         ...
2272	          <Reference URI="">
2273	            <Transforms>
2274	              <Transform
2275	                Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
2276	                <XPath xmlns:dsig="&dsig;">
2277	                not(ancestor-or-self::dsig:Signature)
2278	                </XPath>
2279	              </Transform>

2281	            </Transforms>
2282	            <DigestMethod
2283	   Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
2284	            <DigestValue></DigestValue>
2285	          </Reference>
2286	        </SignedInfo>
2287	        <SignatureValue></SignatureValue>
2288	       </Signature>
2289	       ...
2290	      </Document>

2292	   Due to the null Reference URI in this example, the XPath transform
2293	   input node-set contains all nodes in the entire parse tree starting at
2294	   the root node (except the comment nodes). For each node in this
2295	   node-set, the node is included in the output node-set except if the
2296	   node or one of its ancestors has a tag of Signature that is in the
2297	   namespace given by the replacement text for the entity &dsig;.

2299	   A more elegant solution uses the here function to omit only the
2300	   Signature containing the XPath Transform, thus allowing enveloped
2301	   signatures to sign other signatures. In the example above, use the
2302	   XPath element:

2304	      <XPath xmlns:dsig="&dsig;">
2305	      count(ancestor-or-self::dsig:Signature |
2306	      here()/ancestor::dsig:Signature[1]) >
2307	      count(ancestor-or-self::dsig:Signature)</XPath>

2309	   Since the XPath equality operator converts node sets to string values
2310	   before comparison, we must instead use the XPath union operator (|).
2311	   For each node of the document, the predicate expression is true if and
2312	   only if the node-set containing the node and its Signature element
2313	   ancestors does not include the enveloped Signature element containing
2314	   the XPath expression (the union does not produce a larger set if the
2315	   enveloped Signature element is in the node-set given by
2316	   ancestor-or-self::Signature).

2318	    6.6.4 Enveloped Signature Transform

2320	   Identifier:
2321	          http://www.w3.org/2000/09/xmldsig#enveloped-signature

2323	   An enveloped signature transform T removes the whole Signature element
2324	   containing T from the digest calculation of the Reference element
2325	   containing T. The entire string of characters used by an XML processor
2326	   to match the Signature with the XML production element is removed. The
2327	   output of the transform is equivalent to the output that would result
2328	   from replacing T with an XPath transform containing the following
2329	   XPath parameter element:

2331	      <XPath xmlns:dsig="&dsig;">
2332	      count(ancestor-or-self::dsig:Signature |
2333	      here()/ancestor::dsig:Signature[1]) >
2334	      count(ancestor-or-self::dsig:Signature)</XPath>

2336	   The input and output requirements of this transform are identical to
2337	   those of the XPath transform. Note that it is not necessary to use an
2338	   XPath expression evaluator to create this transform. However, this
2339	   transform MUST produce output in exactly the same manner as the XPath
2340	   transform parameterized by the XPath expression above.

2342	    6.6.5 XSLT Transform

2344	   Identifier:
2345	          http://www.w3.org/TR/1999/REC-xslt-19991116

2347	   The normative specification for XSL Transformations is [XSLT]. The XSL
2348	   transformation is encoded within a namespace-qualified
2349	   stylesheetelement which MUST be the sole child of the Transform
2350	   element.

2352	   This transform requires an octet stream as input. If the actual input
2353	   is an XPath node-set, then the signature application should attempt to
2354	   convert it to octets (apply Canonical XML]) as described in the
2355	   Reference Processing Model (section 4.3.3.2).

2357	   The output of this transform is an octet stream. The processing rules
2358	   for the XSL style sheet or transform element are stated in the XSLT
2359	   specification [XSLT]. We RECOMMEND that XSLT transform authors use an
2360	   output method of xml for XML and HTML. As XSLT implementations do not
2361	   produce consistent serializations of their output, we further
2362	   RECOMMEND inserting a transform after the XSLT transform to
2363	   canonicalize the output. These steps will help to ensure
2364	   interoperability of the resulting signatures among applications that
2365	   support the XSLT transform. Note that if the output is actually HTML,
2366	   then the result of these steps is logically equivalent [XHTML].

2368	7.0 XML Canonicalization and Syntax Constraint Considerations

2370	   Digital signatures only work if the verification calculations are
2371	   performed on exactly the same bits as the signing calculations. If the
2372	   surface representation of the signed data can change between signing
2373	   and verification, then some way to standardize the changeable aspect
2374	   must be used before signing and verification. For example, even for
2375	   simple ASCII text there are at least three widely used line ending
2376	   sequences. If it is possible for signed text to be modified from one
2377	   line ending convention to another between the time of signing and
2378	   signature verification, then the line endings need to be canonicalized
2379	   to a standard form before signing and verification or the signatures
2380	   will break.

2382	   XML is subject to surface representation changes and to processing
2383	   which discards some surface information. For this reason, XML digital
2384	   signatures have a provision for indicating canonicalization methods in
2385	   the signature so that a verifier can use the same canonicalization as
2386	   the signer.

2388	   Throughout this specification we distinguish between the
2389	   canonicalization of a Signature element and other signed XML data
2390	   objects. It is possible for an isolated XML document to be treated as
2391	   if it were binary data so that no changes can occur. In that case, the
2392	   digest of the document will not change and it need not be
2393	   canonicalized if it is signed and verified as such. However, XML that
2394	   is read and processed using standard XML parsing and processing
2395	   techniques is frequently changed such that some of its surface
2396	   representation information is lost or modified. In particular, this
2397	   will occur in many cases for the Signature and enclosed SignedInfo
2398	   elements since they, and possibly an encompassing XML document, will
2399	   be processed as XML.

2401	   Similarly, these considerations apply to Manifest, Object, and
2402	   SignatureProperties elements if those elements have been digested,
2403	   their DigestValue is to be checked, and they are being processed as
2404	   XML.

2406	   The kinds of changes in XML that may need to be canonicalized can be
2407	   divided into three categories. There are those related to the basic
2408	   [XML], as described in 7.1 below. There are those related to [DOM],
2409	   [SAX], or similar processing as described in 7.2 below. And, third,
2410	   there is the possibility of coded character set conversion, such as
2411	   between UTF-8 and UTF-16, both of which all  [XML] compliant
2412	   processors are required to support.

2414	   Any canonicalization algorithm should yield output in a specific fixed
2415	   coded character set. Canonical XML [XML-C14N] uses UTF-8 (without a
2416	   byte order mark (BOM)) and does not provide character normalization.
2417	   We RECOMMEND that signature applications create XML content (Signature
2418	   elements and their descendents/content) in Normalization Form C [NFC,
2419	   NFC-Corrigendum] and check that any XML being consumed is in that form
2420	   as well; (if not, signatures may consequently fail to validate).
2421	   Additionally, none of these algorithms provide data type
2422	   normalization. Applications that normalize data types in varying
2423	   formats (e.g., (true, false) or (1,0)) may not be able to validate
2424	   each other's signatures.

2426	  7.1 XML 1.0, Syntax Constraints, and Canonicalization

2428	   XML 1.0 [XML] defines an interface where a conformant application
2429	   reading XML is given certain information from that XML and not other
2430	   information. In particular,
2431	    1. line endings are normalized to the single character #xA by
2432	       dropping #xD characters if they are immediately followed by a #xA
2433	       and replacing them with #xA in all other cases,
2434	    2. missing attributes declared to have default values are provided to
2435	       the application as if present with the default value,
2436	    3. character references are replaced with the corresponding
2437	       character,
2438	    4. entity references are replaced with the corresponding declared
2439	       entity,

2441	    5. attribute values are normalized by
2442	         A. replacing character and entity references as above,
2443	         B. replacing occurrences of #x9, #xA, and #xD with #x20 (space)
2444	            except that the sequence #xD#xA is replaced by a single
2445	            space, and
2446	         C. if the attribute is not declared to be CDATA, stripping all
2447	            leading and trailing spaces and replacing all interior runs
2448	            of spaces with a single space.

2450	   Note that items (2), (4), and (5C) depend on the presence of a schema,
2451	   DTD or similar declarations. The Signature element type is laxly
2452	   schema valid [XML-schema], consequently external XML or even XML
2453	   within the same document as the signature may be (only) well-formed or
2454	   from another namespace (where permitted by the signature schema); the
2455	   noted items may not be present. Thus, a signature with such content
2456	   will only be verifiable by other signature applications if the
2457	   following syntax constraints are observed when generating any signed
2458	   material including the SignedInfo element:
2459	    1. attributes having default values be explicitly present,
2460	    2. all entity references (except "amp", "lt", "gt", "apos", "quot",
2461	       and other character entities not representable in the encoding
2462	       chosen) be expanded,
2463	    3. attribute value white space be normalized

2465	  7.2 DOM/SAX Processing and Canonicalization

2467	   In addition to the canonicalization and syntax constraints discussed
2468	   above, many XML applications use the Document Object Model [DOM] or
2469	   The Simple API for XML  [SAX]. DOM maps XML into a tree structure of
2470	   nodes and typically assumes it will be used on an entire document with
2471	   subsequent processing being done on this tree. SAX converts XML into a
2472	   series of events such as a start tag, content, etc. In either case,
2473	   many surface characteristics such as the ordering of attributes and
2474	   insignificant white space within start/end tags is lost. In addition,
2475	   namespace declarations are mapped over the nodes to which they apply,
2476	   losing the namespace prefixes in the source text and, in most cases,
2477	   losing where namespace declarations appeared in the original instance.

2479	   If an XML Signature is to be produced or verified on a system using
2480	   the DOM or SAX processing, a canonical method is needed to serialize
2481	   the relevant part of a DOM tree or sequence of SAX events. XML
2482	   canonicalization specifications, such as [XML-C14N], are based only on
2483	   information which is preserved by DOM and SAX. For an XML Signature to
2484	   be verifiable by an implementation using DOM or SAX, not only must the
2485	   XML 1.0 syntax constraints given in the previous section be followed
2486	   but an appropriate XML canonicalization MUST be specified so that the
2487	   verifier can re-serialize DOM/SAX mediated input into the same octet
2488	   stream that was signed.

2490	8.0 Security Considerations

2492	   The XML Signature specification provides a very flexible digital
2493	   signature mechanism. Implementors must give consideration to their
2494	   application threat models and to the following factors.

2496	  8.1 Transforms

2498	   A requirement of this specification is to permit signatures to "apply
2499	   to a part or totality of a XML document." (See [XML-Signature-RD,
2500	   section 3.1.3].) The Transforms mechanism meets this requirement by
2501	   permitting one to sign data derived from processing the content of the
2502	   identified resource. For instance, applications that wish to sign a
2503	   form, but permit users to enter limited field data without
2504	   invalidating a previous signature on the form might use [XPath] to
2505	   exclude those portions the user needs to change. Transforms may be
2506	   arbitrarily specified and may include encoding tranforms,
2507	   canonicalization instructions or even XSLT transformations. Three
2508	   cautions are raised with respect to this feature in the following
2509	   sections.

2511	   Note, core validation behavior does not confirm that the signed data
2512	   was obtained by applying each step of the indicated transforms.
2513	   (Though it does check that the digest of the resulting content matches
2514	   that specified in the signature.)  For example, some application may
2515	   be satisfied with verifying an XML signature over a cached copy of
2516	   already transformed data. Other applications might require that
2517	   content be freshly dereferenced and transformed.

2519	    8.1.1 Only What is Signed is Secure

2521	   First, obviously, signatures over a transformed document do not secure
2522	   any information discarded by transforms: only what is signed is
2523	   secure.

2525	   Note that the use of Canonical  XML [XML-C14N] ensures that all
2526	   internal entities and XML namespaces are expanded within the content
2527	   being signed. All entities are replaced with their definitions and the
2528	   canonical form explicitly represents the namespace that an element
2529	   would otherwise inherit. Applications that do not canonicalize XML
2530	   content (especially the SignedInfo element) SHOULD NOT use internal
2531	   entities and SHOULD represent the namespace explicitly within the
2532	   content being signed since they can not rely upon canonicalization to
2533	   do this for them. Also, users concerned with the integrity of the
2534	   element type definitions associated with the XML instance being signed
2535	   may wish to sign those definitions as well (i.e,. the schema, DTD, or
2536	   natural language description associated with the
2537	   namespace/identifier).

2539	    8.1.2 Only What is "Seen" Should be Signed

2541	   Additionally, the signature secures any information introduced by the
2542	   transform: only what is "seen" (that which is represented to the user
2543	   via visual, auditory or other media) should be signed. If signing is
2544	   intended to convey the judgment or consent of a user (an automated
2545	   mechanism or person), then it is normally necessary to secure as
2546	   exactly as practical the information that was presented to that user.

2548	   Note that this can be accomplished by literally signing what was
2549	   presented, such as the screen images shown a user. However, this may
2550	   result in data which is difficult for subsequent software to
2551	   manipulate. Instead, one can sign the data along with whatever
2552	   filters, style sheets, client profile or other information that
2553	   affects its presentation.

2555	    8.1.3 "See" What is Signed

2557	   Just as a user should only sign what it "sees," persons and automated
2558	   mechanisms that trust the validity of a transformed document on the
2559	   basis of a valid signature should operate over the data that was
2560	   transformed (including canonicalization) and signed, not the original
2561	   pre-transformed data. This recommendation applies to transforms
2562	   specified within the signature as well as those included as part of
2563	   the document itself. For instance, if an XML document includes an
2564	   embedded style sheet [XSLT] it is the transformed document that should
2565	   be represented to the user and signed. To meet this recommendation
2566	   where a document references an external style sheet, the content of
2567	   that external resource should also be signed as via a signature
2568	   Reference -- otherwise the content of that external content might
2569	   change which alters the resulting document without invalidating the
2570	   signature.

2572	   Some applications might operate over the original or intermediary data
2573	   but should be extremely careful about potential weaknesses introduced
2574	   between the original and transformed data. This is a trust decision
2575	   about the character and meaning of the transforms that an application
2576	   needs to make with caution. Consider a canonicalization algorithm that
2577	   normalizes character case (lower to upper) or character composition
2578	   ('e and accent' to 'accented-e'). An adversary could introduce changes
2579	   that are normalized and consequently inconsequential to signature
2580	   validity but material to a DOM processor. For instance, by changing
2581	   the case of a character one might influence the result of an XPath
2582	   selection. A serious risk is introduced if that change is normalized
2583	   for signature validation but the processor operates over the original
2584	   data and returns a different result than intended. Consequently, while
2585	   we RECOMMEND all documents operated upon and generated by signature
2586	   applications be in [NFC, NFC-Corrigendum] (otherwise intermediate
2587	   processors might unintentionally break the signature) encoding
2588	   normalizations SHOULD NOT be done as part of a signature transform, or
2589	   (to state it another way) if normalization does occur, the application
2590	   SHOULD always "see" (operate over) the normalized form.

2592	  8.2 Check the Security Model

2594	   This specification uses public key signatures and keyed hash
2595	   authentication codes. These have substantially different security
2596	   models. Furthermore, it permits user specified algorithms which may
2597	   have other models.

2599	   With public key signatures, any number of parties can hold the public
2600	   key and verify signatures while only the parties with the private key
2601	   can create signatures. The number of holders of the private key should
2602	   be minimized and preferably be one. Confidence by verifiers in the
2603	   public key they are using and its binding to the entity or
2604	   capabilities represented by the corresponding private key is an
2605	   important issue, usually addressed by certificate or online authority
2606	   systems.

2608	   Keyed hash authentication codes, based on secret keys, are typically
2609	   much more efficient in terms of the computational effort required but
2610	   have the characteristic that all verifiers need to have possession of
2611	   the same key as the signer. Thus any verifier can forge signatures.

2613	   This specification permits user provided signature algorithms and
2614	   keying information designators. Such user provided algorithms may have
2615	   different security models. For example, methods involving biometrics
2616	   usually depend on a physical characteristic of the authorized user
2617	   that can not be changed the way public or secret keys can be and may
2618	   have other security model differences.

2620	  8.3 Algorithms, Key Lengths, Certificates, Etc.

2622	   The strength of a particular signature depends on all links in the
2623	   security chain. This includes the signature and digest algorithms
2624	   used, the strength of the key generation [RANDOM] and the size of the
2625	   key, the security of key and certificate authentication and
2626	   distribution mechanisms, certificate chain validation policy,
2627	   protection of cryptographic processing from hostile observation and
2628	   tampering, etc.

2630	   Care must be exercised by applications in executing the various
2631	   algorithms that may be specified in an XML signature and in the
2632	   processing of any "executable content" that might be provided to such
2633	   algorithms as parameters, such as XSLT transforms. The algorithms
2634	   specified in this document will usually be implemented via a trusted
2635	   library but even there perverse parameters might cause unacceptable
2636	   processing or memory demand. Even more care may be warranted with
2637	   application defined algorithms.

2639	   The security of an overall system will also depend on the security and
2640	   integrity of its operating procedures, its personnel, and on the
2641	   administrative enforcement of those procedures. All the factors listed
2642	   in this section are important to the overall security of a system;
2643	   however, most are beyond the scope of this specification.

2645	9.0 Schema, DTD, Data Model, and Valid Examples

2647	   XML Signature Schema Instance
2648	          xmldsig-core-schema.xsd
2649	          Valid XML schema instance based on the 20001024 Schema/DTD
2650	          [XML-Schema].

2652	   XML Signature DTD
2653	          xmldsig-core-schema.dtd

2655	   RDF Data Model
2656	          xmldsig-datamodel-20000112.gif

2658	   XML Signature Object Example
2659	          signature-example.xml
2660	          A cryptographical fabricated XML example that includes foreign
2661	          content and validates under the schema, it also uses
2662	          schemaLocation to aid automated schema fetching and validation.

2664	   RSA XML Signature Example
2665	          signature-example-rsa.xml
2666	          An XML Signature example with generated cryptographic values by
2667	          Merlin Hughes and validated by Gregor Karlinger.

2669	   DSA XML Signature Example
2670	          signature-example-dsa.xml
2671	          Similar to above but uses DSA.

2673	10.0 Definitions

2675	   Authentication Code
2676	          A value generated from the application of a shared key to a
2677	          message via a cryptographic algorithm such that it has the
2678	          properties of message authentication (integrity) but not signer
2679	          authentication

2681	   Authentication, Message
2682	          "A signature should identify what is signed, making it
2683	          impracticable to falsify or alter either the signed matter or
2684	          the signature without detection." [Digital Signature
2685	          Guidelines, ABA]

2687	   Authentication, Signer
2688	          "A signature should indicate who signed a document, message or
2689	          record, and should be difficult for another person to produce
2690	          without authorization." [Digital Signature Guidelines, ABA]

2692	   Core
2693	          The syntax and processing defined by this specification,
2694	          including core validation. We use this term to distinguish
2695	          other markup, processing, and applications semantics from our
2696	          own.

2698	   Data Object (Content/Document)
2699	          The actual binary/octet data being operated on (transformed,
2700	          digested, or signed) by an application -- frequently an HTTP
2701	          entity [HTTP]. Note that the proper noun Object designates a
2702	          specific XML element. Occasionally we refer to a data object as
2703	          a document or as a resource's content. The term element content
2704	          is used to describe the data between XML start and end tags
2705	          [XML]. The term XML document is used to describe data objects
2706	          which conform to the XML specification [XML].

2708	   Integrity
2709	          The inability to change a message without also changing the
2710	          signature value. See message authentication.

2712	   Object
2713	          An XML Signature element wherein arbitrary (non-core) data may
2714	          be placed. An Object element is merely one type of digital data
2715	          (or document) that can be signed via a Reference.

2717	   Resource
2718	          "A resource can be anything that has identity. Familiar
2719	          examples include an electronic document, an image, a service
2720	          (e.g., 'today's weather report for Los Angeles'), and a
2721	          collection of other resources.... The resource is the
2722	          conceptual mapping to an entity or set of entities, not
2723	          necessarily the entity which corresponds to that mapping at any
2724	          particular instance in time. Thus, a resource can remain
2725	          constant even when its content---the entities to which it
2726	          currently corresponds---changes over time, provided that the
2727	          conceptual mapping is not changed in the process." [URI] In
2728	          order to avoid a collision of the term entity within the URI
2729	          and XML specifications, we use the term data object, content or
2730	          document to refer to the actual bits being operated upon.

2732	   Signature
2733	          Formally speaking, a value generated from the application of a
2734	          private key to a message via a cryptographic algorithm such
2735	          that it has the properties of signer authentication and
2736	          message authentication (integrity). (However, we sometimes use
2737	          the term signature generically such that it encompasses
2738	          Authentication Code values as well, but we are careful to make
2739	          the distinction when the property of signer authentication is
2740	          relevant to the exposition.) A signature may be
2741	          (non-exclusively) described as detached, enveloping, or
2742	          enveloped.

2744	   Signature, Application
2745	          An application that implements the MANDATORY (REQUIRED/MUST)
2746	          portions of this specification; these conformance requirements
2747	          are over the structure of the Signature element type and its
2748	          children (including SignatureValue) and mandatory to support
2749	          algorithms.

2751	   Signature, Detached
2752	          The signature is over content external to the Signature
2753	          element, and can be identified via a URI or transform.
2754	          Consequently, the signature is "detached" from the content it
2755	          signs. This definition typically applies to separate data
2756	          objects, but it also includes the instance where the Signature
2757	          and data object reside within the same XML document but are
2758	          sibling elements.

2760	   Signature, Enveloping
2761	          The signature is over content found within an Object element of
2762	          the signature itself. The Object (or its content) is identified
2763	          via a Reference (via a URI fragment identifier or transform).

2765	   Signature, Enveloped
2766	          The signature is over the XML content that contains the
2767	          signature as an element. The content provides the root XML
2768	          document element. Obviously, enveloped signatures must take
2769	          care not to include their own value in the calculation of the
2770	          SignatureValue.

2772	   Transform
2773	          The processing of a octet stream from source content to derived
2774	          content. Typical transforms include XML Canonicalization,
2775	          XPath, and XSLT.

2777	   Validation, Core
2778	          The core processing requirements of this specification
2779	          requiring signature validation and SignedInfo reference
2780	          validation.

2782	   Validation, Reference
2783	          The hash value of the identified and transformed content,
2784	          specified by Reference, matches its specified DigestValue.

2786	   Validation, Signature
2787	          The SignatureValue matches the result of processing SignedInfo
2788	          with  CanonicalizationMethod and SignatureMethod as specified
2789	          in Core Validation (section 3.2).

2791	   Validation, Trust/Application
2792	          The application determines that the semantics associated with a
2793	          signature are valid. For example, an application may validate
2794	          the time stamps or the integrity of the signer key -- though
2795	          this behavior is external to this core specification.

2797	11.0 References

2799	   ABA
2800	          Digital Signature Guidelines.
2801	          http://www.abanet.org/scitech/ec/isc/dsgfree.html

2803	   Bourret
2804	          Declaring Elements and Attributes in an XML DTD. Ron Bourret.
2805	          http://www.rpbourret.com/xml/xmldtd.htm

2807	   DOM
2808	          Document Object Model (DOM) Level 1 Specification. W3C
2809	          Recommendation. V. Apparao, S. Byrne, M. Champion, S. Isaacs,
2810	          I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson,
2811	          L. Wood. October 1998.
2812	          http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/

2814	   DSS
2815	          FIPS PUB 186-1. Digital Signature Standard (DSS). U.S.
2816	          Department of Commerce/National Institute of Standards and
2817	          Technology.
2818	          http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf

2820	   HMAC
2821	          RFC 2104. HMAC: Keyed-Hashing for Message Authentication. H.
2822	          Krawczyk, M. Bellare, R. Canetti. February 1997.
2823	          http://www.ietf.org/rfc/rfc2104.txt

2825	   HTTP
2826	          RFC 2616. Hypertext Transfer Protocol -- HTTP/1.1. J. Gettys,
2827	          J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee.
2828	          June 1999.
2829	          http://www.ietf.org/rfc/rfc2616.txt

2831	   KEYWORDS
2832	          RFC 2119 Key words for use in RFCs to Indicate Requirement
2833	          Levels. S. Bradner. March 1997.
2834	          http://www.ietf.org/rfc/rfc2119.txt

2836	   LDAP-DN
2837	          RFC 2253. Lightweight Directory Access Protocol (v3): UTF-8
2838	          String Representation of Distinguished Names. M. Wahl, S.
2839	          Kille, T. Howes. December 1997.
2840	          http://www.ietf.org/rfc/rfc2253.txt

2842	   MD5
2843	          RFC 1321. The MD5 Message-Digest Algorithm. R. Rivest. April
2844	          1992.
2845	          http://www.ietf.org/rfc/rfc1321.txt

2847	   MIME
2848	          RFC 2045. Multipurpose Internet Mail Extensions (MIME) Part
2849	          One: Format of Internet Message Bodies. N. Freed & N.
2850	          Borenstein. November 1996.
2851	          http://www.ietf.org/rfc/rfc2045.txt

2853	   NFC
2854	          TR15, Unicode Normalization Forms. M. Davis, M. D�rst. Revision
2855	          18: November 1999.
2856	          http://www.unicode.org/unicode/reports/tr15/tr15-18.html.

2858	   NFC-Corrigendum
2859	          Normalization Corrigendum. The Unicode Consortium.
2860	          http://www.unicode.org/unicode/uni2errata/Normalization_Corrige
2861	          ndum.html.

2863	   PGP
2864	          RFC 2440 OpenPGP Message Format. J. Callas, L. Donnerhacke, H.
2865	          Finney, R. Thayer. November 1998.

2867	          http://www.ietf.org/rfc/rfc2440.txt

2869	   RANDOM
2870	          RFC 1750 Randomness Recommendations for Security. D. Eastlake,
2871	          S. Crocker, J. Schiller. December 1994.
2872	          http://www.ietf.org/rfc/rfc1750.txt

2874	   RDF
2875	          RDF Schema W3C Candidate Recommendation. D. Brickley, R.V.
2876	          Guha. March 2000.
2877	          http://www.w3.org/TR/2000/CR-rdf-schema-20000327/
2878	          RDF Model and Syntax W3C Recommendation. O. Lassila, R. Swick.
2879	          February 1999.
2880	          http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/

2882	   1363
2883	          IEEE 1363: Standard Specifications for Public Key Cryptography.
2884	          August 2000.

2886	   PKCS1
2887	          RFC 2437. PKCS #1: RSA Cryptography Specifications Version 2.0.
2888	          B. Kaliski, J. Staddon. October 1998.
2889	          http://www.ietf.org/rfc/rfc2437.txt

2891	   SAX
2892	          SAX: The Simple API for XML David Megginson et al. May 1998.
2893	          http://www.megginson.com/SAX/index.html

2895	   SHA-1
2896	          FIPS PUB 180-1. Secure Hash Standard. U.S. Department of
2897	          Commerce/National Institute of Standards and Technology.
2898	          http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt

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

2904	   UTF-16
2905	          RFC 2781. UTF-16, an encoding of ISO 10646. P. Hoffman , F.
2906	          Yergeau. February 2000.
2907	          http://www.ietf.org/rfc/rfc2781.txt

2909	   UTF-8
2910	          RFC 2279. UTF-8, a transformation format of ISO 10646. F.
2911	          Yergeau. January 1998.
2912	          http://www.ietf.org/rfc/rfc2279.txt

2914	   URI
2915	          RFC 2396. Uniform Resource Identifiers (URI): Generic Syntax.
2916	          T. Berners-Lee, R. Fielding, L. Masinter. August 1998.
2917	          http://www.ietf.org/rfc/rfc2396.txt

2919	   URI-Literal
2920	          RFC 2732. Format for Literal IPv6 Addresses in URL's. R.
2921	          Hinden, B. Carpenter, L. Masinter. December 1999.
2922	          http://www.ietf.org/rfc/rfc2732.txt

2924	   URL
2925	          RFC 1738. Uniform Resource Locators (URL). Berners-Lee, T.,
2926	          Masinter, L., and M. McCahill. December 1994.
2927	          http://www.ietf.org/rfc/rfc1738.txt

2929	   URN
2930	          RFC 2141. URN Syntax. R. Moats. May 1997.
2931	          http://www.ietf.org/rfc/rfc2141.txt
2932	          RFC 2611. URN Namespace Definition Mechanisms. L. Daigle, D.
2933	          van Gulik, R. Iannella, P. Falstrom. June 1999.
2934	          http://www.ietf.org/rfc/rfc2611.txt

2936	   X509v3
2937	          ITU-T Recommendation X.509 version 3 (1997). "Information
2938	          Technology - Open Systems Interconnection - The Directory
2939	          Authentication Framework"  ISO/IEC 9594-8:1997.

2941	   XHTML 1.0
2942	          XHTML(tm) 1.0: The Extensible Hypertext Markup Language W3C
2943	          Recommendation. S. Pemberton, D. Raggett, et al. January 2000.
2944	          http://www.w3.org/TR/2000/REC-xhtml1-20000126/

2946	   XLink
2947	          XML Linking Language. W3C Proposed Recommendation. S. DeRose,
2948	          E. Maler, D. Orchard  December 2000.
2949	          http://www.w3.org/TR/2000/PR-xlink-20001220/

2951	   XML
2952	          Extensible Markup Language (XML) 1.0. W3C Recommendation. T.
2953	          Bray, J. Paoli, C. M. Sperberg-McQueen. February 1998.
2954	          http://www.w3.org/TR/1998/REC-xml-19980210

2956	   XML-C14N
2957	          Canonical XML. W3C Recommendation. J. Boyer. March 2001.
2958	          http://www.w3.org/TR/2001/REC-xml-c14n-20010315
2959	          http://www.ietf.org/rfc/rfc3076.txt

2961	   XML-Japanese
2962	          XML Japanese Profile. W3C Note. M. MURATA April 2000
2963	          http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/

2965	   XML-MT
2966	          RFC 2376. XML Media Types. E. Whitehead, M. Murata. July 1998.
2967	          http://www.ietf.org/rfc/rfc2376.txt

2969	   XML-ns
2970	          Namespaces in XML W3C Recommendation. T. Bray, D. Hollander, A.
2971	          Layman. Janaury 1999.
2972	          http://www.w3.org/TR/1999/REC-xml-names-19990114

2974	   XML-schema
2975	          XML Schema Part 1: Structures W3C Proposed Recommendation. D.
2976	          Beech, M. Maloney, N. Mendelsohn, H. Thompson. October 2000.
2977	          http://www.w3.org/TR/2001/PR-xmlschema-1-20010316/
2978	          XML Schema Part 2: Datatypes W3C Proposed Recommendation. P.
2979	          Biron, A. Malhotra. September 2000.
2980	          http://www.w3.org/TR/2001/PR-xmlschema-1-20010316/

2982	   XML-Signature-RD
2983	          RFC 2807. XML Signature Requirements. W3C Working Draft. J.
2984	          Reagle, April 2000.
2985	          http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014
2986	          http://www.ietf.org/rfc/rfc2807.txt

2988	   XPath
2989	          XML Path Language (XPath) Version 1.0. W3C Recommendation. J.
2990	          Clark, S. DeRose. October 1999.
2991	          http://www.w3.org/TR/1999/REC-xpath-19991116

2993	   XPointer
2994	          XML Pointer Language (XPointer). W3C Working Draft. S. DeRose,
2995	          R. Daniel, E. Maler.
2996	          http://www.w3.org/TR/2001/WD-xptr-20010108

2998	   XSL
2999	          Extensible Stylesheet Language (XSL) W3C Candidate
3000	          Recommendation. S. Adler, A. Berglund, J. Caruso, S. Deach, P.
3001	          Grosso, E. Gutentag, A. Milowski, S. Parnell, J. Richman, S.
3002	          Zilles. October 2000.
3003	          http://www.w3.org/TR/2000/CR-xsl-20001121/

3005	   XSLT
3006	          XSL Transforms (XSLT) Version 1.0. W3C Recommendation. J.
3007	          Clark. November 1999.
3008	          http://www.w3.org/TR/1999/REC-xslt-19991116.html

3010	12. Authors' Address

3012	   Donald E. Eastlake 3rd
3013	   Motorola, 20 Forbes Boulevard
3014	   Mansfield, MA 02048 USA
3015	   Phone: 1-508-261-5434
3016	   Email: Donald.Eastlake@motorola.com

3018	   Joseph M. Reagle Jr., W3C
3019	   Massachusetts Institute of Technology
3020	   Laboratory for Computer Science
3021	   NE43-350, 545 Technology Square
3022	   Cambridge, MA 02139
3023	   Phone: 1.617.258.7621
3024	   Email: reagle@w3.org
3025	   David Solo
3026	   Citigroup
3027	   909 Third Ave, 16th Floor
3028	   NY, NY 10043 USA
3029	   Phone +1-212-559-2900
3030	   Email: dsolo@alum.mit.edu