idnits 2.17.1 draft-chudov-cryptopro-cptls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([TLS], [TLSEXT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (April 1, 2004) is 7329 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GOSTR3411' is mentioned on line 83, but not defined -- Looks like a reference, but probably isn't: '0' on line 169 -- Looks like a reference, but probably isn't: '32' on line 438 == Unused Reference: 'RFC 3280' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC 3279' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'Schneier95' is defined on line 597, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-popov-cryptopro-cpalgs-01 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (ref. 'TLSEXT') (Obsoleted by RFC 4366) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group Grigorij Chudov, CRYPTO-PRO 3 Internet Draft Serguei Leontiev, CRYPTO-PRO 4 Expires October 1, 2004 April 1, 2004 5 Intended Category: Informational 7 Addition of GOST Ciphersuites to Transport Layer Security (TLS) 9 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or made obsolete by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document is intended to register new cipher suites for the 35 Transport Layer Security (TLS) protocol, according to the procedure 36 specified in section A.5 of [TLS], and to register a new TLS 37 extension, according to section 5 of [TLSEXT]. Those cipher suites 38 are based on Russian national cryptographic standards - key 39 derivation algorithms based on GOST R 3410-94 and GOST R 3410-2001 40 public keys, GOST 28147-89 encryption algorithm and GOST R 34.11-94 41 digest algorithm. 43 Table of Contents 45 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . 2 46 2 Proposed Ciphersuites . . . . . . . . . . . . . . . . . . 3 47 3 CipherSuite Definitions . . . . . . . . . . . . . . . . . 3 48 3.1 Key Exchange. . . . . . . . . . . . . . . . . . . . . . . 3 49 3.2 PRF, Signature and Hash . . . . . . . . . . . . . . . . . 3 50 3.3 Cipher and MAC. . . . . . . . . . . . . . . . . . . . . . 3 51 4 TLS Extensions for GOST . . . . . . . . . . . . . . . . . 4 52 5 Data Structures and Computations. . . . . . . . . . . . . 4 53 5.1 Algorithms. . . . . . . . . . . . . . . . . . . . . . . . 4 54 5.2 Keys Calculation. . . . . . . . . . . . . . . . . . . . . 4 55 5.3 Client Hello Extensions . . . . . . . . . . . . . . . . . 5 56 5.4 Server Hello Extensions . . . . . . . . . . . . . . . . . 6 57 5.5 Server Certificate. . . . . . . . . . . . . . . . . . . . 6 58 5.6 Server Key Exchange . . . . . . . . . . . . . . . . . . . 7 59 5.7 Certificate Request . . . . . . . . . . . . . . . . . . . 7 60 5.8 Client Key Exchange Message . . . . . . . . . . . . . . . 7 61 5.9 Certificate Verify. . . . . . . . . . . . . . . . . . . . 8 62 5.10 Finished. . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6 Security Considerations . . . . . . . . . . . . . . . . . 8 64 7 Appendix ASN.1 Modules. . . . . . . . . . . . . . . . . . 9 65 8 References. . . . . . . . . . . . . . . . . . . . . . . . 10 66 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 12 67 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . 12 68 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 14 70 1 Introduction 72 This document proposes the addition of new cipher suites and 73 extensions to the Transport Layer Security (TLS) protocol to support 74 GOST R 34.11-94 digest, GOST 28147-89 encryption and VKO GOST R 75 34.10-94/2001 key exchange algorithms. The cipher suites defined 76 here were proposed by CRYPTO-PRO Company for "Russian Cryptographic 77 Software Compatibility Agreement" community. 79 Algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST 28147-89 and GOST 80 R 34.11-94 have been developed by Russian Federal Agency of 81 Governmental Communication and Information (FAGCI) and "All-Russian 82 Scientific and Research Institute of Standardization". They are 83 described in [GOSTR341094], [GOSTR34102001], [GOSTR3411] and 84 [GOST28147]. Algorithms VKO GOST R 34.10-94/2001 and PRF_GOSTR3411 85 are described in [CPALGS]. 87 This document defines two configurations: 88 anonymous client - authenticated server (only server provides a 89 certificate); 90 authenticated client - authenticated server (client and server 91 exchange certificates). 93 The presentation language used here is the same as in [TLS]. Since 94 this specification extends TLS, these descriptions should be merged 95 with those in the TLS specification and any others that extend TLS. 97 This means, that enum types may not specify all possible values and 98 structures with multiple formats chosen with a select() clause may 99 not indicate all possible cases. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 102 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 103 this document are to be interpreted as described in [RFC 2119]. 105 2 Proposed CipherSuites 107 The new cipher suites proposed here have the following definitions: 109 CipherSuite TLS_GOST341094_WITH_GOST28147_OFB_GOST28147 = {0x00,0x80} 110 CipherSuite TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147= {0x00,0x81} 111 CipherSuite TLS_GOST341094_WITH_NULL_GOSTR3411 = {0x00,0x82} 112 CipherSuite TLS_GOST34102001_WITH_NULL_GOSTR3411 = {0x00,0x83} 114 Note: The above numeric definitions for CipherSuites have not yet 115 been registered. 117 3 CipherSuite Definitions 119 3.1 Key exchange 121 The cipher suites defined here use the following key exchange 122 algorithms: 124 CipherSuite Key Exchange Algorithm 125 TLS_GOST341094_WITH_GOST28147_OFB_GOST28147 VKO GOST R 34.10-94 126 TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147 VKO GOST R 34.10-2001 127 TLS_GOST341094_WITH_NULL_GOSTR3411 VKO GOST R 34.10-94 128 TLS_GOST34102001_WITH_NULL_GOSTR3411 VKO GOST R 34.10-2001 130 Key derivation algorithms based on GOST R 3410-94 and GOST R 131 3410-2001 public keys (VKO GOST R 34.10-94, VKO GOST R 34.10-2001) 132 are described in [CPALGS]. 134 3.2 PRF, Signature and Hash 136 For a PRF, described in section 5 of [TLS], the cipher suites 137 described here use PRF_GOSTR3411 (refer to section 5.1) 139 GOST R 3410-94/2001 signature is used for CertificateVerify message. 141 GOST R 34.11 digest algorithm ([GOSTR341194]) is used for 142 CertificateVerify.signature.gostR3411_hash and Finished.verify_data 143 (see sections 7.4.8 and 7.4.9 of [TLS]) 145 3.3 Cipher and MAC 147 The following cipher algorithm and MAC functions are used (for 148 details refer to section 5.1): 150 CipherSuite Cipher MAC 151 TLS_GOST341094_WITH_GOST28147_OFB_GOST28147 GOST28147 IMIT_GOST28147 152 TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147 GOST28147 IMIT_GOST28147 153 TLS_GOST341094_WITH_NULL_GOSTR3411 - HMAC_GOSTR3411 154 TLS_GOST34102001_WITH_NULL_GOSTR3411 - HMAC_GOSTR3411 156 For all four cipher suites, the use of MAC is slighttly different 157 from the one, described in section 6.2.3.1 of [TLS]. In [TLS], MAC 158 is calculated from the following data: 160 MACed_data[seq_num] = seq_num + 161 TLSCompressed.type + 162 TLSCompressed.version + 163 TLSCompressed.length + 164 TLSCompressed.fragment; 166 These cipher suites use the same input for first record, but for each 167 next record the input from all previous records is concatenated: 169 MACed_data[0] + ... + MACed_data[n] 171 4 TLS Extensions for GOST 173 A new TLS extension -- the Hash, HMAC and PRF Select Extension -- 174 allows a client and server to negotiate the use of a different hash, 175 HMAC and PRF algorithm, instead of those, defined in [TLS]. It 176 follows the general approach outlined in [TLSEXT]. The client 177 enumerates supported hash/HMAC/PRF combinations, by including the 178 appropriate extension in its ClientHello message. By echoing that 179 extension in its ServerHello, the server selects one of them for this 180 TLS connection. Sections 5.3 and 5.4 describe the structure of this 181 extension in further details. 183 5 Data Structures and Computations 185 5.1 Algorithms 187 GOST 28147-89 [GOST28147] uses 256-bit key size and 8-byte IV. 188 Cipher suites, defined here, use GOST 28147-89 as a stream cipher in 189 OFB mode with S-box gost28147-89-UZ-CryptoPro-A (see [CPALGS]) and 190 CryptoPro key meshing algorithm. This is very similar to 191 gost28147-89-CryptoPro-A-ParamSetAI parameter set, except for 192 different cipher mode. 194 IMIT_GOST28147 is GOST 28147-89 [GOST28147] in "IMITOVSTAVKA" mode (4 195 bytes) 197 HMAC_GOSTR3411(secret, data) is based on GOST R 34.11 digest and 198 described in [CPALGS]. 200 PRF_GOSTR3411(secret, label, seed) is based on HMAC_GOSTR3411 and 201 described in [CPALGS]. 203 5.2 Key Calculation 205 Key calculation is done according to section 6.3 of [TLS], with 206 PRF_GOSTR3411 function used instead of PRF. The parameters are as 207 follows: 208 SecurityParameters.hash_size = 32 209 SecurityParameters.key_material_length = 32 210 SecurityParameters.IV_size = 8 211 Length of necessary key material is 144 bytes. 213 5.3 Client Hello Extensions 215 When this message is sent: 217 The Hash, HMAC and PRF Select Extension SHOULD be sent along with any 218 ClientHello message that includes cipher suites, proposed in this 219 document. 221 Meaning of this message: 223 This extension allows client and server to override algorithms, 224 predefined in [TLS], and select the appropriate set of algorithms and 225 parameters for the chosen cipher suite. 227 Structure of this message: 229 The general structure of TLS extensions is described in [TLSEXT] and 230 this specification adds a new type to ExtensionType. 232 enum { hash_alg_select(60000) } ExtensionType; 234 hash_alg_select: Indicates the set of hash/HMAC/PRF algorithms 235 supported by the client. For this extension, the opaque 236 extension_data field contains DER-encoding of the 237 TLSGostExtensionHashHMACSelectClient structure. 239 TLSGostExtensionHashHMACSelect ::= 240 SEQUENCE { 241 hashAlgorithm AlgorithmIdentifier, 242 hmacAlgorithm AlgorithmIdentifier, 243 prfAlgorithm AlgorithmIdentifier 244 } 246 TLSGostExtensionHashHMACSelectClient ::= 247 SEQUENCE OF 248 TLSGostExtensionHashHMACSelect 250 Actions of the sender: 252 A client that proposes algorithm selection in its ClientHello appends 253 this extension along with any others. 255 Actions of the receiver: 257 A server that receives a ClientHello containing this extension MUST 258 use one of the proposed algorithm sets. 260 If a server does not understand this extension or is unable to 261 perform handshake using any of the proposed algorithm sets, it MUST 262 NOT negotiate the use of GOST cipher suites. Depending on what other 263 cipher suites are proposed by the client and supported by the server, 264 this may result in a fatal handshake failure alert due to the lack of 265 common cipher suites. 267 If Client Hello contains GOST cipher suites, but does not contain 268 this extension, the server MUST assume that client proposes the use 269 of the following default set: 271 hashAlgorithm ::= id-GostR3411-94 with NULL algorithmParameters 272 hmacAlgorithm ::= id-Gost28147-89-MAC with NULL algorithmParameters 273 prfAlgorithm ::= id-PRF-GostR3411-94 with NULL algorithmParameters 275 5.4 Server Hello Extensions 277 When this message is sent: 279 The ServerHello Hash, HMAC and PRF Select Extension is sent in 280 response to a Client Hello message containing this extension. 282 Meaning of this message: 284 This extension indicates the server's agreement to use one of the 285 sets of algorithms, given by client, during handshake. 287 Structure of this message: 289 "extension_data" field of the Server Hello extension contains DER- 290 encoding of the TLSGostExtensionHashHMACSelectServer structure. 292 TLSGostExtensionHashHMACSelectServer ::= 293 TLSGostExtensionHashHMACSelect 295 This MUST be one the elements of TLSGostExtensionHashHMACSelectClient 296 sequence. 298 Actions of the sender: 300 A server chooses one algorithm set from the client list, and makes 301 sure that it can complete a handshake using the chosen cipher suite 302 and this algorithm set before sending this extension. 304 Actions of the receiver: 306 A client that receives a ServerHello with this extension makes sure, 307 that server selected one of the algorithm sets, specified in the 308 corresponding ClientHello extension, and proceeds with a handshake, 309 using the algorithms specified in it. 311 5.5 Server Certificate 313 For these cipher suites this message is required and it MUST contain 314 a certificate, with a public key algorithm matching 315 ServerHello.cipher_suite. 317 5.6 Server Key Exchange 319 This message MUST NOT be used in these cipher suites, because all the 320 parameters necessary are present in server certificate (see [CPPK]). 322 5.7 Certificate Request 324 This message is used as described in section 7.4.4 of [TLS], and 325 extended as follows: 327 enum { 328 gost341094(21), gost34102001(22),(255) 329 } ClientCertificateType; 331 gost341094 and gost34102001 certificate types identify that the 332 server accepts GOST R 34.10-94 and GOST R 34.10-2001 public key 333 certificates. 335 5.8 Client Key Exchange Message 337 This message is used as described in section 7.4.7 of [TLS], it is 338 required for these suites, and contains DER-encoded 339 TLSGostKeyTransportBlob structure. 341 enum { vko_gost } KeyExchangeAlgorithm; 343 struct { 344 select (KeyExchangeAlgorithm) { 345 case vko_gost: TLSGostKeyTransportBlob; 346 } exchange_keys; 347 } ClientKeyExchange; 349 ASN1-syntax for this structure is: 351 TLSGostKeyTransportBlob ::= SEQUENCE { 352 keyBlob GostR3410-KeyTransport, 353 proxyKeyBlobs SEQUENCE OF TLSProxyKeyTransportBlob OPTIONAL 354 } 356 TLSProxyKeyTransportBlob ::= SEQUENCE { 357 keyBlob GostR3410-KeyTransport, 358 cert OCTET STRING 359 } 361 GostR3410-KeyTransport is defined in [CPCMS]. 363 keyBlob.transportParameters MUST be present. 365 keyBlob.transportParameters.ephemeralPublicKey MUST be present if the 366 server didn't request client certificate or client's public key 367 algorithm and parameters do not match those of the recipient. Else it 368 SHOULD be omited. 370 proxyKeyBlobs - (optional) contains key exchange for secondary 371 recipients (for example, for the firewall, which audits 372 connections). 373 cert - contains secondary recipient's certificate. 375 Actions of client: 377 First, the client generates a random 32-byte premaster_secret. 379 Then ukm is calculated as first 8 bytes of digest of concatenated 380 client random and server random: keyBlob.transportParameters.ukm = 381 GOSTR3411(client_random|server_random)[0..7] 383 Then client chooses a sender key. If 384 keyBlob.transportParameters.ephemeralPublicKey is present, the 385 corresponding secret key MUST be used as a sender key. If it is 386 missing, the secret key, corresponding to the client certificate MUST 387 be used. 389 Using the sender key and recipient's public key, algorithm VKO GOST R 390 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied 391 to produce KEK. VKO GOST R 34.10-2001 is used with 392 keyBlob.transportParameters.ukm as IV. 394 Then key wrap algorithm, specified by encryptionParamSet, is applied 395 to encrypt premaster_secret and produce CEK_ENC and CEC_MAC. Again, 396 keyBlob.transportParameters.ukm is used as IV. 397 keyBlob.transportParameters.encryptionParamSet is used for all 398 encryption operations. 400 The resulting encrypted key (CEK_ENC) is placed in 401 keyBlob.sessionEncryptedKey.encryptedKey field, it's mac (CEK_MAC) is 402 placed in keyBlob.sessionEncryptedKey.macKey field, and synchrovector 403 (IV) is placed in keyBlob.transportParameters.ukm field. 405 Actions of server: 407 Server MUST verify, that keyBlob.transportParameters.ukm is equal to 408 GOSTR3411(client_random|server_random)[0..7], before decrypting the 409 premaster_secret. 411 Server applies VKO GOST R 34.10-94 or VKO GOST R 34.10-2001, 412 (depending on the client public key type), and key wrap algorithm 413 (depending on encryptionParamSet) in the simillar manner to decrypt 414 the premaster_secret. 416 Server MUST verify keyBlob.sessionEncryptedKey.macKey after 417 decrypting the premaster_secret. 419 5.9 Certificate Verify 421 This message is used as described in section 7.4.8 of [TLS]. If the 422 client have sent both a client certificate and an ephemeral public 423 key, it MUST send a certificate verify message, as a proof of 424 possession of the private key for provided certificate. 426 The TLS structures are extended as follows: 428 enum { gost341094, gost34102001 } 429 SignatureAlgorithm; 431 select (SignatureAlgorithm) { 432 case gost341094: 433 digitally-signed struct { 434 opaque gost341194_hash[32]; 435 }; 436 case gost34102001: 437 digitally-signed struct { 438 opaque gost341194_hash[32]; 439 }; 440 } Signature; 442 CertificateVerify.signature.gostR3411_hash = 443 GOSTR3411(handshake_messages) 445 5.10 Finished 447 This message is used as described in section 7.4.9 of [TLS]. 449 Finished.verify_data = PRF_GOSTR3411(master_secret, finished_label + 450 GOSTR3411(handshake_messages)) [0..11] 452 6 Security Considerations 454 It is RECCOMENDED, that applications verify signature values and 455 subject public keys to conform to [GOSTR34102001], [GOSTR341094] 456 standards prior to their use. 458 Use of the same key for signature and key derivation is NOT 459 RECOMMENDED. 461 It is RECOMENDED for both client and server to verify the private key 462 usage period, if this extension is present in the certificate. 464 The cipher suites TLS_GOST341094_WITH_GOST28147_OFB_GOST28147 and 465 TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147 proposed hereby, have 466 been analyzed by special certification laboratory of Scientific and 467 Technical Centre "ATLAS" in appropriate levels of 468 target_of_evaluation (TOE). 470 It is RECCOMENDED to perform an examination of cipher suites 471 implementations by authorized agency with approved methods of 472 cryptographic analysis. 474 7 Appendix ASN.1 Modules 476 Additional ASN.1 modules, referenced here, can be found in [CPALGS] 477 and [CPCMS]. 479 7.1 Gost-CryptoPro-TLS 480 Gost-CryptoPro-TLS 481 { iso(1) member-body(2) ru(643) rans(2) 482 cryptopro(2) other(1) modules(1) 483 gost-CryptoPro-TransportLayerSecurity(16) 1 } 484 DEFINITIONS ::= 485 BEGIN 486 -- EXPORTS All -- 487 -- The types and values defined in this module are exported for 488 -- use in the other ASN.1 modules contained within the Russian 489 -- Cryptography "GOST" & "GOST R" Specifications, and for the use 490 -- of other applications which will use them to access Russian 491 -- Cryptography services. Other applications may use them for 492 -- their own purposes, but this will not constrain extensions and 493 -- modifications needed to maintain or improve the Russian 494 -- Cryptography service. 495 IMPORTS 496 Certificate, 497 AlgorithmIdentifier 498 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 499 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 500 id-mod(0) id-pkix1-explicit-88(1)} 501 id-CryptoPro-algorithms, gostR3410-EncryptionSyntax 502 FROM Cryptographic-Gost-Useful-Definitions 503 { iso(1) member-body(2) ru(643) rans(2) 504 cryptopro(2) other(1) modules(1) 505 cryptographic-Gost-Useful-Definitions(0) 1 } 506 GostR3410-KeyTransport 507 FROM GostR3410-EncryptionSyntax 508 gostR3410-EncryptionSyntax 509 ; 510 id-PRF-GostR3411-94 OBJECT IDENTIFIER ::= 511 { id-CryptoPro-algorithms prf-gostr3411-94(23) } 512 TLSProxyKeyTransportBlob ::= 513 SEQUENCE { 514 keyBlob GostR3410-KeyTransport, 515 cert OCTET STRING 516 } 517 TLSGostKeyTransportBlob ::= 518 SEQUENCE { 519 keyBlob GostR3410-KeyTransport, 520 proxyKeyBlobs SEQUENCE OF 521 TLSProxyKeyTransportBlob OPTIONAL 522 } 523 TLSGostSrvKeyExchange ::= 524 SEQUENCE OF 525 OCTET STRING (CONSTRAINED BY {Certificate}) 526 TLSGostExtensionHashHMACSelect ::= 527 SEQUENCE { 528 hashAlgorithm AlgorithmIdentifier, 529 hmacAlgorithm AlgorithmIdentifier, 530 prfAlgorithm AlgorithmIdentifier 531 } 532 TLSGostExtensionHashHMACSelectClient ::= 533 SEQUENCE OF 534 TLSGostExtensionHashHMACSelect 535 TLSGostExtensionHashHMACSelectServer ::= 536 TLSGostExtensionHashHMACSelect 538 END -- Gost-CryptoPro-TLS 540 8 References 542 [CPALGS] V. Popov, I. Kurepkin, S. Leontiev "Additional cryp- 543 tographic algorithms for use with GOST 28147-89, GOST 544 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 545 algorithms.", draft-popov-cryptopro-cpalgs-01.txt, 546 work in progress 548 [CPCMS] "Cryptographic Message Syntax (CMS) algorithms for 549 GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, 550 GOST R 34.11-94", IETF draft, , work in progress 553 [CPPK] "Algorithms and Identifiers for the Internet X.509 554 Public Key Infrastructure Certificates and Certifi- 555 cate Revocation List (CRL), corresponding to the 556 algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 557 34.11-94", IETF draft, , work in progress 560 [GOST28147] "Cryptographic Protection for Data Processing Sys- 561 tem", GOST 28147-89, Gosudarstvennyi Standard of 562 USSR, Government Committee of the USSR for Standards, 563 1989. (In Russian); 565 [GOSTR341094] "Information technology. Cryptographic Data Security. 566 Produce and check procedures of Electronic Digital 567 Signatures based on Asymmetric Cryptographic Algo- 568 rithm.", GOST R 34.10-94, Gosudarstvennyi Standard of 569 Russian Federation, Government Committee of the Rus- 570 sia for Standards, 1994. (In Russian); 572 [GOSTR34102001] "Information technology. Cryptographic Data Secu- 573 rity.Signature and verification processes of [elec- 574 tronic] digital signature.", GOST R 34.10-2001, Gosu- 575 darstvennyi Standard of Russian Federation, Govern- 576 ment Committee of the Russia for Standards, 2001. (In 577 Russian); 579 [GOSTR341194] "Information technology. Cryptographic Data Security. 580 Hashing function.", GOST R 34.10-94, Gosudarstvennyi 581 Standard of Russian Federation, Government Committee 582 of the Russia for Standards, 1994. (In Russian); 584 [RFC 3280] Housley, R., Polk, W., Ford, W. and D. Solo, 585 "Internet X.509 Public Key Infrastructure Certificate 586 and Certificate Revocation List (CRL) Profile", RFC 587 3280, April 2002. 589 [RFC 3279] Algorithms and Identifiers for the Internet X.509 590 Public Key Infrastructure Certificate and Certificate 591 Revocation List (CRL) Profile. L. Bassham, W. 592 Polk, R. Housley. April 2002. 594 [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [Schneier95] B. Schneier, Applied cryptography, second edition, 598 John Wiley & Sons, Inc., 1995; 600 [TLS] The TLS Protocol Version 1.0. T. Dierks, C. Allen. 601 January 1999, RFC 2246. 603 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., 604 Mikkelsen, J. and T. Wright, "Transport Layer Secu- 605 rity (TLS) Extensions", RFC 3546, June 2003. 607 [X.660] ITU-T Recommendation X.660 Information Technology - 608 ASN.1 encoding rules: Specification of Basic Encoding 609 Rules (BER), Canonical Encoding Rules (CER) and Dis- 610 tinguished Encoding Rules (DER), 1997. 612 Acknowledgments 614 This document was created in accordance with "Russian Cryptographic 615 Software Compatibility Agreement", signed by FGUE STC "Atlas", 616 CRYPTO-PRO, Factor-TC, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 617 Cryptocom, R-Alpha. The aim of this agreement is to achieve mutual 618 compatibility of the products and solutions. 620 The authors wish to thank: 622 Microsoft Corporation Russia for provided information about 623 company products and solutions, and also for technical consulting 624 in PKI. 626 RSA Security Russia and Demos Co Ltd for active colaboration and 627 critical help in creation of this document. 629 NIP Informzachita for compatibility testing of the proposed data 630 formats while incorporating them into company products. 632 Citrix Inc for help in compatibility testing Citrix products for 633 Microsoft Windows. 635 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 636 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative, 637 creating this document. 639 This document is based on a contribution of CRYPTO-PRO company. Any 640 substantial use of the text from this document must acknowledge 641 CRYPTO-PRO. CRYPTO-PRO requests that all material mentioning or 642 referencing this document identify this as "CRYPTO-PRO CPTLS". 644 Author's Addresses 646 Serguei Leontiev 647 CRYPTO-PRO 648 38, Obraztsova, 649 Moscow, 127018, Russian Federation 650 EMail: lse@cryptopro.ru 652 Grigorij Chudov 653 CRYPTO-PRO 654 38, Obraztsova, 655 Moscow, 127018, Russian Federation 656 EMail: chudov@cryptopro.ru 658 Alexandr Afanasiev 659 Factor-TC 660 office 711, 14, Presnenskij val, 661 Moscow, 123557, Russian Federation 662 EMail: aaaf@factor-ts.ru 664 Nikolaj Nikishin 665 Infotecs GmbH 666 p/b 35, 80-5, Leningradskij prospekt, 667 Moscow, 125315, Russian Federation 668 EMail: nikishin@infotecs.ru 670 Boleslav Izotov 671 FGUE STC "Atlas" 672 38, Obraztsova, 673 Moscow, 127018, Russian Federation 674 EMail: izotov@stcnet.ru 676 Elena Minaeva 677 MD PREI 678 build 3, 6A, Vtoroj Troitskij per., 679 Moscow, Russian Federation 680 EMail: evminaeva@mo.msk.ru 682 Serguei Murugov 683 R-Alpha 684 4/1, Raspletina, 685 Moscow, 123060, Russian Federation 686 EMail: msm@office.ru 688 Igori Ustinov 689 Cryptocom 690 office 239, 51, Leninskij prospekt, 691 Moscow, 119991, Russian Federation 692 EMail: igus@cryptocom.ru 694 Anatolij Erkin 695 SPRCIS (SPbRCZI) 696 1, Obrucheva, 697 St.Petersburg, 195220, Russian Federation 698 EMail: erkin@nevsky.net 700 Full Copyright Statement 702 Copyright (C) The Internet Society (2003). All Rights Reserved. 704 This document and translations of it may be copied and furnished to 705 others, and derivative works that comment on or otherwise explain it 706 or assist in its implementation may be prepared, copied, published 707 and distributed, in whole or in part, without restriction of any 708 kind, provided that the above copyright notice and this paragraph are 709 included on all such copies and derivative works. However, this 710 document itself may not be modified in any way, such as by removing 711 the copyright notice or references to the Internet Society or other 712 Internet organizations, except as needed for the purpose of 713 developing Internet standards in which case the procedures for 714 copyrights defined in the Internet Standards process must be 715 followed, or as required to translate it into languages other than 716 English. 718 The limited permissions granted above are perpetual and will not be 719 revoked by the Internet Society or its successors or assigns. 721 This document and the information contained herein is provided on an 722 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 723 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 724 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 725 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 726 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.