idnits 2.17.1 draft-chudov-cryptopro-cpxmldsig-07.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 (May 31, 2010) is 5080 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-1' is mentioned on line 1037, but not defined == Missing Reference: '1-3' is mentioned on line 1037, but not defined == Missing Reference: 'Dig' is mentioned on line 653, but not defined == Missing Reference: 'Enc' is mentioned on line 655, but not defined == Missing Reference: 'Sym KW' is mentioned on line 657, but not defined == Missing Reference: 'Asym KW' is mentioned on line 659, but not defined == Missing Reference: 'Enc KD' is mentioned on line 677, but not defined == Missing Reference: 'Sig KD' is mentioned on line 677, but not defined == Missing Reference: 'Min SKL' is mentioned on line 667, but not defined == Missing Reference: 'Max SKL' is mentioned on line 670, but not defined == Missing Reference: 'Min AKL' is mentioned on line 672, but not defined == Missing Reference: 'Max AKL' is mentioned on line 674, but not defined ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 1 error (**), 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: December 2, 2010 CRYPTO-PRO 6 May 31, 2010 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-07 12 Abstract 14 This document specifies how to use Russian national cryptographic 15 standards GOST 28147-89, GOST R 34.10-2001 and GOST R 34.11-94 with 16 XML Signatures, XML Encryption, WS-SecureConversation, WS- 17 SecurityPolicy and WS-Trust. A number of Uniform Resource 18 Identifiers (URIs) and XML elements are defined. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 2, 2010. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. GOST Cryptographic Algorithms . . . . . . . . . . . . . . . . 3 56 3. Version and Namespaces . . . . . . . . . . . . . . . . . . . . 3 57 4. XML Schema Preamble and DTD Replacement . . . . . . . . . . . 4 58 4.1. XML Schema Preamble . . . . . . . . . . . . . . . . . . . 5 59 4.2. DTD Replacement . . . . . . . . . . . . . . . . . . . . . 5 60 5. Object Identifiers Representation . . . . . . . . . . . . . . 5 61 6. Specifying GOST within XML Signature and XML Encryption . . . 5 62 6.1. GOST R 34.11-94 Algorithm in DigestMethod . . . . . . . . 6 63 6.2. GOST R 34.11-94 HMAC Algorithm in SignatureMethod . . . . 6 64 6.3. GOST R 34.10-2001 Algorithm in SignatureMethod . . . . . . 7 65 6.4. GOST R 34.10-2001 Public Key in KeyValue . . . . . . . . . 8 66 6.4.1. Key Value Root Element . . . . . . . . . . . . . . . . 8 67 6.4.2. Public Key Parameters . . . . . . . . . . . . . . . . 9 68 6.5. GOST R 34.10-2001-based Key Agreement Algorithm in 69 AgreementMethod . . . . . . . . . . . . . . . . . . . . . 10 70 6.6. GOST R 34.10-2001-based Key Transport Algorithm in 71 EncryptionMethod . . . . . . . . . . . . . . . . . . . . . 10 72 6.7. GOST 28147-89 Algorithm in EncryptionMethod . . . . . . . 11 73 6.8. Symmetric Key Wrap . . . . . . . . . . . . . . . . . . . . 12 74 6.8.1. GOST 28147-89 Key Wrap in EncryptionMethod . . . . . . 12 75 6.8.2. CryptoPro Key Wrap in EncryptionMethod . . . . . . . . 14 76 7. Specifying GOST within WS-* . . . . . . . . . . . . . . . . . 15 77 7.1. GOST Algorithm Suite for WS-SecurityPolicy . . . . . . . . 15 78 7.2. GOST Key Derivation Algorithm for WS-SecureConversation . 16 79 7.3. GOST Computed Key Mechanism for WS-Trust . . . . . . . . . 17 80 7.4. Using WS-Trust for TLS Handshake with GOST Algorithm 81 Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. URN Sub-Namespace Registration for 85 urn:ietf:params:xml:ns:cpxmlsec . . . . . . . . . . . . . 19 86 9.2. Schema Registration . . . . . . . . . . . . . . . . . . . 19 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 10.1. Normative references . . . . . . . . . . . . . . . . . . . 19 89 10.2. Informative references . . . . . . . . . . . . . . . . . . 23 90 Appendix A. Aggregate XML Schema . . . . . . . . . . . . . . . . 23 91 Appendix B. Aggregate DTD . . . . . . . . . . . . . . . . . . . . 24 92 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 25 93 C.1. Signed document . . . . . . . . . . . . . . . . . . . . . 25 94 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 97 1. Introduction 99 This document specifies how to use GOST R 34.10-2001 digital 100 signatures and public keys, GOST R 34.11-94 hash, GOST 28147-89 101 encryption algorithms with XML Signatures [XMLDSIG], XML Encryption 102 [XMLENC-CORE], WS-SecureConversation [WS-SECURECONVERSATION], WS- 103 SecurityPolicy [WS-SECURITYPOLICY] and WS-Trust [WS-TRUST]. 105 This document uses both XML Schema ([XML-SCHEMA-1], [XML-SCHEMA-2]) 106 (normative) and DTD [XML] (informational) to specify the 107 corresponding XML structures. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 110 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 111 this document are to be interpreted as described in [KEYWORDS]. 113 2. GOST Cryptographic Algorithms 115 Algorithms GOST R 34.10-2001, GOST R 34.11-94 and GOST 28147-89 have 116 been developed by Russian Federal Agency of Governmental 117 Communication and Information (FAGCI) and "All-Russian Scientific and 118 Research Institute of Standardization". They are described in 119 [GOSTR341001], [GOSTR341194] ([GOST3431004] and [GOST3431195]) and 120 [GOST28147]. RECOMMENDED parameters for those algorithms are 121 described in [CPALGS]. 123 3. Version and Namespaces 125 This specification makes no provision for an explicit version number 126 in the syntax. If a future version is needed, it will use a 127 different namespace. 129 The XML namespace [XML-NS] URI [RFC3986] that MUST be used by 130 implementations of this (dated) specification is: 132 urn:ietf:params:xml:ns:cpxmlsec 134 The following external XML namespaces are used in this specification 135 (without line breaks; the choice of any namespace prefix is arbitrary 136 and not semantically significant): 138 http://www.w3.org/2000/09/xmldsig# 139 Prefix: 140 dsig 142 Specification: 143 [XMLDSIG] 145 http://www.w3.org/2001/04/xmlenc# 146 Prefix: 147 xenc 148 Specification: 149 [XMLENC-CORE] 151 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 152 Prefix: 153 sp 154 Specification: 155 [WS-SECURITYPOLICY] 157 http://www.w3.org/ns/ws-policy 158 Prefix: 159 wsp 160 Specification: 161 [WS-POLICY] 163 http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 164 Prefix: 165 wsc 166 Specification: 167 [WS-SECURECONVERSATION] 169 http://docs.oasis-open.org/wss/2004/01/ 170 oasis-200401-wss-wssecurity-secext-1.0.xsd 171 Prefix: 172 wsse 173 Specification: 174 [WS-SECURITY] 176 http://docs.oasis-open.org/ws-sx/ws-trust/200512/ 177 Prefix: 178 wst 179 Specification: 180 [WS-TRUST] 182 In the remaining sections of this document elements in the external 183 namespaces are marked as such by using the namespace prefixes defined 184 above. 186 4. XML Schema Preamble and DTD Replacement 187 4.1. XML Schema Preamble 189 The subsequent preamble is to be used with the XML Schema definitions 190 given in the remaining sections of this document. 192 201 4.2. DTD Replacement 203 In order to include GOST XML-signature syntax, the following 204 definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 206 208 5. Object Identifiers Representation 210 Object Identifiers (OIDs) are included in XML by the corresponding 211 URN value as defined in [URNOID]. 213 The subsequent type is to be used to define algorithm parameters by 214 OIDs: 216 217 218 220 221 223 6. Specifying GOST within XML Signature and XML Encryption 225 This section specifies the details of how to use GOST algorithms with 226 XML Signature Syntax and Processing [XMLDSIG] and XML Encryption 227 Syntax and Processing [XMLENC-CORE]. It relies heavily on syntaxes 228 and namespaces defined in [XMLDSIG] and [XMLENC-CORE]. 230 6.1. GOST R 34.11-94 Algorithm in DigestMethod 232 The identifier for the GOST R 34.11-94 digest algorithm is: 234 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 236 The dsig:DigestMethod node may contain a child node cpxmlsec: 237 ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. 238 cpxmlsec:ParametersR3411 node contains one OID specified in section 239 8.2 [CPALGS]. If cpxmlsec:ParametersR3411 node is missing, the 240 application should infer algorithm parameters from other sources. 242 If the application omits cpxmlsec:ParametersR3411 node, it SHOULD use 243 parameters defined by id-GostR3411-94-CryptoProParamSet (see Section 244 11.2 of [CPALGS]). 246 Schema Definition: 248 251 DTD Definition: 253 255 An example of a GOST R 34.11-94 dsig:DigestMethod node is: 257 259 260 urn:oid:1.2.643.2.2.30.1< 261 /cpxmlsec:ParametersR3411> 262 264 A GOST R 34.11-94 digest is a 256-bit string. The content of the 265 dsig:DigestValue element shall be the base64 [RFC4648] encoding of 266 this bit string viewed as a 32-octet octet stream. 268 6.2. GOST R 34.11-94 HMAC Algorithm in SignatureMethod 270 GOST R 34.11-94 can also be used in HMAC [HMAC] as described in 271 section 6.3.1 of [XMLDSIG]. Identifier: 273 urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 275 The dsig:SignatureMethod node may contain a child node cpxmlsec: 276 ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. 277 cpxmlsec:ParametersR3411 node syntax and processing in this case are 278 equivalent to the ones in dsig:DigestMethod case. 280 An example of a GOST R 34.11-94 HMAC disg:SignatureMethod node is: 282 284 285 urn:oid:1.2.643.2.2.30.1< 286 /cpxmlsec:ParametersR3411> 287 289 The output of the GOST R 34.11-94 HMAC algorithm is ultimately the 290 output of the GOST R 34.11-94 digest algorithm. This value shall be 291 base64 [RFC4648] encoded for the dsig:SignatureValue in the same 292 straightforward fashion as the output of the digest algorithm. 294 6.3. GOST R 34.10-2001 Algorithm in SignatureMethod 296 The input to the GOST R 34.10-2001 algorithm is the canonicalized 297 representation of the dsig:SignedInfo element as specified in Section 298 3 of [XMLDSIG]. 300 The identifier for the GOST R 34.10-2001 signature algorithm is 301 (without line break): 303 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411 305 An example of a GOST R 34.10-2001 dsig:SignatureMethod node is 306 (without line break in attribute value): 308 312 GOST R 34.10-2001 signature is a 64-octet value as described in 313 section 2.2.2 of [CPPK]. The content of the dsig:SignatureValue 314 element shall be the base64 [RFC4648] encoding of this value. 316 6.4. GOST R 34.10-2001 Public Key in KeyValue 318 6.4.1. Key Value Root Element 320 GOST R 34.10-2001 public key can be transmitted in cpxmlsec: 321 GOSTKeyValue node. It is included in dsig:KeyValue node just like 322 dsig:RSAKeyValue or xenc:DHKeyValue. 324 cpxmlsec:GOSTKeyValue node consists of an optional child node 325 cpxmlsec:PublicKeyParameters and a mandatory child node cpxmlsec: 326 PublicKey. If cpxmlsec:PublicKeyParameters node is missing, the 327 application should infer parameters from other sources. 329 Schema Definition: 331 334 335 336 339 340 341 343 DTD Definition: 345 347 349 If the application omits cpxmlsec:PublicKeyParameters node, it SHOULD 350 use parameters identified by DefaultPublicKeyParameters. 352 DefaultPublicKeyParameters: 354 355 356 urn:oid:1.2.643.2.2.35.1< 357 /cpxmlsec:publicKeyParamSet> 358 359 urn:oid:1.2.643.2.2.30.1 361 362 urn:oid:1.2.643.2.2.31.1 364 366 6.4.2. Public Key Parameters 368 cpxmlsec:PublicKeyParameters node contains three OIDs: cpxmlsec: 369 publicKeyParamSet, cpxmlsec:digestParamSet and optional cpxmlsec: 370 encryptionParamSet. Parameter values corresponding to these OIDs can 371 be found in [CPALGS]. 373 Schema Definition: 375 376 377 379 381 384 385 387 DTD Definition: 389 392 393 394 396 6.5. GOST R 34.10-2001-based Key Agreement Algorithm in AgreementMethod 398 Key agreement algorithm based on GOST R 34.10-2001 public keys (see 399 Section 5 of [CPALGS]) involves the derivation of shared secret 400 information using keys from the sender and recipient. 402 The identifier for the key agreement algorithm based on GOST R 34.10- 403 2001 is: 405 urn:ietf:params:xml:ns:cpxmlsec:algorithms:agree-gost2001 407 An example of a GOST R 34.10-2001-based key agreement AgreementMethod 408 node is: 410 412 ... 413 414 415 ... 416 417 418 419 ... 420 421 423 The shared keying material for algorithm based on GOST R 34.10-2001 424 needed will be calculated as a result of function VKO GOST R 34.10- 425 2001 (see Section 5.2 of [CPALGS]), which generates GOST KEK using 426 two GOST R 34.10-2001 keypairs and UKM. xenc:KA-Nonce node of xenc: 427 AgreementMethod contains base64 encoded 64-bits value of UKM, if UKM 428 is used. 430 6.6. GOST R 34.10-2001-based Key Transport Algorithm in 431 EncryptionMethod 433 The key transport algorithm based on VKO GOST R 34.10-2001, specified 434 in [CPALGS], is public key encryption algorithms, that MUST be used 435 for key encryption/decryption only. 437 The identifier for the key transport algorithm based on VKO 438 GOST R 34.10-2001 is: 440 urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 442 An example of a VKO GOST R 34.10-2001-based key transport 443 EncryptedKey node is: 445 446 448 449 450 ... 451 452 453 454 ... 455 456 458 The CipherValue for such encrypted key is the base64 encoding of the 459 [X.208-88] DER encoding of a GostR3410-KeyTransport structure (see 460 section 4.2.1 of [CPCMS]). 462 6.7. GOST 28147-89 Algorithm in EncryptionMethod 464 The identifier for the GOST 28147-89 symmetric encryption algorithm 465 is: 467 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 469 The xenc:EncryptionMethod node may contain a child node cpxmlsec: 470 Parameters28147 specifying parameters for GOST 28147-89 algorithm. 471 cpxmlsec:Parameters28147 specifies the set of corresponding 472 Gost28147-89-ParamSetParameters (see Section 8.1 of [CPALGS]). 473 Encryption mode is specified by mode parameter of Gost28147-89- 474 ParamSetParameters structure. CFB and CNT modes are RECOMMENDED to 475 use. If cpxmlsec:Parameters28147 node is missing, the application 476 should infer algorithm parameters from other sources. 478 If the application omits cpxmlsec:Parameters28147 node, it SHOULD use 479 parameters defined by id-Gost28147-89-CryptoPro-A-ParamSet (see 480 Section of 10.2 [CPALGS]). 482 Schema Definition: 484 487 DTD Definition: 489 491 An example of a GOST 28147-89 xenc:EncryptionMethod node is: 493 495 496 urn:oid:1.2.643.2.2.31.1< 497 /cpxmlsec:Parameters28147> 498 500 256-bit key, 64-bit Initialization Vector (IV), and optional 501 parameters are used in GOST 28147-89 encryption algorithm. The 502 resulting cipher text is prefixed by the IV. If included in XML 503 output, it is then base64 encoded. 505 6.8. Symmetric Key Wrap 507 Symmetric Key Wrap algorithms considered in this section are shared 508 secret key encryption algorithms that MUST be used for symmetric keys 509 encryption/decryption only. 511 6.8.1. GOST 28147-89 Key Wrap in EncryptionMethod 513 The GOST 28147-89 Key Wrap algorithm wraps (encrypts) a key (the 514 wrapped key, WK) under a GOST 28147-89 Key Wrap (specified in 515 sections 6.1, 6.2 of [CPALGS]). 517 Note: This algorithm MUST NOT be used without key agreement 518 algorithm, because such WK is constant for every wrapping-encrypting 519 pair. Encrypting many different keys with the same constant WK may 520 reveal that WK. The only key agreement algorithm possible to use 521 with GOST 28147-89 Key Wrap defined by this specification is a 522 GOST R 34.10-2001-based key agreement (see Section 6.5). 524 The identifier for the GOST 28147-89 Key Wrap algorithm is: 526 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-gost 528 The CipherValue for such wrapped key is the base64 encoding of the 529 [X.208-88] DER encoding of a GostR3410-KeyWrap structure. 531 ASN.1 structure: 533 GostR3410-KeyWrap ::= 534 SEQUENCE { 535 encryptedKey Gost28147-89-EncryptedKey, 536 encryptedParameters Gost28147-89-KeyWrapParameters 537 } 539 An example of a GOST 28147-89 Key Wrap EncryptedData node is: 541 542 544 545 546 548 549 551 ... 552 553 554 ... 555 556 557 558 ... 559 560 561 562 563 ... 564 565 566 567 568 ... 569 570 572 Gost28147-89-KeyWrapParameters is described in section 4.1.1 of 573 [CPCMS]. The xenc:KA-Nonce node value of the xenc:AgreementMethod 574 node MUST be used as ukm. 576 The resulting wrapped key (WK) is placed in the Gost28147-89- 577 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 578 Gost28147-89-EncryptedKey macKey field. ukm field of Gost28147-89- 579 KeyWrapParameters MUST be absent. 581 6.8.2. CryptoPro Key Wrap in EncryptionMethod 583 The CryptoPro Key Wrap algorithm wraps (encrypts) a key (wrapped key, 584 WK) under a CryptoPro Key Wrap (specified in sections 6.3, 6.4 of 585 [CPALGS]). 587 The identifier for the CryptoPro Key Wrap algorithms is: 589 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp 591 The CipherValue for such wrapped key is the base64 encoding of the 592 [X.208-88] DER encoding of a GostR3410-KeyWrap structure (see 593 Section 6.8.1). 595 An example of a CryptoPro Key Wrap EncryptedData node is: 597 598 600 601 602 604 605 John Smith 606 607 608 ... 609 610 611 612 613 ... 614 615 617 The resulting wrapped key (WK) is placed in the Gost28147-89- 618 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 619 Gost28147-89-EncryptedKey macKey field. 621 If CryptoPro Key Wrap algorithm is combined with Key Agreement 622 Algorithm, the xenc:KA-Nonce node value of the xenc:AgreementMethod 623 node MUST be used as ukm. ukm field of Gost28147-89-KeyWrapParameters 624 type must be absent. 626 Note: The only key agreement algorithm possible to use with CryptoPro 627 Key Wrap defined by this specification is a GOST R 34.10-2001-based 628 key agreement (see Section 6.5). 630 If CryptoPro Key Wrap algorithm is not combined with Key Agreement 631 Algorithm, ukm field of Gost28147-89-KeyWrapParameters type MUST be 632 present. 634 7. Specifying GOST within WS-* 636 This section specifies the details of how to use GOST algorithms with 637 WS-SecureConversation [WS-SECURECONVERSATION], WS-SecurityPolicy 638 [WS-SECURITYPOLICY] and WS-Trust [WS-TRUST]. 640 7.1. GOST Algorithm Suite for WS-SecurityPolicy 642 This specification defines a new possible value for an [Algorithm 643 Suite] property of a Security Binding (see section 6.1 of 644 [WS-SECURITYPOLICY]). The new value is BasicGost. 646 BasicGost Algorithm Suite defines the following values for operations 647 and properties (without line breaks in URIs): 648 [Sym Sig] 649 urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 650 [Asym Sig] 651 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001- 652 gostr3411 653 [Dig] 654 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 655 [Enc] 656 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 657 [Sym KW] 658 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp 659 [Asym KW] 660 urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 661 [Comp Key] 662 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 663 [Enc KD] 664 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 665 [Sig KD] 666 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 667 [Min SKL] 668 256 670 [Max SKL] 671 256 672 [Min AKL] 673 512 674 [Max AKL] 675 512 677 Note: For definition of [Comp Key], [Enc KD] and [Sig KD] algorithm 678 see Section 7.2 680 To indicate a requirement to use GOST Algorithm Suite defined above 681 conforming implementations MUST place cpxmlsec:BasicGost node in sp: 682 AlgorithmSuite Assertion (see section 7.1 of [WS-SECURITYPOLICY]). 684 Schema Definition: 686 689 DTD Definition: 691 693 An example of a GOST Algorithm Suite in sp:AlgorithmSuite Assertion 694 is: 696 697 698 699 700 702 7.2. GOST Key Derivation Algorithm for WS-SecureConversation 704 This specification defines a new possible value for an Algorithm 705 attribute of a wsc:DerivedKeyToken node (see section 7 of 706 [WS-SECURECONVERSATION]). 708 The new key derivation algorithm identifier is: 710 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 712 An example of a GOST Key Derivation Algorithm in wsc:DerivedKeyToken 713 node is: 715 717 ... 718 ... 719 721 GOST Key Derivation Algorithm uses a pseudo-random function 722 P_GOSTR3411 (see section 4 of [CPALGS]) to derive keys just like a 723 P_SHA-1 function is used in [WS-SECURECONVERSATION] (see section 7). 725 7.3. GOST Computed Key Mechanism for WS-Trust 727 This specification defines a new possible value for a wst:ComputedKey 728 node (see section 4.4.4 of [WS-TRUST]). 730 The new computed key mechanism identifier is: 732 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 734 An example of a GOST Computed Key Mechanism in wst:ComputedKey node 735 (without line breaks) is: 737 738 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 739 741 GOST Computed Key Mechanism uses a pseudo-random function P_GOSTR3411 742 (see section 4 of [CPALGS]) to compute a key just like a P_SHA-1 743 function is used in [WS-TRUST] (see section 4.4.4). It is REQUIRED 744 that EntREQ and EntRES are strings of length 256 bits. 746 7.4. Using WS-Trust for TLS Handshake with GOST Algorithm Suite 748 This specification defines how to use WS-Trust ([WS-TRUST]) to 749 perform TLS Handshake (see [TLS]) and establish secure session for 750 GOST Algorithm Suite. 752 WS-Trust can be used to do TLS Handshake as specified in 753 [WS-TRUST-TLS]. The outcome of the protocol under discussion is a 754 new session key issued using a secure session established by TLS 755 Handshake. Issued session key is intended to secure further 756 communication by means of WS-Security ([WS-SECURITY]). 758 If application is required to use GOST Algorithm Suite after 759 performing TLS Handshake by WS-Trust it MUST use one of GOST 28147-89 760 Cipher Suites for TLS (see [draft.CPTLS]). 762 The main flow of TLS Negotiation over WS-Trust defined in this 763 specification complies with [WS-TRUST-TLS], but there are a few 764 differences specified below that MUST be obeyed. 766 The paragraph R4305 (see section 4.3 of [WS-TRUST-TLS]) MUST be 767 replaced with the following text: 768 The responder is responsible for issuing the key associated with 769 the TLSNego session. If the initiator requested properties for 770 the generated key (e.g. key size) in the initial RST message, the 771 generated key SHOULD match those requirements. The issued key 772 MUST be communicated back to the initiator using the wst: 773 RequestedProofToken element and MUST be protected using CryptoPro 774 Key Wrap algorithm (see section 6.3 of [CPALGS]) where 775 server_write_key (see section 6.3 of [TLS]) is a wrapping key. 776 Wrapped key is contained in the ... elements of 778 the xenc:EncryptedKey. 780 GOST R 34.11-94 and P_GOSTR3411 algorithms MUST be used instead of 781 SHA1 and PSHA1 algorithms correspondingly to compute authenticator 782 (see section 4.9 of [WS-TRUST-TLS]). 784 8. Security Considerations 786 Conforming applications MUST use unique values for ukm and iv. 787 Recipients MAY verify that ukm and iv specified by the sender are 788 unique. 790 Applications SHOULD verify signature values, subject public keys and 791 algorithm parameters to conform to [GOSTR341001], standard before 792 using them. 794 Cryptographic algorithm parameters affect algorithm strength. Using 795 parameters not listed in [CPALGS] is NOT RECOMMENDED (see the 796 Security Considerations section of [CPALGS]). 798 Using the same key for signature and key derivation is NOT 799 RECOMMENDED. 801 It is NOT RECOMMENDED to use XML encryption without XML signature or 802 HMAC. 804 9. IANA Considerations 806 This document uses URNs to describe XML namespaces and XML schemata 807 conforming to a registry mechanism described in [RFC3688]. IANA has 808 registered two URI assignments. 810 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpxmlsec 812 URI: urn:ietf:params:xml:ns:cpxmlsec 814 Registrant Contact: 815 Mikhail V. Pavlov 816 CRYPTO-PRO, Ltd. 817 16/5, Suschevskij val 818 Moscow, 127018 819 Russia 820 Phone: +7 (495) 780 4820 821 Fax: +7 (495) 660 2330 822 Email: pav@CryptoPro.ru 823 URI: http://www.CryptoPro.ru 825 XML: None. Namespace URIs do not represent an XML specification. 827 9.2. Schema Registration 829 URI: urn:ietf:params:xml:schema:cpxmlsec 831 Registrant Contact: 832 Mikhail V. Pavlov 833 CRYPTO-PRO, Ltd. 834 16/5, Suschevskij val 835 Moscow, 127018 836 Russia 837 Phone: +7 (495) 780 4820 838 Fax: +7 (495) 660 2330 839 Email: pav@CryptoPro.ru 840 URI: http://www.CryptoPro.ru 842 XML: The XML can be found in Appendix A. 844 10. References 846 10.1. Normative references 848 [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 849 Cryptographic Algorithms for Use with GOST 28147-89, 850 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 851 Algorithms", RFC 4357, January 2006. 853 [CPCMS] Leontiev, S. and G. Chudov, "Using the GOST 28147-89, 854 GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 855 Algorithms with Cryptographic Message Syntax (CMS)", 856 RFC 4490, May 2006. 858 [CPPK] Leontiev, S. and D. Shefanovski, "Using the 859 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 860 Algorithms with the Internet X.509 Public Key 861 Infrastructure Certificate and CRL Profile", RFC 4491, 862 May 2006. 864 [GOST28147] 865 Government Committee of the USSR for Standards, 866 "Cryptographic Protection for Data Processing System, 867 Gosudarstvennyi Standard of USSR (In Russian)", 868 GOST 28147-89, 1989. 870 [GOST3431004] 871 Council for Standardization, Metrology and Certification 872 of the Commonwealth of Independence States (EASC), Minsk, 873 "Information technology. Cryptographic Data Security. 874 Formation and verification processes of (electronic) 875 digital signature based on Asymmetric Cryptographic 876 Algorithm (In Russian)", GOST 34.310-2004, 2004. 878 [GOST3431195] 879 Council for Standardization, Metrology and Certification 880 of the Commonwealth of Independence States (EASC), Minsk, 881 "Information technology. Cryptographic Data Security. 882 Cashing function (In Russian)", GOST 34.311-95, 1995. 884 [GOSTR341001] 885 Government Committee of the Russia for Standards, 886 "Information technology. Cryptographic Data 887 Security.Signature and verification processes of 888 [electronic] digital signature, Gosudarstvennyi Standard 889 of Russian Federation (In Russian)", GOST R 34.10-2001, 890 2001. 892 [GOSTR341194] 893 Government Committee of the Russia for Standards, 894 "Information technology. Cryptographic Data Security. 895 Hashing function, Gosudarstvennyi Standard of Russian 896 Federation (In Russian)", GOST R 34.11-94, 1994. 898 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 899 Hashing for Message Authentication", RFC 2104, 900 February 1997. 902 [KEYWORDS] 903 Bradner, S., "Key words for use in RFCs to Indicate 904 Requirement Levels", BCP 14, RFC 2119, March 1997. 906 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 907 January 2004. 909 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 910 Resource Identifier (URI): Generic Syntax", STD 66, 911 RFC 3986, January 2005. 913 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 914 Encodings", RFC 4648, October 2006. 916 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 917 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 919 [WS-POLICY] 920 Vedamuthu, A., Orchard, D., Hirsch, F., Hondo, M., 921 Yendluri, P., Boubez, T., and . Yalinalp, "Web Services 922 Policy 1.5 - Framework", W3C REC-ws-policy, 923 September 2007, . 925 [WS-SECURECONVERSATION] 926 Lawrence, K. and C. Kaler, "WS-SecureConversation 1.3", 927 OASIS Standard ws-secureconversation-1.3-os, March 2007, < 928 http://docs.oasis-open.org/ws-sx/ws-secureconversation/ 929 200512/ws-secureconversation-1.3-os.html>. 931 [WS-SECURITY] 932 Lawrence, K. and C. Kaler, "Web Services Security: SOAP 933 Message Security 1.1 (WS-Security 2004)", OASIS 934 Standard wss-v1.1-spec-os-SOAPMessageSecurity, 935 Febraury 2006, . 938 [WS-SECURITYPOLICY] 939 Lawrence, K. and C. Kaler, "WS-SecurityPolicy 1.2", OASIS 940 Standard ws-securitypolicy-1.2-spec-os, July 2007, . 944 [WS-TRUST] 945 Lawrence, K. and C. Kaler, "WS-Trust 1.3", OASIS 946 Standard ws-trust-1.3-os, March 2007, . 950 [WS-TRUST-TLS] 951 Alexander, J., Della-Libera, G., Gajjala, V., Gavrylyuk, 952 K., Kaler, C., McIntosh, M., Nadalin, A., Rich, B., and T. 953 Vishwanath, "Application Note: Using WS-Trust for TLS 954 Handshake", September 2007, . 958 [X.208-88] 959 International International Telephone and Telegraph 960 Consultative Committee, "Specification of Abstract Syntax 961 Notation One (ASN.1)", CCITT Recommendation X.208, 962 November 1988. 964 [XML-NS] Bray, T., Hollander, D., Layman, A., and R. Tobin, 965 "Namespaces in XML (Second Edition)", W3C REC-xml-names, 966 August 2006, 967 . 969 [XML-SCHEMA-1] 970 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 971 "XML Schema Part 1: Structures Second Edition", W3C REC- 972 xmlschema-1, October 2004, 973 . 975 [XML-SCHEMA-2] 976 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 977 Second Edition", W3C REC-xmlschema-2, October 2004, 978 . 980 [XMLDSIG] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 981 Language) XML-Signature Syntax and Processing", RFC 3275, 982 March 2002. 984 [XMLENC-CORE] 985 Eastlake, D. and J. Reagle , "XML Encryption Syntax and 986 Processing", W3C Candidate Recommendation xmlenc-core, 987 August 2002, . 989 [draft.CPTLS] 990 Afanasiev, A., Nikishin, N., Izotov, B., Minaeva, E., 991 Murugov, S., Ustinov, I., Erkin, A., Chudov, G., and S. 992 Leontiev, "GOST 28147-89 Cipher Suites for Transport Layer 993 Security (TLS)", draft-chudov-cryptopro-cptls-04 (work in 994 progress), December 2008. 996 10.2. Informative references 998 [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 999 July 2005. 1001 [URNOID] Mealling, M., "A URN Namespace of Object Identifiers", 1002 RFC 3061, February 2001. 1004 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1005 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1006 Edition)", W3C REC-xml, August 2006, 1007 . 1009 Appendix A. Aggregate XML Schema 1011 1013 1015 1018 ]> 1020 1029 1034 1035 1036 1038 1039 1041 1044 1046 1047 1048 1051 1052 1053 1055 1056 1057 1059 1061 1064 1065 1067 1070 1073 1075 Appendix B. Aggregate DTD 1077 1079 1080 1083 1084 1085 1086 1087 1088 1090 Appendix C. Examples 1092 Examples here are stored in the same format as the examples in 1093 [RFC4134] and can be extracted using the same program. 1095 If you want to extract without the program, copy all the lines 1096 between the "|>" and "|<" markers, remove any page breaks, and remove 1097 the "|" in the first column of each line. The result is a valid 1098 Base64 blob that can be processed by any Base64 decoder. 1100 C.1. Signed document 1102 This sample contain the signed XML document using the sample 1103 certificate from Section 4.2 of [CPPK]. 1105 |>XmlDocSigned2001.xml 1106 |PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48Q3J5cHRvUHJv 1107 |WE1MIFNpZ25lZD0idHJ1ZSI+SGVyZSBpcyBzb21lIGRhdGEgdG8gc2lnbi48U2ln 1108 |bmF0dXJlIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcj 1109 |Ij48U2lnbmVkSW5mbz48Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09 1110 |Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1 1111 |IiAvPjxTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9y 1112 |Zy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0cjM0MTAyMDAxLWdvc3RyMzQxMSIg 1113 |Lz48UmVmZXJlbmNlIFVSST0iIj48VHJhbnNmb3Jtcz48VHJhbnNmb3JtIEFsZ29y 1114 |aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 1115 |ZC1zaWduYXR1cmUiIC8+PC9UcmFuc2Zvcm1zPjxEaWdlc3RNZXRob2QgQWxnb3Jp 1116 |dGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0 1117 |cjM0MTEiIC8+PERpZ2VzdFZhbHVlPi9Kd3RRc3Z5NWsvUjBWZUx6ZG0ySWlqUEJ0 1118 |U0o1cEpSalQ5RlVRSEV5VGc9PC9EaWdlc3RWYWx1ZT48L1JlZmVyZW5jZT48L1Np 1119 |Z25lZEluZm8+PFNpZ25hdHVyZVZhbHVlPkZjYjNxNGlCdmRmZ1lvN245NUdhUUN1 1120 |ZDkxWVA3dzhvVjAzUjZ6a1JEZGxjK0RuQ2MwcjlNc0E1YS9iaFlDeVdQZC9jRVU4 1121 |K3FZRnJ5SmJjaXJ5d0hBPT08L1NpZ25hdHVyZVZhbHVlPjxLZXlJbmZvPjxYNTA5 1122 |RGF0YT48WDUwOUNlcnRpZmljYXRlPk1JSUIwRENDQVg4Q0VDdjF4aDdDRWIwWHg5 1123 |elVZbWEwTGlFd0NBWUdLb1VEQWdJRE1HMHhIekFkQmdOVkJBTU1Ga2R2YzNSU016 1124 |UXhNQzB5TURBeElHVjRZVzF3YkdVeEVqQVFCZ05WQkFvTUNVTnllWEIwYjFCeWJ6 1125 |RUxNQWtHQTFVRUJoTUNVbFV4S1RBbkJna3Foa2lHOXcwQkNRRVdHa2R2YzNSU016 1126 |UXhNQzB5TURBeFFHVjRZVzF3YkdVdVkyOXRNQjRYRFRBMU1EZ3hOakUwTVRneU1G 1127 |b1hEVEUxTURneE5qRTBNVGd5TUZvd2JURWZNQjBHQTFVRUF3d1dSMjl6ZEZJek5E 1128 |RXdMVEl3TURFZ1pYaGhiWEJzWlRFU01CQUdBMVVFQ2d3SlEzSjVjSFJ2VUhKdk1R 1129 |c3dDUVlEVlFRR0V3SlNWVEVwTUNjR0NTcUdTSWIzRFFFSkFSWWFSMjl6ZEZJek5E 1130 |RXdMVEl3TURGQVpYaGhiWEJzWlM1amIyMHdZekFjQmdZcWhRTUNBaE13RWdZSEtv 1131 |VURBZ0lrQUFZSEtvVURBZ0llQVFOREFBUkFoSlZvZFdBQ0drQjFDTTBUakRHSkxQ 1132 |M2xCUU42UTF6MGJTc1A1MDh5ZmxlUDY4d1d1WldJQTlDYWZJV3VEK1NONnFhN2Zs 1133 |Ykh5N0RmRDJhOHl1b2FZREFJQmdZcWhRTUNBZ01EUVFBOEw4a0pSTGNucWV5bjFl 1134 |bjdVMjNTdzZwa2ZFUXUzdTB4RmtWUHZGUS8zY0hlRjI2TkcreHh0WlB6M1RhVFZY 1135 |ZG9pWWtYWWlEMDJyRXgxYlVjTTk3aTwvWDUwOUNlcnRpZmljYXRlPjwvWDUwOURh 1136 |dGE+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjwvQ3J5cHRvUHJvWE1MPg== 1137 |