idnits 2.17.1 draft-ietf-xmldsig-signature-00.txt: 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 53 longer pages, the longest (page 3) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 54 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** 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. RFC 2119 keyword, line 1082: '... the current DTD MUST be able to recog...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 779 has weird spacing: '... during valid...' == Line 780 has weird spacing: '...ficates cachi...' == Line 784 has weird spacing: '...encoded depen...' == Line 787 has weird spacing: '... of the digit...' == Line 788 has weird spacing: '...of this locat...' == (1 more instance...) -- 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.) -- The document date (June 1999) is 9079 days in the past. Is this intentional? 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? 'RFC 2141' on line 643 looks like a reference -- Missing reference section? 'XLink' on line 1007 looks like a reference -- Missing reference section? 'RFC 2396' on line 1199 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XMLDSIG Working Group Richard D. Brown 2 GlobeSet, Inc. 3 Expires December 1999 June 1999 5 Digital Signatures for XML 6 ------- ---------- --- --- 8 Richard D. Brown 9 GlobeSet, Inc. 11 Document Status 13 This document, file name is 14 intended to become a Proposed Standard RFC. Distribution of this 15 document is unlimited. Comments should be sent to the XMLDSIG 16 mailing list or to the author. Additional information can be found 17 on the web sites maintained by the working group. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 This specification defines syntax and procedures for the computation, 40 verification, and encoding of digital signatures using XML. In 41 addition, it proposes a solution to authenticating Web resources by 42 means of XML. 44 Revision History 46 18-June-99: 47 Remove Comments and Suggestions chapter, 48 Change Mailing List Reference 49 Add Contacts Section 50 04-April-99: 51 Fix numerous typos, 52 Complete the algorithm chapters, 53 Add a Comments and Suggestions chapter, 54 Insert the DTD definition, 55 Add a Resources element -- CS #99122601 56 13-October-98: 57 Revision to reflect 1998-09-16 XML Namespaces proposal 58 16-June-98: 59 Initial Draft 61 Contacts 63 Chair(s): 64 Donald Eastlake 3rd 65 Joseph Reagle Jr. 67 Author: 68 Richard D. Brown 70 Mailing List: 71 Discussion: w3c-ietf-xmldsig@w3.org 72 Archive: http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig 73 Subscription: w3c-ietf-xmldsig-request@w3.org 74 specify (un)subscribe in SUBJECT line with an empty body. 76 Web Sites: 77 IETF: http://www.ietf.org/html.charters/xmldsig-charter.html 78 W3C: http://www.w3.org/Signature 80 Table of Contents 82 Document Status............................................1 83 Abstract .................................................1 84 Revision History ..........................................2 85 Contacts...................................................2 87 Table of Contents..........................................3 89 1. Introduction............................................5 90 2. Objective and Requirements..............................5 91 3. Signature Basics........................................6 92 3.1 Signature Element......................................6 93 3.2 Resources Element......................................7 94 3.3 Other Attributes Element...............................7 95 3.4 Originator and Recipient Information Elements..........8 96 3.5 Key Agreement Algorithm Element........................9 97 3.6 Signature Algorithm Element............................9 98 4. Signature Principles....................................9 99 4.1 Enabling Signature in XML Applications.................9 100 4.2 Encapsulating Arbitrary Contents......................10 101 4.3 Implementing Endorsement..............................11 102 4.4 Supporting Composite Documents........................11 103 4.5 Facilitating One-pass Processing......................13 104 5. Syntax Comments........................................14 105 5.1 Namespace Attributes..................................14 106 5.2 dsig:eval Global Attribute............................14 107 5.3 Uniform Resource Names................................15 108 5.4 Basic Data Types......................................16 109 5.5 Algorithm Definitions.................................16 110 6. Detailed Signature Syntax..............................17 111 6.1 Algorithm.............................................17 112 6.2 Attribute.............................................18 113 6.3 Attributes............................................18 114 6.4 Certificate...........................................19 115 6.5 Certificates..........................................20 116 6.6 ContentInfo...........................................20 117 6.7 Date..................................................21 118 6.8 Digest................................................21 119 6.9 DigestAlgorithms......................................22 120 6.10 Identifier...........................................22 121 6.11 Integer..............................................23 122 6.12 IssuerAndSerialNumber................................23 123 6.13 KeyAgreementAlgorithm................................24 124 6.14 Keyword..............................................24 125 6.15 Locator..............................................25 126 6.16 Manifest.............................................25 127 6.17 OriginatorInfo.......................................26 128 6.18 Package..............................................27 129 6.19 Parameter............................................27 130 6.20 Real.................................................28 131 6.21 RecipientInfo........................................29 132 6.22 Resource.............................................29 133 6.23 Resources............................................30 134 6.24 Signature............................................30 135 6.25 SignatureAlgorithm...................................31 136 6.26 Signatures...........................................31 137 6.27 Value................................................32 138 7. Default Document Element...............................32 139 8. Standard Attributes....................................34 140 8.1 Signing-time Attribute................................34 141 9. Digest Algorithms......................................34 142 9.1 SHA1..................................................35 143 9.2 DOM-HASH..............................................35 144 9.3 XHASH.................................................36 145 10. Key Agreement Algorithms..............................37 146 10.1 PKCS12-PBE...........................................38 147 11. Key Exchange Algorithms...............................39 148 11.2 Diffie Hellman.......................................39 149 12. Signature Algorithms..................................39 150 12.1 HMAC.................................................39 151 12.2 DSA..................................................41 152 12.3 RSA-Encryption.......................................42 153 12.4 ECDSA................................................43 154 13. References............................................43 155 14. Signature DTD.........................................44 156 15. Embedded Content Example..............................49 157 16. Detached Signature Example............................51 158 17. Domain-specific Example...............................52 160 1. Introduction 162 XML, the Extensible Markup Language [x], is a syntactical standard 163 elaborated by the World Wide Web Consortium. Subset of an 164 international text-processing standard known as SGML (Standard 165 Generalized Markup Language), XML is intended primarily for 166 structuring data exchanged and served over the World Wide Web. 168 Structuring information permits data to be easily read, exchanged, 169 and acted upon by software agents. It is a first step toward the 170 production of a Web of machine-readable semantics. But, the 171 usefulness of such structured information is limited if its 172 authenticity and trustworthiness cannot be verified. The Web cannot 173 suffice with XML - it needs Signed-XML. 175 2. Objective and Requirements 177 The objective of this specification is to define syntax and 178 procedures for the computation, verification, and encoding of digital 179 signatures using XML. It proposes a solution to authenticating Web 180 resources by means of XML. 182 This specification has been established in light of the requirements 183 that have been gathered while reviewing diverse projects and 184 alternative proposals such as IOTP [x], BIPS [x], SDML [x], FSML [x] 185 and XMLDSIG [x]. Previous experiences with binary cryptographic 186 syntaxes such as PKCS#7 [x] and CMS [x] have also played an 187 important role in this specification. 189 The redaction of this specification has been driven by the following 190 requirements: 192 - The solution shall provide a means for building authentication 193 into XML applications, but shall also propose an XML 194 alternative to binary signature syntax for signing arbitrary 195 contents. 197 - The solution shall provide for digital signature and message 198 authentication codes, considering symmetric and asymmetric 199 authentication schemes as well as dynamic establishment of 200 keying material. 202 - The solution shall provide for certificate-based and account-based 203 authentication schemes. 205 - The solution shall provide a mechanism that eases the production 206 of composite documents that consist of the combination by addition 207 or deletion of authenticated blocks of information, while 208 preserving verifiability of the origin and authenticity of 209 these blocks of information. 211 - The solution shall enable authentication of part or totality of a 212 Web document. 214 - The solution shall enable authentication of internal and external 215 resources. 217 - The solution shall provide for extended signature functionality 218 such as co-signature, endorsement, plurality of recipients, etc. 220 3. Signature Basics 222 3.1 Signature Element 224 This specification consists primarily of the definition of an XML 225 element known as the Signature element. This element is comprised of 226 two sub elements. The first one is a set of authenticated attributes, 227 known as the signature Manifest, which comprises such things as a 228 unique reference to the resources being authenticated and an 229 indication of the keying material and algorithms being used. The 230 second sub-element consists of the digital signature value. 232 233 234 (resources information block) 235 (other attributes) 236 (originator information block) 237 (recipient information block) 238 (key agreement algorithm information block) 239 (signature algorithm information block) 240 241 242 (encoded signature value) 243 244 246 The digital signature is not computed directly from the pieces of 247 information to be authenticated. Instead, the digital signature is 248 computed from a set of authenticated attributes (the Manifest), which 249 includes a reference to, and a digest of, these pieces of 250 information. The authentication is therefore 'indirect'. 252 3.2 Resources Element 254 The Resources element consists of a collection of Resource elements 255 that, in turn, consist of a unique and unambiguous reference to a 256 resource being authenticated. Each Resource element is constructed of 257 a locator, a fingerprint, and optionally a content-type qualifier. 259 260 261 262 263 264 (digest information block) 265 266 267 268 ... 269 270 272 The resource locator is implemented as a simple XML Link [x]. This 273 not only provides a unique addressing scheme for internal and 274 external resources, but also facilitates authentication of composite 275 documents. 277 3.3 Other Attributes Element 279 The Attributes element consists of a collection of Attribute elements 280 that enable attachment and authentication of specific pieces of 281 information that relate to a given signature. An Attribute element is 282 constructed of a type, a criticality, and a value. 284 285 286 287 288 289 (ANY attribute value) 290 291 293 The attribute value consists of ANY content that is defined in the 294 application DTD. Nevertheless, to facilitate the adoption of 295 'standard' attributes, the Signature DTD provides for common types 296 such as 'signing time.' 298 3.4 Originator and Recipient Information Elements 300 The purpose of the Originator and Recipient information elements 301 consists of providing identification and keying material for these 302 respective parties. 304 305 (identification information block) 306 (keying material information block) 307 309 310 (identification information block) 311 (keying material information block) 312 314 The actual content of these two elements depends on the 315 authentication scheme being used and the existence or non-existence 316 of a prior relationship between the parties. In some circumstances, 317 it may be quite difficult to distinguish between identification and 318 keying material information. A unique reference to a digital 319 certificate provides for both. This may also stand true for an 320 account number when a prior relationship exists between the parties. 322 The Originator information element is mandatory. Depending on the 323 existence or non-existence of a prior relationship with the 324 recipient, this block either refers to a public credential such as a 325 digital certificate or displays a unique identifier known by the 326 recipient. 328 The Recipient information element may be used when a document 329 contains multiple signature information blocks, each being intended 330 for a particular recipient. A unique reference in the Recipient 331 information block helps the recipients identify their respective 332 Signature information block. 334 The Recipient information element may also be used when determination 335 of the authentication key consists of a combination of keying 336 material provided by both parties. This would be the case, for 337 example, when establishing a key by means of Diffie Hellman [x ] Key 338 Exchange algorithm. 340 3.5 Key Agreement Algorithm Element 342 The Key Agreement Algorithm element is an optional element that could 343 be used to indicate the algorithm to be used for deriving a one-time 344 session key from a master key. Usage of one-time session key prevents 345 some kinds of attack that require a large volume of cipher-text to be 346 produced by a given key. 348 349 (algorithm information block) 350 352 3.6 Signature Algorithm Element 354 The Signature Algorithm element indicates the algorithm to be used 355 for computation of the signature value. 357 358 (algorithm information block) 359 361 In consideration of the requirements stated previously, this document 362 uses the terminology of 'signature' for qualifying indifferently 363 signature and authentication schemes. Therefore, the signature 364 algorithm mentioned above might refer to a signature algorithm such 365 as DSS or to a message authentication code (MAC) such as HMAC. 367 4. Signature Principles 369 4.1 Enabling Signature in XML Applications 371 As mentioned previously, this specification provides among others a 372 means for building authentication into XML applications. The 373 mechanism adopted herein considers the 'XML Namespaces' specification 374 [x], which defines the requirements for combining multiple DTDs or 375 parts of individual DTD into a single document 377 According to this specification, an XML application can build digital 378 signature support by referring explicitly to the elements defined in 379 the Signature DTD. This is accomplished by associating a namespace 380 prefix to the Signature DTD and qualifying Signature element names by 381 means of this prefix. 383 Association of a namespace prefix to a DTD shall be done by means of 384 a xmlns attribute, which could appear in any element that either 385 refers to or contains sub-elements that refer to elements of the DTD 386 considered. A qualified name consists of a namespace prefix, a colon, 387 and a name. 389 391 392 ... 393 395 396 397 398 399 400 401 402 ... 403 404 405 ... 406 407 409 411 4.2 Encapsulating Arbitrary Contents 413 To facilitate encapsulation of arbitrary contents into an XML 414 document, the Signature DTD defines a Package element. Quite similar 415 to a MIME wrapper, this element provides for such things as content 416 type and content encoding. 418 419 420 421 (safe content) 422 423 425 4.3 Implementing Endorsement 427 Endorsement consists of signing another signature. To facilitate 428 endorsement, the definition of the Signature element provides for an 429 element identifier attribute, which can be used to target a Signature 430 element from a Resource element. 432 433 434 435 436 437 ... 438 439 440 ... 441 442 ... 443 445 446 447 448 449 450 ... 451 452 453 ... 454 455 ... 456 458 4.4 Supporting Composite Documents 460 Some protocols consist of the exchange of documents that result from 461 the combination by addition or deletion of common information blocks. 462 The current proposal shall preserve verifiability of the origin and 463 authenticity of these blocks of information as they are exchanged 464 between parties 466 To facilitate authentication of such composite documents, this 467 specification has adopted an 'indirect' authentication scheme - the 468 signature is applied to unambiguous references to the resources being 469 authenticated instead of their contents. Signature verification does 470 not require the actual contents of the resources. 472 This indirect scheme can be further extended when multiple signatures 473 must be produced for a large number of resources -- repeating the 474 resource elements in multiple signature Manifests might not be 475 optimal. In such circumstances, the application DTD can leverage the 476 Resources element to share the resource definitions between multiple 477 signature elements. 479 480 481 ... 482 483 484 ... 485 486 ... 487 489 490 491 492 493 494 ... 495 496 497 ... 498 499 ... 500 502 503 504 505 506 507 ... 508 509 510 ... 511 512 ... 513 515 The adoption of simple XML links as resource locators makes possible 516 the authentication of composite documents. If IDREFs were used 517 instead, it would have been impossible to ensure validity of partial 518 documents - some IDREFs could have been left referencing non- 519 embedded IDs. 521 4.5 Facilitating One-pass Processing 523 Without further definitions, it would be impossible to determine 524 which blocks of information require authentication and which 525 algorithms need to be employed before interpretation of the Resource 526 elements. These elements being generally located at the end of the 527 document, this restriction would prevent computation of the digests 528 during acquisition of the blocks of information. 530 To facilitate one-pass processing, the current specification uses 531 another functionality offered by the namespaces proposal. This 532 functionality provides for the definition of global attributes that 533 may be used and recognized across multiple elements. This document 534 specifies the dsig:eval global attribute, which could be used for 535 identifying the blocks of information to be authenticated 537 The dsig:eval attribute shall refer to an Algorithm element or list 538 of Algorithm elements that identify the algorithms and parameters to 539 be used for computation of the digest of the element being 540 authenticated. To comply with the requirements of one-pass 541 processing, the Algorithm element should be declared before making 542 use of the dsig:eval attribute. 544 545 546 547 549 551 ... 552 554 555 556 557 558 559 560 561 562 ANBbdshh456wh5== 563 564 565 566 ... 567 568 ... 569 570 When encountering the dsig:eval global attribute on an element, the 571 XML parser is immediately aware of the requirement of computing the 572 digest or digests of this element. All the pieces of information 573 necessary for such computation are provided by the Algorithm element 574 or elements referenced by the attribute. 576 The dsig:eval attribute is purely declarative. Discrepancies between 577 the dsig:eval attribute and the digest algorithm definition in the 578 Resource element shall not invalidate the signature. At the most, 579 such discrepancies will result in a verification failure if the 580 signature-agent cannot memorize nor rewind its input stream. 582 5. Syntax Comments 584 5.1 Namespace Attributes 586 All the elements defined by the Signature DTD are explicitly bound to 587 the XMLDSIG namespace by means of a dsig prefix. In order to make 588 sure that every element could be individually imported by other XML 589 applications, the element definitions given hereinafter 590 systematically declare a fixed xmlns:dsig attribute. 592 594 599 Recall that many XML applications, presumably including namespaces 600 sensitive ones, fail to require validating processors. For correct 601 operations with such applications, namespaces declarations must be 602 also provided either directly or via default attributes declared in 603 the internal subset of the DTD. 605 5.2 dsig:eval Global Attribute 607 As mentioned previously, this specification defines a dsig:eval 608 global attribute that could be used for identifying a block of 609 information to be authenticated. This attribute shall refer to an 610 Algorithm element or elements, which should be declared before making 611 use of the attribute. 613 The XML Namespaces specifications do not explicitly provide for 614 declaration of global attributes. Distinguishing between global 615 attributes and element attributes exists only in the prose 616 description of such attributes. An essential property of global 617 attributes consists nonetheless of the uniqueness of their name that 618 is independent of the elements where they are defined. 620 The definition of elements that could be subject to authentication 621 may define the dsig:eval attribute as follows: 623 625 629 Recall that the namespace prefix that is bound to the XMLDSIG 630 namespace shall be defined before being employed. However, such 631 definition may occur in the element that defines the dsig:eval 632 attribute. 634 The reader shall notice that the terminology 'dsig:eval' is 635 inappropriate and used solely for illustrative purposes. This simply 636 means that the name of this attribute is eval and it belongs to the 637 XMLDSIG namespace (whatever prefix is used). 639 5.3 Uniform Resource Names 641 To prevent potential name conflicts in the definition of the numerous 642 type qualifiers considered herein, this specification uses Uniform 643 Resource Names [RFC 2141]. Nonetheless, this specification leverages 644 established standards such as MIME types by providing unambiguous 645 mapping conventions. 647 A complete list of proposed URNs is given in appendix. This list is 648 temporary and will be submitted for approval to the authors or 649 promoters of the algorithms and data types referenced by these URNs. 651 5.4 Basic Data Types 653 To facilitate the adoption of common procedures for the encoding of 654 attribute and parameter values, this specification defines a series 655 of elements not directly mandated by the Signature DTD. These 656 definitions propose a common approach to encoding basic data types 657 such as Integer, Float, Date, etc... It is expected that these 658 definitions will be reconsidered, as the results of other W3C 659 Activities in this area (i.e. XML-Data) will be adopted. 661 5.5 Algorithm Definitions 663 This specification adopts a unique Algorithm data type. Though 664 noticeably different from its ASN1 counterpart, this data type serves 665 a similar purpose and provides for the definition of algorithm 666 specific parameters. 668 The most noticeable difference with ASN1 consists of the assimilation 669 of sub algorithms as parameters of the primary algorithm. In other 670 words, where ASN1 recognizes an algorithm of the type AlgxWithAlgy 671 (i.e. DsaWithSha1) the current specifications recognize Algx with an 672 Algy parameter. 674 This recursive construct is expected to be more versatile and shall 675 provide a solution applicable to the definition of algorithms in 676 general. However, this definition does not preclude the adoption of 677 shortcuts such as the ones proposed by ASN1. It does not preclude 678 either the adoption of default parameter values. 680 6. Detailed Signature Syntax 682 6.1 Algorithm 684 The Algorithm element consists of a basic data type that uniquely 685 identifies a given algorithm and indicates the parameter values to be 686 used during computation. The construct is recursive and allows a 687 parameter value to refer to another Algorithm element. 689 691 697 Content Description 699 Parameter: The contents of an Algorithm element consists of an 700 optional collection of Parameter elements, which are specified 701 on a per algorithm basis. 703 Attributes Description 705 id: Element identifier that could be used for referencing this 706 element (from a dsig:eval global attribute for example). 708 type: The type of the algorithm expressed as a Uniform Resource 709 name. 711 6.2 Attribute 713 The Attribute element consists of a complementary piece of 714 information, which shall be included in the authenticated part of the 715 document. Though this specification defines standard attributes, this 716 element has been defined primarily for enabling some level of 717 customization in the signature element. An Attribute element consists 718 of a value, a type, and a criticality. 720 722 728 Content Description 730 ANY: The actual value of an attribute depends solely upon its 731 type. 733 Attributes Description 735 type: Type of the attribute expressed as a Uniform Resource Name. 737 critical: Boolean value that indicates if the attribute is 738 critical (true) or not (false). A recipient shall reject a 739 signature that contains a critical attribute that he does not 740 recognize. However, an unrecognized non-critical attribute may 741 be ignored. 743 6.3 Attributes 745 The Attributes element consists of a collection of complementary 746 attributes, which shall be included in the authenticated part of the 747 document. 749 751 755 Content Description 757 Attribute: Collection of Attribute elements. 759 6.4 Certificate 761 The Certificate element may be used for either providing the value of 762 a digital certificate or specifying a location from where it may be 763 retrieved. 765 770 775 Content Description 777 IssuerAndSerialNumber: Unique identifier of this certificate.This 778 element has been made mandatory is order to prevent unnecessary 779 decoding during validation of a certificate chain. This 780 feature also helps certificates caching, especially when the 781 value is not directly provided. 783 Value: Encoding of the certificate value. The actual value to be 784 encoded depends upon the type of the certificate 786 Locator: XML link element that could be used for retrieving a copy 787 of the digital certificate. The actual value being returned by 788 means of this locator depends upon the protocol being used. 790 Attributes Description 792 type: Type of the digital certificate expressed as a Uniform 793 Resource Name. 795 6.5 Certificates 797 The Certificates element consists of a collection of Certificate 798 elements. The Certificate elements contained in this element are 799 intended to be sufficient to make chains from the originator 800 credential(s) to a recognized 'certification authority' for all the 801 recipients. However, this element may contain more Certificate 802 elements than necessary or, alternatively, less than necessary if it 803 is known that recipients have an alternate means of obtaining 804 necessary certificates. 806 808 812 Content Description 814 Certificate: A collection of Certificate elements. 816 6.6 ContentInfo 818 The purpose of the ContentInfo element is to describe a given content 819 such that a receiving user agent can deal with the data in an 820 appropriate manner. 822 824 830 Attributes Description 832 type: Type of the content expressed as a Uniform Resource Name. 834 subtype: Optional sub-classing of the content type. 836 6.7 Date 838 The Date element consists of a constrained ISO 8601:1998 date and 839 time value. 841 843 848 Attributes Description 850 value: The date value expressed according to the format defined 851 below. 853 Date Format 855 This specification requires date values to be expressed according 856 to the following pattern: 858 YYYY '-' MM '-' DD 'T' hh ':' mm [':' ss ['.' f+]]('+' | '-') zzzz 860 YYYY: four-digit year 861 MM: two-digit month (01=January, etc.) 862 DD: two-digit day of the month (01-31) 863 hh: two digits of hour (00-23) 864 mm: two digits of minute (00-59) 865 ss: two digits of second (00-59) optional 866 f: digit(s) of fractions of second - optional 867 zzzz: four digits of amount of offset from UTC expressed in 868 hour (00-11) and minute (00-59) 870 For example, '1994-11-05T16:15:02.031-0500' denotes November 5, 871 1994, 4:15:02 pm and 31 milliseconds, US Eastern Standard Time. 873 6.8 Digest 875 The Digest element consists of the fingerprint of a given resource. 876 This element is constructed of two sub-elements. This first one 877 indicates the algorithm to be used for computation of the 878 fingerprint. The second element consists of the fingerprint value. 880 882 885 Content Description 887 Algorithm: Algorithm to be used for computation of the digest 888 value. 890 Value: Digest value after proper encoding. 892 6.9 DigestAlgorithms 894 The DigestAlgorithms element consists of a collection of Algorithm 895 elements that define the algorithms and parameter values to be 896 employed in the computation of digest values. It is primarily used 897 along with the dsig:eval global attribute for enabling one-pass 898 processing. 900 902 906 Content Description 908 Algorithm: A collection of digest algorithm definitions. 910 6.10 Identifier 912 The Identifier element enables identification between parties that 913 benefit from a prior relationship. The actual meaning and content of 914 this element is left to the parties. 916 918 923 Attributes Description 925 value: Identification data value. 927 6.11 Integer 929 The Integer element is a primary data type that is used in the 930 definition of algorithm parameters. 932 934 939 Attributes Description 941 value: Value of the element given according to the format given 942 below. 944 Integer Format 946 This specification requires integer values to be expressed 947 according to the following pattern: 949 ['+'|'-'] n+ 951 For example, +128, -35635, and 64535 are valid integer values. 953 6.12 IssuerAndSerialNumber 955 The IssuerAndSerialNumber element identifies a certificate, and 956 thereby an entity and a public key, by the distinguished name of the 957 certificate issuer and an issuer-specific certificate serial number. 959 961 967 Attributes Description 969 issuer: Distinguished name of the issuing certification authority. 971 number: Issuer-specific certificate serial number. 973 6.13 KeyAgreementAlgorithm 975 The KeyAgreementAlgorithm element specifies the algorithm to be 976 employed for establishment of a one-time session key. 978 980 984 Content Description 986 Algorithm: Algorithm and parameters to be used for establishment 987 of the session key. 989 6.14 Keyword 991 The Keyword element is a primary data type that is used in the 992 definition of algorithm parameters. 994 996 1001 Attributes Description 1003 value: Value of the element given as a free form string. 1005 6.15 Locator 1007 The Locator element consists of simple XML link [XLink]. This 1008 element allows unambiguous reference to a resource or fragment of a 1009 resource. 1011 1013 1019 Attributes Description 1021 xml:link: Required XML link attribute that specifies the nature of 1022 the link (simple in this case). 1024 href: Locator value that may contains either a URI [RFC 2396], a 1025 fragment identifier, or both. 1027 6.16 Manifest 1029 The Manifest element consists of a collection of attributes that 1030 specify such things as a unique reference to the resource being 1031 authenticated and an indication of the keying material and algorithms 1032 to be used. The signature value is actually computed from the 1033 Manifest. 1035 1041 1044 Content Description 1046 Resources: A collection of Resource elements that consist of a 1047 unique and unambiguous reference to the resources being 1048 authenticated. 1050 Attributes: Optional element that consists of a collection of 1051 complementary attributes to be authenticated. 1053 OriginatorInfo: Element that provides identification and keying 1054 material information related to the originator. 1056 RecipientInfo: Optional element that provides identification and 1057 keying material information related to the recipient. 1059 KeyAgreementAlgorithm: Optional element that indicates the 1060 algorithm to be used for establishment of a one-time session 1061 key. 1063 SignatureAlgorithm: Algorithm to be used for computation of the 1064 signature value. 1066 6.17 OriginatorInfo 1068 The OriginatorInfo element is used for providing identification and 1069 keying material information for the originator. 1071 1073 1077 Content Description 1079 ANY: Identification and keying material information may consist of 1080 ANY construct. Such a definition allows the adoption of 1081 application-specific schemes. However, implementations that 1082 comply with the current DTD MUST be able to recognize and 1083 process the elements Identifier and IssuerAndSerialNumber 1084 defined below. 1086 6.18 Package 1088 The Package element enables encapsulation of an arbitrary content 1089 into an XML document. Behaving like a MIME wrapper, the Package 1090 element provides for such things as content type identification and 1091 content encoding. 1093 1097 1103 Content Description 1105 ContentInfo: Element that provides type information regarding the 1106 content of the Package. 1108 Value: Element that displays the content value of the Package and 1109 provides information regarding possible encoding. 1111 Attributes Description 1113 id: Element identifier that could be used for referencing this 1114 element from a Resource element. 1116 6.19 Parameter 1118 A Parameter element provides the value of a particular algorithm 1119 parameter, whose name and format have been specified for the 1120 algorithm considered. 1122 1124 1128 Content Description 1130 ANY: The contents of a Parameter element consists of ANY valid 1131 construct, which is specified on a per algorithm per parameter 1132 basis. 1134 Attributes Description 1136 type: The type of the parameter expressed as a free form string, 1137 whose value is specified on a per algorithm basis. 1139 6.20 Real 1141 The Real element is a primary data type that is used in the 1142 definition of algorithm parameters. 1144 1146 1151 Attributes Description 1153 value: Value of the element given according to the format given 1154 below. 1156 Real Format 1158 This specification requires real values to be expressed according 1159 to the following pattern: 1161 ['+'|'-'] n+ ['.' f+] ['E' ('+'|'-') ee] 1163 For example, 12, -12.34, +12.34E-01, and +0.5 are valid real 1164 values. 1166 6.21 RecipientInfo 1168 The RecipientInfo element is used for providing identification and 1169 keying material information for the recipient. This element is used 1170 either for enabling recognition of a Signature element by a given 1171 recipient or when determination of the authentication key consists of 1172 the combination of keying material provided by both the recipient and 1173 the originator. 1175 Content Description 1177 The content of this element is similar to the one defined for the 1178 originator (cf. OriginatorInfo element description). 1180 6.22 Resource 1182 The Resource element consists of a unique and unambiguous reference 1183 to a resource being authenticated. It is comprised of a resource 1184 locator, a fingerprint, and optionally a content-type qualifier. 1186 1190 1194 Content Description 1196 ContentInfo: Optional element that provides type information 1197 regarding the resource. 1199 Locator: Locator value that contains a URI [RFC 2396], a fragment 1200 identifier, or both. Notice that making use of a fragment 1201 identifier for a document content other than XML is out of the 1202 scope of this specification and may lead to inconsistent 1203 results. 1205 Digest: Fingerprint of the resource. 1207 6.23 Resources 1209 The Resources element consists of a collection of Resource elements. 1210 Though inaccessible from the Document element of the Signature DTD, 1211 this element is available to more sophisticated constructs that make 1212 use of composite documents. 1214 1216 1222 Content Description 1224 Resource: A collection of Resource elements. 1226 Attributes Description 1228 id: Element identifier that could be used for referencing this 1229 element from a Resource element. 1231 6.24 Signature 1233 The Signature element constitutes the core of this specification. It 1234 is comprised of two sub-elements. The first one is a set of 1235 attributes, known as the Manifest, which actually constitutes the 1236 authenticated part of the document. The second sub-element consists 1237 of the signature value. 1239 1241 1247 Content Description 1249 Manifest: Element constructed from the set of attributes that 1250 constitute the authenticated part of the document. 1252 Value: The signature value after proper encoding. 1254 Attributes Description 1256 id: Element identifier that could be used for referencing the 1257 Signature element from a Resource element when implementing 1258 endorsement. 1260 6.25 SignatureAlgorithm 1262 The SignatureAlgorithm element specifies the algorithm to be employed 1263 for computation of a signature value. 1265 1267 1271 Content Description 1273 Algorithm: Algorithm and parameters to be used for computation of 1274 the signature value. 1276 6.26 Signatures 1278 The Signatures element consists of a collection of Signature 1279 elements. As mentioned in a previous paragraph, this element has been 1280 defined for the purpose of facilitating DOM manipulations. 1282 1284 1288 Content Description 1290 Signature: A collection of Signature elements. 1292 6.27 Value 1294 The Value element consists of a primary data type that is used 1295 throughout this proposal for inlining and encoding of arbitrary 1296 values. 1298 1300 1305 Content Description 1307 PCDATA: Content value after adequate encoding. 1309 Attributes Description 1311 encoding: This attribute specifies the scheme to be employed for 1312 recovering the original byte stream from the content of the 1313 element. This specification recognizes the following two 1314 schemes: 1316 none: the content has not been subject to any particular 1317 encoding. This does not preclude however the use of native 1318 XML encoding such as CDATA section or XML escaping. 1320 base64: The content has been encoded by means of the base64 1321 encoding scheme. 1323 7. Default Document Element 1325 Though it is primarily intended for enabling authentication in other 1326 XML applications, the XML Signature DTD specifies a default document 1327 element. This definition has been intentionally kept simple and is 1328 intended to provide an XML alternative to the ASN1 data types 1329 Authenticated Data and Signed Data defined by CMS [x] and PKCS#7 [x] 1330 binary syntax standards. 1332 The definition given below addresses the following requirements: 1334 - Authentication of arbitrary contents: This may be done by adequate 1335 encapsulation and encoding of the arbitrary contents into the 1336 Package element, which shall be further authenticated by means of 1337 a Signature element. 1339 - Detached signature: This may be done by means of a Signature 1340 element that refers to a resource external to the document. 1342 - Authentication versus signature: The distinction between 1343 authentication and signature only depends upon the algorithms 1344 being employed for computation of the 'signature' value. 1346 - Plurality of recipients: This consists of the insertion of a 1347 plurality of Signature elements, each making use of recipient 1348 dependent keying material. 1350 - Plurality of signers: This consists of the insertion of a 1351 plurality of Signature elements, each making use of originator 1352 dependent keying material. 1354 1359 1363 Content Description 1365 DigestAlgorithms: This element has been made mandatory whenever 1366 the document embeds the contents to be authenticated. This 1367 element specifies the algorithm to be used for computation of 1368 the digest of the Package elements, thus enabling one-pass 1369 processing. 1371 Package: This element is used for enveloping and encoding of the 1372 contents to be authenticated. Whenever employed, this element 1373 shall make use of the dsig:eval global attribute 1375 Signatures: This element consists of a collection of Signature 1376 elements. 1378 Certificates: This element consists of a collection of Certificate 1379 elements, which may be required by a given key management 1380 infrastructure. 1382 8. Standard Attributes 1384 This specification recognizes the following standard attributes. 1386 8.1 Signing-time Attribute 1388 Standard attribute that could be used for specifying the time at 1389 which the originator purportedly performed the signature process. 1390 This attribute content shall be given as a Date element. 1392 Specification: 1394 URN: urn:ietf-org:xmldsig-signing-time 1396 Type: dsig:Date 1398 Example: 1400 1401 1402 1404 9. Digest Algorithms 1406 This specification contemplates two types of digest algorithms: 1408 - Surface string digest algorithms: These algorithms do not have any 1409 particular knowledge about the content being digested and operate 1410 on the raw content value. Changes in the surface string of a given 1411 content affect directly the value of the digest being produced. 1413 - Canonical digest algorithms: These algorithms have been tailored 1414 for a particular content type and produce a digest value that 1415 depends upon the core semantics of such content. Changes limited 1416 to the surface string of a given content do not affect the value 1417 of the digest being produced. 1419 9.1 SHA1 1421 Surface string digest algorithm designed by NIST and NSA for use with 1422 the Digital Signature Standard. This algorithm is documented in NIST 1423 FIPS Publication 180-1. 1425 Specifications: 1427 URN: urn:nist-gov:sha1 1429 Parameters: 1431 This algorithm does not require any parameter. 1433 9.2 DOM-HASH 1435 XML canonical digest algorithm proposed by IBM Tokyo Research 1436 Laboratory and documented in the DOMHASH proposal [x]. This algorithm 1437 operates on the DOM representation of the document and provides an 1438 unambiguous means for recursive computation of the hash value of the 1439 nodes that constitute the DOM tree. This algorithm has many 1440 applications such as computation of digital signature and 1441 synchronization of DOM trees. However, because the hash value of an 1442 element is computed from the hash values of the inner elements, this 1443 algorithm is better adapted to small documents that do not require 1444 one-pass processing. 1446 As of today, this algorithm is limited to the contents of an XML 1447 document and, therefore, does not provide for authentication of the 1448 internal or external subset of the DTD. 1450 The DOM-HASH algorithm requires a single parameter, which shall 1451 consist of a surface string digest algorithm such as SHA1. 1453 Specifications: 1455 URN: urn:ibm-com:dom-hash 1457 Parameters: 1459 digest-algorithm Surface string digest algorithm to be used for 1460 computation of the digest value. 1462 type: dsig:Algorithm 1464 default: urn:nist-gov:sha1 1466 Example: 1468 1469 1470 1471 1472 1474 9.3 XHASH 1476 XML canonical digest algorithm proposed by GlobeSet and documented in 1477 the XHASH proposal [x]. This algorithm has been inspired by the DOM 1478 HASH proposal, but operates closer to the surface string of the 1479 document. Elements and attributes are subject to formalization in a 1480 way quite similar to the one proposed by DOM-HASH - XML delimiters 1481 are represented by binary values and entities are replaced by their 1482 actual values. However, formalization happens as elements are 1483 acquired. Furthermore, this algorithm takes into account some 1484 specifics of this specification (e.g. dsig:eval attribute). 1486 The XHASH algorithm makes use of two parameters. The first one 1487 consists of a surface string digest algorithm such as SHA1. The 1488 second one, optional, may be used for specifying how non-significant 1489 SPACE characters shall be handled by default. Actually, the XML 1490 Specifications define the xml:space attribute that could be used for 1491 specifying if non-significant SPACE characters are to be preserved. 1492 However, possible values for this attribute are limited to 'default' 1493 and 'preserve'. Thus, there is no known way to explicitly specify 1494 that non-significant SPACE characters should be discarded 1496 Specifications: 1498 URN: urn:globeset-com:xhash 1500 Parameters: 1502 digest-algorithm Surface string digest algorithm to be used 1503 for computation of the digest value. 1505 type: dsig:Algorithm 1507 default: urn:nist-gov:sha1 1509 white-spaces Default processing of non-significant SPACE 1510 characters. 1512 type: dsig:Keyword 1514 value: preserve: Non-significant SPACE characters are to be 1515 preserved in a way similar to what should be done in 1516 presence of an xml:space preserve attribute. 1518 ignore: Unless overridden by means of an xml:space preserve 1519 attribute, non-significant SPACE characters shall be ignored 1520 during computation of the canonical form of the contents. 1522 default: ignore 1524 Example 1526 1527 1528 1529 1530 1531 1532 1533 1535 10. Key Agreement Algorithms 1537 A key-agreement algorithm consists of a function that is used for 1538 deriving a one-time session key from a given master key. Usage of 1539 one-time session keys prevents some kinds of attacks that require a 1540 large volume of cipher-text to be produced with a given key. 1542 Usage of a key-agreement algorithm is recommended when authentication 1543 is based upon a shared secret. This shared secret could have been 1544 exchanged either by offline means (e.g. mail) or computed dynamically 1545 by means of a key-exchange algorithm such as Diffie Hellman [x]. 1547 10.1 PKCS12-PBE 1549 Key-agreement algorithm proposed by RSA Laboratories and documented 1550 in PKCS12 [x]. This algorithm is a generalization of the PBE 1551 algorithm defined in PKCS5 [x] and provides for the generation of 1552 symmetric keys and other cryptographic parameters from an established 1553 password. 1555 This algorithm requires three parameters. The first one consists of a 1556 one-way hash function (i.e. SHA1), the second one of a random string 1557 (salt), and the last one of an iteration count 1559 Specifications 1561 URN: urn:rsasdi-com:pkcs12-pbe 1563 Parameters: 1565 digest-algorithm One-way hash function used as the pseudo- 1566 random number generator. 1568 type: dsig:Algorithm 1570 default: urn:nist-gov:sha1 1572 random-string Random string value used to seed the PRNG. 1574 type: dsig:Value 1576 default: no default. 1578 iteration-count 1580 type: dsig:Integer 1582 default: 256 1584 Example 1586 1587 1588 1589 1590 1591 1592 Abkirjegks123qwgtawd456g47 1593 1594 1595 1596 1597 1598 1600 11. Key Exchange Algorithms 1602 A key-exchange algorithm enables dynamic establishment of a master 1603 secret key that results from the combination of keying material 1604 provided by the parties involved in an exchange. The parties may 1605 further establish a one-time session key from such a master secret 1606 key by means of a key-agreement algorithm. 1608 Key-exchange algorithms shall not be defined in the body of a signed 1609 document. Their usage is implicit and depends solely upon the keying 1610 material being used for authentication. 1612 11.1 Diffie Hellman 1614 Key-exchange algorithm named from its authors and documented in 1615 X9.42. 1617 12. Signature Algorithms 1619 This specification abusively uses the terminology of 'digital 1620 signature' for qualifying indifferently digital signature and message 1621 authentication codes. Thus, the signature algorithms contemplated 1622 herein include public-key digital signature algorithms such as DSA 1623 and message authentication codes such as HMAC. 1625 12.1 HMAC 1627 Message Authentication Code proposed by H. Krawczyk and al. and 1628 documented in RFC2104 1630 This specification adopts a scheme that differs a bit from the common 1631 usage of this algorithm -- computation of the MAC is performed on the 1632 hash of the contents being authenticated instead of the actual 1633 contents. Thence, the actual signature value output by the algorithm 1634 might be depicted as follows: 1636 SignatureValue = HMAC( SecretKet, H(dsig:Manifest)) 1638 This specification also considered HMAC output truncation such as 1639 proposed by Preneel and van Oorschot. In their paper [x] these two 1640 researchers have shown some analytical advantages of truncating the 1641 output of hash-based MAC functions. Such output truncation is also 1642 considered in the RFC document. 1644 HMAC requires three parameters. The first one consists of a canonical 1645 digest algorithm. The second one consists of a hash function. The 1646 last one is optional and specifies the length in bit of the truncated 1647 output. If this last parameter is absent, no truncation shall occur. 1649 Specifications 1651 URN: urn:ietf-org:hmac 1653 Parameters: 1655 digest-algorithm Canonical or surface-string digest algorithm 1656 to be is used for computation of the Manifest fingerprint. 1658 type: dsig:Algorithm 1660 default: urn:nist-gov:sha1 1662 hash-function Hash function that is used to compute the MAC 1663 value from the secret key and the fingerprint of the signature 1664 Manifest. 1666 type: dsig:Algorithm 1668 default: urn:nist-gov:sha1 1670 output-length Length in bits of the truncated MAC value. 1672 type: dsig:Integer 1674 default: no default. 1676 Signature Value Encoding: 1678 The output of this algorithm can be assumed as a large integer value. 1679 The signature value shall consist of the octet-encoded value of this 1680 integer. Integer to octet-stream conversion shall be done according 1681 to PKCS#1 [x] specification with a k parameter equals to ((Hlen +7) 1682 mod8), Mlen being the length in bits of the MAC value. 1684 Example 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1698 12.2 DSA 1700 Public-key signature algorithm proposed by NIST for use with the 1701 Digital Signature Standard. This standard is documented in NIST FIPS 1702 Publication 186 [x] and ANSI X9.30 [x]. 1704 The DSA algorithm requires a single parameter, which consists of the 1705 canonical digest algorithm to be used for computing the fingerprint 1706 of the signature Manifest. 1708 Specifications 1710 URN: urn:nist-gov:dsa 1712 Parameters: 1714 digest-algorithm Canonical or surface-string digest algorithm 1715 to be is used for computation of the Manifest fingerprint. 1717 type: dsig:Algorithm 1719 default: urn:nist-gov:sha1 1721 Signature Value Encoding: 1723 The output of this algorithm consists of a pair of integers usually 1724 referred by the pair (r, s). The signature value shall consist of the 1725 concatenation of two octet-streams that respectively result from the 1726 octet-encoding of the values r and s. Integer to octet-stream 1727 conversion shall be done according to PKCS#1 [x] specification with a 1728 k parameter equals to 20. 1730 Example 1732 1733 1734 1735 1736 1738 12.3 RSA-Encryption 1740 Public-key signature algorithm proposed by RSA Laboratories and 1741 documented in PKCS#1 [x]. 1743 This specification adopts the RSA encryption algorithm with padding 1744 block type 01. For computing the signature value, the signer shall 1745 first digest the signature Manifest and then encrypt the resulting 1746 digest with his private key. 1748 This signature algorithm requires a single parameter, which consists 1749 of the canonical digest algorithm to be used for computing the 1750 fingerprint of the signature Manifest. 1752 Specifications 1754 URN: urn:rsasdi-com:rsa-encryption 1756 Parameters: 1758 digest-algorithm Canonical or surface-string digest algorithm 1759 to be is used for computation of the Manifest fingerprint. 1761 type: dsig:Algorithm 1763 default: urn:nist-gov:sha1 1765 Signature Value Encoding: 1767 The output of this algorithm consists of single octet-stream. No 1768 further encoding is required. 1770 Example 1772 1773 1774 1775 1776 1778 12.4 ECDSA 1780 Public-key signature algorithm proposed independently by Neil Koblitz 1781 and Victor Miller. This algorithm is being proposed as an ANSI 1782 standard and is documented in ANSI X9.62 standard proposal [x] and 1783 IEEE/P1363 standard draft proposal [x]. 1785 The ECDSA algorithm requires a single parameter, which consists of 1786 the canonical digest algorithm to be used for computing the 1787 fingerprint of the signature Manifest. 1789 Specifications 1791 URN: urn:ansi-org:ecdsa 1793 Parameters: 1795 digest-algorithm Canonical or surface-string digest algorithm 1796 to be is used for computation of the Manifest fingerprint. 1798 type: dsig:Algorithm 1800 default: urn:nist-gov:sha1 1802 Signature Value Encoding: 1804 The output of this algorithm consists of a pair of integers usually 1805 referred by the pair (r, s). The signature value shall consist of the 1806 concatenation of two octet-streams that respectively result from the 1807 octet-encoding of the values r and s. Integer to octet-stream 1808 conversion shall be done according to PKCS#1 [x] specification with a 1809 k parameter equals to 20. 1811 Example 1813 1814 1815 1816 1817 1819 13. References 1821 [...more to come...] 1822 14. Signature DTD 1824 <-- XML Signature DTD - 990404 - Revision 0 ---> 1826 1828 1833 1837 1839 1845 1847 1853 1855 1859 1864 1868 1869 1873 1875 1881 1883 1888 1890 1894 1896 1900 1902 1907 1909 1913 1915 1921 1923 1927 1929 1934 1936 1942 1948 1952 1954 1957 1959 1963 1967 1973 1975 1980 1982 1987 1991 1995 1997 2002 2004 2010 2012 2016 2018 2022 2024 2029 15. Embedded Content Example 2031 This example illustrates use of the default document element for 2032 attachment and authentication of an arbitrary piece of information. 2034 2035 2038 2040 2041 2043 2045 2046 2048 2049 abncjflf311257gghn6mj2k134h64AANHdd12== 2050 2051 2053 2054 2055 2057 2058 2059 2060 2061 2062 2063 bndWGryrt245u6t1dgURTIrr4ir5= 2064 2065 2066 2067 2069 2070 2072 2073 2074 2075 2076 2079 2081 2082 2084 2085 2086 2087 2088 2090 2092 2093 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 2094 2096 2098 2100 2102 2103 2106 2108 2110 2111 2114 2115 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 2116 2117 2119 2121 2123 16. Detached Signature Example 2125 This example illustrates use of the default document element for 2126 production of a detached-signature. This example assumes that 2127 recipient and originator benefit from a prior relationship. 2129 2130 2133 2135 2137 2138 2140 2141 2142 2144 2146 2147 2148 2149 bndWGryrt245u6t1dgURTIrr4ir5= 2150 2151 2152 2153 2155 2156 2157 2159 2160 2161 2162 2163 2164 2165 2166 2167 2169 2171 2172 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 2173 2175 2177 2179 2181 17. Domain-specific Example 2183 This example illustrates how to leverage the XML Signature DTD to 2184 enable authentication in another XML application. 2186 This application contemplates the production of authenticated Ticket 2187 documents that conform to the following DTD 2189 2190 2192 %XmlDsigDtd; 2194 2195 2199 2200 2204 2205 2210 2211 2216 The following consists of a Ticket document that conforms to the 2217 previous DTD. The system makes use of a public-key signature 2218 algorithm (RSA) and relies upon X509v3 credentials. 2220 2221 2223 2225 2226 2229 2232 2234 2235 2237 2238 2239 2240 2241 2242 2243 bndWGryrt245u6t1dgURTIrr4ir5= 2244 2245 2246 2247 2249 2250 2253 2255 2256 2257 2258 2259 2260 2261 2263 2264 2265 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 2266 2268 2270 2271 2274 2275 xsqsfasDys2h44u4ehJDe54he5j4dJYTJ= 2276 2277 2279 2281 File Name: draft-ietf-xmldsig-signature-00.txt 2282 Expires: Deember 1999