idnits 2.17.1 draft-chudov-cryptopro-cpxmldsig-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 854. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 878. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 49 has weird spacing: '...ryption synta...' == Line 110 has weird spacing: '...ryption synta...' == The document seems to lack 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (December 12, 2008) is 5615 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-2' is mentioned on line 710, but not defined == Missing Reference: '1-3' is mentioned on line 710, but not defined == Missing Reference: '0-9' is mentioned on line 710, but not defined ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chudov 3 Internet-Draft S. Leontiev 4 Intended status: Informational A. Chelpanov 5 Expires: June 15, 2009 P. Smirnov 6 CRYPTO-PRO 7 December 12, 2008 9 GOST based Security Uniform Resource Identifiers (URIs). 10 draft-chudov-cryptopro-cpxmldsig-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 This Internet-Draft will expire on June 15, 2009. 37 Abstract 39 This document specifies how to use Russian national cryptographic 40 standards GOST R 34.10-2001, GOST R 34.10-94, GOST R 34.11-94 41 GOST 28147-89 with XML Signatures and XML encryption. The mechanism 42 specified provides integrity, message authentication, and/or data 43 encryption and/or signer authentication services. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. GOST R 34.10-94/2001 . . . . . . . . . . . . . . . . . . . . . 3 49 3. Specifying GOST within XMLDSIG and XML encryption syntax 50 and processing . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Version, Namespaces and Identifiers . . . . . . . . . . . 3 52 3.2. XML Schema Preamble and DTD Replacement . . . . . . . . . 4 53 3.2.1. XML Schema Preamble . . . . . . . . . . . . . . . . . 4 54 3.2.2. DTD Replacement . . . . . . . . . . . . . . . . . . . 4 55 3.3. Public Key Signature Algorithms . . . . . . . . . . . . . 4 56 3.4. DigestMethod Algorithms . . . . . . . . . . . . . . . . . 5 57 3.5. Hash Message Authentication Code Algorithms . . . . . . . 5 58 3.6. GOST Key Values . . . . . . . . . . . . . . . . . . . . . 5 59 3.6.1. Key Value Root Element . . . . . . . . . . . . . . . . 5 60 3.6.2. GOST R 34.10 Parameters . . . . . . . . . . . . . . . 7 61 3.7. EncryptionMethod Algorithms . . . . . . . . . . . . . . . 8 62 3.8. Key Agreement Algorithms . . . . . . . . . . . . . . . . . 9 63 3.9. Key Transport Algorithm . . . . . . . . . . . . . . . . . 10 64 3.10. Symmetric Key Wrap . . . . . . . . . . . . . . . . . . . . 10 65 3.10.1. GOST 28147-89 Key Wrap . . . . . . . . . . . . . . . . 10 66 3.10.2. CryptoPro Key Wrap . . . . . . . . . . . . . . . . . . 11 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.1. Signed message . . . . . . . . . . . . . . . . . . . . . . 12 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.1. Normative references . . . . . . . . . . . . . . . . . . . 13 73 7.2. Informative references . . . . . . . . . . . . . . . . . . 15 74 Appendix A. Aggregate XML Schema . . . . . . . . . . . . . . . . 15 75 Appendix B. Aggregate DTD . . . . . . . . . . . . . . . . . . . . 17 76 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 17 77 C.1. Signed document . . . . . . . . . . . . . . . . . . . . . 17 78 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 80 Intellectual Property and Copyright Statements . . . . . . . . . . 21 82 1. Introduction 84 This document specifies how to use GOST R 34.10-2001, GOST R 34.10-94 85 digital signatures and public keys, GOST R 34.11-94 hash, 86 GOST 28147-89 encryption algorithms with XML Signatures [XMLDSIG] and 87 XML Encryption. 89 This document uses both XML Schemas ([XML-SCHEMA-1], [XML-SCHEMA-2]) 90 (normative) and DTDs [XML] (informational) for specifying the 91 corresponding XML structures. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 94 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 95 this document are to be interpreted as described in [KEYWORDS]. 97 2. GOST R 34.10-94/2001 99 Algorithms GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 100 have been developed by Russian Federal Agency of Governmental 101 Communication and Information (FAGCI) and "All-Russian Scientific and 102 Research Institute of Standardization". They are described in 103 [GOSTR341094], [GOSTR341001] and [GOSTR341194] ([GOST3431095], 104 [GOST3431004] and [GOST3431195]). RECOMMENDED parameters for those 105 algorithms are described in [CPALGS]. 107 The only hash function used with GOST R 34.10-94/2001 is 108 GOST R 34.11-94. 110 3. Specifying GOST within XMLDSIG and XML encryption syntax and 111 processing 113 This section specifies the details of how to use GOST algorithms with 114 XML Signature Syntax and Processing [XMLDSIG] and XML Encryption 115 Syntax and Processing [XMLENC-CORE]. It relies heavily on syntaxes 116 and namespaces defined in [XMLDSIG] and [XMLENC-CORE]. 118 3.1. Version, Namespaces and Identifiers 120 This specification makes no provision for an explicit version number 121 in the syntax. If a future version is needed, it will use a 122 different namespace. 124 The XML namespace [XML-NS] URI [RFC2396] that MUST be used by 125 implementations of this (dated) specification is: 127 http://www.w3.org/2006/10/xmldsig-gost# 129 Elements in the namespace of the [XMLDSIG] specification are marked 130 as such by using the namespace prefix "dsig" in the remaining 131 sections of this document. 133 Elements in the namespace of the [XMLENC-CORE] specification are 134 marked as such by using the namespace prefix "xenc" in the remaining 135 sections of this document. 137 3.2. XML Schema Preamble and DTD Replacement 139 3.2.1. XML Schema Preamble 141 The subsequent preamble is to be used with the XML Schema definitions 142 given in the remaining sections of this document. 144 151 3.2.2. DTD Replacement 153 In order to include GOST XML-signature syntax, the following 154 definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 156 158 3.3. Public Key Signature Algorithms 160 The input to the GOST R 34.10-94/2001 algorithms is the canonicalized 161 representation of the dsig:SignedInfo element as specified in Section 162 3 of [XMLDSIG]. 164 The signature value (text value of element dsig:SignatureValue - see 165 section 4.2 of [XMLDSIG]) consists of the base64 encoding of the 64 166 octets as described in section 2.2 of [CPPK]. 168 The identifier for the GOST R 34.10-94 signature algorithm is: 169 http://www.w3.org/2006/10/xmldsig-gost#gostr341094-gostr3411 171 The identifier for the GOST R 34.10-2001 signature algorithm is: 172 http://www.w3.org/2006/10/xmldsig-gost#gostr34102001-gostr3411 174 3.4. DigestMethod Algorithms 176 The identifier for the GOST R 34.11-94 digest algorithm is: 177 http://www.w3.org/2006/10/xmldsig-gost#gostr3411 179 The DigestMethod may contain optional element gost:ParametersR3411. 180 ParametersR3411 contains one OID specified in section 8.2. [CPALGS]. 181 If ParametersR3411 is missed, the application implicitly knows about 182 it from other means. 184 It is RECOMMENDED to use parameters defined by id-GostR3411-94- 185 CryptoProParamSet if ParametersR3411 is omitted (see Section 11.2 186 [CPALGS]). 188 Schema Definition: 190 193 DTD Definition: 195 197 3.5. Hash Message Authentication Code Algorithms 199 GOST R 34.11-94 can also be used in HMAC [HMAC] as described in 200 section 6.3.1 of [XMLDSIG]. Identifier: 201 http://www.w3.org/2006/10/xmldsig-gost#hmac-gostr3411 203 The Hash Message Authentication Code Algorithms contain the same 204 parameters as DigestMethod Algorithms. 206 If ParametersR3411 is missed, the parameters, identified by id- 207 GostR3411-94-CryptoProParamSet, are RECOMMENDED to use (see Section 208 11.2 [CPALGS]). 210 3.6. GOST Key Values 212 3.6.1. Key Value Root Element 214 Elements of KeyValue1994Type and KeyValue2001Type types are used for 215 GOST public keys encoding. The usage of these elements with 216 [XMLDSIG] or [XMLENC-CORE] is the same as for dsig:RSAKeyValue or 217 xenc:DHKeyValue predefined elements in dsig:KeyValue. 219 The elements consist of an optional subelement PublicKeyParameters 220 and the mandatory subelement PublicKey. If PublicKeyParameters are 221 missing in an instance, this means that the application knows about 222 them from other means (implicitly). 224 Schema Definition: 226 229 230 231 234 235 236 238 241 242 243 246 247 248 250 DTD Definition: 252 254 256 258 If KeyValue2001Type PublicKeyParameters subelement is missed, the 259 parameters, identified by DefaultPublicKeyParameters2001, are 260 RECOMMENDED to use. 262 DefaultPublicKeyParameters2001: 264 265 1.2.643.2.2.35.1 266 267 1.2.643.2.2.30.1 268 269 1.2.643.2.2.31.1 270 271 273 If KeyValue1994Type PublicKeyParameters subelement is missed, the 274 parameters, defined by DefaultPublicKeyParameters1994, are 275 RECOMMENDED to use. 277 DefaultPublicKeyParameters1994: 279 280 1.2.643.2.2.32.2 281 282 1.2.643.2.2.30.1 283 284 1.2.643.2.2.31.1 285 286 288 3.6.2. GOST R 34.10 Parameters 290 Gost paramaters contain three OIDs: publicKeyParamSet, digestParamSet 291 and optional encryptionParamSet. Parameter values, corresponding to 292 these OIDs, can be found in [CPALGS]. 294 Schema Definition: 296 297 298 300 302 305 306 307 308 309 311 313 316 317 319 320 321 322 323 325 DTD Definition: 327 330 333 334 335 337 3.7. EncryptionMethod Algorithms 339 This subsection gives identifiers and information for GOST 28147-89 340 EncryptionMethod Algorithms. 342 The identifier for the GOST 28147-89 encryption algorithm is: 343 http://www.w3.org/2006/10/xmldsig-gost#gost28147 345 Complete description of GOST 28147-89 can be found in [GOST28147] (in 346 Russian). 348 256-bit key, 64-bit Initialization Vector (IV), and optional 349 parameters are used in GOST 28147-89 encryption method algorithms. 351 The resulting cipher text is prefixed by the IV. If included in XML 352 output, it is then base64 encoded. 354 GostParameters28147 specifies the set of corresponding Gost28147-89- 355 ParamSetParameters (see Section 8.1 of [CPALGS] ). Encryption mode 356 is specified by mode parameter of Gost28147-89-ParamSetParameters 357 structure. CFB and CNT modes are RECOMMENDED to use. If 358 ParametersR3411 is missed, the application implicitly knows about it 359 from other means. 361 If GostParameters28147 is omitted, the parameters, defined by id- 362 Gost28147-89-CryptoPro-A-ParamSet, are RECOMMENDED to use (see 363 Section 8.1 [CPALGS]). 365 Schema Definition: 367 368 369 371 DTD Definition: 373 375 3.8. Key Agreement Algorithms 377 Key agreement algorithms based on GOST R 34.10-94/2001 public keys 378 (see Section 5 [CPALGS]) involves the derivation of shared secret 379 information based on compatible keys from the sender and recipient. 381 The identifiers for the algorithms based on GOST R 34.10-94/2001 are: 382 http://www.w3.org/2006/10/xmldsig-gost#agree-gost1994 383 http://www.w3.org/2006/10/xmldsig-gost#agree-gost2001 385 The shared keying material for algorithm based on GOST R 34.10-94 386 needed will be calculated as a result of function VKO GOST R 34.10-94 387 (see Section 5.1 [CPALGS]), which generates GOST KEK using two 388 GOST R 34.10-94 keypairs. 390 The shared keying material for algorithm based on GOST R 34.10-2001 391 needed will be calculated as a result of function VKO GOST R 34.10- 392 2001 (see Section 5.2 [CPALGS]), which generates GOST KEK using two 393 GOST R 34.10-2001 keypairs and UKM. KA-Nonce field of 394 AgreementMethod contains base64 encoded 64-bits value of UKM, if UKM 395 is used. 397 3.9. Key Transport Algorithm 399 The key transport alogorithms based on VKO GOST R 34.10-2001 or VKO 400 GOST R 34.10-1994, specified in [CPALGS], are public key encryption 401 algorithms, which MUST be used for key encryption/decryption only. 403 The identifiers for the algorithms based on VKO GOST R 34.10-94/2001 404 are: 405 http://www.w3.org/2006/10/xmldsig-gost#transport-gost1994 406 http://www.w3.org/2006/10/xmldsig-gost#transport-gost2001 408 The CipherValue for such encrypted key is the base64 encoding of the 409 [X.208-88] encoding structure GostR3410-KeyTransport (see section 410 4.2.1 [CPCMS]). 412 In order to produce the KEK, the algorithm VKO GOST R 34.10-94/2001 413 (described in [CPALGS]) is used with the secret key, which 414 corresponds to the GostR3410-TransportParameters ephemeralPublicKey, 415 and recipient's public key. 417 If the CryptoPro key wrap algorithm is used to produce CEK_ENC, 418 CEK_MAC, and UKM, then GostR3410-TransportParameters 419 encryptionParamSet is used for all encryption operations. 421 The resulting encrypted key (CEK_ENC) is placed in the Gost28147-89- 422 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 423 Gost28147-89-EncryptedKey macKey field, and UKM is placed in the 424 GostR3410-TransportParameters ukm field. 426 3.10. Symmetric Key Wrap 428 Symmetric Key Wrap algorithms are shared secret key encryption 429 algorithms, which MUST be used for symmetric keys encryption/ 430 decryption only. 432 3.10.1. GOST 28147-89 Key Wrap 434 The GOST 28147-89 Key Wrap algorithms wrap (encrypt) a key (the 435 wrapped key, WK) under a GOST 28147-89 Key Wrap (specified in 436 sections 6.1, 6.2 [CPALGS]). 438 Note: These algorithms MUST NOT be used without Key Agreement 439 algorithm, because such WK is constant for every wrappnig-encrypting 440 pair. The encryption of many different keys with the same constant 441 WK may reveal that WK. 443 The identifier for the GOST 28147-89 Key Wrap algorithms is 444 http://www.w3.org/2006/10/xmldsig-gost#kw-gost 446 The CipherValue for such wrapped key is the base64 encoding of the 447 [X.208-88] DER encoding structure GostR3410-KeyWrap. 449 ASN.1 structure: 451 GostR3410-KeyWrap ::= 452 SEQUENCE { 453 encryptedKey Gost28147-89-EncryptedKey, 454 encryptedParameters Gost28147-89-KeyWrapParameters 455 } 457 Gost28147-89-KeyWrapParameters is described in section 4.1.1 of 458 [CPCMS]. KA-Nonce field of AgreementMethod tag MUST be used as ukm. 460 The resulting wrapped key (WK) is placed in the Gost28147-89- 461 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 462 Gost28147-89-EncryptedKey macKey field. ukm field of Gost28147-89- 463 KeyWrapParameters MUST be absent. 465 3.10.2. CryptoPro Key Wrap 467 The CryptoPro Key Wrap algorithm wraps (encrypts) a key (wrapped key, 468 WK) under a CryptoPro Key Wrap (specified in sections 6.3, 6.4 469 [CPALGS]). 471 The identifier for the CryptoPro Key Wrap algorithms is 472 http://www.w3.org/2006/10/xmldsig-gost#kw-cp 474 The CipherValue for such wrapped key is the base64 encoding of the 475 [X.208-88] DER encoding structure GostR3410-KeyWrap (See 'GOST 476 28147-89 Key Wrap'). 478 The resulting wrapped key (WK) is placed in the Gost28147-89- 479 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 480 Gost28147-89-EncryptedKey macKey field. 482 If CryptoPro Key wrap algorithm is combined with Key Agreement 483 Algorithm, KA-Nonce field of AgreementMethod tag MUST be used as ukm. 484 ukm field of Gost28147-89-KeyWrapParameters type must be absent. 486 If CryptoPro Key wrap algorithm is not combined with Key Agreement 487 Algorithm, ukm field of Gost28147-89-KeyWrapParameters type MUST be 488 present. 490 4. Security Considerations 492 Conforming applications MUST use unique values for ukm and iv. 493 Recipients MAY verify that ukm and iv, specified by the sender, are 494 unique. 496 It is RECOMMENDED that software applications verify signature values, 497 subject public keys and algorithm parameters to conform to 498 [GOSTR341001], [GOSTR341094] standards before to use them. 500 Cryptographic algorithm parameters affect algorithm strength. The 501 use of parameters not listed in [CPALGS] is NOT RECOMMENDED (see the 502 Security Considerations section of [CPALGS]). 504 Use of the same key for signature and key derivation is NOT 505 RECOMMENDED. 507 SHOULD NOT use XML encryption without XML signature or HMAC. 509 5. Examples 511 5.1. Signed message 513 This message is signed using the sample certificate. 515 6. IANA Considerations 517 IANA has assigned the following values for GOST 28147-89 mode ciphers 518 definitions: 520 IANA has assigned the following XML namespace [XML-NS] URN: 521 http://www.w3.org/2006/10/xmldsig-gost# 523 [IANA please remove] Note: The above URN have not yet been 524 registered. 526 7. References 527 7.1. Normative references 529 [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 530 Cryptographic Algorithms for Use with GOST 28147-89, 531 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 532 Algorithms", RFC 4357, January 2006. 534 [CPCMS] Leontiev, S. and G. Chudov, "Using the GOST 28147-89, 535 GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 536 Algorithms with Cryptographic Message Syntax (CMS)", 537 RFC 4490, May 2006. 539 [CPPK] Leontiev, S. and D. Shefanovski, "Using the 540 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 541 Algorithms with the Internet X.509 Public Key 542 Infrastructure Certificate and CRL Profile", RFC 4491, 543 May 2006. 545 [GOST28147] 546 Government Committee of the USSR for Standards, 547 "Cryptographic Protection for Data Processing System, 548 Gosudarstvennyi Standard of USSR (In Russian)", 549 GOST 28147-89, 1989. 551 [GOST3431004] 552 Council for Standardization, Metrology and Certification 553 of the Commonwealth of Independence States (EASC), Minsk, 554 "Information technology. Cryptographic Data Security. 555 Formation and verification processes of (electronic) 556 digital signature based on Asymmetric Cryptographic 557 Algorithm (In Russian)", GOST 34.310-2004, 2004. 559 [GOST3431095] 560 Council for Standardization, Metrology and Certification 561 of the Commonwealth of Independence States (EASC), Minsk, 562 "Information technology. Cryptographic Data Security. 563 Produce and check procedures of Electronic Digital 564 Signature based on Asymmetric Cryptographic Algorithm (In 565 Russian)", GOST 34.310-95, 1995. 567 [GOST3431195] 568 Council for Standardization, Metrology and Certification 569 of the Commonwealth of Independence States (EASC), Minsk, 570 "Information technology. Cryptographic Data Security. 571 Cashing function (In Russian)", GOST 34.311-95, 1995. 573 [GOSTR341001] 574 Government Committee of the Russia for Standards, 575 "Information technology. Cryptographic Data 576 Security.Signature and verification processes of 577 [electronic] digital signature, Gosudarstvennyi Standard 578 of Russian Federation (In Russian)", GOST R 34.10-2001, 579 2001. 581 [GOSTR341094] 582 Government Committee of the Russia for Standards, 583 "Information technology. Cryptographic Data Security. 584 Produce and check procedures of Electronic Digital 585 Signatures based on Asymmetric Cryptographic Algorithm, 586 Gosudarstvennyi Standard of Russian Federation (In 587 Russian)", GOST R 34.10-94, 1994. 589 [GOSTR341194] 590 Government Committee of the Russia for Standards, 591 "Information technology. Cryptographic Data Security. 592 Hashing function, Gosudarstvennyi Standard of Russian 593 Federation (In Russian)", GOST R 34.11-94, 1994. 595 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 596 Hashing for Message Authentication", RFC 2104, 597 February 1997. 599 [KEYWORDS] 600 Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, March 1997. 603 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 604 Resource Identifiers (URI): Generic Syntax", RFC 2396, 605 August 1998. 607 [X.208-88] 608 International International Telephone and Telegraph 609 Consultative Committee, "Specification of Abstract Syntax 610 Notation One (ASN.1)", CCITT Recommendation X.208, 611 November 1988. 613 [XML-NS] Bray, T., Hollander, D., Layman, A., and R. Tobin, 614 "Namespaces in XML (Second Edition)", W3C REC-xml-names, 615 August 2006, 616 . 618 [XML-SCHEMA-1] 619 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 620 "XML Schema Part 1: Structures Second Edition", W3C REC- 621 xmlschema-1, October 2004, 622 . 624 [XML-SCHEMA-2] 625 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 626 Second Edition", W3C REC-xmlschema-2, October 2004, 627 . 629 [XMLDSIG] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 630 Language) XML-Signature Syntax and Processing", RFC 3275, 631 March 2002. 633 [XMLENC-CORE] 634 Eastlake, D. and J. Reagle , "XML Encryption Syntax and 635 Processing", W3C Candidate Recommendation xmlenc-core, 636 August 2002, . 638 7.2. Informative references 640 [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 641 July 2005. 643 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 644 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 645 Edition)", W3C REC-xml, August 2006, 646 . 648 Appendix A. Aggregate XML Schema 650 652 659 661 662 663 666 667 668 669 671 672 673 676 677 678 680 681 682 684 686 689 690 692 693 694 696 698 701 702 704 705 706 708 709 710 711 712 714 717 719 Appendix B. Aggregate DTD 721 723 725 726 729 732 733 734 735 736 738 Appendix C. Examples 740 Examples here are stored in the same format as the examples in 741 [RFC4134] and can be extracted using the same program. 743 If you want to extract without the program, copy all the lines 744 between the "|>" and "|<" markers, remove any page breaks, and remove 745 the "|" in the first column of each line. The result is a valid 746 Base64 blob that can be processed by any Base64 decoder. 748 C.1. Signed document 750 This sample contain the signed XML document using the sample 751 certificate from Section 4.2 of [CPPK]. 753 |>XmlDocSigned2001.xml 754 |PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48Q3J5cHRvUHJv 755 |WE1MIFNpZ25lZD0idHJ1ZSI+SGVyZSBpcyBzb21lIGRhdGEgdG8gc2lnbi48U2ln 756 |bmF0dXJlIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcj 757 |Ij48U2lnbmVkSW5mbz48Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09 758 |Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1 759 |IiAvPjxTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9y 760 |Zy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0cjM0MTAyMDAxLWdvc3RyMzQxMSIg 761 |Lz48UmVmZXJlbmNlIFVSST0iIj48VHJhbnNmb3Jtcz48VHJhbnNmb3JtIEFsZ29y 762 |aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 763 |ZC1zaWduYXR1cmUiIC8+PC9UcmFuc2Zvcm1zPjxEaWdlc3RNZXRob2QgQWxnb3Jp 764 |dGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0 765 |cjM0MTEiIC8+PERpZ2VzdFZhbHVlPi9Kd3RRc3Z5NWsvUjBWZUx6ZG0ySWlqUEJ0 766 |U0o1cEpSalQ5RlVRSEV5VGc9PC9EaWdlc3RWYWx1ZT48L1JlZmVyZW5jZT48L1Np 767 |Z25lZEluZm8+PFNpZ25hdHVyZVZhbHVlPkZjYjNxNGlCdmRmZ1lvN245NUdhUUN1 768 |ZDkxWVA3dzhvVjAzUjZ6a1JEZGxjK0RuQ2MwcjlNc0E1YS9iaFlDeVdQZC9jRVU4 769 |K3FZRnJ5SmJjaXJ5d0hBPT08L1NpZ25hdHVyZVZhbHVlPjxLZXlJbmZvPjxYNTA5 770 |RGF0YT48WDUwOUNlcnRpZmljYXRlPk1JSUIwRENDQVg4Q0VDdjF4aDdDRWIwWHg5 771 |elVZbWEwTGlFd0NBWUdLb1VEQWdJRE1HMHhIekFkQmdOVkJBTU1Ga2R2YzNSU016 772 |UXhNQzB5TURBeElHVjRZVzF3YkdVeEVqQVFCZ05WQkFvTUNVTnllWEIwYjFCeWJ6 773 |RUxNQWtHQTFVRUJoTUNVbFV4S1RBbkJna3Foa2lHOXcwQkNRRVdHa2R2YzNSU016 774 |UXhNQzB5TURBeFFHVjRZVzF3YkdVdVkyOXRNQjRYRFRBMU1EZ3hOakUwTVRneU1G 775 |b1hEVEUxTURneE5qRTBNVGd5TUZvd2JURWZNQjBHQTFVRUF3d1dSMjl6ZEZJek5E 776 |RXdMVEl3TURFZ1pYaGhiWEJzWlRFU01CQUdBMVVFQ2d3SlEzSjVjSFJ2VUhKdk1R 777 |c3dDUVlEVlFRR0V3SlNWVEVwTUNjR0NTcUdTSWIzRFFFSkFSWWFSMjl6ZEZJek5E 778 |RXdMVEl3TURGQVpYaGhiWEJzWlM1amIyMHdZekFjQmdZcWhRTUNBaE13RWdZSEtv 779 |VURBZ0lrQUFZSEtvVURBZ0llQVFOREFBUkFoSlZvZFdBQ0drQjFDTTBUakRHSkxQ 780 |M2xCUU42UTF6MGJTc1A1MDh5ZmxlUDY4d1d1WldJQTlDYWZJV3VEK1NONnFhN2Zs 781 |Ykh5N0RmRDJhOHl1b2FZREFJQmdZcWhRTUNBZ01EUVFBOEw4a0pSTGNucWV5bjFl 782 |bjdVMjNTdzZwa2ZFUXUzdTB4RmtWUHZGUS8zY0hlRjI2TkcreHh0WlB6M1RhVFZY 783 |ZG9pWWtYWWlEMDJyRXgxYlVjTTk3aTwvWDUwOUNlcnRpZmljYXRlPjwvWDUwOURh 784 |dGE+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjwvQ3J5cHRvUHJvWE1MPg== 785 |