idnits 2.17.1 draft-chudov-cryptopro-cpxmldsig-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 6, 2013) is 3793 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-1' is mentioned on line 1133, but not defined == Missing Reference: '1-3' is mentioned on line 1133, but not defined == Missing Reference: 'Dig' is mentioned on line 750, but not defined == Missing Reference: 'Enc' is mentioned on line 752, but not defined == Missing Reference: 'Sym KW' is mentioned on line 754, but not defined == Missing Reference: 'Asym KW' is mentioned on line 756, but not defined == Missing Reference: 'Enc KD' is mentioned on line 773, but not defined == Missing Reference: 'Sig KD' is mentioned on line 773, but not defined == Missing Reference: 'Min SKL' is mentioned on line 764, but not defined == Missing Reference: 'Max SKL' is mentioned on line 766, but not defined == Missing Reference: 'Min AKL' is mentioned on line 768, but not defined == Missing Reference: 'Max AKL' is mentioned on line 770, 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 CRYPTO-PRO 5 Expires: June 9, 2014 A. Chelpanov 6 InfoTeCS 7 December 6, 2013 9 Using GOST 28147-89, GOST R 34.10, and GOST R 34.11 Algorithms for XML 10 Security 11 draft-chudov-cryptopro-cpxmldsig-08 13 Abstract 15 This document specifies how to use Russian national cryptographic 16 standards GOST 28147-89, GOST R 34.10 and GOST R 34.11 with XML 17 Signatures, XML Encryption, WS-SecureConversation, WS-SecurityPolicy 18 and WS-Trust. A number of Uniform Resource Identifiers (URIs) and 19 XML elements are defined. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 9, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. GOST Cryptographic Algorithms . . . . . . . . . . . . . . . . 4 57 3. Version and Namespaces . . . . . . . . . . . . . . . . . . . . 4 58 4. XML Schema Preamble and DTD Replacement . . . . . . . . . . . 5 59 4.1. XML Schema Preamble . . . . . . . . . . . . . . . . . . . 6 60 4.2. DTD Replacement . . . . . . . . . . . . . . . . . . . . . 6 61 5. Object Identifiers Representation . . . . . . . . . . . . . . 6 62 6. Specifying GOST within XML Signature and XML Encryption . . . 6 63 6.1. GOST R 34.11-94 Algorithm in DigestMethod . . . . . . . . 7 64 6.2. GOST R 34.11-2012 Algorithm with 256-bit output in 65 DigestMethod . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.3. GOST R 34.11-2012 Algorithm with 512-bit output in 67 DigestMethod . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.4. GOST R 34.11-94 HMAC Algorithm in SignatureMethod . . . . 8 69 6.5. GOST R 34.10-2001 Algorithm in SignatureMethod . . . . . . 9 70 6.6. GOST R 34.10-2012 Algorithm in SignatureMethod . . . . . . 9 71 6.7. GOST R 34.10-2001 Public Key in KeyValue . . . . . . . . . 10 72 6.7.1. Key Value Root Element . . . . . . . . . . . . . . . . 10 73 6.7.2. Public Key Parameters . . . . . . . . . . . . . . . . 11 74 6.8. GOST R 34.10-2001-based Key Agreement Algorithm in 75 AgreementMethod . . . . . . . . . . . . . . . . . . . . . 12 76 6.9. GOST R 34.10-2001-based Key Transport Algorithm in 77 EncryptionMethod . . . . . . . . . . . . . . . . . . . . . 12 78 6.10. GOST 28147-89 Algorithm in EncryptionMethod . . . . . . . 13 79 6.11. GOST 28147-89 authenticated encryption in 80 EncryptionMethod . . . . . . . . . . . . . . . . . . . . . 14 81 6.12. Symmetric Key Wrap . . . . . . . . . . . . . . . . . . . . 15 82 6.12.1. GOST 28147-89 Key Wrap in EncryptionMethod . . . . . . 15 83 6.12.2. CryptoPro Key Wrap in EncryptionMethod . . . . . . . . 16 84 7. Specifying GOST within WS-* . . . . . . . . . . . . . . . . . 18 85 7.1. GOST Algorithm Suite for WS-SecurityPolicy . . . . . . . . 18 86 7.2. GOST Key Derivation Algorithm for WS-SecureConversation . 19 87 7.3. GOST Computed Key Mechanism for WS-Trust . . . . . . . . . 20 88 7.4. Using WS-Trust for TLS Handshake with GOST Algorithm 89 Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 9.1. URN Sub-Namespace Registration for 93 urn:ietf:params:xml:ns:cpxmlsec . . . . . . . . . . . . . 21 94 9.2. Schema Registration . . . . . . . . . . . . . . . . . . . 22 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 10.1. Normative references . . . . . . . . . . . . . . . . . . . 22 97 10.2. Informative references . . . . . . . . . . . . . . . . . . 25 98 Appendix A. Aggregate XML Schema . . . . . . . . . . . . . . . . 26 99 Appendix B. Aggregate DTD . . . . . . . . . . . . . . . . . . . . 27 100 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 27 101 C.1. Signed document . . . . . . . . . . . . . . . . . . . . . 28 102 Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . . 28 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 105 1. Introduction 107 This document specifies how to use GOST R 34.10 digital signatures 108 and public keys, GOST R 34.11 hash, GOST 28147-89 encryption 109 algorithms with XML Signatures [XMLDSIG], XML Encryption 110 [XMLENC-CORE], WS-SecureConversation [WS-SECURECONVERSATION], WS- 111 SecurityPolicy [WS-SECURITYPOLICY] and WS-Trust [WS-TRUST]. 113 This document uses both XML Schema ([XML-SCHEMA-1], [XML-SCHEMA-2]) 114 (normative) and DTD [XML] (informational) to specify the 115 corresponding XML structures. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 118 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 119 this document are to be interpreted as described in [KEYWORDS]. 121 2. GOST Cryptographic Algorithms 123 Algorithms GOST R 34.10-2001, GOST R 34.11-94 and GOST 28147-89 have 124 been developed by Russian Federal Agency of Governmental 125 Communication and Information (FAGCI) and "All-Russian Scientific and 126 Research Institute of Standardization". They are described in 127 [GOSTR341001], [GOSTR341194] ([GOST3431004] and [GOST3431195]) and 128 [GOST28147]. RECOMMENDED parameters for those algorithms are 129 described in [CPALGS]. 131 3. Version and Namespaces 133 This specification makes no provision for an explicit version number 134 in the syntax. If a future version is needed, it will use a 135 different namespace. 137 The XML namespace [XML-NS] URI [RFC3986] that MUST be used by 138 implementations of this (dated) specification is: 140 urn:ietf:params:xml:ns:cpxmlsec 142 The following external XML namespaces are used in this specification 143 (without line breaks; the choice of any namespace prefix is arbitrary 144 and not semantically significant): 146 http://www.w3.org/2000/09/xmldsig# 147 Prefix: 148 dsig 150 Specification: 151 [XMLDSIG] 153 http://www.w3.org/2001/04/xmlenc# 154 Prefix: 155 xenc 156 Specification: 157 [XMLENC-CORE] 159 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702 160 Prefix: 161 sp 162 Specification: 163 [WS-SECURITYPOLICY] 165 http://www.w3.org/ns/ws-policy 166 Prefix: 167 wsp 168 Specification: 169 [WS-POLICY] 171 http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512 172 Prefix: 173 wsc 174 Specification: 175 [WS-SECURECONVERSATION] 177 http://docs.oasis-open.org/wss/2004/01/ 178 oasis-200401-wss-wssecurity-secext-1.0.xsd 179 Prefix: 180 wsse 181 Specification: 182 [WS-SECURITY] 184 http://docs.oasis-open.org/ws-sx/ws-trust/200512/ 185 Prefix: 186 wst 187 Specification: 188 [WS-TRUST] 190 In the remaining sections of this document elements in the external 191 namespaces are marked as such by using the namespace prefixes defined 192 above. 194 4. XML Schema Preamble and DTD Replacement 195 4.1. XML Schema Preamble 197 The subsequent preamble is to be used with the XML Schema definitions 198 given in the remaining sections of this document. 200 209 4.2. DTD Replacement 211 In order to include GOST XML-signature syntax, the following 212 definition of the entity Key.ANY SHOULD replace the one in [XMLDSIG]: 214 216 5. Object Identifiers Representation 218 Object Identifiers (OIDs) are included in XML by the corresponding 219 URN value as defined in [URNOID]. 221 The subsequent type is to be used to define algorithm parameters by 222 OIDs: 224 225 226 228 229 231 6. Specifying GOST within XML Signature and XML Encryption 233 This section specifies the details of how to use GOST algorithms with 234 XML Signature Syntax and Processing [XMLDSIG] and XML Encryption 235 Syntax and Processing [XMLENC-CORE]. It relies heavily on syntaxes 236 and namespaces defined in [XMLDSIG] and [XMLENC-CORE]. 238 6.1. GOST R 34.11-94 Algorithm in DigestMethod 240 The identifier for the GOST R 34.11-94 digest algorithm is: 242 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 244 The dsig:DigestMethod node may contain a child node cpxmlsec: 245 ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. 246 cpxmlsec:ParametersR3411 node contains one OID specified in section 247 8.2 [CPALGS]. If cpxmlsec:ParametersR3411 node is missing, the 248 application should infer algorithm parameters from other sources. 250 If the application omits cpxmlsec:ParametersR3411 node, it SHOULD use 251 parameters defined by id-GostR3411-94-CryptoProParamSet (see Section 252 11.2 of [CPALGS]). 254 Schema Definition: 256 259 DTD Definition: 261 263 An example of a GOST R 34.11-94 dsig:DigestMethod node is: 265 267 268 urn:oid:1.2.643.2.2.30.1< 269 /cpxmlsec:ParametersR3411> 270 272 A GOST R 34.11-94 digest is a 256-bit string. The content of the 273 dsig:DigestValue element shall be the base64 [RFC4648] encoding of 274 this bit string viewed as a 32-octet octet stream. 276 6.2. GOST R 34.11-2012 Algorithm with 256-bit output in DigestMethod 278 The identifier for the GOST R 34.11-2012 digest algorithm with 256- 279 bit output is: 280 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256 282 An example of a GOST R 34.11-2012 with 256-bit output dsig: 283 DigestMethod node is: 285 288 A GOST R 34.11-2012 digest in this case is a 256-bit string. The 289 content of the dsig:DigestValue element shall be the base64 [RFC4648] 290 encoding of this bit string viewed as a 32-octet octet stream. 292 6.3. GOST R 34.11-2012 Algorithm with 512-bit output in DigestMethod 294 The identifier for the GOST R 34.11-2012 digest algorithm with 512- 295 bit output is: 296 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-512 298 An example of a GOST R 34.11-2012 with 512-bit output dsig: 299 DigestMethod node is: 301 304 A GOST R 34.11-2012 digest in this case is a 512-bit string. The 305 content of the dsig:DigestValue element shall be the base64 [RFC4648] 306 encoding of this bit string viewed as a 64-octet octet stream. 308 6.4. GOST R 34.11-94 HMAC Algorithm in SignatureMethod 310 GOST R 34.11-94 can also be used in HMAC [HMAC] as described in 311 section 6.3.1 of [XMLDSIG]. Identifier: 313 urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 315 The dsig:SignatureMethod node may contain a child node cpxmlsec: 316 ParametersR3411 specifying parameters for GOST R 34.11-94 algorithm. 317 cpxmlsec:ParametersR3411 node syntax and processing in this case are 318 equivalent to the ones in dsig:DigestMethod case. 320 An example of a GOST R 34.11-94 HMAC disg:SignatureMethod node is: 322 324 325 urn:oid:1.2.643.2.2.30.1< 326 /cpxmlsec:ParametersR3411> 328 330 The output of the GOST R 34.11-94 HMAC algorithm is ultimately the 331 output of the GOST R 34.11-94 digest algorithm. This value shall be 332 base64 [RFC4648] encoded for the dsig:SignatureValue in the same 333 straightforward fashion as the output of the digest algorithm in 334 Section 6.1. 336 6.5. GOST R 34.10-2001 Algorithm in SignatureMethod 338 The input to the GOST R 34.10-2001 algorithm is the canonicalized 339 representation of the dsig:SignedInfo element as specified in Section 340 3 of [XMLDSIG]. 342 The identifier for the GOST R 34.10-2001 signature algorithm is 343 (without line break): 345 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001-gostr3411 347 An example of a GOST R 34.10-2001 dsig:SignatureMethod node is 348 (without line break in attribute value): 350 354 GOST R 34.10-2001 signature is a 64-octet value as described in 355 section 2.2.2 of [CPPK]. The content of the dsig:SignatureValue 356 element shall be the base64 [RFC4648] encoding of this value. 358 6.6. GOST R 34.10-2012 Algorithm in SignatureMethod 360 The input to the GOST R 34.10-2012 algorithm is the canonicalized 361 representation of the dsig:SignedInfo element as specified in Section 362 3 of [XMLDSIG]. 364 The identifiers for the GOST R 34.10-2012 signature algorithm are 365 (without line breaks): 367 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012- 368 gostr34112012-256 369 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012- 370 gostr34112012-512 372 Both identifiers refer to GOST R 34.11-2012 as digest algorithm. The 373 first one denotes that the 256-bit output version of that algorithm 374 is used, the second one corresponds to 512-bit output. 376 An example of a GOST R 34.10-2012 dsig:SignatureMethod node is 377 (without line break in attribute value): 379 383 6.7. GOST R 34.10-2001 Public Key in KeyValue 385 6.7.1. Key Value Root Element 387 GOST R 34.10-2001 public key can be transmitted in cpxmlsec: 388 GOSTKeyValue node. It is included in dsig:KeyValue node just like 389 dsig:RSAKeyValue or xenc:DHKeyValue. 391 cpxmlsec:GOSTKeyValue node consists of an optional child node 392 cpxmlsec:PublicKeyParameters and a mandatory child node cpxmlsec: 393 PublicKey. If cpxmlsec:PublicKeyParameters node is missing, the 394 application should infer parameters from other sources. 396 Schema Definition: 398 401 402 403 406 407 408 410 DTD Definition: 412 414 416 If the application omits cpxmlsec:PublicKeyParameters node, it SHOULD 417 use parameters identified by DefaultPublicKeyParameters. 419 DefaultPublicKeyParameters: 421 422 423 urn:oid:1.2.643.2.2.35.1< 424 /cpxmlsec:publicKeyParamSet> 425 426 urn:oid:1.2.643.2.2.30.1 428 429 urn:oid:1.2.643.2.2.31.1 431 433 6.7.2. Public Key Parameters 435 cpxmlsec:PublicKeyParameters node contains three OIDs: cpxmlsec: 436 publicKeyParamSet, cpxmlsec:digestParamSet and optional cpxmlsec: 437 encryptionParamSet. Parameter values corresponding to these OIDs can 438 be found in [CPALGS]. 440 Schema Definition: 442 443 444 446 448 451 452 454 DTD Definition: 456 459 460 461 463 6.8. GOST R 34.10-2001-based Key Agreement Algorithm in AgreementMethod 465 Key agreement algorithm based on GOST R 34.10-2001 public keys (see 466 Section 5 of [CPALGS]) involves the derivation of shared secret 467 information using keys from the sender and recipient. 469 The identifier for the key agreement algorithm based on GOST R 34.10- 470 2001 is: 472 urn:ietf:params:xml:ns:cpxmlsec:algorithms:agree-gost2001 474 An example of a GOST R 34.10-2001-based key agreement AgreementMethod 475 node is: 477 479 ... 480 481 482 ... 483 484 485 486 ... 487 488 490 The shared keying material for algorithm based on GOST R 34.10-2001 491 needed will be calculated as a result of function VKO GOST R 34.10- 492 2001 (see Section 5.2 of [CPALGS]), which generates GOST KEK using 493 two GOST R 34.10-2001 keypairs and UKM. xenc:KA-Nonce node of xenc: 494 AgreementMethod contains base64 encoded 64-bits value of UKM, if UKM 495 is used. 497 6.9. GOST R 34.10-2001-based Key Transport Algorithm in 498 EncryptionMethod 500 The key transport algorithm based on VKO GOST R 34.10-2001, specified 501 in [CPALGS], is public key encryption algorithms, that MUST be used 502 for key encryption/decryption only. 504 The identifier for the key transport algorithm based on VKO 505 GOST R 34.10-2001 is: 507 urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 509 An example of a VKO GOST R 34.10-2001-based key transport 510 EncryptedKey node is: 512 513 515 516 517 ... 518 519 520 521 ... 522 523 525 The CipherValue for such encrypted key is the base64 encoding of the 526 [X.208-88] DER encoding of a GostR3410-KeyTransport structure (see 527 section 4.2.1 of [CPCMS]). 529 6.10. GOST 28147-89 Algorithm in EncryptionMethod 531 The identifier for the GOST 28147-89 symmetric encryption algorithm 532 is: 534 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 536 The xenc:EncryptionMethod node may contain a child node cpxmlsec: 537 Parameters28147 specifying parameters for GOST 28147-89 algorithm. 538 cpxmlsec:Parameters28147 specifies the set of corresponding 539 Gost28147-89-ParamSetParameters (see Section 8.1 of [CPALGS]). 540 Encryption mode is specified by mode parameter of Gost28147-89- 541 ParamSetParameters structure. CFB and CNT modes are RECOMMENDED to 542 use. If cpxmlsec:Parameters28147 node is missing, the application 543 should infer algorithm parameters from other sources. 545 If the application omits cpxmlsec:Parameters28147 node, it SHOULD use 546 parameters defined by id-Gost28147-89-CryptoPro-A-ParamSet (see 547 Section of 10.2 [CPALGS]). 549 Schema Definition: 551 554 DTD Definition: 556 558 An example of a GOST 28147-89 xenc:EncryptionMethod node is: 560 562 563 urn:oid:1.2.643.2.2.31.1< 564 /cpxmlsec:Parameters28147> 565 567 256-bit key, 64-bit Initialization Vector (IV), and optional 568 parameters are used in GOST 28147-89 encryption algorithm. The 569 resulting cipher text is prefixed by the IV. If included in XML 570 output, it is then base64 encoded. 572 6.11. GOST 28147-89 authenticated encryption in EncryptionMethod 574 The identifier for the GOST 28147-89 authenticated encryption 575 algorithm is: 577 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147aead 579 The xenc:EncryptionMethod node may contain a child node cpxmlsec: 580 Parameters28147 specifying parameters for GOST 28147-89 algorithm. 582 If the application omits cpxmlsec:Parameters28147 node, it SHOULD use 583 parameters defined by id-tc26-gost-28147-param-Z. 585 An example of a GOST 28147-89 AEAD xenc:EncryptionMethod node is: 587 589 590 urn:oid:1.2.643.7.1.2.5.1.1< 591 /cpxmlsec:Parameters28147> 592 594 256-bit key, 64-bit Initialization Vector (IV), and optional 595 parameters are used in GOST 28147-89 authenticated encryption 596 algorithm. The resulting cipher text is prefixed by the IV and 597 suffixed by the MAC. Standard XML encryption padding, id-Gost28147- 598 89-CryptoPro-KeyMeshing, imitovstavka and CNT mode should be used 599 during encryption. If included in XML output, it is then base64 600 encoded. 602 6.12. Symmetric Key Wrap 604 Symmetric Key Wrap algorithms considered in this section are shared 605 secret key encryption algorithms that MUST be used for symmetric keys 606 encryption/decryption only. 608 6.12.1. GOST 28147-89 Key Wrap in EncryptionMethod 610 The GOST 28147-89 Key Wrap algorithm wraps (encrypts) a key (the 611 wrapped key, WK) under a GOST 28147-89 Key Wrap (specified in 612 sections 6.1, 6.2 of [CPALGS]). 614 Note: This algorithm MUST NOT be used without key agreement 615 algorithm, because such WK is constant for every wrapping-encrypting 616 pair. Encrypting many different keys with the same constant WK may 617 reveal that WK. The only key agreement algorithm possible to use 618 with GOST 28147-89 Key Wrap defined by this specification is a 619 GOST R 34.10-2001-based key agreement (see Section 6.8). 621 The identifier for the GOST 28147-89 Key Wrap algorithm is: 623 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-gost 625 The CipherValue for such wrapped key is the base64 encoding of the 626 [X.208-88] DER encoding of a GostR3410-KeyWrap structure. 628 ASN.1 structure: 630 GostR3410-KeyWrap ::= 631 SEQUENCE { 632 encryptedKey Gost28147-89-EncryptedKey, 633 encryptedParameters Gost28147-89-KeyWrapParameters 634 } 636 An example of a GOST 28147-89 Key Wrap EncryptedData node is: 638 639 641 642 643 645 646 648 ... 649 650 651 ... 652 653 654 655 ... 656 657 658 659 660 ... 661 662 663 664 665 ... 666 667 669 Gost28147-89-KeyWrapParameters is described in section 4.1.1 of 670 [CPCMS]. The xenc:KA-Nonce node value of the xenc:AgreementMethod 671 node MUST be used as ukm. 673 The resulting wrapped key (WK) is placed in the Gost28147-89- 674 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 675 Gost28147-89-EncryptedKey macKey field. ukm field of Gost28147-89- 676 KeyWrapParameters MUST be absent. 678 6.12.2. CryptoPro Key Wrap in EncryptionMethod 680 The CryptoPro Key Wrap algorithm wraps (encrypts) a key (wrapped key, 681 WK) under a CryptoPro Key Wrap (specified in sections 6.3, 6.4 of 682 [CPALGS]). 684 The identifier for the CryptoPro Key Wrap algorithms is: 686 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp 688 The CipherValue for such wrapped key is the base64 encoding of the 689 [X.208-88] DER encoding of a GostR3410-KeyWrap structure (see 690 Section 6.12.1). 692 An example of a CryptoPro Key Wrap EncryptedData node is: 694 695 697 698 699 701 702 John Smith 703 704 705 ... 706 707 708 709 710 ... 711 712 714 The resulting wrapped key (WK) is placed in the Gost28147-89- 715 EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the 716 Gost28147-89-EncryptedKey macKey field. 718 If CryptoPro Key Wrap algorithm is combined with Key Agreement 719 Algorithm, the xenc:KA-Nonce node value of the xenc:AgreementMethod 720 node MUST be used as ukm. ukm field of Gost28147-89-KeyWrapParameters 721 type must be absent. 723 Note: The only key agreement algorithm possible to use with CryptoPro 724 Key Wrap defined by this specification is a GOST R 34.10-2001-based 725 key agreement (see Section 6.8). 727 If CryptoPro Key Wrap algorithm is not combined with Key Agreement 728 Algorithm, ukm field of Gost28147-89-KeyWrapParameters type MUST be 729 present. 731 7. Specifying GOST within WS-* 733 This section specifies the details of how to use GOST algorithms with 734 WS-SecureConversation [WS-SECURECONVERSATION], WS-SecurityPolicy 735 [WS-SECURITYPOLICY] and WS-Trust [WS-TRUST]. 737 7.1. GOST Algorithm Suite for WS-SecurityPolicy 739 This specification defines a new possible value for an [Algorithm 740 Suite] property of a Security Binding (see section 6.1 of 741 [WS-SECURITYPOLICY]). The new value is BasicGost. 743 BasicGost Algorithm Suite defines the following values for operations 744 and properties (without line breaks in URIs): 745 [Sym Sig] 746 urn:ietf:params:xml:ns:cpxmlsec:algorithms:hmac-gostr3411 747 [Asym Sig] 748 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102001- 749 gostr3411 750 [Dig] 751 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr3411 752 [Enc] 753 urn:ietf:params:xml:ns:cpxmlsec:algorithms:gost28147 754 [Sym KW] 755 urn:ietf:params:xml:ns:cpxmlsec:algorithms:kw-cp 756 [Asym KW] 757 urn:ietf:params:xml:ns:cpxmlsec:algorithms:transport-gost2001 758 [Comp Key] 759 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 760 [Enc KD] 761 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 762 [Sig KD] 763 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 764 [Min SKL] 765 256 766 [Max SKL] 767 256 768 [Min AKL] 769 512 770 [Max AKL] 771 512 773 Note: For definition of [Comp Key], [Enc KD] and [Sig KD] algorithm 774 see Section 7.2 776 To indicate a requirement to use GOST Algorithm Suite defined above 777 conforming implementations MUST place cpxmlsec:BasicGost node in sp: 778 AlgorithmSuite Assertion (see section 7.1 of [WS-SECURITYPOLICY]). 780 Schema Definition: 782 785 DTD Definition: 787 789 An example of a GOST Algorithm Suite in sp:AlgorithmSuite Assertion 790 is: 792 793 794 795 796 798 7.2. GOST Key Derivation Algorithm for WS-SecureConversation 800 This specification defines a new possible value for an Algorithm 801 attribute of a wsc:DerivedKeyToken node (see section 7 of 802 [WS-SECURECONVERSATION]). 804 The new key derivation algorithm identifier is: 806 urn:ietf:params:xml:ns:cpxmlsec:algorithms:dk-p-gostr3411 808 An example of a GOST Key Derivation Algorithm in wsc:DerivedKeyToken 809 node is: 811 813 ... 814 ... 815 817 GOST Key Derivation Algorithm uses a pseudo-random function 818 P_GOSTR3411 (see section 4 of [CPALGS]) to derive keys just like a 819 P_SHA-1 function is used in [WS-SECURECONVERSATION] (see section 7). 821 7.3. GOST Computed Key Mechanism for WS-Trust 823 This specification defines a new possible value for a wst:ComputedKey 824 node (see section 4.4.4 of [WS-TRUST]). 826 The new computed key mechanism identifier is: 828 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 830 An example of a GOST Computed Key Mechanism in wst:ComputedKey node 831 (without line breaks) is: 833 834 urn:ietf:params:xml:ns:cpxmlsec:algorithms:ck-p-gostr3411 835 837 GOST Computed Key Mechanism uses a pseudo-random function P_GOSTR3411 838 (see section 4 of [CPALGS]) to compute a key just like a P_SHA-1 839 function is used in [WS-TRUST] (see section 4.4.4). It is REQUIRED 840 that EntREQ and EntRES are strings of length 256 bits. 842 7.4. Using WS-Trust for TLS Handshake with GOST Algorithm Suite 844 This specification defines how to use WS-Trust ([WS-TRUST]) to 845 perform TLS Handshake (see [TLS]) and establish secure session for 846 GOST Algorithm Suite. 848 WS-Trust can be used to do TLS Handshake as specified in 849 [WS-TRUST-TLS]. The outcome of the protocol under discussion is a 850 new session key issued using a secure session established by TLS 851 Handshake. Issued session key is intended to secure further 852 communication by means of WS-Security ([WS-SECURITY]). 854 If application is required to use GOST Algorithm Suite after 855 performing TLS Handshake by WS-Trust it MUST use one of GOST 28147-89 856 Cipher Suites for TLS (see [draft.CPTLS]). 858 The main flow of TLS Negotiation over WS-Trust defined in this 859 specification complies with [WS-TRUST-TLS], but there are a few 860 differences specified below that MUST be obeyed. 862 The paragraph R4305 (see section 4.3 of [WS-TRUST-TLS]) MUST be 863 replaced with the following text: 864 The responder is responsible for issuing the key associated with 865 the TLSNego session. If the initiator requested properties for 866 the generated key (e.g. key size) in the initial RST message, the 867 generated key SHOULD match those requirements. The issued key 868 MUST be communicated back to the initiator using the wst: 869 RequestedProofToken element and MUST be protected using CryptoPro 870 Key Wrap algorithm (see section 6.3 of [CPALGS]) where 871 server_write_key (see section 6.3 of [TLS]) is a wrapping key. 872 Wrapped key is contained in the ... elements of 874 the xenc:EncryptedKey. 876 GOST R 34.11-94 and P_GOSTR3411 algorithms MUST be used instead of 877 SHA1 and PSHA1 algorithms correspondingly to compute authenticator 878 (see section 4.9 of [WS-TRUST-TLS]). 880 8. Security Considerations 882 Conforming applications MUST use unique values for ukm and iv. 883 Recipients MAY verify that ukm and iv specified by the sender are 884 unique. 886 Applications SHOULD verify signature values, subject public keys and 887 algorithm parameters to conform to [GOSTR341001], standard before 888 using them. 890 Cryptographic algorithm parameters affect algorithm strength. Using 891 parameters not listed in [CPALGS] is NOT RECOMMENDED (see the 892 Security Considerations section of [CPALGS]). 894 Using the same key for signature and key derivation is NOT 895 RECOMMENDED. 897 It is NOT RECOMMENDED to use XML encryption without XML signature or 898 HMAC. 900 9. IANA Considerations 902 This document uses URNs to describe XML namespaces and XML schemata 903 conforming to a registry mechanism described in [RFC3688]. IANA has 904 registered two URI assignments. 906 9.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpxmlsec 908 URI: urn:ietf:params:xml:ns:cpxmlsec 910 Registrant Contact: 911 Mikhail V. Pavlov 912 CRYPTO-PRO, Ltd. 913 16/5, Suschevskij val 914 Moscow, 127018 915 Russia 916 Phone: +7 (495) 780 4820 917 Fax: +7 (495) 660 2330 918 Email: pav@CryptoPro.ru 919 URI: http://www.CryptoPro.ru 921 XML: None. Namespace URIs do not represent an XML specification. 923 9.2. Schema Registration 925 URI: urn:ietf:params:xml:schema:cpxmlsec 927 Registrant Contact: 928 Mikhail V. Pavlov 929 CRYPTO-PRO, Ltd. 930 16/5, Suschevskij val 931 Moscow, 127018 932 Russia 933 Phone: +7 (495) 780 4820 934 Fax: +7 (495) 660 2330 935 Email: pav@CryptoPro.ru 936 URI: http://www.CryptoPro.ru 938 XML: The XML can be found in Appendix A. 940 10. References 942 10.1. Normative references 944 [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 945 Cryptographic Algorithms for Use with GOST 28147-89, 946 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 947 Algorithms", RFC 4357, January 2006. 949 [CPCMS] Leontiev, S. and G. Chudov, "Using the GOST 28147-89, 950 GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 951 Algorithms with Cryptographic Message Syntax (CMS)", 952 RFC 4490, May 2006. 954 [CPPK] Leontiev, S. and D. Shefanovski, "Using the 955 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 956 Algorithms with the Internet X.509 Public Key 957 Infrastructure Certificate and CRL Profile", RFC 4491, 958 May 2006. 960 [GOST28147] 961 Government Committee of the USSR for Standards, 962 "Cryptographic Protection for Data Processing System, 963 Gosudarstvennyi Standard of USSR (In Russian)", 964 GOST 28147-89, 1989. 966 [GOST3431004] 967 Council for Standardization, Metrology and Certification 968 of the Commonwealth of Independence States (EASC), Minsk, 969 "Information technology. Cryptographic Data Security. 970 Formation and verification processes of (electronic) 971 digital signature based on Asymmetric Cryptographic 972 Algorithm (In Russian)", GOST 34.310-2004, 2004. 974 [GOST3431195] 975 Council for Standardization, Metrology and Certification 976 of the Commonwealth of Independence States (EASC), Minsk, 977 "Information technology. Cryptographic Data Security. 978 Cashing function (In Russian)", GOST 34.311-95, 1995. 980 [GOSTR341001] 981 Government Committee of the Russia for Standards, 982 "Information technology. Cryptographic Data 983 Security.Signature and verification processes of 984 [electronic] digital signature, Gosudarstvennyi Standard 985 of Russian Federation (In Russian)", GOST R 34.10-2001, 986 2001. 988 [GOSTR341194] 989 Government Committee of the Russia for Standards, 990 "Information technology. Cryptographic Data Security. 991 Hashing function, Gosudarstvennyi Standard of Russian 992 Federation (In Russian)", GOST R 34.11-94, 1994. 994 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 995 Hashing for Message Authentication", RFC 2104, 996 February 1997. 998 [KEYWORDS] 999 Bradner, S., "Key words for use in RFCs to Indicate 1000 Requirement Levels", BCP 14, RFC 2119, March 1997. 1002 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1003 January 2004. 1005 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1006 Resource Identifier (URI): Generic Syntax", STD 66, 1007 RFC 3986, January 2005. 1009 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1010 Encodings", RFC 4648, October 2006. 1012 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 1013 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1015 [WS-POLICY] 1016 Vedamuthu, A., Orchard, D., Hirsch, F., Hondo, M., 1017 Yendluri, P., Boubez, T., and . Yalinalp, "Web Services 1018 Policy 1.5 - Framework", W3C REC-ws-policy, 1019 September 2007, . 1021 [WS-SECURECONVERSATION] 1022 Lawrence, K. and C. Kaler, "WS-SecureConversation 1.3", 1023 OASIS Standard ws-secureconversation-1.3-os, March 2007, < 1024 http://docs.oasis-open.org/ws-sx/ws-secureconversation/ 1025 200512/ws-secureconversation-1.3-os.html>. 1027 [WS-SECURITY] 1028 Lawrence, K. and C. Kaler, "Web Services Security: SOAP 1029 Message Security 1.1 (WS-Security 2004)", OASIS 1030 Standard wss-v1.1-spec-os-SOAPMessageSecurity, 1031 Febraury 2006, . 1034 [WS-SECURITYPOLICY] 1035 Lawrence, K. and C. Kaler, "WS-SecurityPolicy 1.2", OASIS 1036 Standard ws-securitypolicy-1.2-spec-os, July 2007, . 1040 [WS-TRUST] 1041 Lawrence, K. and C. Kaler, "WS-Trust 1.3", OASIS 1042 Standard ws-trust-1.3-os, March 2007, . 1046 [WS-TRUST-TLS] 1047 Alexander, J., Della-Libera, G., Gajjala, V., Gavrylyuk, 1048 K., Kaler, C., McIntosh, M., Nadalin, A., Rich, B., and T. 1049 Vishwanath, "Application Note: Using WS-Trust for TLS 1050 Handshake", September 2007, . 1054 [X.208-88] 1055 International International Telephone and Telegraph 1056 Consultative Committee, "Specification of Abstract Syntax 1057 Notation One (ASN.1)", CCITT Recommendation X.208, 1058 November 1988. 1060 [XML-NS] Bray, T., Hollander, D., Layman, A., and R. Tobin, 1061 "Namespaces in XML (Second Edition)", W3C REC-xml-names, 1062 August 2006, 1063 . 1065 [XML-SCHEMA-1] 1066 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1067 "XML Schema Part 1: Structures Second Edition", W3C REC- 1068 xmlschema-1, October 2004, 1069 . 1071 [XML-SCHEMA-2] 1072 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1073 Second Edition", W3C REC-xmlschema-2, October 2004, 1074 . 1076 [XMLDSIG] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 1077 Language) XML-Signature Syntax and Processing", RFC 3275, 1078 March 2002. 1080 [XMLENC-CORE] 1081 Eastlake, D. and J. Reagle , "XML Encryption Syntax and 1082 Processing", W3C Candidate Recommendation xmlenc-core, 1083 August 2002, . 1085 [draft.CPTLS] 1086 Afanasiev, A., Nikishin, N., Izotov, B., Minaeva, E., 1087 Murugov, S., Ustinov, I., Erkin, A., Chudov, G., and S. 1088 Leontiev, "GOST 28147-89 Cipher Suites for Transport Layer 1089 Security (TLS)", draft-chudov-cryptopro-cptls-04 (work in 1090 progress), December 2008. 1092 10.2. Informative references 1094 [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 1095 July 2005. 1097 [URNOID] Mealling, M., "A URN Namespace of Object Identifiers", 1098 RFC 3061, February 2001. 1100 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1101 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth 1102 Edition)", W3C REC-xml, August 2006, 1103 . 1105 Appendix A. Aggregate XML Schema 1107 1109 1111 1114 ]> 1116 1125 1130 1131 1132 1134 1135 1137 1140 1142 1143 1144 1147 1148 1149 1151 1152 1153 1155 1157 1160 1161 1163 1166 1169 1171 Appendix B. Aggregate DTD 1173 1175 1176 1179 1180 1181 1182 1183 1184 1186 Appendix C. Examples 1188 Examples here are stored in the same format as the examples in 1189 [RFC4134] and can be extracted using the same program. 1191 If you want to extract without the program, copy all the lines 1192 between the "|>" and "|<" markers, remove any page breaks, and remove 1193 the "|" in the first column of each line. The result is a valid 1194 Base64 blob that can be processed by any Base64 decoder. 1196 C.1. Signed document 1198 This sample contain the signed XML document using the sample 1199 certificate from Section 4.2 of [CPPK]. 1201 |>XmlDocSigned2001.xml 1202 |PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz48Q3J5cHRvUHJv 1203 |WE1MIFNpZ25lZD0idHJ1ZSI+SGVyZSBpcyBzb21lIGRhdGEgdG8gc2lnbi48U2ln 1204 |bmF0dXJlIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcj 1205 |Ij48U2lnbmVkSW5mbz48Q2Fub25pY2FsaXphdGlvbk1ldGhvZCBBbGdvcml0aG09 1206 |Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDEvUkVDLXhtbC1jMTRuLTIwMDEwMzE1 1207 |IiAvPjxTaWduYXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9y 1208 |Zy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0cjM0MTAyMDAxLWdvc3RyMzQxMSIg 1209 |Lz48UmVmZXJlbmNlIFVSST0iIj48VHJhbnNmb3Jtcz48VHJhbnNmb3JtIEFsZ29y 1210 |aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3Bl 1211 |ZC1zaWduYXR1cmUiIC8+PC9UcmFuc2Zvcm1zPjxEaWdlc3RNZXRob2QgQWxnb3Jp 1212 |dGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzA0L3htbGRzaWctbW9yZSNnb3N0 1213 |cjM0MTEiIC8+PERpZ2VzdFZhbHVlPi9Kd3RRc3Z5NWsvUjBWZUx6ZG0ySWlqUEJ0 1214 |U0o1cEpSalQ5RlVRSEV5VGc9PC9EaWdlc3RWYWx1ZT48L1JlZmVyZW5jZT48L1Np 1215 |Z25lZEluZm8+PFNpZ25hdHVyZVZhbHVlPkZjYjNxNGlCdmRmZ1lvN245NUdhUUN1 1216 |ZDkxWVA3dzhvVjAzUjZ6a1JEZGxjK0RuQ2MwcjlNc0E1YS9iaFlDeVdQZC9jRVU4 1217 |K3FZRnJ5SmJjaXJ5d0hBPT08L1NpZ25hdHVyZVZhbHVlPjxLZXlJbmZvPjxYNTA5 1218 |RGF0YT48WDUwOUNlcnRpZmljYXRlPk1JSUIwRENDQVg4Q0VDdjF4aDdDRWIwWHg5 1219 |elVZbWEwTGlFd0NBWUdLb1VEQWdJRE1HMHhIekFkQmdOVkJBTU1Ga2R2YzNSU016 1220 |UXhNQzB5TURBeElHVjRZVzF3YkdVeEVqQVFCZ05WQkFvTUNVTnllWEIwYjFCeWJ6 1221 |RUxNQWtHQTFVRUJoTUNVbFV4S1RBbkJna3Foa2lHOXcwQkNRRVdHa2R2YzNSU016 1222 |UXhNQzB5TURBeFFHVjRZVzF3YkdVdVkyOXRNQjRYRFRBMU1EZ3hOakUwTVRneU1G 1223 |b1hEVEUxTURneE5qRTBNVGd5TUZvd2JURWZNQjBHQTFVRUF3d1dSMjl6ZEZJek5E 1224 |RXdMVEl3TURFZ1pYaGhiWEJzWlRFU01CQUdBMVVFQ2d3SlEzSjVjSFJ2VUhKdk1R 1225 |c3dDUVlEVlFRR0V3SlNWVEVwTUNjR0NTcUdTSWIzRFFFSkFSWWFSMjl6ZEZJek5E 1226 |RXdMVEl3TURGQVpYaGhiWEJzWlM1amIyMHdZekFjQmdZcWhRTUNBaE13RWdZSEtv 1227 |VURBZ0lrQUFZSEtvVURBZ0llQVFOREFBUkFoSlZvZFdBQ0drQjFDTTBUakRHSkxQ 1228 |M2xCUU42UTF6MGJTc1A1MDh5ZmxlUDY4d1d1WldJQTlDYWZJV3VEK1NONnFhN2Zs 1229 |Ykh5N0RmRDJhOHl1b2FZREFJQmdZcWhRTUNBZ01EUVFBOEw4a0pSTGNucWV5bjFl 1230 |bjdVMjNTdzZwa2ZFUXUzdTB4RmtWUHZGUS8zY0hlRjI2TkcreHh0WlB6M1RhVFZY 1231 |ZG9pWWtYWWlEMDJyRXgxYlVjTTk3aTwvWDUwOUNlcnRpZmljYXRlPjwvWDUwOURh 1232 |dGE+PC9LZXlJbmZvPjwvU2lnbmF0dXJlPjwvQ3J5cHRvUHJvWE1MPg== 1233 |