idnits 2.17.1 draft-chudov-cryptopro-cpxmldsig-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == 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 19, 2008) is 5606 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-1' is mentioned on line 984, but not defined == Missing Reference: '1-3' is mentioned on line 984, but not defined == Missing Reference: 'Dig' is mentioned on line 656, but not defined == Missing Reference: 'Enc' is mentioned on line 658, but not defined == Missing Reference: 'Sym KW' is mentioned on line 660, but not defined == Missing Reference: 'Asym KW' is mentioned on line 662, but not defined == Missing Reference: 'Enc KD' is mentioned on line 679, but not defined == Missing Reference: 'Sig KD' is mentioned on line 679, but not defined == Missing Reference: 'Min SKL' is mentioned on line 670, but not defined == Missing Reference: 'Max SKL' is mentioned on line 672, but not defined == Missing Reference: 'Min AKL' is mentioned on line 674, but not defined == Missing Reference: 'Max AKL' is mentioned on line 676, but not defined Summary: 0 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Leontiev 3 Internet-Draft P. Smirnov 4 Intended status: Informational A. Chelpanov 5 Expires: June 22, 2009 CRYPTO-PRO 6 December 19, 2008 8 Using GOST 28147-89, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms 9 for XML Security 10 draft-chudov-cryptopro-cpxmldsig-04 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 22, 2009. 35 Copyright Notice 37 Copyright (c) 2008 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This document specifies how to use Russian national cryptographic 50 standards GOST 28147-89, GOST R 34.10-2001 and GOST R 34.11-94 with 51 XML Signatures, XML Encryption, WS-SecureConversation, WS- 52 SecurityPolicy and WS-Trust. A number of Uniform Resource 53 Identifiers (URIs) and XML elements are defined. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. GOST Cryptographic Algorithms . . . . . . . . . . . . . . . . 4 59 3. Version and Namespaces . . . . . . . . . . . . . . . . . . . . 4 60 4. XML Schema Preamble and DTD Replacement . . . . . . . . . . . 5 61 4.1. XML Schema Preamble . . . . . . . . . . . . . . . . . . . 6 62 4.2. DTD Replacement . . . . . . . . . . . . . . . . . . . . . 6 63 5. Object Identifiers Representation . . . . . . . . . . . . . . 6 64 6. Specifying GOST within XML Signature and XML Encryption . . . 6 65 6.1. GOST R 34.11-94 Algorithm in DigestMethod . . . . . . . . 7 66 6.2. GOST R 34.11-94 HMAC Algorithm in SignatureMethod . . . . 7 67 6.3. GOST R 34.10-2001 Algorithm in SignatureMethod . . . . . . 8 68 6.4. GOST R 34.10-2001 Public Key in KeyValue . . . . . . . . . 8 69 6.4.1. Key Value Root Element . . . . . . . . . . . . . . . . 8 70 6.4.2. Public Key Parameters . . . . . . . . . . . . . . . . 9 71 6.5. GOST R 34.10-2001-based Key Agreement Algorithm in 72 AgreementMethod . . . . . . . . . . . . . . . . . . . . . 10 73 6.6. GOST R 34.10-2001-based Key Transport Algorithm in 74 EncryptionMethod . . . . . . . . . . . . . . . . . . . . . 11 75 6.7. GOST 28147-89 Algorithm in EncryptionMethod . . . . . . . 11 76 6.8. Symmetric Key Wrap . . . . . . . . . . . . . . . . . . . . 12 77 6.8.1. GOST 28147-89 Key Wrap in EncryptionMethod . . . . . . 12 78 6.8.2. CryptoPro Key Wrap in EncryptionMethod . . . . . . . . 14 79 7. Specifying GOST within WS-* . . . . . . . . . . . . . . . . . 16 80 7.1. GOST Algorithm Suite for WS-SecurityPolicy . . . . . . . . 16 81 7.2. GOST Key Derivation Algorithm for WS-SecureConversation . 17 82 7.3. GOST Computed Key Mechanism for WS-Trust . . . . . . . . . 17 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 85 9.1. URN Sub-Namespace Registration for 86 urn:ietf:params:xml:ns:cpxmlsec . . . . . . . . . . . . . 18 87 9.2. Schema Registration . . . . . . . . . . . . . . . . . . . 19 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 89 10.1. Normative references . . . . . . . . . . . . . . . . . . . 19 90 10.2. Informative references . . . . . . . . . . . . . . . . . . 22 91 Appendix A. Aggregate XML Schema . . . . . . . . . . . . . . . . 22 92 Appendix B. Aggregate DTD . . . . . . . . . . . . . . . . . . . . 24 93 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 24 94 C.1. Signed document . . . . . . . . . . . . . . . . . . . . . 24 95 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 98 1. Introduction 100 This document specifies how to use GOST R 34.10-2001 digital 101 signatures and public keys, GOST R 34.11-94 hash, GOST 28147-89 102 encryption algorithms with XML Signatures [XMLDSIG], XML Encryption 103 [XMLENC-CORE], WS-SecureConversation [WS-SECURECONVERSATION], WS- 104 SecurityPolicy [WS-SECURITYPOLICY] and WS-Trust [WS-TRUST]. 106 This document uses both XML Schemas ([XML-SCHEMA-1], [XML-SCHEMA-2]) 107 (normative) and DTDs [XML] (informational) to specify the 108 corresponding XML structures. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 111 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 112 this document are to be interpreted as described in [KEYWORDS]. 114 2. GOST Cryptographic Algorithms 116 Algorithms GOST R 34.10-2001, GOST R 34.11-94 and GOST 28147-89 have 117 been developed by Russian Federal Agency of Governmental 118 Communication and Information (FAGCI) and "All-Russian Scientific and 119 Research Institute of Standardization". They are described in 120 [GOSTR341001], [GOSTR341194] ([GOST3431004] and [GOST3431195]) and 121 [GOST28147]. RECOMMENDED parameters for those algorithms are 122 described in [CPALGS]. 124 3. Version and Namespaces 126 This specification makes no provision for an explicit version number 127 in the syntax. If a future version is needed, it will use a 128 different namespace. 130 The XML namespace [XML-NS] URI [RFC3986] that MUST be used by 131 implementations of this (dated) specification is: 133 urn:ietf:params:xml:ns:cpxmlsec 135 The following external XML namespaces are used in this specification 136 (without line breaks; the choice of any namespace prefix is arbitrary 137 and not semantically significant): 139 http://www.w3.org/2000/09/xmldsig# 140 Prefix: 141 dsig 143 Specification: 144 [XMLDSIG] 146 http://www.w3.org/2001/04/xmlenc# 147 Prefix: 148 xenc 149 Specification: 150 [XMLENC-CORE] 152 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 153 Prefix: 154 sp 155 Specification: 156 [WS-SECURITYPOLICY] 158 http://www.w3.org/ns/ws-policy 159 Prefix: 160 wsp 161 Specification: 162 [WS-POLICY] 164 http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 165 Prefix: 166 wsc 167 Specification: 168 [WS-SECURECONVERSATION] 170 http://docs.oasis-open.org/wss/2004/01/ 171 oasis-200401-wss-wssecurity-secext-1.0.xsd 172 Prefix: 173 wsse 174 Specification: 175 [WS-SECURITY] 177 http://docs.oasis-open.org/ws-sx/ws-trust/200512/ 178 Prefix: 179 wst 180 Specification: 181 [WS-TRUST] 183 In the remaining sections of this document elements in the external 184 namespaces are marked as such by using the namespace prefixes defined 185 above. 187 4. XML Schema Preamble and DTD Replacement 188 4.1. XML Schema Preamble 190 The subsequent preamble is to be used with the XML Schema definitions 191 given in the remaining sections of this document. 193 202 4.2. DTD Replacement 204 In order to include GOST XML-signature syntax, the following 205 definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 207 209 5. Object Identifiers Representation 211 Object Identifiers (OIDs) are included in XML by the corresponding 212 URN value as defined in [URNOID]. 214 The subsequent type is to be used to define algorithm parameters by 215 OIDs: 217 218 219 221 222 224 6. Specifying GOST within XML Signature and XML Encryption 226 This section specifies the details of how to use GOST algorithms with 227 XML Signature Syntax and Processing [XMLDSIG] and XML Encryption 228 Syntax and Processing [XMLENC-CORE]. It relies heavily on syntaxes 229 and namespaces defined in [XMLDSIG] and [XMLENC-CORE]. 231 6.1. GOST R 34.11-94 Algorithm in DigestMethod 233 The identifier for the GOST R 34.11-94 digest algorithm is: 235 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 237 The dsig:DigestMethod node may contain a child node cpxmlsec: 238 ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. 239 cpxmlsec:ParametersR3411 node contains one OID specified in section 240 8.2 [CPALGS]. If cpxmlsec:ParametersR3411 node is missing, the 241 application should infer algorithm parameters from other sources. 243 If the application omits cpxmlsec:ParametersR3411 node, it SHOULD use 244 parameters defined by id-GostR3411-94-CryptoProParamSet (see Section 245 11.2 of [CPALGS]). 247 Schema Definition: 249 252 DTD Definition: 254 256 An example of a GOST R 34.11-94 dsig:DigestMethod node is: 258 260 261 urn:oid:1.2.643.2.2.30.1< 262 /cpxmlsec:ParametersR3411> 263 265 A GOST R 34.11-94 digest is a 256-bit string. The content of the 266 dsig:DigestValue element shall be the base64 [RFC4648] encoding of 267 this bit string viewed as a 32-octet octet stream. 269 6.2. GOST R 34.11-94 HMAC Algorithm in SignatureMethod 271 GOST R 34.11-94 can also be used in HMAC [HMAC] as described in 272 section 6.3.1 of [XMLDSIG]. Identifier: 274 urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 276 The dsig:SignatureMethod node may contain a child node cpxmlsec: 277 ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. 278 cpxmlsec:ParametersR3411 node syntax and processing in this case are 279 equivalent to the ones in dsig:DigestMethod case. 281 An example of a GOST R 34.11-94 HMAC disg:SignatureMethod node is: 283 285 286 urn:oid:1.2.643.2.2.30.1< 287 /cpxmlsec:ParametersR3411> 288 290 The output of the GOST R 34.11-94 HMAC algorithm is ultimately the 291 output of the GOST R 34.11-94 digest algorithm. This value shall be 292 base64 [RFC4648] encoded for the dsig:SignatureValue in the same 293 straightforward fashion as the output of the digest algorithm. 295 6.3. GOST R 34.10-2001 Algorithm in SignatureMethod 297 The input to the GOST R 34.10-2001 algorithm is the canonicalized 298 representation of the dsig:SignedInfo element as specified in Section 299 3 of [XMLDSIG]. 301 The identifier for the GOST R 34.10-2001 signature algorithm is 302 (without line break): 304 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411 306 An example of a GOST R 34.10-2001 dsig:SignatureMethod node is 307 (without line break in attribute value): 309 313 GOST R 34.10-2001 signature is a 64-octet value as described in 314 section 2.2 of [CPPK]. The content of the dsig:SignatureValue 315 element shall be the base64 [RFC4648] encoding of this value. 317 6.4. GOST R 34.10-2001 Public Key in KeyValue 319 6.4.1. Key Value Root Element 321 GOST R 34.10-2001 public key can be transmitted in cpxmlsec: 322 GOSTKeyValue node. It is included in dsig:KeyValue node just like 323 dsig:RSAKeyValue or xenc:DHKeyValue. 325 cpxmlsec:GOSTKeyValue node consists of an optional child node 326 cpxmlsec:PublicKeyParameters and a mandatory child node cpxmlsec: 328 PublicKey. If cpxmlsec:PublicKeyParameters node is missing, the 329 application should infer parameters from other sources. 331 Schema Definition: 333 336 337 338 341 342 343 345 DTD Definition: 347 349 351 If the application omits cpxmlsec:PublicKeyParameters node, it SHOULD 352 use parameters identified by DefaultPublicKeyParameters. 354 DefaultPublicKeyParameters: 356 357 358 urn:oid:1.2.643.2.2.35.1< 359 /cpxmlsec:publicKeyParamSet> 360 361 urn:oid:1.2.643.2.2.30.1 363 364 urn:oid:1.2.643.2.2.31.1 366 368 6.4.2. Public Key Parameters 370 cpxmlsec:PublicKeyParameters node contains three OIDs: cpxmlsec: 371 publicKeyParamSet, cpxmlsec:digestParamSet and optional cpxmlsec: 372 encryptionParamSet. Parameter values corresponding to these OIDs can 373 be found in [CPALGS]. 375 Schema Definition: 377 378 379 381 383 386 387 389 DTD Definition: 391 394 395 396 398 6.5. GOST R 34.10-2001-based Key Agreement Algorithm in AgreementMethod 400 Key agreement algorithm based on GOST R 34.10-2001 public keys (see 401 Section 5 of [CPALGS]) involves the derivation of shared secret 402 information using keys from the sender and recipient. 404 The identifier for the key agreement algorithm based on GOST R 34.10- 405 2001 is: 407 urn:ietf:params:xml:ns:cpxmlsec:algorithms:agree-gost2001 409 An example of a GOST R 34.10-2001-based key agreement AgreementMethod 410 node is: 412 414 ... 415 416 417 ... 418 419 420 421 ... 422 424 426 The shared keying material for algorithm based on GOST R 34.10-2001 427 needed will be calculated as a result of function VKO GOST R 34.10- 428 2001 (see Section 5.2 of [CPALGS]), which generates GOST KEK using 429 two GOST R 34.10-2001 keypairs and UKM. xenc:KA-Nonce node of xenc: 430 AgreementMethod contains base64 encoded 64-bits value of UKM, if UKM 431 is used. 433 6.6. GOST R 34.10-2001-based Key Transport Algorithm in 434 EncryptionMethod 436 The key transport alogorithm based on VKO GOST R 34.10-2001, 437 specified in [CPALGS], is public key encryption algorithms, that MUST 438 be used for key encryption/decryption only. 440 The identifier for the key transport algorithm based on VKO 441 GOST R 34.10-2001 is: 443 urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 445 An example of a VKO GOST R 34.10-2001-based key transport 446 EncryptedKey node is: 448 449 451 452 453 ... 454 455 456 457 ... 458 459 461 The CipherValue for such encrypted key is the base64 encoding of the 462 [X.208-88] DER encoding of a GostR3410-KeyTransport structure (see 463 section 4.2.1 of [CPCMS]). 465 6.7. GOST 28147-89 Algorithm in EncryptionMethod 467 The identifier for the GOST 28147-89 symmetric encryption algorithm 468 is: 470 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 472 The xenc:EncryptionMethod node may contain a child node cpxmlsec: 473 Parameters28147 specifying parameters for GOST 28147-89 algorithm. 474 cpxmlsec:Parameters28147 specifies the set of corresponding 475 Gost28147-89-ParamSetParameters (see Section 8.1 of [CPALGS]). 476 Encryption mode is specified by mode parameter of Gost28147-89- 477 ParamSetParameters structure. CFB and CNT modes are RECOMMENDED to 478 use. If cpxmlsec:Parameters28147 node is missing, the application 479 should infer algorithm parameters from other sources. 481 If the application omits cpxmlsec:Parameters28147 node, it SHOULD use 482 parameters defined by id-Gost28147-89-CryptoPro-A-ParamSet (see 483 Section of 10.2 [CPALGS]). 485 Schema Definition: 487 490 DTD Definition: 492 494 An example of a GOST 28147-89 xenc:EncryptionMethod node is: 496 498 499 urn:oid:1.2.643.2.2.31.1< 500 /cpxmlsec:Parameters28147> 501 503 256-bit key, 64-bit Initialization Vector (IV), and optional 504 parameters are used in GOST 28147-89 encryption algorithm. The 505 resulting cipher text is prefixed by the IV. If included in XML 506 output, it is then base64 encoded. 508 6.8. Symmetric Key Wrap 510 Symmetric Key Wrap algorithms considered in this section are shared 511 secret key encryption algorithms that MUST be used for symmetric keys 512 encryption/decryption only. 514 6.8.1. GOST 28147-89 Key Wrap in EncryptionMethod 516 The GOST 28147-89 Key Wrap algorithm wraps (encrypts) a key (the 517 wrapped key, WK) under a GOST 28147-89 Key Wrap (specified in 518 sections 6.1, 6.2 of [CPALGS]). 520 Note: This algorithm MUST NOT be used without key agreement 521 algorithm, because such WK is constant for every wrapping-encrypting 522 pair. Encrypting many different keys with the same constant WK may 523 reveal that WK. The only key agreement algorithm possible to use 524 with GOST 28147-89 Key Wrap defined by this specification is a 525 GOST R 34.10-2001-based key agreement (see Section 6.5). 527 The identifier for the GOST 28147-89 Key Wrap algorithm is: 529 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-gost 531 The CipherValue for such wrapped key is the base64 encoding of the 532 [X.208-88] DER encoding of a GostR3410-KeyWrap structure. 534 ASN.1 structure: 536 GostR3410-KeyWrap ::= 537 SEQUENCE { 538 encryptedKey Gost28147-89-EncryptedKey, 539 encryptedParameters Gost28147-89-KeyWrapParameters 540 } 542 An example of a GOST 28147-89 Key Wrap EncryptedData node is: 544 545 547 548 549 551 552 554 ... 555 556 557 ... 558 559 560 561 ... 562 563 564 565 566 ... 567 568 569 570 571 ... 572 573 575 Gost28147-89-KeyWrapParameters is described in section 4.1.1 of 576 [CPCMS]. The xenc:KA-Nonce node value of the xenc:AgreementMethod 577 node MUST be used as ukm. 579 The resulting wrapped key (WK) is placed in the Gost28147-89- 580 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 581 Gost28147-89-EncryptedKey macKey field. ukm field of Gost28147-89- 582 KeyWrapParameters MUST be absent. 584 6.8.2. CryptoPro Key Wrap in EncryptionMethod 586 The CryptoPro Key Wrap algorithm wraps (encrypts) a key (wrapped key, 587 WK) under a CryptoPro Key Wrap (specified in sections 6.3, 6.4 of 588 [CPALGS]). 590 The identifier for the CryptoPro Key Wrap algorithms is: 592 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp 594 The CipherValue for such wrapped key is the base64 encoding of the 595 [X.208-88] DER encoding of a GostR3410-KeyWrap structure (see 596 Section 6.8.1). 598 An example of a CryptoPro Key Wrap EncryptedData node is: 600 601 603 604 605 607 608 John Smith 609 610 611 ... 612 613 614 615 616 ... 617 618 620 The resulting wrapped key (WK) is placed in the Gost28147-89- 621 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 622 Gost28147-89-EncryptedKey macKey field. 624 If CryptoPro Key Wrap algorithm is combined with Key Agreement 625 Algorithm, the xenc:KA-Nonce node value of the xenc:AgreementMethod 626 node MUST be used as ukm. ukm field of Gost28147-89-KeyWrapParameters 627 type must be absent. 629 Note: The only key agreement algorithm possible to use with CryptoPro 630 Key Wrap defined by this specification is a GOST R 34.10-2001-based 631 key agreement (see Section 6.5). 633 If CryptoPro Key Wrap algorithm is not combined with Key Agreement 634 Algorithm, ukm field of Gost28147-89-KeyWrapParameters type MUST be 635 present. 637 7. Specifying GOST within WS-* 639 This section specifies the details of how to use GOST algorithms with 640 WS-SecureConversation [WS-SECURECONVERSATION], WS-SecurityPolicy 641 [WS-SECURITYPOLICY] and WS-Trust [WS-TRUST]. 643 7.1. GOST Algorithm Suite for WS-SecurityPolicy 645 This specification defines a new possible value for an [Algorithm 646 Suite] property of a Security Binding (see section 6.1 of 647 [WS-SECURITYPOLICY]). The new value is BasicGost. 649 BasicGost Algorithm Suite defines the following values for operations 650 and properties (without line breaks in URIs): 651 [Sym Sig] 652 urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 653 [Asym Sig] 654 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001- 655 gostr3411 656 [Dig] 657 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 658 [Enc] 659 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 660 [Sym KW] 661 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp 662 [Asym KW] 663 urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 664 [Comp Key] 665 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 666 [Enc KD] 667 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 668 [Sig KD] 669 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 670 [Min SKL] 671 256 672 [Max SKL] 673 256 674 [Min AKL] 675 512 676 [Max AKL] 677 512 679 Note: For definition of [Comp Key], [Enc KD] and [Sig KD] algorithm 680 see Section 7.2 682 To indicate a requirement to use GOST Algorithm Suite defined above 683 conforming implementaions MUST place cpxmlsec:BasicGost node in sp: 684 AlgorithmSuite Assertion (see section 7.1 of [WS-SECURITYPOLICY]). 686 Schema Definition: 688 691 DTD Definition: 693 695 An example of a GOST Algorithm Suite in sp:AlgorithmSuite Assertion 696 is: 698 699 700 701 702 704 7.2. GOST Key Derivation Algorithm for WS-SecureConversation 706 This specification defines a new possible value for an Algorithm 707 attribute of a wsc:DerivedKeyToken node (see section 7 of 708 [WS-SECURECONVERSATION]). 710 The new key derivation algorithm identifier is: 712 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 714 An example of a GOST Key Derivation Algorithm in wsc:DerivedKeyToken 715 node is: 717 719 ... 720 ... 721 723 GOST Key Derivation Algorithm uses a pseudorandom function 724 P_GOSTR3411 (see section 4 of [CPALGS]) to derive keys just like a 725 P_SHA-1 function is used in [WS-SECURECONVERSATION] (see section 7). 727 7.3. GOST Computed Key Mechanism for WS-Trust 729 This specification defines a new possible value for a wst:ComputedKey 730 node (see section 4.4.4 of [WS-TRUST]). 732 The new computed key mechanism identifier is: 734 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 736 An example of a GOST Computed Key Mechanism in wst:ComputedKey node 737 (without line breaks) is: 739 740 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 741 743 GOST Computed Key Mechanism uses a pseudorandom function P_GOSTR3411 744 (see section 4 of [CPALGS]) to compute a key just like a P_SHA-1 745 function is used in [WS-TRUST] (see section 4.4.4). It is REQUIRED 746 that EntREQ and EntRES are strings of length 256 bits. 748 8. Security Considerations 750 Conforming applications MUST use unique values for ukm and iv. 751 Recipients MAY verify that ukm and iv specified by the sender are 752 unique. 754 Applications SHOULD verify signature values, subject public keys and 755 algorithm parameters to conform to [GOSTR341001], standard before 756 using them. 758 Cryptographic algorithm parameters affect algorithm strength. Using 759 parameters not listed in [CPALGS] is NOT RECOMMENDED (see the 760 Security Considerations section of [CPALGS]). 762 Using the same key for signature and key derivation is NOT 763 RECOMMENDED. 765 It is NOT RECOMMENDED to use XML encryption without XML signature or 766 HMAC. 768 9. IANA Considerations 770 This document uses URNs to describe XML namespaces and XML schemas 771 conforming to a registry mechanism described in [RFC3688]. IANA has 772 registered two URI assignments. 774 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpxmlsec 776 URI: urn:ietf:params:xml:ns:cpxmlsec 778 Registrant Contact: 780 Mikhail V. Pavlov 781 CRYPTO-PRO, Ltd. 782 16/5, Suschevskij val 783 Moscow, 127018 784 Russia 785 Phone: +7 (495) 780 4820 786 Fax: +7 (495) 660 2330 787 Email: pav@CryptoPro.ru 788 URI: http://www.CryptoPro.ru 790 XML: None. Namespace URIs do not represent an XML specification. 792 9.2. Schema Registration 794 URI: urn:ietf:params:xml:schema:cpxmlsec 796 Registrant Contact: 797 Mikhail V. Pavlov 798 CRYPTO-PRO, Ltd. 799 16/5, Suschevskij val 800 Moscow, 127018 801 Russia 802 Phone: +7 (495) 780 4820 803 Fax: +7 (495) 660 2330 804 Email: pav@CryptoPro.ru 805 URI: http://www.CryptoPro.ru 807 XML: The XML can be found in Appendix A. 809 10. References 811 10.1. Normative references 813 [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 814 Cryptographic Algorithms for Use with GOST 28147-89, 815 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 816 Algorithms", RFC 4357, January 2006. 818 [CPCMS] Leontiev, S. and G. Chudov, "Using the GOST 28147-89, 819 GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 820 Algorithms with Cryptographic Message Syntax (CMS)", 821 RFC 4490, May 2006. 823 [CPPK] Leontiev, S. and D. Shefanovski, "Using the 824 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 825 Algorithms with the Internet X.509 Public Key 826 Infrastructure Certificate and CRL Profile", RFC 4491, 827 May 2006. 829 [GOST28147] 830 Government Committee of the USSR for Standards, 831 "Cryptographic Protection for Data Processing System, 832 Gosudarstvennyi Standard of USSR (In Russian)", 833 GOST 28147-89, 1989. 835 [GOST3431004] 836 Council for Standardization, Metrology and Certification 837 of the Commonwealth of Independence States (EASC), Minsk, 838 "Information technology. Cryptographic Data Security. 839 Formation and verification processes of (electronic) 840 digital signature based on Asymmetric Cryptographic 841 Algorithm (In Russian)", GOST 34.310-2004, 2004. 843 [GOST3431195] 844 Council for Standardization, Metrology and Certification 845 of the Commonwealth of Independence States (EASC), Minsk, 846 "Information technology. Cryptographic Data Security. 847 Cashing function (In Russian)", GOST 34.311-95, 1995. 849 [GOSTR341001] 850 Government Committee of the Russia for Standards, 851 "Information technology. Cryptographic Data 852 Security.Signature and verification processes of 853 [electronic] digital signature, Gosudarstvennyi Standard 854 of Russian Federation (In Russian)", GOST R 34.10-2001, 855 2001. 857 [GOSTR341194] 858 Government Committee of the Russia for Standards, 859 "Information technology. Cryptographic Data Security. 860 Hashing function, Gosudarstvennyi Standard of Russian 861 Federation (In Russian)", GOST R 34.11-94, 1994. 863 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 864 Hashing for Message Authentication", RFC 2104, 865 February 1997. 867 [KEYWORDS] 868 Bradner, S., "Key words for use in RFCs to Indicate 869 Requirement Levels", BCP 14, RFC 2119, March 1997. 871 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 872 January 2004. 874 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 875 Resource Identifier (URI): Generic Syntax", STD 66, 876 RFC 3986, January 2005. 878 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 879 Encodings", RFC 4648, October 2006. 881 [WS-POLICY] 882 Vedamuthu, A., Orchard, D., Hirsch, F., Hondo, M., 883 Yendluri, P., Boubez, T., and Ue. Yalcinalp, "Web Services 884 Policy 1.5 - Framework", W3C REC-ws-policy, 885 September 2007, . 887 [WS-SECURECONVERSATION] 888 Lawrence, K. and C. Kaler, "WS-SecureConversation 1.3", 889 OASIS Standard ws-secureconversation-1.3-os, March 2007, < 890 http://docs.oasis-open.org/ws-sx/ws-secureconversation/ 891 200512/ws-secureconversation-1.3-os.html>. 893 [WS-SECURITY] 894 Lawrence, K. and C. Kaler, "Web Services Security: SOAP 895 Message Security 1.1 (WS-Security 2004)", OASIS 896 Standard wss-v1.1-spec-os-SOAPMessageSecurity, 897 Febraury 2006, . 900 [WS-SECURITYPOLICY] 901 Lawrence, K. and C. Kaler, "WS-SecurityPolicy 1.2", OASIS 902 Standard ws-securitypolicy-1.2-spec-os, July 2007, . 906 [WS-TRUST] 907 Lawrence, K. and C. Kaler, "WS-Trust 1.3", OASIS 908 Standard ws-trust-1.3-os, March 2007, . 912 [X.208-88] 913 International International Telephone and Telegraph 914 Consultative Committee, "Specification of Abstract Syntax 915 Notation One (ASN.1)", CCITT Recommendation X.208, 916 November 1988. 918 [XML-NS] Bray, T., Hollander, D., Layman, A., and R. Tobin, 919 "Namespaces in XML (Second Edition)", W3C REC-xml-names, 920 August 2006, 921 . 923 [XML-SCHEMA-1] 924 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 925 "XML Schema Part 1: Structures Second Edition", W3C REC- 926 xmlschema-1, October 2004, 927 . 929 [XML-SCHEMA-2] 930 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 931 Second Edition", W3C REC-xmlschema-2, October 2004, 932 . 934 [XMLDSIG] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 935 Language) XML-Signature Syntax and Processing", RFC 3275, 936 March 2002. 938 [XMLENC-CORE] 939 Eastlake, D. and J. Reagle , "XML Encryption Syntax and 940 Processing", W3C Candidate Recommendation xmlenc-core, 941 August 2002, . 943 10.2. Informative references 945 [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 946 July 2005. 948 [URNOID] Mealling, M., "A URN Namespace of Object Identifiers", 949 RFC 3061, February 2001. 951 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 952 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 953 Edition)", W3C REC-xml, August 2006, 954 . 956 Appendix A. Aggregate XML Schema 958 960 962 965 ]> 967 976 981 982 983 985 986 988 991 993 994 995 998 999 1000 1002 1003 1004 1006 1008 1011 1012 1014 1017 1020 1022 Appendix B. Aggregate DTD 1024 1026 1027 1030 1031 1032 1033 1034 1035 1037 Appendix C. Examples 1039 Examples here are stored in the same format as the examples in 1040 [RFC4134] and can be extracted using the same program. 1042 If you want to extract without the program, copy all the lines 1043 between the "|>" and "|<" markers, remove any page breaks, and remove 1044 the "|" in the first column of each line. The result is a valid 1045 Base64 blob that can be processed by any Base64 decoder. 1047 C.1. Signed document 1049 This sample contain the signed XML document using the sample 1050 certificate from Section 4.2 of [CPPK]. 1052 |>XmlDocSigned2001.xml 1053 |PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48Q3J5cHRvUHJv 1054 |WE1MIFNpZ25lZD0idHJ1ZSI+SGVyZSBpcyBzb21lIGRhdGEgdG8gc2lnbi48U2ln 1055 |bmF0dXJlIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcj 1056 |Ij48U2lnbmVkSW5mbz48Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09 1057 |Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1 1058 |IiAvPjxTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9y 1059 |Zy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0cjM0MTAyMDAxLWdvc3RyMzQxMSIg 1060 |Lz48UmVmZXJlbmNlIFVSST0iIj48VHJhbnNmb3Jtcz48VHJhbnNmb3JtIEFsZ29y 1061 |aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 1062 |ZC1zaWduYXR1cmUiIC8+PC9UcmFuc2Zvcm1zPjxEaWdlc3RNZXRob2QgQWxnb3Jp 1063 |dGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0 1064 |cjM0MTEiIC8+PERpZ2VzdFZhbHVlPi9Kd3RRc3Z5NWsvUjBWZUx6ZG0ySWlqUEJ0 1065 |U0o1cEpSalQ5RlVRSEV5VGc9PC9EaWdlc3RWYWx1ZT48L1JlZmVyZW5jZT48L1Np 1066 |Z25lZEluZm8+PFNpZ25hdHVyZVZhbHVlPkZjYjNxNGlCdmRmZ1lvN245NUdhUUN1 1067 |ZDkxWVA3dzhvVjAzUjZ6a1JEZGxjK0RuQ2MwcjlNc0E1YS9iaFlDeVdQZC9jRVU4 1068 |K3FZRnJ5SmJjaXJ5d0hBPT08L1NpZ25hdHVyZVZhbHVlPjxLZXlJbmZvPjxYNTA5 1069 |RGF0YT48WDUwOUNlcnRpZmljYXRlPk1JSUIwRENDQVg4Q0VDdjF4aDdDRWIwWHg5 1070 |elVZbWEwTGlFd0NBWUdLb1VEQWdJRE1HMHhIekFkQmdOVkJBTU1Ga2R2YzNSU016 1071 |UXhNQzB5TURBeElHVjRZVzF3YkdVeEVqQVFCZ05WQkFvTUNVTnllWEIwYjFCeWJ6 1072 |RUxNQWtHQTFVRUJoTUNVbFV4S1RBbkJna3Foa2lHOXcwQkNRRVdHa2R2YzNSU016 1073 |UXhNQzB5TURBeFFHVjRZVzF3YkdVdVkyOXRNQjRYRFRBMU1EZ3hOakUwTVRneU1G 1074 |b1hEVEUxTURneE5qRTBNVGd5TUZvd2JURWZNQjBHQTFVRUF3d1dSMjl6ZEZJek5E 1075 |RXdMVEl3TURFZ1pYaGhiWEJzWlRFU01CQUdBMVVFQ2d3SlEzSjVjSFJ2VUhKdk1R 1076 |c3dDUVlEVlFRR0V3SlNWVEVwTUNjR0NTcUdTSWIzRFFFSkFSWWFSMjl6ZEZJek5E 1077 |RXdMVEl3TURGQVpYaGhiWEJzWlM1amIyMHdZekFjQmdZcWhRTUNBaE13RWdZSEtv 1078 |VURBZ0lrQUFZSEtvVURBZ0llQVFOREFBUkFoSlZvZFdBQ0drQjFDTTBUakRHSkxQ 1079 |M2xCUU42UTF6MGJTc1A1MDh5ZmxlUDY4d1d1WldJQTlDYWZJV3VEK1NONnFhN2Zs 1080 |Ykh5N0RmRDJhOHl1b2FZREFJQmdZcWhRTUNBZ01EUVFBOEw4a0pSTGNucWV5bjFl 1081 |bjdVMjNTdzZwa2ZFUXUzdTB4RmtWUHZGUS8zY0hlRjI2TkcreHh0WlB6M1RhVFZY 1082 |ZG9pWWtYWWlEMDJyRXgxYlVjTTk3aTwvWDUwOUNlcnRpZmljYXRlPjwvWDUwOURh 1083 |dGE+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjwvQ3J5cHRvUHJvWE1MPg== 1084 |