idnits 2.17.1 draft-chudov-cryptopro-cpxmldsig-05.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 (January 28, 2009) is 5566 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-1' is mentioned on line 1042, but not defined == Missing Reference: '1-3' is mentioned on line 1042, but not defined == Missing Reference: 'Dig' is mentioned on line 658, but not defined == Missing Reference: 'Enc' is mentioned on line 660, but not defined == Missing Reference: 'Sym KW' is mentioned on line 662, but not defined == Missing Reference: 'Asym KW' is mentioned on line 664, but not defined == Missing Reference: 'Enc KD' is mentioned on line 681, but not defined == Missing Reference: 'Sig KD' is mentioned on line 681, but not defined == Missing Reference: 'Min SKL' is mentioned on line 672, but not defined == Missing Reference: 'Max SKL' is mentioned on line 674, but not defined == Missing Reference: 'Min AKL' is mentioned on line 676, but not defined == Missing Reference: 'Max AKL' is mentioned on line 678, 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: August 1, 2009 CRYPTO-PRO 6 January 28, 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-05 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 August 1, 2009. 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 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 7.4. Using WS-Trust for TLS Handshake with GOST Algorithm 84 Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 9.1. URN Sub-Namespace Registration for 88 urn:ietf:params:xml:ns:cpxmlsec . . . . . . . . . . . . . 19 89 9.2. Schema Registration . . . . . . . . . . . . . . . . . . . 20 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 10.1. Normative references . . . . . . . . . . . . . . . . . . . 20 92 10.2. Informative references . . . . . . . . . . . . . . . . . . 23 93 Appendix A. Aggregate XML Schema . . . . . . . . . . . . . . . . 23 94 Appendix B. Aggregate DTD . . . . . . . . . . . . . . . . . . . . 25 95 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 25 96 C.1. Signed document . . . . . . . . . . . . . . . . . . . . . 25 97 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 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 Schemas ([XML-SCHEMA-1], [XML-SCHEMA-2]) 109 (normative) and DTDs [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 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: 330 PublicKey. If cpxmlsec:PublicKeyParameters node is missing, the 331 application should infer parameters from other sources. 333 Schema Definition: 335 338 339 340 343 344 345 347 DTD Definition: 349 351 353 If the application omits cpxmlsec:PublicKeyParameters node, it SHOULD 354 use parameters identified by DefaultPublicKeyParameters. 356 DefaultPublicKeyParameters: 358 359 360 urn:oid:1.2.643.2.2.35.1< 361 /cpxmlsec:publicKeyParamSet> 362 363 urn:oid:1.2.643.2.2.30.1 365 366 urn:oid:1.2.643.2.2.31.1 368 370 6.4.2. Public Key Parameters 372 cpxmlsec:PublicKeyParameters node contains three OIDs: cpxmlsec: 373 publicKeyParamSet, cpxmlsec:digestParamSet and optional cpxmlsec: 374 encryptionParamSet. Parameter values corresponding to these OIDs can 375 be found in [CPALGS]. 377 Schema Definition: 379 380 381 383 385 388 389 391 DTD Definition: 393 396 397 398 400 6.5. GOST R 34.10-2001-based Key Agreement Algorithm in AgreementMethod 402 Key agreement algorithm based on GOST R 34.10-2001 public keys (see 403 Section 5 of [CPALGS]) involves the derivation of shared secret 404 information using keys from the sender and recipient. 406 The identifier for the key agreement algorithm based on GOST R 34.10- 407 2001 is: 409 urn:ietf:params:xml:ns:cpxmlsec:algorithms:agree-gost2001 411 An example of a GOST R 34.10-2001-based key agreement AgreementMethod 412 node is: 414 416 ... 417 418 419 ... 420 421 422 423 ... 424 426 428 The shared keying material for algorithm based on GOST R 34.10-2001 429 needed will be calculated as a result of function VKO GOST R 34.10- 430 2001 (see Section 5.2 of [CPALGS]), which generates GOST KEK using 431 two GOST R 34.10-2001 keypairs and UKM. xenc:KA-Nonce node of xenc: 432 AgreementMethod contains base64 encoded 64-bits value of UKM, if UKM 433 is used. 435 6.6. GOST R 34.10-2001-based Key Transport Algorithm in 436 EncryptionMethod 438 The key transport alogorithm based on VKO GOST R 34.10-2001, 439 specified in [CPALGS], is public key encryption algorithms, that MUST 440 be used for key encryption/decryption only. 442 The identifier for the key transport algorithm based on VKO 443 GOST R 34.10-2001 is: 445 urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 447 An example of a VKO GOST R 34.10-2001-based key transport 448 EncryptedKey node is: 450 451 453 454 455 ... 456 457 458 459 ... 460 461 463 The CipherValue for such encrypted key is the base64 encoding of the 464 [X.208-88] DER encoding of a GostR3410-KeyTransport structure (see 465 section 4.2.1 of [CPCMS]). 467 6.7. GOST 28147-89 Algorithm in EncryptionMethod 469 The identifier for the GOST 28147-89 symmetric encryption algorithm 470 is: 472 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 474 The xenc:EncryptionMethod node may contain a child node cpxmlsec: 475 Parameters28147 specifying parameters for GOST 28147-89 algorithm. 476 cpxmlsec:Parameters28147 specifies the set of corresponding 477 Gost28147-89-ParamSetParameters (see Section 8.1 of [CPALGS]). 478 Encryption mode is specified by mode parameter of Gost28147-89- 479 ParamSetParameters structure. CFB and CNT modes are RECOMMENDED to 480 use. If cpxmlsec:Parameters28147 node is missing, the application 481 should infer algorithm parameters from other sources. 483 If the application omits cpxmlsec:Parameters28147 node, it SHOULD use 484 parameters defined by id-Gost28147-89-CryptoPro-A-ParamSet (see 485 Section of 10.2 [CPALGS]). 487 Schema Definition: 489 492 DTD Definition: 494 496 An example of a GOST 28147-89 xenc:EncryptionMethod node is: 498 500 501 urn:oid:1.2.643.2.2.31.1< 502 /cpxmlsec:Parameters28147> 503 505 256-bit key, 64-bit Initialization Vector (IV), and optional 506 parameters are used in GOST 28147-89 encryption algorithm. The 507 resulting cipher text is prefixed by the IV. If included in XML 508 output, it is then base64 encoded. 510 6.8. Symmetric Key Wrap 512 Symmetric Key Wrap algorithms considered in this section are shared 513 secret key encryption algorithms that MUST be used for symmetric keys 514 encryption/decryption only. 516 6.8.1. GOST 28147-89 Key Wrap in EncryptionMethod 518 The GOST 28147-89 Key Wrap algorithm wraps (encrypts) a key (the 519 wrapped key, WK) under a GOST 28147-89 Key Wrap (specified in 520 sections 6.1, 6.2 of [CPALGS]). 522 Note: This algorithm MUST NOT be used without key agreement 523 algorithm, because such WK is constant for every wrapping-encrypting 524 pair. Encrypting many different keys with the same constant WK may 525 reveal that WK. The only key agreement algorithm possible to use 526 with GOST 28147-89 Key Wrap defined by this specification is a 527 GOST R 34.10-2001-based key agreement (see Section 6.5). 529 The identifier for the GOST 28147-89 Key Wrap algorithm is: 531 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-gost 533 The CipherValue for such wrapped key is the base64 encoding of the 534 [X.208-88] DER encoding of a GostR3410-KeyWrap structure. 536 ASN.1 structure: 538 GostR3410-KeyWrap ::= 539 SEQUENCE { 540 encryptedKey Gost28147-89-EncryptedKey, 541 encryptedParameters Gost28147-89-KeyWrapParameters 542 } 544 An example of a GOST 28147-89 Key Wrap EncryptedData node is: 546 547 549 550 551 553 554 556 ... 557 558 559 ... 560 561 562 563 ... 564 565 566 567 568 ... 569 570 571 572 573 ... 574 575 577 Gost28147-89-KeyWrapParameters is described in section 4.1.1 of 578 [CPCMS]. The xenc:KA-Nonce node value of the xenc:AgreementMethod 579 node MUST be used as ukm. 581 The resulting wrapped key (WK) is placed in the Gost28147-89- 582 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 583 Gost28147-89-EncryptedKey macKey field. ukm field of Gost28147-89- 584 KeyWrapParameters MUST be absent. 586 6.8.2. CryptoPro Key Wrap in EncryptionMethod 588 The CryptoPro Key Wrap algorithm wraps (encrypts) a key (wrapped key, 589 WK) under a CryptoPro Key Wrap (specified in sections 6.3, 6.4 of 590 [CPALGS]). 592 The identifier for the CryptoPro Key Wrap algorithms is: 594 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp 596 The CipherValue for such wrapped key is the base64 encoding of the 597 [X.208-88] DER encoding of a GostR3410-KeyWrap structure (see 598 Section 6.8.1). 600 An example of a CryptoPro Key Wrap EncryptedData node is: 602 603 605 606 607 609 610 John Smith 611 612 613 ... 614 615 616 617 618 ... 619 620 622 The resulting wrapped key (WK) is placed in the Gost28147-89- 623 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 624 Gost28147-89-EncryptedKey macKey field. 626 If CryptoPro Key Wrap algorithm is combined with Key Agreement 627 Algorithm, the xenc:KA-Nonce node value of the xenc:AgreementMethod 628 node MUST be used as ukm. ukm field of Gost28147-89-KeyWrapParameters 629 type must be absent. 631 Note: The only key agreement algorithm possible to use with CryptoPro 632 Key Wrap defined by this specification is a GOST R 34.10-2001-based 633 key agreement (see Section 6.5). 635 If CryptoPro Key Wrap algorithm is not combined with Key Agreement 636 Algorithm, ukm field of Gost28147-89-KeyWrapParameters type MUST be 637 present. 639 7. Specifying GOST within WS-* 641 This section specifies the details of how to use GOST algorithms with 642 WS-SecureConversation [WS-SECURECONVERSATION], WS-SecurityPolicy 643 [WS-SECURITYPOLICY] and WS-Trust [WS-TRUST]. 645 7.1. GOST Algorithm Suite for WS-SecurityPolicy 647 This specification defines a new possible value for an [Algorithm 648 Suite] property of a Security Binding (see section 6.1 of 649 [WS-SECURITYPOLICY]). The new value is BasicGost. 651 BasicGost Algorithm Suite defines the following values for operations 652 and properties (without line breaks in URIs): 653 [Sym Sig] 654 urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 655 [Asym Sig] 656 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001- 657 gostr3411 658 [Dig] 659 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 660 [Enc] 661 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 662 [Sym KW] 663 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp 664 [Asym KW] 665 urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 666 [Comp Key] 667 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 668 [Enc KD] 669 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 670 [Sig KD] 671 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 672 [Min SKL] 673 256 674 [Max SKL] 675 256 676 [Min AKL] 677 512 678 [Max AKL] 679 512 681 Note: For definition of [Comp Key], [Enc KD] and [Sig KD] algorithm 682 see Section 7.2 684 To indicate a requirement to use GOST Algorithm Suite defined above 685 conforming implementaions MUST place cpxmlsec:BasicGost node in sp: 686 AlgorithmSuite Assertion (see section 7.1 of [WS-SECURITYPOLICY]). 688 Schema Definition: 690 693 DTD Definition: 695 697 An example of a GOST Algorithm Suite in sp:AlgorithmSuite Assertion 698 is: 700 701 702 703 704 706 7.2. GOST Key Derivation Algorithm for WS-SecureConversation 708 This specification defines a new possible value for an Algorithm 709 attribute of a wsc:DerivedKeyToken node (see section 7 of 710 [WS-SECURECONVERSATION]). 712 The new key derivation algorithm identifier is: 714 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 716 An example of a GOST Key Derivation Algorithm in wsc:DerivedKeyToken 717 node is: 719 721 ... 722 ... 723 725 GOST Key Derivation Algorithm uses a pseudorandom function 726 P_GOSTR3411 (see section 4 of [CPALGS]) to derive keys just like a 727 P_SHA-1 function is used in [WS-SECURECONVERSATION] (see section 7). 729 7.3. GOST Computed Key Mechanism for WS-Trust 731 This specification defines a new possible value for a wst:ComputedKey 732 node (see section 4.4.4 of [WS-TRUST]). 734 The new computed key mechanism identifier is: 736 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 738 An example of a GOST Computed Key Mechanism in wst:ComputedKey node 739 (without line breaks) is: 741 742 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 743 745 GOST Computed Key Mechanism uses a pseudorandom function P_GOSTR3411 746 (see section 4 of [CPALGS]) to compute a key just like a P_SHA-1 747 function is used in [WS-TRUST] (see section 4.4.4). It is REQUIRED 748 that EntREQ and EntRES are strings of length 256 bits. 750 7.4. Using WS-Trust for TLS Handshake with GOST Algorithm Suite 752 This specification defines how to use WS-Trust ([WS-TRUST]) to 753 perform TLS Handshake (see [TLS]) and establish secure session for 754 GOST Algorithm Suite. 756 WS-Trust can be used to do TLS Handshake as specified in 757 [WS-TRUST-TLS]. The outcome of the protocol under discussion is a 758 new session key issued using a secure session established by TLS 759 Handshake. Issued session key is intended to secure further 760 communication by means of WS-Security ([WS-SECURITY]). 762 If application is required to use GOST Algorithm Suite after 763 performing TLS Handshake by WS-Trust it MUST use one of GOST 28147-89 764 Cipher Suites for TLS (see [draft.CPTLS]). 766 The main flow of TLS Negotiation over WS-Trust defined in this 767 specification complies with [WS-TRUST-TLS], but there are a few 768 differences specified below that MUST be obeyed. 770 The paragraph R4305 (see section 4.3 of [WS-TRUST-TLS]) MUST be 771 replaced with the following text: 772 The responder is responsible for issuing the key associated with 773 the TLSNego session. If the initiator requested properties for 774 the generated key (e.g. key size) in the initial RST message, the 775 generated key SHOULD match those requirements. The issued key 776 MUST be communicated back to the initiator using the wst: 777 RequestedProofToken element and MUST be protected using CryptoPro 778 Key Wrap algorithm (see section 6.3 of [CPALGS]) where 779 server_write_key (see section 6.3 of [TLS]) is a wrapping key. 780 Wrapped key is contained in the ... elements of 782 the xenc:EncryptedKey. 784 GOST R 34.11-94 and P_GOSTR3411 algorithms MUST be used instead of 785 SHA1 and PSHA1 algorithms correspondingly to compute authenticator 786 (see section 4.9 of [WS-TRUST-TLS]). 788 8. Security Considerations 790 Conforming applications MUST use unique values for ukm and iv. 791 Recipients MAY verify that ukm and iv specified by the sender are 792 unique. 794 Applications SHOULD verify signature values, subject public keys and 795 algorithm parameters to conform to [GOSTR341001], standard before 796 using them. 798 Cryptographic algorithm parameters affect algorithm strength. Using 799 parameters not listed in [CPALGS] is NOT RECOMMENDED (see the 800 Security Considerations section of [CPALGS]). 802 Using the same key for signature and key derivation is NOT 803 RECOMMENDED. 805 It is NOT RECOMMENDED to use XML encryption without XML signature or 806 HMAC. 808 9. IANA Considerations 810 This document uses URNs to describe XML namespaces and XML schemas 811 conforming to a registry mechanism described in [RFC3688]. IANA has 812 registered two URI assignments. 814 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpxmlsec 816 URI: urn:ietf:params:xml:ns:cpxmlsec 818 Registrant Contact: 819 Mikhail V. Pavlov 820 CRYPTO-PRO, Ltd. 821 16/5, Suschevskij val 822 Moscow, 127018 823 Russia 824 Phone: +7 (495) 780 4820 825 Fax: +7 (495) 660 2330 826 Email: pav@CryptoPro.ru 827 URI: http://www.CryptoPro.ru 829 XML: None. Namespace URIs do not represent an XML specification. 831 9.2. Schema Registration 833 URI: urn:ietf:params:xml:schema:cpxmlsec 835 Registrant Contact: 836 Mikhail V. Pavlov 837 CRYPTO-PRO, Ltd. 838 16/5, Suschevskij val 839 Moscow, 127018 840 Russia 841 Phone: +7 (495) 780 4820 842 Fax: +7 (495) 660 2330 843 Email: pav@CryptoPro.ru 844 URI: http://www.CryptoPro.ru 846 XML: The XML can be found in Appendix A. 848 10. References 850 10.1. Normative references 852 [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 853 Cryptographic Algorithms for Use with GOST 28147-89, 854 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 855 Algorithms", RFC 4357, January 2006. 857 [CPCMS] Leontiev, S. and G. Chudov, "Using the GOST 28147-89, 858 GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 859 Algorithms with Cryptographic Message Syntax (CMS)", 860 RFC 4490, May 2006. 862 [CPPK] Leontiev, S. and D. Shefanovski, "Using the 863 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 864 Algorithms with the Internet X.509 Public Key 865 Infrastructure Certificate and CRL Profile", RFC 4491, 866 May 2006. 868 [GOST28147] 869 Government Committee of the USSR for Standards, 870 "Cryptographic Protection for Data Processing System, 871 Gosudarstvennyi Standard of USSR (In Russian)", 872 GOST 28147-89, 1989. 874 [GOST3431004] 875 Council for Standardization, Metrology and Certification 876 of the Commonwealth of Independence States (EASC), Minsk, 877 "Information technology. Cryptographic Data Security. 879 Formation and verification processes of (electronic) 880 digital signature based on Asymmetric Cryptographic 881 Algorithm (In Russian)", GOST 34.310-2004, 2004. 883 [GOST3431195] 884 Council for Standardization, Metrology and Certification 885 of the Commonwealth of Independence States (EASC), Minsk, 886 "Information technology. Cryptographic Data Security. 887 Cashing function (In Russian)", GOST 34.311-95, 1995. 889 [GOSTR341001] 890 Government Committee of the Russia for Standards, 891 "Information technology. Cryptographic Data 892 Security.Signature and verification processes of 893 [electronic] digital signature, Gosudarstvennyi Standard 894 of Russian Federation (In Russian)", GOST R 34.10-2001, 895 2001. 897 [GOSTR341194] 898 Government Committee of the Russia for Standards, 899 "Information technology. Cryptographic Data Security. 900 Hashing function, Gosudarstvennyi Standard of Russian 901 Federation (In Russian)", GOST R 34.11-94, 1994. 903 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 904 Hashing for Message Authentication", RFC 2104, 905 February 1997. 907 [KEYWORDS] 908 Bradner, S., "Key words for use in RFCs to Indicate 909 Requirement Levels", BCP 14, RFC 2119, March 1997. 911 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 912 January 2004. 914 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 915 Resource Identifier (URI): Generic Syntax", STD 66, 916 RFC 3986, January 2005. 918 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 919 Encodings", RFC 4648, October 2006. 921 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 922 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 924 [WS-POLICY] 925 Vedamuthu, A., Orchard, D., Hirsch, F., Hondo, M., 926 Yendluri, P., Boubez, T., and Ue. Yalcinalp, "Web Services 927 Policy 1.5 - Framework", W3C REC-ws-policy, 928 September 2007, . 930 [WS-SECURECONVERSATION] 931 Lawrence, K. and C. Kaler, "WS-SecureConversation 1.3", 932 OASIS Standard ws-secureconversation-1.3-os, March 2007, < 933 http://docs.oasis-open.org/ws-sx/ws-secureconversation/ 934 200512/ws-secureconversation-1.3-os.html>. 936 [WS-SECURITY] 937 Lawrence, K. and C. Kaler, "Web Services Security: SOAP 938 Message Security 1.1 (WS-Security 2004)", OASIS 939 Standard wss-v1.1-spec-os-SOAPMessageSecurity, 940 Febraury 2006, . 943 [WS-SECURITYPOLICY] 944 Lawrence, K. and C. Kaler, "WS-SecurityPolicy 1.2", OASIS 945 Standard ws-securitypolicy-1.2-spec-os, July 2007, . 949 [WS-TRUST] 950 Lawrence, K. and C. Kaler, "WS-Trust 1.3", OASIS 951 Standard ws-trust-1.3-os, March 2007, . 955 [WS-TRUST-TLS] 956 Alexander, J., Della-Libera, G., Gajjala, V., Gavrylyuk, 957 K., Kaler, C., McIntosh, M., Nadalin, A., Rich, B., and T. 958 Vishwanath, "Application Note: Using WS-Trust for TLS 959 Handshake", September 2007, . 963 [X.208-88] 964 International International Telephone and Telegraph 965 Consultative Committee, "Specification of Abstract Syntax 966 Notation One (ASN.1)", CCITT Recommendation X.208, 967 November 1988. 969 [XML-NS] Bray, T., Hollander, D., Layman, A., and R. Tobin, 970 "Namespaces in XML (Second Edition)", W3C REC-xml-names, 971 August 2006, 972 . 974 [XML-SCHEMA-1] 975 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 976 "XML Schema Part 1: Structures Second Edition", W3C REC- 977 xmlschema-1, October 2004, 978 . 980 [XML-SCHEMA-2] 981 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 982 Second Edition", W3C REC-xmlschema-2, October 2004, 983 . 985 [XMLDSIG] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 986 Language) XML-Signature Syntax and Processing", RFC 3275, 987 March 2002. 989 [XMLENC-CORE] 990 Eastlake, D. and J. Reagle , "XML Encryption Syntax and 991 Processing", W3C Candidate Recommendation xmlenc-core, 992 August 2002, . 994 [draft.CPTLS] 995 Afanasiev, A., Nikishin, N., Izotov, B., Minaeva, E., 996 Murugov, S., Ustinov, I., Erkin, A., Chudov, G., and S. 997 Leontiev, "GOST 28147-89 Cipher Suites for Transport Layer 998 Security (TLS)", draft-chudov-cryptopro-cptls-04 (work in 999 progress), December 2008. 1001 10.2. Informative references 1003 [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 1004 July 2005. 1006 [URNOID] Mealling, M., "A URN Namespace of Object Identifiers", 1007 RFC 3061, February 2001. 1009 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1010 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1011 Edition)", W3C REC-xml, August 2006, 1012 . 1014 Appendix A. Aggregate XML Schema 1016 1018 1020 1023 ]> 1025 1034 1039 1040 1041 1043 1044 1046 1049 1051 1052 1053 1056 1057 1058 1060 1061 1062 1064 1066 1070 1071 1073 1076 1079 1081 Appendix B. Aggregate DTD 1083 1085 1086 1089 1090 1091 1092 1093 1094 1096 Appendix C. Examples 1098 Examples here are stored in the same format as the examples in 1099 [RFC4134] and can be extracted using the same program. 1101 If you want to extract without the program, copy all the lines 1102 between the "|>" and "|<" markers, remove any page breaks, and remove 1103 the "|" in the first column of each line. The result is a valid 1104 Base64 blob that can be processed by any Base64 decoder. 1106 C.1. Signed document 1108 This sample contain the signed XML document using the sample 1109 certificate from Section 4.2 of [CPPK]. 1111 |>XmlDocSigned2001.xml 1112 |PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48Q3J5cHRvUHJv 1113 |WE1MIFNpZ25lZD0idHJ1ZSI+SGVyZSBpcyBzb21lIGRhdGEgdG8gc2lnbi48U2ln 1114 |bmF0dXJlIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcj 1115 |Ij48U2lnbmVkSW5mbz48Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09 1116 |Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1 1117 |IiAvPjxTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9y 1118 |Zy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0cjM0MTAyMDAxLWdvc3RyMzQxMSIg 1119 |Lz48UmVmZXJlbmNlIFVSST0iIj48VHJhbnNmb3Jtcz48VHJhbnNmb3JtIEFsZ29y 1120 |aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 1121 |ZC1zaWduYXR1cmUiIC8+PC9UcmFuc2Zvcm1zPjxEaWdlc3RNZXRob2QgQWxnb3Jp 1122 |dGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0 1123 |cjM0MTEiIC8+PERpZ2VzdFZhbHVlPi9Kd3RRc3Z5NWsvUjBWZUx6ZG0ySWlqUEJ0 1124 |U0o1cEpSalQ5RlVRSEV5VGc9PC9EaWdlc3RWYWx1ZT48L1JlZmVyZW5jZT48L1Np 1125 |Z25lZEluZm8+PFNpZ25hdHVyZVZhbHVlPkZjYjNxNGlCdmRmZ1lvN245NUdhUUN1 1126 |ZDkxWVA3dzhvVjAzUjZ6a1JEZGxjK0RuQ2MwcjlNc0E1YS9iaFlDeVdQZC9jRVU4 1127 |K3FZRnJ5SmJjaXJ5d0hBPT08L1NpZ25hdHVyZVZhbHVlPjxLZXlJbmZvPjxYNTA5 1128 |RGF0YT48WDUwOUNlcnRpZmljYXRlPk1JSUIwRENDQVg4Q0VDdjF4aDdDRWIwWHg5 1129 |elVZbWEwTGlFd0NBWUdLb1VEQWdJRE1HMHhIekFkQmdOVkJBTU1Ga2R2YzNSU016 1130 |UXhNQzB5TURBeElHVjRZVzF3YkdVeEVqQVFCZ05WQkFvTUNVTnllWEIwYjFCeWJ6 1131 |RUxNQWtHQTFVRUJoTUNVbFV4S1RBbkJna3Foa2lHOXcwQkNRRVdHa2R2YzNSU016 1132 |UXhNQzB5TURBeFFHVjRZVzF3YkdVdVkyOXRNQjRYRFRBMU1EZ3hOakUwTVRneU1G 1133 |b1hEVEUxTURneE5qRTBNVGd5TUZvd2JURWZNQjBHQTFVRUF3d1dSMjl6ZEZJek5E 1134 |RXdMVEl3TURFZ1pYaGhiWEJzWlRFU01CQUdBMVVFQ2d3SlEzSjVjSFJ2VUhKdk1R 1135 |c3dDUVlEVlFRR0V3SlNWVEVwTUNjR0NTcUdTSWIzRFFFSkFSWWFSMjl6ZEZJek5E 1136 |RXdMVEl3TURGQVpYaGhiWEJzWlM1amIyMHdZekFjQmdZcWhRTUNBaE13RWdZSEtv 1137 |VURBZ0lrQUFZSEtvVURBZ0llQVFOREFBUkFoSlZvZFdBQ0drQjFDTTBUakRHSkxQ 1138 |M2xCUU42UTF6MGJTc1A1MDh5ZmxlUDY4d1d1WldJQTlDYWZJV3VEK1NONnFhN2Zs 1139 |Ykh5N0RmRDJhOHl1b2FZREFJQmdZcWhRTUNBZ01EUVFBOEw4a0pSTGNucWV5bjFl 1140 |bjdVMjNTdzZwa2ZFUXUzdTB4RmtWUHZGUS8zY0hlRjI2TkcreHh0WlB6M1RhVFZY 1141 |ZG9pWWtYWWlEMDJyRXgxYlVjTTk3aTwvWDUwOUNlcnRpZmljYXRlPjwvWDUwOURh 1142 |dGE+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjwvQ3J5cHRvUHJvWE1MPg== 1143 |