idnits 2.17.1 draft-chudov-cryptopro-cpxmldsig-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1119. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1130. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1143. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 17, 2008) is 5607 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-1' is mentioned on line 957, but not defined == Missing Reference: '1-3' is mentioned on line 957, but not defined == Missing Reference: 'Dig' is mentioned on line 646, but not defined == Missing Reference: 'Enc' is mentioned on line 648, but not defined == Missing Reference: 'Sym KW' is mentioned on line 650, but not defined == Missing Reference: 'Asym KW' is mentioned on line 652, but not defined == Missing Reference: 'Enc KD' is mentioned on line 669, but not defined == Missing Reference: 'Sig KD' is mentioned on line 669, but not defined == Missing Reference: 'Min SKL' is mentioned on line 660, but not defined == Missing Reference: 'Max SKL' is mentioned on line 662, but not defined == Missing Reference: 'Min AKL' is mentioned on line 664, but not defined == Missing Reference: 'Max AKL' is mentioned on line 666, but not defined Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Leontiev 3 Internet-Draft P. Smirnov 4 Intended status: Informational A. Chelpanov 5 Expires: June 20, 2009 CRYPTO-PRO 6 December 17, 2008 8 Using GOST 28147-89, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms 9 for XML Security 10 draft-chudov-cryptopro-cpxmldsig-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 20, 2009. 37 Abstract 39 This document specifies how to use Russian national cryptographic 40 standards GOST 28147-89, GOST R 34.10-2001 and GOST R 34.11-94 with 41 XML Signatures, XML Encryption, WS-SecureConversation, WS- 42 SecurityPolicy and WS-Trust. A number of Uniform Resource 43 Identifiers (URIs) and XML elements are defined. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. GOST Cryptographic Algorithms . . . . . . . . . . . . . . . . 3 49 3. Version and Namespaces . . . . . . . . . . . . . . . . . . . . 3 50 4. XML Schema Preamble and DTD Replacement . . . . . . . . . . . 4 51 4.1. XML Schema Preamble . . . . . . . . . . . . . . . . . . . 5 52 4.2. DTD Replacement . . . . . . . . . . . . . . . . . . . . . 5 53 5. Object Identifiers Representation . . . . . . . . . . . . . . 5 54 6. Specifying GOST within XML Signature and XML Encryption . . . 5 55 6.1. GOST R 34.11-94 Algorithm in DigestMethod . . . . . . . . 6 56 6.2. GOST R 34.11-94 HMAC Algorithm in SignatureMethod . . . . 6 57 6.3. GOST R 34.10-2001 Algorithm in SignatureMethod . . . . . . 7 58 6.4. GOST R 34.10-2001 Public Key in KeyValue . . . . . . . . . 7 59 6.4.1. Key Value Root Element . . . . . . . . . . . . . . . . 7 60 6.4.2. Public Key Parameters . . . . . . . . . . . . . . . . 8 61 6.5. GOST R 34.10-2001-based Key Agreement Algorithm in 62 AgreementMethod . . . . . . . . . . . . . . . . . . . . . 9 63 6.6. GOST R 34.10-2001-based Key Transport Algorithm in 64 EncryptionMethod . . . . . . . . . . . . . . . . . . . . . 10 65 6.7. GOST 28147-89 Algorithm in EncryptionMethod . . . . . . . 10 66 6.8. Symmetric Key Wrap . . . . . . . . . . . . . . . . . . . . 11 67 6.8.1. GOST 28147-89 Key Wrap in EncryptionMethod . . . . . . 11 68 6.8.2. CryptoPro Key Wrap in EncryptionMethod . . . . . . . . 13 69 7. Specifying GOST within WS-* . . . . . . . . . . . . . . . . . 15 70 7.1. GOST Algorithm Suite for WS-SecurityPolicy . . . . . . . . 15 71 7.2. GOST Key Derivation Algorithm for WS-SecureConversation . 16 72 7.3. GOST Computed Key Mechanism for WS-Trust . . . . . . . . . 16 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 75 9.1. URN Sub-Namespace Registration for 76 urn:ietf:params:xml:ns:cpxmlsec . . . . . . . . . . . . . 17 77 9.2. Schema Registration . . . . . . . . . . . . . . . . . . . 18 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 10.1. Normative references . . . . . . . . . . . . . . . . . . . 18 80 10.2. Informative references . . . . . . . . . . . . . . . . . . 21 81 Appendix A. Aggregate XML Schema . . . . . . . . . . . . . . . . 21 82 Appendix B. Aggregate DTD . . . . . . . . . . . . . . . . . . . . 22 83 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 23 84 C.1. Signed document . . . . . . . . . . . . . . . . . . . . . 23 85 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 24 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 87 Intellectual Property and Copyright Statements . . . . . . . . . . 26 89 1. Introduction 91 This document specifies how to use GOST R 34.10-2001 digital 92 signatures and public keys, GOST R 34.11-94 hash, GOST 28147-89 93 encryption algorithms with XML Signatures [XMLDSIG], XML Encryption 94 [XMLENC-CORE], WS-SecureConversation [WS-SECURECONVERSATION], WS- 95 SecurityPolicy [WS-SECURITYPOLICY] and WS-Trust [WS-TRUST]. 97 This document uses both XML Schemas ([XML-SCHEMA-1], [XML-SCHEMA-2]) 98 (normative) and DTDs [XML] (informational) to specify the 99 corresponding XML structures. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 102 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 103 this document are to be interpreted as described in [KEYWORDS]. 105 2. GOST Cryptographic Algorithms 107 Algorithms GOST R 34.10-2001, GOST R 34.11-94 and GOST 28147-89 have 108 been developed by Russian Federal Agency of Governmental 109 Communication and Information (FAGCI) and "All-Russian Scientific and 110 Research Institute of Standardization". They are described in 111 [GOSTR341001], [GOSTR341194] ([GOST3431004] and [GOST3431195]) and 112 [GOST28147]. RECOMMENDED parameters for those algorithms are 113 described in [CPALGS]. 115 3. Version and Namespaces 117 This specification makes no provision for an explicit version number 118 in the syntax. If a future version is needed, it will use a 119 different namespace. 121 The XML namespace [XML-NS] URI [RFC3986] that MUST be used by 122 implementations of this (dated) specification is: 124 urn:ietf:params:xml:ns:cpxmlsec 126 The following external XML namespaces are used in this specification 127 (without line breaks; the choice of any namespace prefix is arbitrary 128 and not semantically significant): 130 http://www.w3.org/2000/09/xmldsig# 131 Prefix: 132 dsig 134 Specification: 135 [XMLDSIG] 137 http://www.w3.org/2001/04/xmlenc# 138 Prefix: 139 xenc 140 Specification: 141 [XMLENC-CORE] 143 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 144 Prefix: 145 sp 146 Specification: 147 [WS-SECURITYPOLICY] 149 http://www.w3.org/ns/ws-policy 150 Prefix: 151 wsp 152 Specification: 153 [WS-POLICY] 155 http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 156 Prefix: 157 wsc 158 Specification: 159 [WS-SECURECONVERSATION] 161 http://docs.oasis-open.org/wss/2004/01/ 162 oasis-200401-wss-wssecurity-secext-1.0.xsd 163 Prefix: 164 wsse 165 Specification: 166 [WS-SECURITY] 168 http://docs.oasis-open.org/ws-sx/ws-trust/200512/ 169 Prefix: 170 wst 171 Specification: 172 [WS-TRUST] 174 In the remaining sections of this document elements in the external 175 namespaces are marked as such by using the namespace prefixes defined 176 above. 178 4. XML Schema Preamble and DTD Replacement 179 4.1. XML Schema Preamble 181 The subsequent preamble is to be used with the XML Schema definitions 182 given in the remaining sections of this document. 184 193 4.2. DTD Replacement 195 In order to include GOST XML-signature syntax, the following 196 definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 198 200 5. Object Identifiers Representation 202 Object Identifiers (OIDs) are included in XML by the corresponding 203 URN value as defined in [URNOID]. 205 The subsequent type is to be used to define algorithm parameters by 206 OIDs: 208 209 210 212 213 215 6. Specifying GOST within XML Signature and XML Encryption 217 This section specifies the details of how to use GOST algorithms with 218 XML Signature Syntax and Processing [XMLDSIG] and XML Encryption 219 Syntax and Processing [XMLENC-CORE]. It relies heavily on syntaxes 220 and namespaces defined in [XMLDSIG] and [XMLENC-CORE]. 222 6.1. GOST R 34.11-94 Algorithm in DigestMethod 224 The identifier for the GOST R 34.11-94 digest algorithm is: 226 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 228 The dsig:DigestMethod node may contain a child node gost: 229 ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. 230 gost:ParametersR3411 node contains one OID specified in section 8.2 231 [CPALGS]. If gost:ParametersR3411 node is missing, the application 232 should infer algorithm parameters from other sources. 234 If the application omits gost:ParametersR3411 node, it SHOULD use 235 parameters defined by id-GostR3411-94-CryptoProParamSet (see Section 236 11.2 of [CPALGS]). 238 Schema Definition: 240 243 DTD Definition: 245 247 An example of a GOST R 34.11-94 dsig:DigestMethod node is: 249 251 252 urn:oid:1.2.643.2.2.30.1< 253 /gost:ParametersR3411> 254 256 A GOST R 34.11-94 digest is a 256-bit string. The content of the 257 dsig:DigestValue element shall be the base64 [RFC4648] encoding of 258 this bit string viewed as a 32-octet octet stream. 260 6.2. GOST R 34.11-94 HMAC Algorithm in SignatureMethod 262 GOST R 34.11-94 can also be used in HMAC [HMAC] as described in 263 section 6.3.1 of [XMLDSIG]. Identifier: 265 urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 267 The dsig:SignatureMethod node may contain a child node gost: 268 ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. 269 gost:ParametersR3411 node syntax and processing in this case are 270 equivalent to the ones in dsig:DigestMethod case. 272 An example of a GOST R 34.11-94 HMAC disg:SignatureMethod node is: 274 276 277 urn:oid:1.2.643.2.2.30.1< 278 /gost:ParametersR3411> 279 281 The output of the GOST R 34.11-94 HMAC algorithm is ultimately the 282 output of the GOST R 34.11-94 digest algorithm. This value shall be 283 base64 [RFC4648] encoded for the dsig:SignatureValue in the same 284 straightforward fashion as the output of the digest algorithm. 286 6.3. GOST R 34.10-2001 Algorithm in SignatureMethod 288 The input to the GOST R 34.10-2001 algorithm is the canonicalized 289 representation of the dsig:SignedInfo element as specified in Section 290 3 of [XMLDSIG]. 292 The identifier for the GOST R 34.10-2001 signature algorithm is 293 (without line break): 295 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411 297 An example of a GOST R 34.10-2001 dsig:SignatureMethod node is 298 (without line break in attribute value): 300 304 GOST R 34.10-2001 signature is a 64-octet value as described in 305 section 2.2 of [CPPK]. The content of the dsig:SignatureValue 306 element shall be the base64 [RFC4648] encoding of this value. 308 6.4. GOST R 34.10-2001 Public Key in KeyValue 310 6.4.1. Key Value Root Element 312 GOST R 34.10-2001 public key can be transmitted in gost:GOSTKeyValue 313 node. It is included in dsig:KeyValue node just like dsig: 314 RSAKeyValue or xenc:DHKeyValue. 316 gost:GOSTKeyValue node consists of an optional child node gost: 317 PublicKeyParameters and a mandatory child node gost:PublicKey. If 318 gost:PublicKeyParameters node is missing, the application should 319 infer parameters from other sources. 321 Schema Definition: 323 326 327 328 331 332 333 335 DTD Definition: 337 339 341 If the application omits gost:PublicKeyParameters node, it SHOULD use 342 parameters identified by DefaultPublicKeyParameters. 344 DefaultPublicKeyParameters: 346 347 348 urn:oid:1.2.643.2.2.35.1< 349 /gost:publicKeyParamSet> 350 351 urn:oid:1.2.643.2.2.30.1 353 354 urn:oid:1.2.643.2.2.31.1 356 358 6.4.2. Public Key Parameters 360 gost:PublicKeyParameters node contains three OIDs: gost: 361 publicKeyParamSet, gost:digestParamSet and optional gost: 362 encryptionParamSet. Parameter values corresponding to these OIDs can 363 be found in [CPALGS]. 365 Schema Definition: 367 368 369 371 373 376 377 379 DTD Definition: 381 384 385 386 388 6.5. GOST R 34.10-2001-based Key Agreement Algorithm in AgreementMethod 390 Key agreement algorithm based on GOST R 34.10-2001 public keys (see 391 Section 5 of [CPALGS]) involves the derivation of shared secret 392 information using keys from the sender and recipient. 394 The identifier for the key agreement algorithm based on GOST R 34.10- 395 2001 is: 397 urn:ietf:params:xml:ns:cpxmlsec:algorithms:agree-gost2001 399 An example of a GOST R 34.10-2001-based key agreement AgreementMethod 400 node is: 402 404 ... 405 406 407 ... 408 409 410 411 ... 412 414 416 The shared keying material for algorithm based on GOST R 34.10-2001 417 needed will be calculated as a result of function VKO GOST R 34.10- 418 2001 (see Section 5.2 of [CPALGS]), which generates GOST KEK using 419 two GOST R 34.10-2001 keypairs and UKM. xenc:KA-Nonce node of xenc: 420 AgreementMethod contains base64 encoded 64-bits value of UKM, if UKM 421 is used. 423 6.6. GOST R 34.10-2001-based Key Transport Algorithm in 424 EncryptionMethod 426 The key transport alogorithm based on VKO GOST R 34.10-2001, 427 specified in [CPALGS], is public key encryption algorithms, that MUST 428 be used for key encryption/decryption only. 430 The identifier for the key transport algorithm based on VKO 431 GOST R 34.10-2001 is: 433 urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 435 An example of a VKO GOST R 34.10-2001-based key transport 436 EncryptedKey node is: 438 439 441 442 443 ... 444 445 446 447 ... 448 449 451 The CipherValue for such encrypted key is the base64 encoding of the 452 [X.208-88] DER encoding of a GostR3410-KeyTransport structure (see 453 section 4.2.1 of [CPCMS]). 455 6.7. GOST 28147-89 Algorithm in EncryptionMethod 457 The identifier for the GOST 28147-89 symmetric encryption algorithm 458 is: 460 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 462 The xenc:EncryptionMethod node may contain a child node gost: 463 Parameters28147 specifying parameters for GOST 28147-89 algorithm. 464 gost:Parameters28147 specifies the set of corresponding Gost28147-89- 465 ParamSetParameters (see Section 8.1 of [CPALGS]). Encryption mode is 466 specified by mode parameter of Gost28147-89-ParamSetParameters 467 structure. CFB and CNT modes are RECOMMENDED to use. If gost: 468 Parameters28147 node is missing, the application should infer 469 algorithm parameters from other sources. 471 If the application omits gost:Parameters28147 node, it SHOULD use 472 parameters defined by id-Gost28147-89-CryptoPro-A-ParamSet (see 473 Section of 10.2 [CPALGS]). 475 Schema Definition: 477 480 DTD Definition: 482 484 An example of a GOST 28147-89 xenc:EncryptionMethod node is: 486 488 489 urn:oid:1.2.643.2.2.31.1< 490 /gost:Parameters28147> 491 493 256-bit key, 64-bit Initialization Vector (IV), and optional 494 parameters are used in GOST 28147-89 encryption algorithm. The 495 resulting cipher text is prefixed by the IV. If included in XML 496 output, it is then base64 encoded. 498 6.8. Symmetric Key Wrap 500 Symmetric Key Wrap algorithms considered in this section are shared 501 secret key encryption algorithms that MUST be used for symmetric keys 502 encryption/decryption only. 504 6.8.1. GOST 28147-89 Key Wrap in EncryptionMethod 506 The GOST 28147-89 Key Wrap algorithm wraps (encrypts) a key (the 507 wrapped key, WK) under a GOST 28147-89 Key Wrap (specified in 508 sections 6.1, 6.2 of [CPALGS]). 510 Note: This algorithm MUST NOT be used without key agreement 511 algorithm, because such WK is constant for every wrapping-encrypting 512 pair. Encrypting many different keys with the same constant WK may 513 reveal that WK. The only key agreement algorithm possible to use 514 with GOST 28147-89 Key Wrap defined by this specification is a 515 GOST R 34.10-2001-based key agreement (see Section 6.5). 517 The identifier for the GOST 28147-89 Key Wrap algorithm is: 519 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-gost 521 The CipherValue for such wrapped key is the base64 encoding of the 522 [X.208-88] DER encoding of a GostR3410-KeyWrap structure. 524 ASN.1 structure: 526 GostR3410-KeyWrap ::= 527 SEQUENCE { 528 encryptedKey Gost28147-89-EncryptedKey, 529 encryptedParameters Gost28147-89-KeyWrapParameters 530 } 532 An example of a GOST 28147-89 Key Wrap EncryptedData node is: 534 535 537 538 539 541 542 544 ... 545 546 547 ... 548 549 550 551 ... 552 553 554 555 556 ... 557 558 559 560 561 ... 562 563 565 Gost28147-89-KeyWrapParameters is described in section 4.1.1 of 566 [CPCMS]. The xenc:KA-Nonce node value of the xenc:AgreementMethod 567 node MUST be used as ukm. 569 The resulting wrapped key (WK) is placed in the Gost28147-89- 570 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 571 Gost28147-89-EncryptedKey macKey field. ukm field of Gost28147-89- 572 KeyWrapParameters MUST be absent. 574 6.8.2. CryptoPro Key Wrap in EncryptionMethod 576 The CryptoPro Key Wrap algorithm wraps (encrypts) a key (wrapped key, 577 WK) under a CryptoPro Key Wrap (specified in sections 6.3, 6.4 of 578 [CPALGS]). 580 The identifier for the CryptoPro Key Wrap algorithms is: 582 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp 584 The CipherValue for such wrapped key is the base64 encoding of the 585 [X.208-88] DER encoding of a GostR3410-KeyWrap structure (see 586 Section 6.8.1). 588 An example of a CryptoPro Key Wrap EncryptedData node is: 590 591 593 594 595 597 598 John Smith 599 600 601 ... 602 603 604 605 606 ... 607 608 610 The resulting wrapped key (WK) is placed in the Gost28147-89- 611 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 612 Gost28147-89-EncryptedKey macKey field. 614 If CryptoPro Key Wrap algorithm is combined with Key Agreement 615 Algorithm, the xenc:KA-Nonce node value of the xenc:AgreementMethod 616 node MUST be used as ukm. ukm field of Gost28147-89-KeyWrapParameters 617 type must be absent. 619 Note: The only key agreement algorithm possible to use with CryptoPro 620 Key Wrap defined by this specification is a GOST R 34.10-2001-based 621 key agreement (see Section 6.5). 623 If CryptoPro Key Wrap algorithm is not combined with Key Agreement 624 Algorithm, ukm field of Gost28147-89-KeyWrapParameters type MUST be 625 present. 627 7. Specifying GOST within WS-* 629 This section specifies the details of how to use GOST algorithms with 630 WS-SecureConversation [WS-SECURECONVERSATION], WS-SecurityPolicy 631 [WS-SECURITYPOLICY] and WS-Trust [WS-TRUST]. 633 7.1. GOST Algorithm Suite for WS-SecurityPolicy 635 This specification defines a new possible value for an [Algorithm 636 Suite] property of a Security Binding (see section 6.1 of 637 [WS-SECURITYPOLICY]). The new value is BasicGost. 639 BasicGost Algorithm Suite defines the following values for operations 640 and properties (without line breaks in URIs): 641 [Sym Sig] 642 urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 643 [Asym Sig] 644 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001- 645 gostr3411 646 [Dig] 647 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 648 [Enc] 649 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 650 [Sym KW] 651 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp 652 [Asym KW] 653 urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 654 [Comp Key] 655 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 656 [Enc KD] 657 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 658 [Sig KD] 659 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 660 [Min SKL] 661 256 662 [Max SKL] 663 256 664 [Min AKL] 665 512 666 [Max AKL] 667 512 669 Note: For definition of [Comp Key], [Enc KD] and [Sig KD] algorithm 670 see Section 7.2 672 To indicate a requirement to use GOST Algorithm Suite defined above 673 conforming implementaions MUST place gost:BasicGost node in sp: 674 AlgorithmSuite Assertion (see section 7.1 of [WS-SECURITYPOLICY]). 676 Schema Definition: 678 681 DTD Definition: 683 685 An example of a GOST Algorithm Suite in sp:AlgorithmSuite Assertion 686 is: 688 689 690 691 692 694 7.2. GOST Key Derivation Algorithm for WS-SecureConversation 696 This specification defines a new possible value for an Algorithm 697 attribute of a wsc:DerivedKeyToken node (see section 7 of 698 [WS-SECURECONVERSATION]). 700 The new key derivation algorithm identifier is: 702 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 704 An example of a GOST Key Derivation Algorithm in wsc:DerivedKeyToken 705 node is: 707 709 ... 710 ... 711 713 GOST Key Derivation Algorithm uses a pseudorandom function 714 P_GOSTR3411 (see section 4 of [CPALGS]) to derive keys just like a 715 P_SHA-1 function is used in [WS-SECURECONVERSATION] (see section 7). 717 7.3. GOST Computed Key Mechanism for WS-Trust 719 This specification defines a new possible value for a wst:ComputedKey 720 node (see section 4.4.4 of [WS-TRUST]). 722 The new computed key mechanism identifier is: 724 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 726 An example of a GOST Computed Key Mechanism in wst:ComputedKey node 727 (without line breaks) is: 729 730 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 731 733 GOST Computed Key Mechanism uses a pseudorandom function P_GOSTR3411 734 (see section 4 of [CPALGS]) to compute a key just like a P_SHA-1 735 function is used in [WS-TRUST] (see section 4.4.4). It is REQUIRED 736 that EntREQ and EntRES are strings of length 256 bits. 738 8. Security Considerations 740 Conforming applications MUST use unique values for ukm and iv. 741 Recipients MAY verify that ukm and iv specified by the sender are 742 unique. 744 Applications SHOULD verify signature values, subject public keys and 745 algorithm parameters to conform to [GOSTR341001], standard before 746 using them. 748 Cryptographic algorithm parameters affect algorithm strength. Using 749 parameters not listed in [CPALGS] is NOT RECOMMENDED (see the 750 Security Considerations section of [CPALGS]). 752 Using the same key for signature and key derivation is NOT 753 RECOMMENDED. 755 It is NOT RECOMMENDED to use XML encryption without XML signature or 756 HMAC. 758 9. IANA Considerations 760 This document uses URNs to describe XML namespaces and XML schemas 761 conforming to a registry mechanism described in [RFC3688]. IANA has 762 registered two URI assignments. 764 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpxmlsec 766 URI: urn:ietf:params:xml:ns:cpxmlsec 768 Registrant Contact: See the "Authors' Addresses" section of this 769 document. 771 XML: None. Namespace URIs do not represent an XML specification. 773 9.2. Schema Registration 775 URI: urn:ietf:params:xml:schema:cpxmlsec 777 Registrant Contact: See the "Authors' Addresses" section of this 778 document. 780 XML: The XML can be found in Appendix A. 782 10. References 784 10.1. Normative references 786 [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 787 Cryptographic Algorithms for Use with GOST 28147-89, 788 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 789 Algorithms", RFC 4357, January 2006. 791 [CPCMS] Leontiev, S. and G. Chudov, "Using the GOST 28147-89, 792 GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 793 Algorithms with Cryptographic Message Syntax (CMS)", 794 RFC 4490, May 2006. 796 [CPPK] Leontiev, S. and D. Shefanovski, "Using the 797 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 798 Algorithms with the Internet X.509 Public Key 799 Infrastructure Certificate and CRL Profile", RFC 4491, 800 May 2006. 802 [GOST28147] 803 Government Committee of the USSR for Standards, 804 "Cryptographic Protection for Data Processing System, 805 Gosudarstvennyi Standard of USSR (In Russian)", 806 GOST 28147-89, 1989. 808 [GOST3431004] 809 Council for Standardization, Metrology and Certification 810 of the Commonwealth of Independence States (EASC), Minsk, 811 "Information technology. Cryptographic Data Security. 812 Formation and verification processes of (electronic) 813 digital signature based on Asymmetric Cryptographic 814 Algorithm (In Russian)", GOST 34.310-2004, 2004. 816 [GOST3431195] 817 Council for Standardization, Metrology and Certification 818 of the Commonwealth of Independence States (EASC), Minsk, 819 "Information technology. Cryptographic Data Security. 820 Cashing function (In Russian)", GOST 34.311-95, 1995. 822 [GOSTR341001] 823 Government Committee of the Russia for Standards, 824 "Information technology. Cryptographic Data 825 Security.Signature and verification processes of 826 [electronic] digital signature, Gosudarstvennyi Standard 827 of Russian Federation (In Russian)", GOST R 34.10-2001, 828 2001. 830 [GOSTR341194] 831 Government Committee of the Russia for Standards, 832 "Information technology. Cryptographic Data Security. 833 Hashing function, Gosudarstvennyi Standard of Russian 834 Federation (In Russian)", GOST R 34.11-94, 1994. 836 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 837 Hashing for Message Authentication", RFC 2104, 838 February 1997. 840 [KEYWORDS] 841 Bradner, S., "Key words for use in RFCs to Indicate 842 Requirement Levels", BCP 14, RFC 2119, March 1997. 844 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 845 January 2004. 847 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 848 Resource Identifier (URI): Generic Syntax", STD 66, 849 RFC 3986, January 2005. 851 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 852 Encodings", RFC 4648, October 2006. 854 [WS-POLICY] 855 Vedamuthu, A., Orchard, D., Hirsch, F., Hondo, M., 856 Yendluri, P., Boubez, T., and Ue. Yalcinalp, "Web Services 857 Policy 1.5 - Framework", W3C REC-ws-policy, 858 September 2007, . 860 [WS-SECURECONVERSATION] 861 Lawrence, K. and C. Kaler, "WS-SecureConversation 1.3", 862 OASIS Standard ws-secureconversation-1.3-os, March 2007, < 863 http://docs.oasis-open.org/ws-sx/ws-secureconversation/ 864 200512/ws-secureconversation-1.3-os.html>. 866 [WS-SECURITY] 867 Lawrence, K. and C. Kaler, "Web Services Security: SOAP 868 Message Security 1.1 (WS-Security 2004)", OASIS 869 Standard wss-v1.1-spec-os-SOAPMessageSecurity, 870 Febraury 2006, . 873 [WS-SECURITYPOLICY] 874 Lawrence, K. and C. Kaler, "WS-SecurityPolicy 1.2", OASIS 875 Standard ws-securitypolicy-1.2-spec-os, July 2007, . 879 [WS-TRUST] 880 Lawrence, K. and C. Kaler, "WS-Trust 1.3", OASIS 881 Standard ws-trust-1.3-os, March 2007, . 885 [X.208-88] 886 International International Telephone and Telegraph 887 Consultative Committee, "Specification of Abstract Syntax 888 Notation One (ASN.1)", CCITT Recommendation X.208, 889 November 1988. 891 [XML-NS] Bray, T., Hollander, D., Layman, A., and R. Tobin, 892 "Namespaces in XML (Second Edition)", W3C REC-xml-names, 893 August 2006, 894 . 896 [XML-SCHEMA-1] 897 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 898 "XML Schema Part 1: Structures Second Edition", W3C REC- 899 xmlschema-1, October 2004, 900 . 902 [XML-SCHEMA-2] 903 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 904 Second Edition", W3C REC-xmlschema-2, October 2004, 905 . 907 [XMLDSIG] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 908 Language) XML-Signature Syntax and Processing", RFC 3275, 909 March 2002. 911 [XMLENC-CORE] 912 Eastlake, D. and J. Reagle , "XML Encryption Syntax and 913 Processing", W3C Candidate Recommendation xmlenc-core, 914 August 2002, . 916 10.2. Informative references 918 [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 919 July 2005. 921 [URNOID] Mealling, M., "A URN Namespace of Object Identifiers", 922 RFC 3061, February 2001. 924 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 925 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 926 Edition)", W3C REC-xml, August 2006, 927 . 929 Appendix A. Aggregate XML Schema 931 933 935 938 ]> 940 949 954 955 956 959 960 962 965 967 968 969 972 973 974 976 977 978 980 982 985 986 988 991 994 996 Appendix B. Aggregate DTD 997 999 1000 1003 1004 1005 1006 1007 1008 1010 Appendix C. Examples 1012 Examples here are stored in the same format as the examples in 1013 [RFC4134] and can be extracted using the same program. 1015 If you want to extract without the program, copy all the lines 1016 between the "|>" and "|<" markers, remove any page breaks, and remove 1017 the "|" in the first column of each line. The result is a valid 1018 Base64 blob that can be processed by any Base64 decoder. 1020 C.1. Signed document 1022 This sample contain the signed XML document using the sample 1023 certificate from Section 4.2 of [CPPK]. 1025 |>XmlDocSigned2001.xml 1026 |PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48Q3J5cHRvUHJv 1027 |WE1MIFNpZ25lZD0idHJ1ZSI+SGVyZSBpcyBzb21lIGRhdGEgdG8gc2lnbi48U2ln 1028 |bmF0dXJlIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcj 1029 |Ij48U2lnbmVkSW5mbz48Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09 1030 |Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1 1031 |IiAvPjxTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9y 1032 |Zy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0cjM0MTAyMDAxLWdvc3RyMzQxMSIg 1033 |Lz48UmVmZXJlbmNlIFVSST0iIj48VHJhbnNmb3Jtcz48VHJhbnNmb3JtIEFsZ29y 1034 |aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 1035 |ZC1zaWduYXR1cmUiIC8+PC9UcmFuc2Zvcm1zPjxEaWdlc3RNZXRob2QgQWxnb3Jp 1036 |dGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0 1037 |cjM0MTEiIC8+PERpZ2VzdFZhbHVlPi9Kd3RRc3Z5NWsvUjBWZUx6ZG0ySWlqUEJ0 1038 |U0o1cEpSalQ5RlVRSEV5VGc9PC9EaWdlc3RWYWx1ZT48L1JlZmVyZW5jZT48L1Np 1039 |Z25lZEluZm8+PFNpZ25hdHVyZVZhbHVlPkZjYjNxNGlCdmRmZ1lvN245NUdhUUN1 1040 |ZDkxWVA3dzhvVjAzUjZ6a1JEZGxjK0RuQ2MwcjlNc0E1YS9iaFlDeVdQZC9jRVU4 1041 |K3FZRnJ5SmJjaXJ5d0hBPT08L1NpZ25hdHVyZVZhbHVlPjxLZXlJbmZvPjxYNTA5 1042 |RGF0YT48WDUwOUNlcnRpZmljYXRlPk1JSUIwRENDQVg4Q0VDdjF4aDdDRWIwWHg5 1043 |elVZbWEwTGlFd0NBWUdLb1VEQWdJRE1HMHhIekFkQmdOVkJBTU1Ga2R2YzNSU016 1044 |UXhNQzB5TURBeElHVjRZVzF3YkdVeEVqQVFCZ05WQkFvTUNVTnllWEIwYjFCeWJ6 1045 |RUxNQWtHQTFVRUJoTUNVbFV4S1RBbkJna3Foa2lHOXcwQkNRRVdHa2R2YzNSU016 1046 |UXhNQzB5TURBeFFHVjRZVzF3YkdVdVkyOXRNQjRYRFRBMU1EZ3hOakUwTVRneU1G 1047 |b1hEVEUxTURneE5qRTBNVGd5TUZvd2JURWZNQjBHQTFVRUF3d1dSMjl6ZEZJek5E 1048 |RXdMVEl3TURFZ1pYaGhiWEJzWlRFU01CQUdBMVVFQ2d3SlEzSjVjSFJ2VUhKdk1R 1049 |c3dDUVlEVlFRR0V3SlNWVEVwTUNjR0NTcUdTSWIzRFFFSkFSWWFSMjl6ZEZJek5E 1050 |RXdMVEl3TURGQVpYaGhiWEJzWlM1amIyMHdZekFjQmdZcWhRTUNBaE13RWdZSEtv 1051 |VURBZ0lrQUFZSEtvVURBZ0llQVFOREFBUkFoSlZvZFdBQ0drQjFDTTBUakRHSkxQ 1052 |M2xCUU42UTF6MGJTc1A1MDh5ZmxlUDY4d1d1WldJQTlDYWZJV3VEK1NONnFhN2Zs 1053 |Ykh5N0RmRDJhOHl1b2FZREFJQmdZcWhRTUNBZ01EUVFBOEw4a0pSTGNucWV5bjFl 1054 |bjdVMjNTdzZwa2ZFUXUzdTB4RmtWUHZGUS8zY0hlRjI2TkcreHh0WlB6M1RhVFZY 1055 |ZG9pWWtYWWlEMDJyRXgxYlVjTTk3aTwvWDUwOUNlcnRpZmljYXRlPjwvWDUwOURh 1056 |dGE+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjwvQ3J5cHRvUHJvWE1MPg== 1057 |