idnits 2.17.1 draft-chudov-cryptopro-cptls-04.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 8, 2008) is 5618 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 178 -- Looks like a reference, but probably isn't: '32' on line 346 == Missing Reference: 'RFC5246' is mentioned on line 424, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2716 (ref. 'EAP-TLS') (Obsoleted by RFC 5216) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 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: Informational CRYPTO-PRO 5 Expires: June 11, 2009 December 8, 2008 7 GOST 28147-89 Cipher Suites for Transport Layer Security (TLS) 8 draft-chudov-cryptopro-cptls-04 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on June 11, 2009. 33 Copyright Notice 35 Copyright (c) 2008 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document is intended to register new cipher suites for the 48 Transport Layer Security (TLS) protocol, according to the procedure 49 specified in TLS Protocol standards. These cipher suites are based 50 on Russian national cryptographic standards - GOST R 34.10-94 and 51 GOST R 34.10-2001 public keys, GOST 28147-89 encryption algorithm and 52 GOST R 34.11-94 digest algorithm. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. CipherSuite Definitions . . . . . . . . . . . . . . . . . . . 3 58 2.1. Key Exchange . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. PRF, Signature and Hash . . . . . . . . . . . . . . . . . 4 60 2.3. Cipher and MAC . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Data Structures and Computations . . . . . . . . . . . . . . . 5 62 3.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Keys Calculation . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 5 65 3.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 5 66 3.5. Certificate Request . . . . . . . . . . . . . . . . . . . 6 67 3.6. Client Key Exchange Message . . . . . . . . . . . . . . . 6 68 3.7. Certificate Verify . . . . . . . . . . . . . . . . . . . . 8 69 3.8. Finished . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1. Normative references . . . . . . . . . . . . . . . . . . . 10 75 7.2. Informative references . . . . . . . . . . . . . . . . . . 12 76 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 12 77 A.1. Gost-CryptoPro-TLS . . . . . . . . . . . . . . . . . . . . 12 78 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 This document proposes the addition of new cipher suites to the 84 Transport Layer Security (TLS) protocol to support GOST R 34.11-94 85 digest, GOST 28147-89 encryption and VKO GOST R 34.10-94/2001 key 86 exchange algorithms. The cipher suites defined here were proposed by 87 CRYPTO-PRO Company for the "Russian Cryptographic Software 88 Compatibility Agreement" community. 90 Algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST 28147-89 and 91 GOST R 34.11-94 have been developed by Russian Federal Agency of 92 Governmental Communication and Information (FAGCI) and "All-Russian 93 Scientific and Research Institute of Standardization". They are 94 described in [GOSTR341094], [GOSTR341001], [GOSTR341194] and 95 [GOST28147] ([GOST3431095], [GOST3431004], [GOST3431195]). 96 Algorithms VKO GOST R 34.10-94/2001 and PRF_GOSTR3411 are described 97 in [CPALGS]. 99 This document defines two configurations: 100 anonymous client - authenticated server (only server provides a 101 certificate); 102 authenticated client - authenticated server (client and server 103 exchange certificates). 105 The presentation language used here is the same as in [TLS1.2]. 106 Since this specification extends [TLS1.2], these descriptions should 107 be merged with those in the TLS specification and any others that 108 extend TLS. This means, that enum types may not specify all possible 109 values and structures with multiple formats chosen with a select() 110 clause may not indicate all possible cases. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 113 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 114 this document are to be interpreted as described in [RFC2119]. 116 2. CipherSuite Definitions 118 2.1. Key Exchange 120 The cipher suites defined here use the following key exchange 121 algorithms: 123 +-------------------------------------+------------------------+ 124 | CipherSuite | Key Exchange Algorithm | 125 +-------------------------------------+------------------------+ 126 | TLS_GOSTR341094_WITH_28147_CNT_IMIT | VKO GOST R 34.10-94 | 127 | TLS_GOSTR341001_WITH_28147_CNT_IMIT | VKO GOST R 34.10-2001 | 128 | TLS_GOSTR341094_WITH_NULL_GOSTR3411 | VKO GOST R 34.10-94 | 129 | TLS_GOSTR341001_WITH_NULL_GOSTR3411 | VKO GOST R 34.10-2001 | 130 +-------------------------------------+------------------------+ 132 Key derivation algorithms based on GOST R 34.10-94 and GOST R 34.10- 133 2001 public keys (VKO GOST R 34.10-94, VKO GOST R 34.10-2001) are 134 described in [CPALGS]. 136 2.2. PRF, Signature and Hash 138 The cipher suites described here use HMAC and TLS PRF, as described 139 in section 5 of [TLS1.2], based on GOST R 34.11-94 hash function 140 (HMAC_GOSTR3411 and PRF_GOSTR3411), with parameter set identified by 141 id-GostR3411-94-CryptoProParamSet (refer to [CPALGS]). The same PRF 142 MUST be used for all dependent protocols, such as [EAP-TLS]. 144 GOST R 34.10-94/2001 signature is used for CertificateVerify message. 146 GOST R 34.11 digest algorithm ([GOSTR341194]) is used for 147 CertificateVerify.signature.gostR3411_hash and Finished.verify_data 148 (see sections 7.4.10 and 7.4.11 of [TLS1.2]) 150 2.3. Cipher and MAC 152 The following cipher algorithm and MAC functions are used (for 153 details refer to Section 3.1): 155 +-------------------------------------+-----------+----------------+ 156 | CipherSuite | Cipher | MAC | 157 +-------------------------------------+-----------+----------------+ 158 | TLS_GOSTR341094_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 | 159 | TLS_GOSTR341001_WITH_28147_CNT_IMIT | GOST28147 | IMIT_GOST28147 | 160 | TLS_GOSTR341094_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 | 161 | TLS_GOSTR341001_WITH_NULL_GOSTR3411 | - | HMAC_GOSTR3411 | 162 +-------------------------------------+-----------+----------------+ 164 For all four cipher suites, the use of MAC is slighttly different 165 from the one, described in section 6.2.3.1 of [TLS1.2] for standard 166 stream ciphers, where MAC is calculated from the following data: 168 MACed_data[seq_num] = seq_num + 169 TLSCompressed.type + 170 TLSCompressed.version + 171 TLSCompressed.length + 172 TLSCompressed.fragment; 174 Cipher suites defined in this document use the same input for first 175 record, but for each consequent record the input from all previous 176 records is concatenated: 178 MACed_data[0] + ... + MACed_data[n] 180 3. Data Structures and Computations 182 3.1. Algorithms 184 GOST 28147-89 [GOST28147] uses 256-bit key size and 8-byte IV. 185 Cipher suites, defined here, use GOST 28147-89 as a stream cipher in 186 counter mode with S-box parameter from id-Gost28147-89-CryptoPro-A- 187 ParamSet (see [CPALGS]) and CryptoPro key meshing algorithm. 189 IMIT_GOST28147 is GOST 28147-89 [GOST28147] in "IMITOVSTAVKA" mode (4 190 bytes) 192 3.2. Keys Calculation 194 Key calculation is done according to section 6.3 of [TLS1.2], using 195 PRF_GOSTR3411. The parameters are as follows: 197 SecurityParameters.enc_key_length = 32 198 SecurityParameters.mac_key_length = 32 199 SecurityParameters.fixed_iv_length = 8 201 Length of necessary key material is 144 bytes. 203 3.3. Server Certificate 205 For these cipher suites this message is required and it MUST contain 206 a certificate, with a public key algorithm matching 207 ServerHello.cipher_suite. 209 3.4. Server Key Exchange 211 This message MUST NOT be used in these cipher suites, because all the 212 parameters necessary are present in server certificate (see [CPPK]). 214 3.5. Certificate Request 216 This message is used as described in section 7.4.4 of [TLS1.2], and 217 extended as follows: 219 enum { 220 gostr341094(21), gostr34102001(22),(255) 221 } ClientCertificateType; 223 gostr341094 and gostr34102001 certificate types identify that the 224 server accepts GOST R 34.10-94 and GOST R 34.10-2001 public key 225 certificates. 227 enum{ 228 gostr3411(XX) 229 } HashAlgorithm; 231 enum{ 232 gostr341094(XX), gostr34102001(XX) 233 } SignatureAlgorithm; 235 gostr3411 hash type identifes that the server accepts GOST R 34.11-94 236 hash function. It is RECOMMENDED to populate 237 CertificateRequest.certificate_hash only with gostr3411 value, when 238 one of the cipher suites described in this document is chosen. 240 The server SHOULD populate supported_signature_algorithm field with 241 SignatureAndHashAlgorithm pairs, where HashAlgorithm equals gostr3411 242 and SignatureAlgorithm matches corresponding ClientCertificateType. 244 3.6. Client Key Exchange Message 246 This message is used as described in section 7.4.7 of [TLS1.2], it is 247 required for these suites, and contains DER-encoded 248 TLSGostKeyTransportBlob structure [X.660]. 250 enum { vko_gost } KeyExchangeAlgorithm; 252 struct { 253 select (KeyExchangeAlgorithm) { 254 case vko_gost: TLSGostKeyTransportBlob; 255 } exchange_keys; 256 } ClientKeyExchange; 258 ASN1-syntax for this structure is: 260 TLSGostKeyTransportBlob ::= SEQUENCE { 261 keyBlob GostR3410-KeyTransport, 262 proxyKeyBlobs SEQUENCE OF TLSProxyKeyTransportBlob OPTIONAL 263 } 265 TLSProxyKeyTransportBlob ::= SEQUENCE { 266 keyBlob GostR3410-KeyTransport, 267 cert OCTET STRING 268 } 270 GostR3410-KeyTransport is defined in [CPCMS]. 272 keyBlob.transportParameters MUST be present. 274 keyBlob.transportParameters.ephemeralPublicKey MUST be present if the 275 server didn't request client certificate or client's public key 276 algorithm and parameters do not match those of the recipient. Else 277 it SHOULD be omited. 279 proxyKeyBlobs - (optional) contains key exchange for secondary 280 recipients (for example, for the firewall, which audits connections). 282 cert - contains secondary recipient's certificate. 284 Actions of client: 286 First, the client generates a random 32-byte premaster_secret. 288 Then shared_ukm is calculated as first 8 bytes of digest of 289 concatenated client random and server random: 291 shared_ukm = GOSTR3411(client_random|server_random)[0..7] 293 Then client chooses a sender key. If 294 keyBlob.transportParameters.ephemeralPublicKey is present, the 295 corresponding secret key MUST be used as a sender key. If it is 296 missing, the secret key, corresponding to the client certificate MUST 297 be used. 299 Using the sender key and recipient's public key, algorithm VKO 300 GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is 301 applied to produce KEK. VKO GOST R 34.10-2001 is used with 302 shared_ukm as UKM. 304 Then CryptoPro Key Wrap algorithm is applied to encrypt 305 premaster_secret and produce CEK_ENC and CEK_MAC. Again, shared_ukm 306 is used as UKM. keyBlob.transportParameters.encryptionParamSet is 307 used for all encryption operations. 309 The resulting encrypted key (CEK_ENC) is placed in 310 keyBlob.sessionEncryptedKey.encryptedKey field, it's mac (CEK_MAC) is 311 placed in keyBlob.sessionEncryptedKey.macKey field, and shared_ukm 312 (UKM) is placed in keyBlob.transportParameters.ukm field. 314 Actions of server: 316 Server MUST verify, that keyBlob.transportParameters.ukm is equal to 317 GOSTR3411(client_random|server_random)[0..7], before decrypting the 318 premaster_secret. 320 Server applies VKO GOST R 34.10-94 or VKO GOST R 34.10-2001, 321 (depending on the client public key type), and CryptoPro Key Unwrap 322 algorithm in the simillar manner to decrypt the premaster_secret. 324 Server MUST verify keyBlob.sessionEncryptedKey.macKey after 325 decrypting the premaster_secret. 327 3.7. Certificate Verify 329 This message is used as described in section 7.4.8 of [TLS1.2]. If 330 the client have sent both a client certificate and an ephemeral 331 public key, it MUST send a certificate verify message, as a proof of 332 possession of the private key for provided certificate. 334 The TLS structures are extended as follows: 336 enum { gostr341094, gostr34102001 } 337 SignatureAlgorithm; 339 select (SignatureAlgorithm) { 340 case gostr341094: 341 digitally-signed struct { 342 opaque gostr341194_hash[32]; 343 }; 344 case gostr34102001: 345 digitally-signed struct { 346 opaque gostr341194_hash[32]; 347 }; 348 } Signature; 350 CertificateVerify.signature.gostR3411_hash = 351 GOSTR3411(handshake_messages) 353 3.8. Finished 355 This message is used as described in section 7.4.9 of [TLS1.2]. 357 Finished.verify_data = PRF_GOSTR3411(master_secret, finished_label, 358 GOSTR3411(handshake_messages)) [0..11] 360 4. Compatibility 362 For historical reasons, some applications use the cipher suites 363 specified herein with [TLS1.0], using some features of [TLS1.2], 364 including cipher-suite dependent PRF, Finished and Certificate Verify 365 computations. 367 5. Security Considerations 369 It is RECOMMENDED that software applications verify signature values, 370 subject public keys and algorithm parameters to conform to 371 [GOSTR341001], [GOSTR341094] standards prior to their use. 373 Use of the same key for signature and key derivation is NOT 374 RECOMMENDED. 376 It is RECOMMENDED for both client and server to verify the private 377 key usage period, if this extension is present in the certificate. 379 The cipher suites TLS_GOSTR341094_WITH_28147_CNT_IMIT and 380 TLS_GOSTR341001_WITH_28147_CNT_IMIT proposed hereby, have been 381 analyzed by special certification laboratory of Scientific and 382 Technical Centre "ATLAS" in appropriate levels of 383 target_of_evaluation (TOE). 385 It is RECOMMENDED to subject the implementations of these cipher 386 suites to examination by an authorized agency with approved methods 387 of cryptographic analysis. 389 6. IANA Considerations 391 This document defines the following new cipher suites, whose values 392 presented here are used by several implementations of the same cipher 393 suites for TLS 1.0, and were described in previous drafts. They are 394 currently listed in the registry as reserved. IANA is requested to 395 update the TLS Cipher Suite registry defined in [RFC5246] with these 396 values. 398 CipherSuite TLS_GOSTR341094_WITH_28147_CNT_IMIT = {0x00,0x80} 399 CipherSuite TLS_GOSTR341001_WITH_28147_CNT_IMIT = {0x00,0x81} 400 CipherSuite TLS_GOSTR341094_WITH_NULL_GOSTR3411 = {0x00,0x82} 401 CipherSuite TLS_GOSTR341001_WITH_NULL_GOSTR3411 = {0x00,0x83} 403 This document defines the following new client certificate types, 404 whose values presented here are used by several implementations of 405 the same suites for TLS 1.0, and were described in previous drafts. 406 They are currently listed in the registry as reserved. IANA is 407 requested to update the TLS ClientCertificateType Identifiers 408 Registry defined in [RFC5246] with these values. 410 enum { 411 gostr341094(21), gostr34102001(22) 412 } ClientCertificateType; 414 This document defines the following new signature algorithm types, 415 whose values are to be assigned from the TLS SignatureAlgorithm 416 Registry defined in [RFC5246]. 418 enum{ 419 gostr341094(XX), gostr34102001(XX) 420 } SignatureAlgorithm; 422 This document defines the following new hash algorithm types, whose 423 values are to be assigned from the TLS HashAlgorithm Registry defined 424 in [RFC5246]. 426 enum { 427 gostr3411(XX) 428 } HashAlgorithm; 430 7. References 432 7.1. Normative references 434 [CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, "Additional 435 Cryptographic Algorithms for Use with GOST 28147-89, GOST 436 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 437 Algorithms", RFC 4357, January 2006. 439 [CPCMS] Leontiev, S. and G. Chudov, "Using the GOST 28147-89, GOST 440 R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 441 Algorithms with Cryptographic Message Syntax (CMS)", 442 RFC 4490, May 2006. 444 [CPPK] Leontiev, S. and D. Shefanovski, "Using the GOST R 445 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 446 Algorithms with the Internet X.509 Public Key 447 Infrastructure Certificate and CRL Profile", RFC 4491, 448 May 2006. 450 [GOST28147] 451 Government Committee of the USSR for Standards, 452 "Cryptographic Protection for Data Processing System, 453 Gosudarstvennyi Standard of USSR (In Russian)", 454 GOST 28147-89, 1989. 456 [GOST3431004] 457 Council for Standardization, Metrology and Certification 458 of the Commonwealth of Independence States (EASC), Minsk, 459 "Information technology. Cryptographic Data Security. 460 Formation and verification processes of (electronic) 461 digital signature based on Asymmetric Cryptographic 462 Algorithm (In Russian)", GOST 34.310-2004, 2004. 464 [GOST3431095] 465 Council for Standardization, Metrology and Certification 466 of the Commonwealth of Independence States (EASC), Minsk, 467 "Information technology. Cryptographic Data Security. 468 Produce and check procedures of Electronic Digital 469 Signature based on Asymmetric Cryptographic Algorithm (In 470 Russian)", GOST 34.310-95, 1995. 472 [GOST3431195] 473 Council for Standardization, Metrology and Certification 474 of the Commonwealth of Independence States (EASC), Minsk, 475 "Information technology. Cryptographic Data Security. 476 Cashing function (In Russian)", GOST 34.311-95, 1995. 478 [GOSTR341001] 479 Government Committee of the Russia for Standards, 480 "Information technology. Cryptographic Data 481 Security.Signature and verification processes of 482 [electronic] digital signature, Gosudarstvennyi Standard 483 of Russian Federation (In Russian)", GOST R 34.10-2001, 484 2001. 486 [GOSTR341094] 487 Government Committee of the Russia for Standards, 488 "Information technology. Cryptographic Data Security. 489 Produce and check procedures of Electronic Digital 490 Signatures based on Asymmetric Cryptographic Algorithm, 491 Gosudarstvennyi Standard of Russian Federation (In 492 Russian)", GOST R 34.10-94, 1994. 494 [GOSTR341194] 495 Government Committee of the Russia for Standards, 496 "Information technology. Cryptographic Data Security. 497 Hashing function, Gosudarstvennyi Standard of Russian 498 Federation (In Russian)", GOST R 34.11-94, 1994. 500 [TLS1.2] Dierks, T. and E. Rescorla, "The TLS Protocol", 501 draft-ietf-tls-rfc4346-bis-01 (work in progress), 502 June 2006. 504 7.2. Informative references 506 [EAP-TLS] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 507 Protocol", RFC 2716, October 1999. 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, March 1997. 512 [TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 513 RFC 2246, January 1999. 515 [X.660] ISO/IEC, "ITU-T Recommendation X.660 Information 516 Technology - ASN.1 encoding rules: Specification of Basic 517 Encoding Rules (BER), Canonical Encoding Rules (CER) and 518 Distinguished Encoding Rules (DER)", ITU-T X.660, 1997. 520 Appendix A. ASN.1 Modules 522 Additional ASN.1 modules, referenced here, can be found in [CPALGS] 523 and [CPCMS]. 525 A.1. Gost-CryptoPro-TLS 527 Gost-CryptoPro-TLS 528 { iso(1) member-body(2) ru(643) rans(2) 529 cryptopro(2) other(1) modules(1) gost-CryptoPro-TLS(16) 1 } 530 DEFINITIONS ::= 531 BEGIN 532 -- EXPORTS All -- 533 -- The types and values defined in this module are exported for 534 -- use in the other ASN.1 modules contained within the Russian 535 -- Cryptography "GOST" & "GOST R" Specifications, and for the use 536 -- of other applications which will use them to access Russian 537 -- Cryptography services. Other applications may use them for 538 -- their own purposes, but this will not constrain extensions and 539 -- modifications needed to maintain or improve the Russian 540 -- Cryptography service. 542 IMPORTS 543 Certificate, 544 AlgorithmIdentifier 545 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 546 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 547 id-mod(0) id-pkix1-explicit-88(1)} 548 id-CryptoPro-algorithms, gostR3410-EncryptionSyntax 549 FROM Cryptographic-Gost-Useful-Definitions 550 { iso(1) member-body(2) ru(643) rans(2) 551 cryptopro(2) other(1) modules(1) 552 cryptographic-Gost-Useful-Definitions(0) 1 } 553 GostR3410-KeyTransport 554 FROM GostR3410-EncryptionSyntax 555 gostR3410-EncryptionSyntax 556 ; 557 id-PRF-GostR3411-94 OBJECT IDENTIFIER ::= 558 { id-CryptoPro-algorithms prf-gostr3411-94(23) } 559 TLSProxyKeyTransportBlob ::= 560 SEQUENCE { 561 keyBlob GostR3410-KeyTransport, 562 cert OCTET STRING 563 } 564 TLSGostKeyTransportBlob ::= 565 SEQUENCE { 566 keyBlob GostR3410-KeyTransport, 567 proxyKeyBlobs SEQUENCE OF 568 TLSProxyKeyTransportBlob OPTIONAL 569 } 570 TLSGostSrvKeyExchange ::= 571 SEQUENCE OF 572 OCTET STRING (CONSTRAINED BY {Certificate}) 573 TLSGostExtensionHashHMACSelect ::= 574 SEQUENCE { 575 hashAlgorithm AlgorithmIdentifier, 576 hmacAlgorithm AlgorithmIdentifier, 577 prfAlgorithm AlgorithmIdentifier 578 } 579 TLSGostExtensionHashHMACSelectClient ::= 580 SEQUENCE OF 581 TLSGostExtensionHashHMACSelect 582 TLSGostExtensionHashHMACSelectServer ::= 583 TLSGostExtensionHashHMACSelect 585 END -- Gost-CryptoPro-TLS 587 Appendix B. Acknowledgments 589 This document was created in accordance with "Russian Cryptographic 590 Software Compatibility Agreement", signed by FGUE STC "Atlas", 591 CRYPTO-PRO, Factor-TS, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 592 Cryptocom, R-Alpha. The aim of this agreement is to achieve mutual 593 compatibility of the products and solutions. 595 The authors wish to thank: 597 Microsoft Corporation Russia for provided information about 598 company products and solutions, and also for technical consulting 599 in PKI. 600 RSA Security Russia and Demos Co Ltd for active colaboration and 601 critical help in creation of this document. 602 NIP Informzachita for compatibility testing of the proposed data 603 formats while incorporating them into company products. 604 Citrix Inc for help in compatibility testing Citrix products for 605 Microsoft Windows. 606 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 607 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative, 608 creating this document. 610 Author's Addresses 612 Alexandr Afanasiev 613 Factor-TS 614 office 711, 14, Presnenskij val, 615 Moscow, 123557, Russian Federation 616 EMail: afa1@factor-ts.ru 618 Nikolaj Nikishin 619 Infotecs GmbH 620 p/b 35, 80-5, Leningradskij prospekt, 621 Moscow, 125315, Russian Federation 622 EMail: nikishin@infotecs.ru 624 Boleslav Izotov 625 FGUE STC "Atlas" 626 38, Obraztsova, 627 Moscow, 127018, Russian Federation 628 EMail: izotov@nii.voskhod.ru 630 Elena Minaeva 631 MD PREI 632 build 3, 6A, Vtoroj Troitskij per., 633 Moscow, Russian Federation 634 EMail: evminaeva@mail.ru 636 Serguei Murugov 637 R-Alpha 638 4/1, Raspletina, 639 Moscow, 123060, Russian Federation 640 EMail: msm@top-cross.ru 642 Igor Ustinov 643 Cryptocom 644 office 239, 51, Leninskij prospekt, 645 Moscow, 119991, Russian Federation 646 EMail: igus@cryptocom.ru 648 Anatolij Erkin 649 SPRCIS (SPbRCZI) 650 1, Obrucheva, 651 St.Petersburg, 195220, Russian Federation 652 EMail: erkin@nevsky.net 654 Authors' Addresses 656 Grigorij S. Chudov (editor) 657 CRYPTO-PRO, Ltd. 658 16/5, Suschevskij val 659 Moscow 127018 660 Russia 662 Phone: +7 (495) 780 48 20 663 Fax: +7 (495) 660 2330 664 Email: chudov@CryptoPro.ru 665 URI: http://www.CryptoPro.ru 667 Serguei E. Leontiev (editor) 668 CRYPTO-PRO, Ltd. 669 16/5, Suschevskij val 670 Moscow 127018 671 Russia 673 Phone: +7 (495) 933 11 68 674 Fax: +7 (495) 933 11 68 675 Email: lse@CryptoPro.ru 676 URI: http://www.CryptoPro.ru