idnits 2.17.1 draft-chudov-cryptopro-cpxmldsig-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (November 26, 2009) is 5266 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-1' is mentioned on line 1040, but not defined == Missing Reference: '1-3' is mentioned on line 1040, 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 680, but not defined == Missing Reference: 'Sig KD' is mentioned on line 680, but not defined == Missing Reference: 'Min SKL' is mentioned on line 670, but not defined == Missing Reference: 'Max SKL' is mentioned on line 673, but not defined == Missing Reference: 'Min AKL' is mentioned on line 675, but not defined == Missing Reference: 'Max AKL' is mentioned on line 677, but not defined ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 2 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: May 30, 2010 CRYPTO-PRO 6 November 26, 2009 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-06 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 May 30, 2010. 35 Copyright Notice 37 Copyright (c) 2009 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 in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document specifies how to use Russian national cryptographic 49 standards GOST 28147-89, GOST R 34.10-2001 and GOST R 34.11-94 with 50 XML Signatures, XML Encryption, WS-SecureConversation, WS- 51 SecurityPolicy and WS-Trust. A number of Uniform Resource 52 Identifiers (URIs) and XML elements are defined. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. GOST Cryptographic Algorithms . . . . . . . . . . . . . . . . 4 58 3. Version and Namespaces . . . . . . . . . . . . . . . . . . . . 4 59 4. XML Schema Preamble and DTD Replacement . . . . . . . . . . . 5 60 4.1. XML Schema Preamble . . . . . . . . . . . . . . . . . . . 6 61 4.2. DTD Replacement . . . . . . . . . . . . . . . . . . . . . 6 62 5. Object Identifiers Representation . . . . . . . . . . . . . . 6 63 6. Specifying GOST within XML Signature and XML Encryption . . . 6 64 6.1. GOST R 34.11-94 Algorithm in DigestMethod . . . . . . . . 7 65 6.2. GOST R 34.11-94 HMAC Algorithm in SignatureMethod . . . . 7 66 6.3. GOST R 34.10-2001 Algorithm in SignatureMethod . . . . . . 8 67 6.4. GOST R 34.10-2001 Public Key in KeyValue . . . . . . . . . 9 68 6.4.1. Key Value Root Element . . . . . . . . . . . . . . . . 9 69 6.4.2. Public Key Parameters . . . . . . . . . . . . . . . . 10 70 6.5. GOST R 34.10-2001-based Key Agreement Algorithm in 71 AgreementMethod . . . . . . . . . . . . . . . . . . . . . 11 72 6.6. GOST R 34.10-2001-based Key Transport Algorithm in 73 EncryptionMethod . . . . . . . . . . . . . . . . . . . . . 11 74 6.7. GOST 28147-89 Algorithm in EncryptionMethod . . . . . . . 12 75 6.8. Symmetric Key Wrap . . . . . . . . . . . . . . . . . . . . 13 76 6.8.1. GOST 28147-89 Key Wrap in EncryptionMethod . . . . . . 13 77 6.8.2. CryptoPro Key Wrap in EncryptionMethod . . . . . . . . 15 78 7. Specifying GOST within WS-* . . . . . . . . . . . . . . . . . 16 79 7.1. GOST Algorithm Suite for WS-SecurityPolicy . . . . . . . . 16 80 7.2. GOST Key Derivation Algorithm for WS-SecureConversation . 17 81 7.3. GOST Computed Key Mechanism for WS-Trust . . . . . . . . . 18 82 7.4. Using WS-Trust for TLS Handshake with GOST Algorithm 83 Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 18 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 9.1. URN Sub-Namespace Registration for 87 urn:ietf:params:xml:ns:cpxmlsec . . . . . . . . . . . . . 20 88 9.2. Schema Registration . . . . . . . . . . . . . . . . . . . 20 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 10.1. Normative references . . . . . . . . . . . . . . . . . . . 20 91 10.2. Informative references . . . . . . . . . . . . . . . . . . 24 92 Appendix A. Aggregate XML Schema . . . . . . . . . . . . . . . . 24 93 Appendix B. Aggregate DTD . . . . . . . . . . . . . . . . . . . . 25 94 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 26 95 C.1. Signed document . . . . . . . . . . . . . . . . . . . . . 26 97 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 27 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 100 1. Introduction 102 This document specifies how to use GOST R 34.10-2001 digital 103 signatures and public keys, GOST R 34.11-94 hash, GOST 28147-89 104 encryption algorithms with XML Signatures [XMLDSIG], XML Encryption 105 [XMLENC-CORE], WS-SecureConversation [WS-SECURECONVERSATION], WS- 106 SecurityPolicy [WS-SECURITYPOLICY] and WS-Trust [WS-TRUST]. 108 This document uses both XML Schema ([XML-SCHEMA-1], [XML-SCHEMA-2]) 109 (normative) and DTD [XML] (informational) to specify the 110 corresponding XML structures. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 113 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 114 this document are to be interpreted as described in [KEYWORDS]. 116 2. GOST Cryptographic Algorithms 118 Algorithms GOST R 34.10-2001, GOST R 34.11-94 and GOST 28147-89 have 119 been developed by Russian Federal Agency of Governmental 120 Communication and Information (FAGCI) and "All-Russian Scientific and 121 Research Institute of Standardization". They are described in 122 [GOSTR341001], [GOSTR341194] ([GOST3431004] and [GOST3431195]) and 123 [GOST28147]. RECOMMENDED parameters for those algorithms are 124 described in [CPALGS]. 126 3. Version and Namespaces 128 This specification makes no provision for an explicit version number 129 in the syntax. If a future version is needed, it will use a 130 different namespace. 132 The XML namespace [XML-NS] URI [RFC3986] that MUST be used by 133 implementations of this (dated) specification is: 135 urn:ietf:params:xml:ns:cpxmlsec 137 The following external XML namespaces are used in this specification 138 (without line breaks; the choice of any namespace prefix is arbitrary 139 and not semantically significant): 141 http://www.w3.org/2000/09/xmldsig# 142 Prefix: 143 dsig 145 Specification: 146 [XMLDSIG] 148 http://www.w3.org/2001/04/xmlenc# 149 Prefix: 150 xenc 151 Specification: 152 [XMLENC-CORE] 154 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 155 Prefix: 156 sp 157 Specification: 158 [WS-SECURITYPOLICY] 160 http://www.w3.org/ns/ws-policy 161 Prefix: 162 wsp 163 Specification: 164 [WS-POLICY] 166 http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 167 Prefix: 168 wsc 169 Specification: 170 [WS-SECURECONVERSATION] 172 http://docs.oasis-open.org/wss/2004/01/ 173 oasis-200401-wss-wssecurity-secext-1.0.xsd 174 Prefix: 175 wsse 176 Specification: 177 [WS-SECURITY] 179 http://docs.oasis-open.org/ws-sx/ws-trust/200512/ 180 Prefix: 181 wst 182 Specification: 183 [WS-TRUST] 185 In the remaining sections of this document elements in the external 186 namespaces are marked as such by using the namespace prefixes defined 187 above. 189 4. XML Schema Preamble and DTD Replacement 190 4.1. XML Schema Preamble 192 The subsequent preamble is to be used with the XML Schema definitions 193 given in the remaining sections of this document. 195 204 4.2. DTD Replacement 206 In order to include GOST XML-signature syntax, the following 207 definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 209 211 5. Object Identifiers Representation 213 Object Identifiers (OIDs) are included in XML by the corresponding 214 URN value as defined in [URNOID]. 216 The subsequent type is to be used to define algorithm parameters by 217 OIDs: 219 220 221 223 224 226 6. Specifying GOST within XML Signature and XML Encryption 228 This section specifies the details of how to use GOST algorithms with 229 XML Signature Syntax and Processing [XMLDSIG] and XML Encryption 230 Syntax and Processing [XMLENC-CORE]. It relies heavily on syntaxes 231 and namespaces defined in [XMLDSIG] and [XMLENC-CORE]. 233 6.1. GOST R 34.11-94 Algorithm in DigestMethod 235 The identifier for the GOST R 34.11-94 digest algorithm is: 237 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 239 The dsig:DigestMethod node may contain a child node cpxmlsec: 240 ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. 241 cpxmlsec:ParametersR3411 node contains one OID specified in section 242 8.2 [CPALGS]. If cpxmlsec:ParametersR3411 node is missing, the 243 application should infer algorithm parameters from other sources. 245 If the application omits cpxmlsec:ParametersR3411 node, it SHOULD use 246 parameters defined by id-GostR3411-94-CryptoProParamSet (see Section 247 11.2 of [CPALGS]). 249 Schema Definition: 251 254 DTD Definition: 256 258 An example of a GOST R 34.11-94 dsig:DigestMethod node is: 260 262 263 urn:oid:1.2.643.2.2.30.1< 264 /cpxmlsec:ParametersR3411> 265 267 A GOST R 34.11-94 digest is a 256-bit string. The content of the 268 dsig:DigestValue element shall be the base64 [RFC4648] encoding of 269 this bit string viewed as a 32-octet octet stream. 271 6.2. GOST R 34.11-94 HMAC Algorithm in SignatureMethod 273 GOST R 34.11-94 can also be used in HMAC [HMAC] as described in 274 section 6.3.1 of [XMLDSIG]. Identifier: 276 urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 278 The dsig:SignatureMethod node may contain a child node cpxmlsec: 279 ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. 280 cpxmlsec:ParametersR3411 node syntax and processing in this case are 281 equivalent to the ones in dsig:DigestMethod case. 283 An example of a GOST R 34.11-94 HMAC disg:SignatureMethod node is: 285 287 288 urn:oid:1.2.643.2.2.30.1< 289 /cpxmlsec:ParametersR3411> 290 292 The output of the GOST R 34.11-94 HMAC algorithm is ultimately the 293 output of the GOST R 34.11-94 digest algorithm. This value shall be 294 base64 [RFC4648] encoded for the dsig:SignatureValue in the same 295 straightforward fashion as the output of the digest algorithm. 297 6.3. GOST R 34.10-2001 Algorithm in SignatureMethod 299 The input to the GOST R 34.10-2001 algorithm is the canonicalized 300 representation of the dsig:SignedInfo element as specified in Section 301 3 of [XMLDSIG]. 303 The identifier for the GOST R 34.10-2001 signature algorithm is 304 (without line break): 306 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411 308 An example of a GOST R 34.10-2001 dsig:SignatureMethod node is 309 (without line break in attribute value): 311 315 GOST R 34.10-2001 signature is a 64-octet value as described in 316 section 2.2.2 of [CPPK]. The content of the dsig:SignatureValue 317 element shall be the base64 [RFC4648] encoding of this value. 319 6.4. GOST R 34.10-2001 Public Key in KeyValue 321 6.4.1. Key Value Root Element 323 GOST R 34.10-2001 public key can be transmitted in cpxmlsec: 324 GOSTKeyValue node. It is included in dsig:KeyValue node just like 325 dsig:RSAKeyValue or xenc:DHKeyValue. 327 cpxmlsec:GOSTKeyValue node consists of an optional child node 328 cpxmlsec:PublicKeyParameters and a mandatory child node cpxmlsec: 329 PublicKey. If cpxmlsec:PublicKeyParameters node is missing, the 330 application should infer parameters from other sources. 332 Schema Definition: 334 337 338 339 342 343 344 346 DTD Definition: 348 350 352 If the application omits cpxmlsec:PublicKeyParameters node, it SHOULD 353 use parameters identified by DefaultPublicKeyParameters. 355 DefaultPublicKeyParameters: 357 358 359 urn:oid:1.2.643.2.2.35.1< 360 /cpxmlsec:publicKeyParamSet> 361 362 urn:oid:1.2.643.2.2.30.1 364 365 urn:oid:1.2.643.2.2.31.1 367 369 6.4.2. Public Key Parameters 371 cpxmlsec:PublicKeyParameters node contains three OIDs: cpxmlsec: 372 publicKeyParamSet, cpxmlsec:digestParamSet and optional cpxmlsec: 373 encryptionParamSet. Parameter values corresponding to these OIDs can 374 be found in [CPALGS]. 376 Schema Definition: 378 379 380 382 384 387 388 390 DTD Definition: 392 395 396 397 399 6.5. GOST R 34.10-2001-based Key Agreement Algorithm in AgreementMethod 401 Key agreement algorithm based on GOST R 34.10-2001 public keys (see 402 Section 5 of [CPALGS]) involves the derivation of shared secret 403 information using keys from the sender and recipient. 405 The identifier for the key agreement algorithm based on GOST R 34.10- 406 2001 is: 408 urn:ietf:params:xml:ns:cpxmlsec:algorithms:agree-gost2001 410 An example of a GOST R 34.10-2001-based key agreement AgreementMethod 411 node is: 413 415 ... 416 417 418 ... 419 420 421 422 ... 423 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 algorithm based on VKO GOST R 34.10-2001, specified 437 in [CPALGS], is public key encryption algorithms, that MUST be used 438 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 673 [Max SKL] 674 256 675 [Min AKL] 676 512 677 [Max AKL] 678 512 680 Note: For definition of [Comp Key], [Enc KD] and [Sig KD] algorithm 681 see Section 7.2 683 To indicate a requirement to use GOST Algorithm Suite defined above 684 conforming implementations MUST place cpxmlsec:BasicGost node in sp: 685 AlgorithmSuite Assertion (see section 7.1 of [WS-SECURITYPOLICY]). 687 Schema Definition: 689 692 DTD Definition: 694 696 An example of a GOST Algorithm Suite in sp:AlgorithmSuite Assertion 697 is: 699 700 701 702 703 705 7.2. GOST Key Derivation Algorithm for WS-SecureConversation 707 This specification defines a new possible value for an Algorithm 708 attribute of a wsc:DerivedKeyToken node (see section 7 of 709 [WS-SECURECONVERSATION]). 711 The new key derivation algorithm identifier is: 713 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 715 An example of a GOST Key Derivation Algorithm in wsc:DerivedKeyToken 716 node is: 718 720 ... 721 ... 722 724 GOST Key Derivation Algorithm uses a pseudo-random function 725 P_GOSTR3411 (see section 4 of [CPALGS]) to derive keys just like a 726 P_SHA-1 function is used in [WS-SECURECONVERSATION] (see section 7). 728 7.3. GOST Computed Key Mechanism for WS-Trust 730 This specification defines a new possible value for a wst:ComputedKey 731 node (see section 4.4.4 of [WS-TRUST]). 733 The new computed key mechanism identifier is: 735 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 737 An example of a GOST Computed Key Mechanism in wst:ComputedKey node 738 (without line breaks) is: 740 741 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 742 744 GOST Computed Key Mechanism uses a pseudo-random function P_GOSTR3411 745 (see section 4 of [CPALGS]) to compute a key just like a P_SHA-1 746 function is used in [WS-TRUST] (see section 4.4.4). It is REQUIRED 747 that EntREQ and EntRES are strings of length 256 bits. 749 7.4. Using WS-Trust for TLS Handshake with GOST Algorithm Suite 751 This specification defines how to use WS-Trust ([WS-TRUST]) to 752 perform TLS Handshake (see [TLS]) and establish secure session for 753 GOST Algorithm Suite. 755 WS-Trust can be used to do TLS Handshake as specified in 756 [WS-TRUST-TLS]. The outcome of the protocol under discussion is a 757 new session key issued using a secure session established by TLS 758 Handshake. Issued session key is intended to secure further 759 communication by means of WS-Security ([WS-SECURITY]). 761 If application is required to use GOST Algorithm Suite after 762 performing TLS Handshake by WS-Trust it MUST use one of GOST 28147-89 763 Cipher Suites for TLS (see [draft.CPTLS]). 765 The main flow of TLS Negotiation over WS-Trust defined in this 766 specification complies with [WS-TRUST-TLS], but there are a few 767 differences specified below that MUST be obeyed. 769 The paragraph R4305 (see section 4.3 of [WS-TRUST-TLS]) MUST be 770 replaced with the following text: 771 The responder is responsible for issuing the key associated with 772 the TLSNego session. If the initiator requested properties for 773 the generated key (e.g. key size) in the initial RST message, the 774 generated key SHOULD match those requirements. The issued key 775 MUST be communicated back to the initiator using the wst: 776 RequestedProofToken element and MUST be protected using CryptoPro 777 Key Wrap algorithm (see section 6.3 of [CPALGS]) where 778 server_write_key (see section 6.3 of [TLS]) is a wrapping key. 779 Wrapped key is contained in the ... elements of 781 the xenc:EncryptedKey. 783 GOST R 34.11-94 and P_GOSTR3411 algorithms MUST be used instead of 784 SHA1 and PSHA1 algorithms correspondingly to compute authenticator 785 (see section 4.9 of [WS-TRUST-TLS]). 787 8. Security Considerations 789 Conforming applications MUST use unique values for ukm and iv. 790 Recipients MAY verify that ukm and iv specified by the sender are 791 unique. 793 Applications SHOULD verify signature values, subject public keys and 794 algorithm parameters to conform to [GOSTR341001], standard before 795 using them. 797 Cryptographic algorithm parameters affect algorithm strength. Using 798 parameters not listed in [CPALGS] is NOT RECOMMENDED (see the 799 Security Considerations section of [CPALGS]). 801 Using the same key for signature and key derivation is NOT 802 RECOMMENDED. 804 It is NOT RECOMMENDED to use XML encryption without XML signature or 805 HMAC. 807 9. IANA Considerations 809 This document uses URNs to describe XML namespaces and XML schemata 810 conforming to a registry mechanism described in [RFC3688]. IANA has 811 registered two URI assignments. 813 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpxmlsec 815 URI: urn:ietf:params:xml:ns:cpxmlsec 817 Registrant Contact: 818 Mikhail V. Pavlov 819 CRYPTO-PRO, Ltd. 820 16/5, Suschevskij val 821 Moscow, 127018 822 Russia 823 Phone: +7 (495) 780 4820 824 Fax: +7 (495) 660 2330 825 Email: pav@CryptoPro.ru 826 URI: http://www.CryptoPro.ru 828 XML: None. Namespace URIs do not represent an XML specification. 830 9.2. Schema Registration 832 URI: urn:ietf:params:xml:schema:cpxmlsec 834 Registrant Contact: 835 Mikhail V. Pavlov 836 CRYPTO-PRO, Ltd. 837 16/5, Suschevskij val 838 Moscow, 127018 839 Russia 840 Phone: +7 (495) 780 4820 841 Fax: +7 (495) 660 2330 842 Email: pav@CryptoPro.ru 843 URI: http://www.CryptoPro.ru 845 XML: The XML can be found in Appendix A. 847 10. References 849 10.1. Normative references 851 [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 852 Cryptographic Algorithms for Use with GOST 28147-89, 853 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 854 Algorithms", RFC 4357, January 2006. 856 [CPCMS] Leontiev, S. and G. Chudov, "Using the GOST 28147-89, 857 GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 858 Algorithms with Cryptographic Message Syntax (CMS)", 859 RFC 4490, May 2006. 861 [CPPK] Leontiev, S. and D. Shefanovski, "Using the 862 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 863 Algorithms with the Internet X.509 Public Key 864 Infrastructure Certificate and CRL Profile", RFC 4491, 865 May 2006. 867 [GOST28147] 868 Government Committee of the USSR for Standards, 869 "Cryptographic Protection for Data Processing System, 870 Gosudarstvennyi Standard of USSR (In Russian)", 871 GOST 28147-89, 1989. 873 [GOST3431004] 874 Council for Standardization, Metrology and Certification 875 of the Commonwealth of Independence States (EASC), Minsk, 876 "Information technology. Cryptographic Data Security. 877 Formation and verification processes of (electronic) 878 digital signature based on Asymmetric Cryptographic 879 Algorithm (In Russian)", GOST 34.310-2004, 2004. 881 [GOST3431195] 882 Council for Standardization, Metrology and Certification 883 of the Commonwealth of Independence States (EASC), Minsk, 884 "Information technology. Cryptographic Data Security. 885 Cashing function (In Russian)", GOST 34.311-95, 1995. 887 [GOSTR341001] 888 Government Committee of the Russia for Standards, 889 "Information technology. Cryptographic Data 890 Security.Signature and verification processes of 891 [electronic] digital signature, Gosudarstvennyi Standard 892 of Russian Federation (In Russian)", GOST R 34.10-2001, 893 2001. 895 [GOSTR341194] 896 Government Committee of the Russia for Standards, 897 "Information technology. Cryptographic Data Security. 898 Hashing function, Gosudarstvennyi Standard of Russian 899 Federation (In Russian)", GOST R 34.11-94, 1994. 901 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 902 Hashing for Message Authentication", RFC 2104, 903 February 1997. 905 [KEYWORDS] 906 Bradner, S., "Key words for use in RFCs to Indicate 907 Requirement Levels", BCP 14, RFC 2119, March 1997. 909 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 910 January 2004. 912 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 913 Resource Identifier (URI): Generic Syntax", STD 66, 914 RFC 3986, January 2005. 916 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 917 Encodings", RFC 4648, October 2006. 919 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 920 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 922 [WS-POLICY] 923 Vedamuthu, A., Orchard, D., Hirsch, F., Hondo, M., 924 Yendluri, P., Boubez, T., and . Yalinalp, "Web Services 925 Policy 1.5 - Framework", W3C REC-ws-policy, 926 September 2007, . 928 [WS-SECURECONVERSATION] 929 Lawrence, K. and C. Kaler, "WS-SecureConversation 1.3", 930 OASIS Standard ws-secureconversation-1.3-os, March 2007, < 931 http://docs.oasis-open.org/ws-sx/ws-secureconversation/ 932 200512/ws-secureconversation-1.3-os.html>. 934 [WS-SECURITY] 935 Lawrence, K. and C. Kaler, "Web Services Security: SOAP 936 Message Security 1.1 (WS-Security 2004)", OASIS 937 Standard wss-v1.1-spec-os-SOAPMessageSecurity, 938 Febraury 2006, . 941 [WS-SECURITYPOLICY] 942 Lawrence, K. and C. Kaler, "WS-SecurityPolicy 1.2", OASIS 943 Standard ws-securitypolicy-1.2-spec-os, July 2007, . 947 [WS-TRUST] 948 Lawrence, K. and C. Kaler, "WS-Trust 1.3", OASIS 949 Standard ws-trust-1.3-os, March 2007, . 953 [WS-TRUST-TLS] 954 Alexander, J., Della-Libera, G., Gajjala, V., Gavrylyuk, 955 K., Kaler, C., McIntosh, M., Nadalin, A., Rich, B., and T. 956 Vishwanath, "Application Note: Using WS-Trust for TLS 957 Handshake", September 2007, . 961 [X.208-88] 962 International International Telephone and Telegraph 963 Consultative Committee, "Specification of Abstract Syntax 964 Notation One (ASN.1)", CCITT Recommendation X.208, 965 November 1988. 967 [XML-NS] Bray, T., Hollander, D., Layman, A., and R. Tobin, 968 "Namespaces in XML (Second Edition)", W3C REC-xml-names, 969 August 2006, 970 . 972 [XML-SCHEMA-1] 973 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 974 "XML Schema Part 1: Structures Second Edition", W3C REC- 975 xmlschema-1, October 2004, 976 . 978 [XML-SCHEMA-2] 979 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 980 Second Edition", W3C REC-xmlschema-2, October 2004, 981 . 983 [XMLDSIG] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 984 Language) XML-Signature Syntax and Processing", RFC 3275, 985 March 2002. 987 [XMLENC-CORE] 988 Eastlake, D. and J. Reagle , "XML Encryption Syntax and 989 Processing", W3C Candidate Recommendation xmlenc-core, 990 August 2002, . 992 [draft.CPTLS] 993 Afanasiev, A., Nikishin, N., Izotov, B., Minaeva, E., 994 Murugov, S., Ustinov, I., Erkin, A., Chudov, G., and S. 995 Leontiev, "GOST 28147-89 Cipher Suites for Transport Layer 996 Security (TLS)", draft-chudov-cryptopro-cptls-04 (work in 997 progress), December 2008. 999 10.2. Informative references 1001 [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 1002 July 2005. 1004 [URNOID] Mealling, M., "A URN Namespace of Object Identifiers", 1005 RFC 3061, February 2001. 1007 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1008 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1009 Edition)", W3C REC-xml, August 2006, 1010 . 1012 Appendix A. Aggregate XML Schema 1014 1016 1018 1021 ]> 1023 1032 1037 1038 1039 1041 1042 1044 1047 1049 1050 1051 1054 1055 1056 1058 1059 1060 1062 1064 1067 1068 1070 1073 1076 1078 Appendix B. Aggregate DTD 1080 1082 1083 1086 1087 1088 1089 1090 1091 1093 Appendix C. Examples 1095 Examples here are stored in the same format as the examples in 1096 [RFC4134] and can be extracted using the same program. 1098 If you want to extract without the program, copy all the lines 1099 between the "|>" and "|<" markers, remove any page breaks, and remove 1100 the "|" in the first column of each line. The result is a valid 1101 Base64 blob that can be processed by any Base64 decoder. 1103 C.1. Signed document 1105 This sample contain the signed XML document using the sample 1106 certificate from Section 4.2 of [CPPK]. 1108 |>XmlDocSigned2001.xml 1109 |PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48Q3J5cHRvUHJv 1110 |WE1MIFNpZ25lZD0idHJ1ZSI+SGVyZSBpcyBzb21lIGRhdGEgdG8gc2lnbi48U2ln 1111 |bmF0dXJlIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcj 1112 |Ij48U2lnbmVkSW5mbz48Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09 1113 |Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1 1114 |IiAvPjxTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9y 1115 |Zy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0cjM0MTAyMDAxLWdvc3RyMzQxMSIg 1116 |Lz48UmVmZXJlbmNlIFVSST0iIj48VHJhbnNmb3Jtcz48VHJhbnNmb3JtIEFsZ29y 1117 |aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 1118 |ZC1zaWduYXR1cmUiIC8+PC9UcmFuc2Zvcm1zPjxEaWdlc3RNZXRob2QgQWxnb3Jp 1119 |dGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0 1120 |cjM0MTEiIC8+PERpZ2VzdFZhbHVlPi9Kd3RRc3Z5NWsvUjBWZUx6ZG0ySWlqUEJ0 1121 |U0o1cEpSalQ5RlVRSEV5VGc9PC9EaWdlc3RWYWx1ZT48L1JlZmVyZW5jZT48L1Np 1122 |Z25lZEluZm8+PFNpZ25hdHVyZVZhbHVlPkZjYjNxNGlCdmRmZ1lvN245NUdhUUN1 1123 |ZDkxWVA3dzhvVjAzUjZ6a1JEZGxjK0RuQ2MwcjlNc0E1YS9iaFlDeVdQZC9jRVU4 1124 |K3FZRnJ5SmJjaXJ5d0hBPT08L1NpZ25hdHVyZVZhbHVlPjxLZXlJbmZvPjxYNTA5 1125 |RGF0YT48WDUwOUNlcnRpZmljYXRlPk1JSUIwRENDQVg4Q0VDdjF4aDdDRWIwWHg5 1126 |elVZbWEwTGlFd0NBWUdLb1VEQWdJRE1HMHhIekFkQmdOVkJBTU1Ga2R2YzNSU016 1127 |UXhNQzB5TURBeElHVjRZVzF3YkdVeEVqQVFCZ05WQkFvTUNVTnllWEIwYjFCeWJ6 1128 |RUxNQWtHQTFVRUJoTUNVbFV4S1RBbkJna3Foa2lHOXcwQkNRRVdHa2R2YzNSU016 1129 |UXhNQzB5TURBeFFHVjRZVzF3YkdVdVkyOXRNQjRYRFRBMU1EZ3hOakUwTVRneU1G 1130 |b1hEVEUxTURneE5qRTBNVGd5TUZvd2JURWZNQjBHQTFVRUF3d1dSMjl6ZEZJek5E 1131 |RXdMVEl3TURFZ1pYaGhiWEJzWlRFU01CQUdBMVVFQ2d3SlEzSjVjSFJ2VUhKdk1R 1132 |c3dDUVlEVlFRR0V3SlNWVEVwTUNjR0NTcUdTSWIzRFFFSkFSWWFSMjl6ZEZJek5E 1133 |RXdMVEl3TURGQVpYaGhiWEJzWlM1amIyMHdZekFjQmdZcWhRTUNBaE13RWdZSEtv 1134 |VURBZ0lrQUFZSEtvVURBZ0llQVFOREFBUkFoSlZvZFdBQ0drQjFDTTBUakRHSkxQ 1135 |M2xCUU42UTF6MGJTc1A1MDh5ZmxlUDY4d1d1WldJQTlDYWZJV3VEK1NONnFhN2Zs 1136 |Ykh5N0RmRDJhOHl1b2FZREFJQmdZcWhRTUNBZ01EUVFBOEw4a0pSTGNucWV5bjFl 1137 |bjdVMjNTdzZwa2ZFUXUzdTB4RmtWUHZGUS8zY0hlRjI2TkcreHh0WlB6M1RhVFZY 1138 |ZG9pWWtYWWlEMDJyRXgxYlVjTTk3aTwvWDUwOUNlcnRpZmljYXRlPjwvWDUwOURh 1139 |dGE+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjwvQ3J5cHRvUHJvWE1MPg== 1140 |