idnits 2.17.1 draft-chudov-cryptopro-cptls-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 688. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (September 8, 2006) is 6439 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 170 -- Looks like a reference, but probably isn't: '32' on line 340 ** Downref: Normative reference to an Informational RFC: RFC 4357 (ref. 'CPALGS') -- Possible downref: Non-RFC (?) normative reference: ref. 'GOST28147' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOST3431004' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOST3431095' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOST3431195' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOSTR341001' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOSTR341094' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOSTR341194' -- Obsolete informational reference (is this intentional?): RFC 2716 (ref. 'EAP-TLS') (Obsoleted by RFC 5216) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 - G. Chudov, Ed. 3 Internet-Draft S. Leontiev, Ed. 4 Intended status: Standards Track CRYPTO-PRO 5 Expires: March 12, 2007 September 8, 2006 7 GOST 28147-89 Cipher Suites for Transport Layer Security (TLS) 8 draft-chudov-cryptopro-cptls-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of 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 March 12, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document is intended to register new cipher suites for the 42 Transport Layer Security (TLS) protocol, according to the procedure 43 specified in TLS Protocol standards. These cipher suites are based 44 on Russian national cryptographic standards - GOST R 34.10-94 and 45 GOST R 34.10-2001 public keys, GOST 28147-89 encryption algorithm and 46 GOST R 34.11-94 digest algorithm. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. CipherSuite Definitions . . . . . . . . . . . . . . . . . . . 3 52 2.1. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. PRF, Signature and Hash . . . . . . . . . . . . . . . . . 4 54 2.3. Cipher and MAC . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Data Structures and Computations . . . . . . . . . . . . . . . 5 56 3.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. Keys Calculation . . . . . . . . . . . . . . . . . . . . . 5 58 3.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 5 59 3.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 5 60 3.5. Certificate Request . . . . . . . . . . . . . . . . . . . 6 61 3.6. Client Key Exchange Message . . . . . . . . . . . . . . . 6 62 3.7. Certificate Verify . . . . . . . . . . . . . . . . . . . . 8 63 3.8. Finished . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 7.1. Normative references . . . . . . . . . . . . . . . . . . . 10 69 7.2. Informative references . . . . . . . . . . . . . . . . . . 11 70 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 12 71 A.1. Gost-CryptoPro-TLS . . . . . . . . . . . . . . . . . . . . 12 72 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Intellectual Property and Copyright Statements . . . . . . . . . . 16 76 1. Introduction 78 This document proposes the addition of new cipher suites to the 79 Transport Layer Security (TLS) protocol to support GOST R 34.11-94 80 digest, GOST 28147-89 encryption and VKO GOST R 34.10-94/2001 key 81 exchange algorithms. The cipher suites defined here were proposed by 82 CRYPTO-PRO Company for the "Russian Cryptographic Software 83 Compatibility Agreement" community. 85 Algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST 28147-89 and 86 GOST R 34.11-94 have been developed by Russian Federal Agency of 87 Governmental Communication and Information (FAGCI) and "All-Russian 88 Scientific and Research Institute of Standardization". They are 89 described in [GOSTR341094], [GOSTR341001], [GOSTR341194] and 90 [GOST28147] ([GOST3431095], [GOST3431004], [GOST3431195]). 91 Algorithms VKO GOST R 34.10-94/2001 and PRF_GOSTR3411 are described 92 in [CPALGS]. 94 This document defines two configurations: 95 anonymous client - authenticated server (only server provides a 96 certificate); 97 authenticated client - authenticated server (client and server 98 exchange certificates). 100 The presentation language used here is the same as in [TLS1.2]. 101 Since this specification extends [TLS1.2], these descriptions should 102 be merged with those in the TLS specification and any others that 103 extend TLS. This means, that enum types may not specify all possible 104 values and structures with multiple formats chosen with a select() 105 clause may not indicate all possible cases. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 108 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 109 this document are to be interpreted as described in [RFC2119]. 111 2. CipherSuite Definitions 113 2.1. Key Exchange 115 The cipher suites defined here use the following key exchange 116 algorithms: 118 +-------------------------------------+------------------------+ 119 | CipherSuite | Key Exchange Algorithm | 120 +-------------------------------------+------------------------+ 121 | TLS_GOSTR341094_WITH_28147_CNT_IMIT | VKO GOST R 34.10-94 | 122 | TLS_GOSTR341001_WITH_28147_CNT_IMIT | VKO GOST R 34.10-2001 | 123 | TLS_GOSTR341094_WITH_NULL_GOSTR3411 | VKO GOST R 34.10-94 | 124 | TLS_GOSTR341001_WITH_NULL_GOSTR3411 | VKO GOST R 34.10-2001 | 125 +-------------------------------------+------------------------+ 127 Key derivation algorithms based on GOST R 34.10-94 and GOST R 34.10- 128 2001 public keys (VKO GOST R 34.10-94, VKO GOST R 34.10-2001) are 129 described in [CPALGS]. 131 2.2. PRF, Signature and Hash 133 For a PRF, described in section 5 of [TLS1.2], the cipher suites 134 described here use PRF_GOSTR3411 (refer to Section 3.1). The same 135 PRF MUST be used for all dependent protocols, such as [EAP-TLS]. 137 GOST R 34.10-94/2001 signature is used for CertificateVerify message. 139 GOST R 34.11 digest algorithm ([GOSTR341194]) is used for 140 CertificateVerify.signature.gostR3411_hash and Finished.verify_data 141 (see sections 7.4.10 and 7.4.11 of [TLS1.2]) 143 2.3. Cipher and MAC 145 The following cipher algorithm and MAC functions are used (for 146 details refer to Section 3.1): 148 +-------------------------------------+-----------+----------------+ 149 | CipherSuite | Cipher | MAC | 150 +-------------------------------------+-----------+----------------+ 151 | TLS_GOSTR341094_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 | 152 | TLS_GOSTR341001_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 | 153 | TLS_GOSTR341094_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 | 154 | TLS_GOSTR341001_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 | 155 +-------------------------------------+-----------+----------------+ 157 For all four cipher suites, the use of MAC is slighttly different 158 from the one, described in section 6.2.3.1 of [TLS1.2]. In [TLS1.2], 159 MAC is calculated from the following data: 161 MACed_data[seq_num] = seq_num + 162 TLSCompressed.type + 163 TLSCompressed.version + 164 TLSCompressed.length + 165 TLSCompressed.fragment; 167 These cipher suites use the same input for first record, but for each 168 next record the input from all previous records is concatenated: 170 MACed_data[0] + ... + MACed_data[n] 172 3. Data Structures and Computations 174 3.1. Algorithms 176 GOST 28147-89 [GOST28147] uses 256-bit key size and 8-byte IV. 177 Cipher suites, defined here, use GOST 28147-89 as a stream cipher in 178 counter mode with S-box from id-Gost28147-89-CryptoPro-A-ParamSet 179 (see [CPALGS]) and CryptoPro key meshing algorithm. 181 IMIT_GOST28147 is GOST 28147-89 [GOST28147] in "IMITOVSTAVKA" mode (4 182 bytes) 184 HMAC_GOSTR3411(secret, data) is based on GOST R 34.11-94 digest and 185 described in [CPALGS]. 187 PRF_GOSTR3411(secret, label, seed) is based on HMAC_GOSTR3411 and 188 described in [CPALGS]. 190 3.2. Keys Calculation 192 Key calculation is done according to section 6.3 of [TLS1.2], with 193 PRF_GOSTR3411 function used instead of PRF. The parameters are as 194 follows: 196 SecurityParameters.hash_size = 32 197 SecurityParameters.key_material_length = 32 198 SecurityParameters.IV_size = 8 200 Length of necessary key material is 144 bytes. 202 3.3. Server Certificate 204 For these cipher suites this message is required and it MUST contain 205 a certificate, with a public key algorithm matching 206 ServerHello.cipher_suite. 208 3.4. Server Key Exchange 210 This message MUST NOT be used in these cipher suites, because all the 211 parameters necessary are present in server certificate (see [CPPK]). 213 3.5. Certificate Request 215 This message is used as described in section 7.4.5 of [TLS1.2], and 216 extended as follows: 218 enum { 219 gostr341094(21), gostr34102001(22),(255) 220 } ClientCertificateType; 222 gostr341094 and gostr34102001 certificate types identify that the 223 server accepts GOST R 34.10-94 and GOST R 34.10-2001 public key 224 certificates. 226 [IANA please remove] Note: The above numeric definitions for 227 ClientCertificateType have not yet been registered. 229 enum{ 230 gostr3411(XX), (255) 231 } HashType; 233 gostr3411 hash type identifes that the server accepts GOST R 34.11-94 234 hash function. It is RECOMMENDED to populate 235 CertificateRequest.certificate_hash only with gostr3411 value, when 236 one of the cipher suites described in this document is chosen. 238 3.6. Client Key Exchange Message 240 This message is used as described in section 7.4.9 of [TLS1.2], it is 241 required for these suites, and contains DER-encoded 242 TLSGostKeyTransportBlob structure [X.660]. 244 enum { vko_gost } KeyExchangeAlgorithm; 246 struct { 247 select (KeyExchangeAlgorithm) { 248 case vko_gost: TLSGostKeyTransportBlob; 249 } exchange_keys; 250 } ClientKeyExchange; 252 ASN1-syntax for this structure is: 254 TLSGostKeyTransportBlob ::= SEQUENCE { 255 keyBlob GostR3410-KeyTransport, 256 proxyKeyBlobs SEQUENCE OF TLSProxyKeyTransportBlob OPTIONAL 257 } 259 TLSProxyKeyTransportBlob ::= SEQUENCE { 260 keyBlob GostR3410-KeyTransport, 261 cert OCTET STRING 262 } 264 GostR3410-KeyTransport is defined in [CPCMS]. 266 keyBlob.transportParameters MUST be present. 268 keyBlob.transportParameters.ephemeralPublicKey MUST be present if the 269 server didn't request client certificate or client's public key 270 algorithm and parameters do not match those of the recipient. Else 271 it SHOULD be omited. 273 proxyKeyBlobs - (optional) contains key exchange for secondary 274 recipients (for example, for the firewall, which audits connections). 276 cert - contains secondary recipient's certificate. 278 Actions of client: 280 First, the client generates a random 32-byte premaster_secret. 282 Then shared_ukm is calculated as first 8 bytes of digest of 283 concatenated client random and server random: 285 shared_ukm = GOSTR3411(client_random|server_random)[0..7] 287 Then client chooses a sender key. If 288 keyBlob.transportParameters.ephemeralPublicKey is present, the 289 corresponding secret key MUST be used as a sender key. If it is 290 missing, the secret key, corresponding to the client certificate MUST 291 be used. 293 Using the sender key and recipient's public key, algorithm VKO 294 GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is 295 applied to produce KEK. VKO GOST R 34.10-2001 is used with 296 shared_ukm as UKM. 298 Then CryptoPro Key Wrap algorithm is applied to encrypt 299 premaster_secret and produce CEK_ENC and CEK_MAC. Again, shared_ukm 300 is used as UKM. keyBlob.transportParameters.encryptionParamSet is 301 used for all encryption operations. 303 The resulting encrypted key (CEK_ENC) is placed in 304 keyBlob.sessionEncryptedKey.encryptedKey field, it's mac (CEK_MAC) is 305 placed in keyBlob.sessionEncryptedKey.macKey field, and shared_ukm 306 (UKM) is placed in keyBlob.transportParameters.ukm field. 308 Actions of server: 310 Server MUST verify, that keyBlob.transportParameters.ukm is equal to 311 GOSTR3411(client_random|server_random)[0..7], before decrypting the 312 premaster_secret. 314 Server applies VKO GOST R 34.10-94 or VKO GOST R 34.10-2001, 315 (depending on the client public key type), and CryptoPro Key Unwrap 316 algorithm in the simillar manner to decrypt the premaster_secret. 318 Server MUST verify keyBlob.sessionEncryptedKey.macKey after 319 decrypting the premaster_secret. 321 3.7. Certificate Verify 323 This message is used as described in section 7.4.10 of [TLS1.2]. If 324 the client have sent both a client certificate and an ephemeral 325 public key, it MUST send a certificate verify message, as a proof of 326 possession of the private key for provided certificate. 328 The TLS structures are extended as follows: 330 enum { gostr341094, gostr34102001 } 331 SignatureAlgorithm; 333 select (SignatureAlgorithm) { 334 case gostr341094: 335 digitally-signed struct { 336 opaque gostr341194_hash[32]; 337 }; 338 case gostr34102001: 339 digitally-signed struct { 340 opaque gostr341194_hash[32]; 341 }; 342 } Signature; 344 CertificateVerify.signature.gostR3411_hash = 345 GOSTR3411(handshake_messages) 347 3.8. Finished 349 This message is used as described in section 7.4.11 of [TLS1.2]. 351 Finished.verify_data = PRF_GOSTR3411(master_secret, finished_label, 352 GOSTR3411(handshake_messages)) [0..11] 354 4. Compatibility 356 Some applications use the cipher suites specified herein with 357 [TLS1.0], using features of [TLS1.2], including cipher-suite 358 dependent PRF, Finished and Certificate Verify computations. 360 5. Security Considerations 362 It is RECOMMENDED that software applications verify signature values, 363 subject public keys and algorithm parameters to conform to 364 [GOSTR341001], [GOSTR341094] standards prior to their use. 366 Use of the same key for signature and key derivation is NOT 367 RECOMMENDED. 369 It is RECOMMENDED for both client and server to verify the private 370 key usage period, if this extension is present in the certificate. 372 The cipher suites TLS_GOSTR341094_WITH_28147_CNT_IMIT and 373 TLS_GOSTR341001_WITH_28147_CNT_IMIT proposed hereby, have been 374 analyzed by special certification laboratory of Scientific and 375 Technical Centre "ATLAS" in appropriate levels of 376 target_of_evaluation (TOE). 378 It is RECOMMENDED to subject the implementations of these cipher 379 suites to examination by an authorized agency with approved methods 380 of cryptographic analysis. 382 6. IANA Considerations 384 IANA has assigned the following values for GOST 28147-89 mode ciphers 385 definitions: 387 enum { 388 gostr341094(21), gostr34102001(22) 389 } ClientCertificateType; 390 enum{ 391 gostr3411(XX) 392 } HashType; 394 CipherSuite TLS_GOSTR341094_WITH_28147_CNT_IMIT = {0x00,0x80} 395 CipherSuite TLS_GOSTR341001_WITH_28147_CNT_IMIT = {0x00,0x81} 396 CipherSuite TLS_GOSTR341094_WITH_NULL_GOSTR3411 = {0x00,0x82} 397 CipherSuite TLS_GOSTR341001_WITH_NULL_GOSTR3411 = {0x00,0x83} 399 [IANA please remove] Note: The above numeric definitions for 400 CipherSuites and ClientCertificateType have not yet been registered. 402 7. References 404 7.1. Normative references 406 [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 407 Cryptographic Algorithms for Use with GOST 28147-89, GOST 408 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 409 Algorithms", RFC 4357, January 2006. 411 [CPCMS] Leontiev, S. and G. Chudov, "Using the GOST 28147-89, GOST 412 R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 413 Algorithms with Cryptographic Message Syntax (CMS)", 414 RFC 4490, May 2006. 416 [CPPK] Leontiev, S. and D. Shefanovski, "Using the GOST R 417 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 418 Algorithms with the Internet X.509 Public Key 419 Infrastructure Certificate and CRL Profile", RFC 4491, 420 May 2006. 422 [GOST28147] 423 Government Committee of the USSR for Standards, 424 "Cryptographic Protection for Data Processing System, 425 Gosudarstvennyi Standard of USSR (In Russian)", 426 GOST 28147-89, 1989. 428 [GOST3431004] 429 Council for Standardization, Metrology and Certification 430 of the Commonwealth of Independence States (EASC), Minsk, 431 "Information technology. Cryptographic Data Security. 432 Formation and verification processes of (electronic) 433 digital signature based on Asymmetric Cryptographic 434 Algorithm (In Russian)", GOST 34.310-2004, 2004. 436 [GOST3431095] 437 Council for Standardization, Metrology and Certification 438 of the Commonwealth of Independence States (EASC), Minsk, 439 "Information technology. Cryptographic Data Security. 440 Produce and check procedures of Electronic Digital 441 Signature based on Asymmetric Cryptographic Algorithm (In 442 Russian)", GOST 34.310-95, 1995. 444 [GOST3431195] 445 Council for Standardization, Metrology and Certification 446 of the Commonwealth of Independence States (EASC), Minsk, 447 "Information technology. Cryptographic Data Security. 448 Cashing function (In Russian)", GOST 34.311-95, 1995. 450 [GOSTR341001] 451 Government Committee of the Russia for Standards, 452 "Information technology. Cryptographic Data 453 Security.Signature and verification processes of 454 [electronic] digital signature, Gosudarstvennyi Standard 455 of Russian Federation (In Russian)", GOST R 34.10-2001, 456 2001. 458 [GOSTR341094] 459 Government Committee of the Russia for Standards, 460 "Information technology. Cryptographic Data Security. 461 Produce and check procedures of Electronic Digital 462 Signatures based on Asymmetric Cryptographic Algorithm, 463 Gosudarstvennyi Standard of Russian Federation (In 464 Russian)", GOST R 34.10-94, 1994. 466 [GOSTR341194] 467 Government Committee of the Russia for Standards, 468 "Information technology. Cryptographic Data Security. 469 Hashing function, Gosudarstvennyi Standard of Russian 470 Federation (In Russian)", GOST R 34.11-94, 1994. 472 [TLS1.2] Dierks, T. and E. Rescorla, "The TLS Protocol", 473 draft-ietf-tls-rfc4346-bis-01 (work in progress), 474 June 2006. 476 7.2. Informative references 478 [EAP-TLS] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 479 Protocol", RFC 2716, October 1999. 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 485 RFC 2246, January 1999. 487 [X.660] ISO/IEC, "ITU-T Recommendation X.660 Information 488 Technology - ASN.1 encoding rules: Specification of Basic 489 Encoding Rules (BER), Canonical Encoding Rules (CER) and 490 Distinguished Encoding Rules (DER)", ITU-T X.660, 1997. 492 Appendix A. ASN.1 Modules 494 Additional ASN.1 modules, referenced here, can be found in [CPALGS] 495 and [CPCMS]. 497 A.1. Gost-CryptoPro-TLS 499 Gost-CryptoPro-TLS 500 { iso(1) member-body(2) ru(643) rans(2) 501 cryptopro(2) other(1) modules(1) gost-CryptoPro-TLS(16) 1 } 502 DEFINITIONS ::= 503 BEGIN 504 -- EXPORTS All -- 505 -- The types and values defined in this module are exported for 506 -- use in the other ASN.1 modules contained within the Russian 507 -- Cryptography "GOST" & "GOST R" Specifications, and for the use 508 -- of other applications which will use them to access Russian 509 -- Cryptography services. Other applications may use them for 510 -- their own purposes, but this will not constrain extensions and 511 -- modifications needed to maintain or improve the Russian 512 -- Cryptography service. 513 IMPORTS 514 Certificate, 515 AlgorithmIdentifier 516 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 517 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 518 id-mod(0) id-pkix1-explicit-88(1)} 519 id-CryptoPro-algorithms, gostR3410-EncryptionSyntax 520 FROM Cryptographic-Gost-Useful-Definitions 521 { iso(1) member-body(2) ru(643) rans(2) 522 cryptopro(2) other(1) modules(1) 523 cryptographic-Gost-Useful-Definitions(0) 1 } 524 GostR3410-KeyTransport 525 FROM GostR3410-EncryptionSyntax 526 gostR3410-EncryptionSyntax 527 ; 528 id-PRF-GostR3411-94 OBJECT IDENTIFIER ::= 529 { id-CryptoPro-algorithms prf-gostr3411-94(23) } 530 TLSProxyKeyTransportBlob ::= 531 SEQUENCE { 532 keyBlob GostR3410-KeyTransport, 533 cert OCTET STRING 534 } 535 TLSGostKeyTransportBlob ::= 536 SEQUENCE { 537 keyBlob GostR3410-KeyTransport, 538 proxyKeyBlobs SEQUENCE OF 539 TLSProxyKeyTransportBlob OPTIONAL 540 } 541 TLSGostSrvKeyExchange ::= 542 SEQUENCE OF 543 OCTET STRING (CONSTRAINED BY {Certificate}) 544 TLSGostExtensionHashHMACSelect ::= 545 SEQUENCE { 546 hashAlgorithm AlgorithmIdentifier, 547 hmacAlgorithm AlgorithmIdentifier, 548 prfAlgorithm AlgorithmIdentifier 549 } 550 TLSGostExtensionHashHMACSelectClient ::= 551 SEQUENCE OF 552 TLSGostExtensionHashHMACSelect 553 TLSGostExtensionHashHMACSelectServer ::= 554 TLSGostExtensionHashHMACSelect 556 END -- Gost-CryptoPro-TLS 558 Appendix B. Acknowledgments 560 This document was created in accordance with "Russian Cryptographic 561 Software Compatibility Agreement", signed by FGUE STC "Atlas", 562 CRYPTO-PRO, Factor-TS, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 563 Cryptocom, R-Alpha. The aim of this agreement is to achieve mutual 564 compatibility of the products and solutions. 566 The authors wish to thank: 568 Microsoft Corporation Russia for provided information about 569 company products and solutions, and also for technical consulting 570 in PKI. 571 RSA Security Russia and Demos Co Ltd for active colaboration and 572 critical help in creation of this document. 573 NIP Informzachita for compatibility testing of the proposed data 574 formats while incorporating them into company products. 575 Citrix Inc for help in compatibility testing Citrix products for 576 Microsoft Windows. 578 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 579 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative, 580 creating this document. 582 Author's Addresses 584 Alexandr Afanasiev 585 Factor-TS 586 office 711, 14, Presnenskij val, 587 Moscow, 123557, Russian Federation 588 EMail: afa1@factor-ts.ru 590 Nikolaj Nikishin 591 Infotecs GmbH 592 p/b 35, 80-5, Leningradskij prospekt, 593 Moscow, 125315, Russian Federation 594 EMail: nikishin@infotecs.ru 596 Boleslav Izotov 597 FGUE STC "Atlas" 598 38, Obraztsova, 599 Moscow, 127018, Russian Federation 600 EMail: izotov@nii.voskhod.ru 602 Elena Minaeva 603 MD PREI 604 build 3, 6A, Vtoroj Troitskij per., 605 Moscow, Russian Federation 606 EMail: evminaeva@mail.ru 608 Serguei Murugov 609 R-Alpha 610 4/1, Raspletina, 611 Moscow, 123060, Russian Federation 612 EMail: msm@top-cross.ru 614 Igor Ustinov 615 Cryptocom 616 office 239, 51, Leninskij prospekt, 617 Moscow, 119991, Russian Federation 618 EMail: igus@cryptocom.ru 620 Anatolij Erkin 621 SPRCIS (SPbRCZI) 622 1, Obrucheva, 623 St.Petersburg, 195220, Russian Federation 624 EMail: erkin@nevsky.net 626 Authors' Addresses 628 Grigorij S. Chudov (editor) 629 CRYPTO-PRO, Ltd. 630 38, Obraztsova 631 Moscow 127018 632 Russia 634 Phone: +7 (495) 933 11 68 635 Fax: +7 (495) 933 11 68 636 Email: chudov@CryptoPro.ru 637 URI: http://www.CryptoPro.ru 639 Serguei E. Leontiev (editor) 640 CRYPTO-PRO, Ltd. 641 38, Obraztsova 642 Moscow 127018 643 Russia 645 Phone: +7 (495) 933 11 68 646 Fax: +7 (495) 933 11 68 647 Email: lse@CryptoPro.ru 648 URI: http://www.CryptoPro.ru 650 Full Copyright Statement 652 Copyright (C) The Internet Society (2006). 654 This document is subject to the rights, licenses and restrictions 655 contained in BCP 78, and except as set forth therein, the authors 656 retain all their rights. 658 This document and the information contained herein are provided on an 659 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 660 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 661 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 662 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 663 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 664 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 666 Intellectual Property 668 The IETF takes no position regarding the validity or scope of any 669 Intellectual Property Rights or other rights that might be claimed to 670 pertain to the implementation or use of the technology described in 671 this document or the extent to which any license under such rights 672 might or might not be available; nor does it represent that it has 673 made any independent effort to identify any such rights. Information 674 on the procedures with respect to rights in RFC documents can be 675 found in BCP 78 and BCP 79. 677 Copies of IPR disclosures made to the IETF Secretariat and any 678 assurances of licenses to be made available, or the result of an 679 attempt made to obtain a general license or permission for the use of 680 such proprietary rights by implementers or users of this 681 specification can be obtained from the IETF on-line IPR repository at 682 http://www.ietf.org/ipr. 684 The IETF invites any interested party to bring to its attention any 685 copyrights, patents or patent applications, or other proprietary 686 rights that may cover technology that may be required to implement 687 this standard. Please address the information to the IETF at 688 ietf-ipr@ietf.org. 690 Acknowledgment 692 Funding for the RFC Editor function is provided by the IETF 693 Administrative Support Activity (IASA).