idnits 2.17.1 draft-chudov-cryptopro-cptls-02.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 597. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. 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]), 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 (September 8, 2005) is 6805 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GOSTR3411' is mentioned on line 86, but not defined -- Looks like a reference, but probably isn't: '0' on line 172 -- Looks like a reference, but probably isn't: '32' on line 331 == Unused Reference: 'Schneier95' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'TLSEXT' is defined on line 489, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-pkix-gost-cppk-03 == Outdated reference: A later version (-07) exists of draft-ietf-smime-gost-05 ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (ref. 'TLSEXT') (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 2716 (ref. 'EAP-TLS') (Obsoleted by RFC 5216) Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Grigorij Chudov, CRYPTO-PRO 3 Serguei Leontiev, CRYPTO-PRO 4 Expires March 8, 2006 September 8, 2005 5 Intended Category: Informational 7 GOST Cipher Suites for Transport Layer Security 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than a "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 8, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document is intended to register new cipher suites for the 43 Transport Layer Security (TLS) protocol, according to the procedure 44 specified in section A.5 of [TLS]. These cipher suites are based on 45 Russian national cryptographic standards - GOST R 34.10-94 and GOST R 46 34.10-2001 public keys, GOST 28147-89 encryption algorithm and GOST R 47 34.11-94 digest algorithm. 49 Table of Contents 51 1 Introduction. . . . . . . . . . . . . . . . . . . . . . . 2 52 2 Proposed Ciphersuites . . . . . . . . . . . . . . . . . . 3 53 3 CipherSuite Definitions . . . . . . . . . . . . . . . . . 3 54 3.1 Key Exchange. . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2 PRF, Signature and Hash . . . . . . . . . . . . . . . . . 3 56 3.3 Cipher and MAC. . . . . . . . . . . . . . . . . . . . . . 4 57 4 Data Structures and Computations. . . . . . . . . . . . . 4 58 4.1 Algorithms. . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2 Keys Calculation. . . . . . . . . . . . . . . . . . . . . 5 60 4.3 Server Certificate. . . . . . . . . . . . . . . . . . . . 5 61 4.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 5 62 4.5 Certificate Request . . . . . . . . . . . . . . . . . . . 5 63 4.6 Client Key Exchange Message . . . . . . . . . . . . . . . 5 64 4.7 Certificate Verify. . . . . . . . . . . . . . . . . . . . 7 65 4.8 Finished. . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5 Security Considerations . . . . . . . . . . . . . . . . . 8 67 6 Appendix ASN.1 Modules. . . . . . . . . . . . . . . . . . 8 68 7 References. . . . . . . . . . . . . . . . . . . . . . . . 10 69 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 70 Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . 12 71 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 13 73 1 Introduction 75 This document proposes the addition of new cipher suites to the 76 Transport Layer Security (TLS) protocol to support GOST R 34.11-94 77 digest, GOST 28147-89 encryption and VKO GOST R 34.10-94/2001 key 78 exchange algorithms. The cipher suites defined here were proposed by 79 CRYPTO-PRO Company for the "Russian Cryptographic Software 80 Compatibility Agreement" community. 82 Algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST 28147-89 and GOST 83 R 34.11-94 have been developed by Russian Federal Agency of 84 Governmental Communication and Information (FAGCI) and "All-Russian 85 Scientific and Research Institute of Standardization". They are 86 described in [GOSTR341094], [GOSTR341001], [GOSTR3411] and 87 [GOST28147]. Algorithms VKO GOST R 34.10-94/2001 and PRF_GOSTR3411 88 are described in [CPALGS]. 90 This document defines two configurations: 91 anonymous client - authenticated server (only server provides a 92 certificate); 93 authenticated client - authenticated server (client and server 94 exchange certificates). 96 The presentation language used here is the same as in [TLS]. Since 97 this specification extends TLS, these descriptions should be merged 98 with those in the TLS specification and any others that extend TLS. 99 This means, that enum types may not specify all possible values and 100 structures with multiple formats chosen with a select() clause may 101 not indicate all possible cases. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 104 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 105 this document are to be interpreted as described in [RFC 2119]. 107 2 Proposed CipherSuites 109 The new cipher suites proposed here have the following definitions: 111 CipherSuite TLS_GOST341094_WITH_GOST28147_OFB_GOST28147 = {0x00,0x80} 112 CipherSuite TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147= {0x00,0x81} 113 CipherSuite TLS_GOST341094_WITH_NULL_GOSTR3411 = {0x00,0x82} 114 CipherSuite TLS_GOST34102001_WITH_NULL_GOSTR3411 = {0x00,0x83} 116 Note: The above numeric definitions for CipherSuites have not yet 117 been registered. 119 3 CipherSuite Definitions 121 3.1 Key exchange 123 The cipher suites defined here use the following key exchange 124 algorithms: 126 CipherSuite Key Exchange Algorithm 127 TLS_GOST341094_WITH_GOST28147_OFB_GOST28147 VKO GOST R 34.10-94 128 TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147 VKO GOST R 34.10-2001 129 TLS_GOST341094_WITH_NULL_GOSTR3411 VKO GOST R 34.10-94 130 TLS_GOST34102001_WITH_NULL_GOSTR3411 VKO GOST R 34.10-2001 132 Key derivation algorithms based on GOST R 3410-94 and GOST R 133 3410-2001 public keys (VKO GOST R 34.10-94, VKO GOST R 34.10-2001) 134 are described in [CPALGS]. 136 3.2 PRF, Signature and Hash 138 For a PRF, described in section 5 of [TLS], the cipher suites 139 described here use PRF_GOSTR3411 (refer to section 4.1). The same PRF 140 MUST be used for all dependent protocols, such as [EAP-TLS]. 142 GOST R 3410-94/2001 signature is used for CertificateVerify message. 144 GOST R 34.11 digest algorithm ([GOSTR341194]) is used for 145 CertificateVerify.signature.gostR3411_hash and Finished.verify_data 146 (see sections 7.4.8 and 7.4.9 of [TLS]) 148 3.3 Cipher and MAC 150 The following cipher algorithm and MAC functions are used (for 151 details refer to section 4.1): 153 CipherSuite Cipher MAC 154 TLS_GOST341094_WITH_GOST28147_OFB_GOST28147 GOST28147 IMIT_GOST28147 155 TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147 GOST28147 IMIT_GOST28147 156 TLS_GOST341094_WITH_NULL_GOSTR3411 - HMAC_GOSTR3411 157 TLS_GOST34102001_WITH_NULL_GOSTR3411 - HMAC_GOSTR3411 159 For all four cipher suites, the use of MAC is slighttly different 160 from the one, described in section 6.2.3.1 of [TLS]. In [TLS], MAC 161 is calculated from the following data: 163 MACed_data[seq_num] = seq_num + 164 TLSCompressed.type + 165 TLSCompressed.version + 166 TLSCompressed.length + 167 TLSCompressed.fragment; 169 These cipher suites use the same input for first record, but for each 170 next record the input from all previous records is concatenated: 172 MACed_data[0] + ... + MACed_data[n] 174 4 Data Structures and Computations 176 4.1 Algorithms 178 GOST 28147-89 [GOST28147] uses 256-bit key size and 8-byte IV. 179 Cipher suites, defined here, use GOST 28147-89 as a stream cipher in 180 OFB mode with S-box from id-Gost28147-89-CryptoPro-A-ParamSet (see 181 [CPALGS]) and CryptoPro key meshing algorithm. 183 IMIT_GOST28147 is GOST 28147-89 [GOST28147] in "IMITOVSTAVKA" mode (4 184 bytes) 186 HMAC_GOSTR3411(secret, data) is based on GOST R 34.11 digest and 187 described in [CPALGS]. 189 PRF_GOSTR3411(secret, label, seed) is based on HMAC_GOSTR3411 and 190 described in [CPALGS]. 192 4.2 Key Calculation 194 Key calculation is done according to section 6.3 of [TLS], with 195 PRF_GOSTR3411 function used instead of PRF. The parameters are as 196 follows: 197 SecurityParameters.hash_size = 32 198 SecurityParameters.key_material_length = 32 199 SecurityParameters.IV_size = 8 200 Length of necessary key material is 144 bytes. 202 4.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 4.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 4.3 Certificate Request 215 This message is used as described in section 7.4.4 of [TLS], and 216 extended as follows: 218 enum { 219 gost341094(21), gost34102001(22),(255) 220 } ClientCertificateType; 222 gost341094 and gost34102001 certificate types identify that the 223 server accepts GOST R 34.10-94 and GOST R 34.10-2001 public key 224 certificates. 226 Note: The above numeric definitions for ClientCertificateType have 227 not yet been registered. 229 4.6 Client Key Exchange Message 231 This message is used as described in section 7.4.7 of [TLS], it is 232 required for these suites, and contains DER-encoded 233 TLSGostKeyTransportBlob structure. 235 enum { vko_gost } KeyExchangeAlgorithm; 237 struct { 238 select (KeyExchangeAlgorithm) { 239 case vko_gost: TLSGostKeyTransportBlob; 241 } exchange_keys; 242 } ClientKeyExchange; 244 ASN1-syntax for this structure is: 246 TLSGostKeyTransportBlob ::= SEQUENCE { 247 keyBlob GostR3410-KeyTransport, 248 proxyKeyBlobs SEQUENCE OF TLSProxyKeyTransportBlob OPTIONAL 249 } 251 TLSProxyKeyTransportBlob ::= SEQUENCE { 252 keyBlob GostR3410-KeyTransport, 253 cert OCTET STRING 254 } 256 GostR3410-KeyTransport is defined in [CPCMS]. 258 keyBlob.transportParameters MUST be present. 260 keyBlob.transportParameters.ephemeralPublicKey MUST be present if the 261 server didn't request client certificate or client's public key 262 algorithm and parameters do not match those of the recipient. Else it 263 SHOULD be omited. 265 proxyKeyBlobs - (optional) contains key exchange for secondary 266 recipients (for example, for the firewall, which audits 267 connections). 268 cert - contains secondary recipient's certificate. 270 Actions of client: 272 First, the client generates a random 32-byte premaster_secret. 274 Then shared_ukm is calculated as first 8 bytes of digest of 275 concatenated client random and server random: shared_ukm = 276 GOSTR3411(client_random|server_random)[0..7] 278 Then client chooses a sender key. If 279 keyBlob.transportParameters.ephemeralPublicKey is present, the 280 corresponding secret key MUST be used as a sender key. If it is 281 missing, the secret key, corresponding to the client certificate MUST 282 be used. 284 Using the sender key and recipient's public key, algorithm VKO GOST R 285 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied 286 to produce KEK. VKO GOST R 34.10-2001 is used with shared_ukm as 287 UKM. 289 Then CryptoPro Key Wrap algorithm is applied to encrypt 290 premaster_secret and produce CEK_ENC and CEK_MAC. Again, shared_ukm 291 is used as UKM. keyBlob.transportParameters.encryptionParamSet is 292 used for all encryption operations. 294 The resulting encrypted key (CEK_ENC) is placed in 295 keyBlob.sessionEncryptedKey.encryptedKey field, it's mac (CEK_MAC) is 296 placed in keyBlob.sessionEncryptedKey.macKey field, and shared_ukm 297 (UKM) is placed in keyBlob.transportParameters.ukm field. 299 Actions of server: 301 Server MUST verify, that keyBlob.transportParameters.ukm is equal to 302 GOSTR3411(client_random|server_random)[0..7], before decrypting the 303 premaster_secret. 305 Server applies VKO GOST R 34.10-94 or VKO GOST R 34.10-2001, 306 (depending on the client public key type), and CryptoPro Key Unwrap 307 algorithm in the simillar manner to decrypt the premaster_secret. 309 Server MUST verify keyBlob.sessionEncryptedKey.macKey after 310 decrypting the premaster_secret. 312 4.7 Certificate Verify 314 This message is used as described in section 7.4.8 of [TLS]. If the 315 client have sent both a client certificate and an ephemeral public 316 key, it MUST send a certificate verify message, as a proof of 317 possession of the private key for provided certificate. 319 The TLS structures are extended as follows: 321 enum { gost341094, gost34102001 } 322 SignatureAlgorithm; 324 select (SignatureAlgorithm) { 325 case gost341094: 326 digitally-signed struct { 327 opaque gost341194_hash[32]; 328 }; 329 case gost34102001: 330 digitally-signed struct { 331 opaque gost341194_hash[32]; 332 }; 333 } Signature; 335 CertificateVerify.signature.gostR3411_hash = 336 GOSTR3411(handshake_messages) 338 4.8 Finished 340 This message is used as described in section 7.4.9 of [TLS]. 342 Finished.verify_data = PRF_GOSTR3411(master_secret, finished_label + 343 GOSTR3411(handshake_messages)) [0..11] 345 5 Security Considerations 347 It is RECOMMENDED that software applications verify signature values, 348 subject public keys and algorithm parameters to conform to 349 [GOSTR341001], [GOSTR341094] standards prior to their use. 351 Use of the same key for signature and key derivation is NOT 352 RECOMMENDED. 354 It is RECOMMENDED for both client and server to verify the private 355 key usage period, if this extension is present in the certificate. 357 The cipher suites TLS_GOST341094_WITH_GOST28147_OFB_GOST28147 and 358 TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147 proposed hereby, have 359 been analyzed by special certification laboratory of Scientific and 360 Technical Centre "ATLAS" in appropriate levels of 361 target_of_evaluation (TOE). 363 It is RECOMMENDED to subject the implementations of these cipher 364 suites to examination by an authorized agency with approved methods 365 of cryptographic analysis. 367 6 Appendix ASN.1 Modules 369 Additional ASN.1 modules, referenced here, can be found in [CPALGS] 370 and [CPCMS]. 372 6.1 Gost-CryptoPro-TLS 374 Gost-CryptoPro-TLS 375 { iso(1) member-body(2) ru(643) rans(2) 376 cryptopro(2) other(1) modules(1) gost-CryptoPro-TLS(16) 1 } 377 DEFINITIONS ::= 378 BEGIN 379 -- EXPORTS All -- 380 -- The types and values defined in this module are exported for 381 -- use in the other ASN.1 modules contained within the Russian 382 -- Cryptography "GOST" & "GOST R" Specifications, and for the use 383 -- of other applications which will use them to access Russian 384 -- Cryptography services. Other applications may use them for 385 -- their own purposes, but this will not constrain extensions and 386 -- modifications needed to maintain or improve the Russian 387 -- Cryptography service. 388 IMPORTS 389 Certificate, 390 AlgorithmIdentifier 391 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 392 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 393 id-mod(0) id-pkix1-explicit-88(1)} 394 id-CryptoPro-algorithms, gostR3410-EncryptionSyntax 395 FROM Cryptographic-Gost-Useful-Definitions 396 { iso(1) member-body(2) ru(643) rans(2) 397 cryptopro(2) other(1) modules(1) 398 cryptographic-Gost-Useful-Definitions(0) 1 } 399 GostR3410-KeyTransport 400 FROM GostR3410-EncryptionSyntax 401 gostR3410-EncryptionSyntax 402 ; 403 id-PRF-GostR3411-94 OBJECT IDENTIFIER ::= 404 { id-CryptoPro-algorithms prf-gostr3411-94(23) } 405 TLSProxyKeyTransportBlob ::= 406 SEQUENCE { 407 keyBlob GostR3410-KeyTransport, 408 cert OCTET STRING 409 } 410 TLSGostKeyTransportBlob ::= 411 SEQUENCE { 412 keyBlob GostR3410-KeyTransport, 413 proxyKeyBlobs SEQUENCE OF 414 TLSProxyKeyTransportBlob OPTIONAL 415 } 416 TLSGostSrvKeyExchange ::= 417 SEQUENCE OF 418 OCTET STRING (CONSTRAINED BY {Certificate}) 419 TLSGostExtensionHashHMACSelect ::= 420 SEQUENCE { 421 hashAlgorithm AlgorithmIdentifier, 422 hmacAlgorithm AlgorithmIdentifier, 423 prfAlgorithm AlgorithmIdentifier 424 } 425 TLSGostExtensionHashHMACSelectClient ::= 426 SEQUENCE OF 427 TLSGostExtensionHashHMACSelect 428 TLSGostExtensionHashHMACSelectServer ::= 429 TLSGostExtensionHashHMACSelect 431 END -- Gost-CryptoPro-TLS 432 7 References 434 Normative references: 436 [CPALGS] V. Popov, I. Kurepkin, S. Leontiev, "Additional crypto- 437 graphic algorithms for use with GOST 28147-89, GOST R 438 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 algo- 439 rithms.", September 2005, draft-popov-cryptopro- 440 cpalgs-04.txt 442 [CPPK] S. Leontiev, D. Shefanovskij, "Algorithms and Identi- 443 fiers for the Internet X.509 Public Key Infrastructure 444 Certificates and Certificate Revocation List (CRL), 445 corresponding to the algorithms GOST R 34.10-94, GOST R 446 34.10-2001, GOST R 34.11-94", September 2005, draft- 447 ietf-pkix-gost-cppk-03.txt 449 [CPCMS] S. Leontiev, G. Chudov, "Using the GOST 28147-89, GOST 450 R 34.11-94, GOST R 34.10-94 and GOST R 34.10-2001 algo- 451 rithms with the Cryptographic Message Syntax (CMS)", 452 September 2005, draft-ietf-smime-gost-05.txt 454 [GOST28147] "Cryptographic Protection for Data Processing System", 455 GOST 28147-89, Gosudarstvennyi Standard of USSR, Gov- 456 ernment Committee of the USSR for Standards, 1989. (In 457 Russian); 459 [GOSTR341094] "Information technology. Cryptographic Data Security. 460 Produce and check procedures of Electronic Digital Sig- 461 natures based on Asymmetric Cryptographic Algorithm.", 462 GOST R 34.10-94, Gosudarstvennyi Standard of Russian 463 Federation, Government Committee of the Russia for 464 Standards, 1994. (In Russian); 466 [GOSTR341001] "Information technology. Cryptographic Data Secu- 467 rity.Signature and verification processes of [elec- 468 tronic] digital signature.", GOST R 34.10-2001, Gosu- 469 darstvennyi Standard of Russian Federation, Government 470 Committee of the Russia for Standards, 2001. (In Rus- 471 sian); 473 [GOSTR341194] "Information technology. Cryptographic Data Security. 474 Hashing function.", GOST R 34.10-94, Gosudarstvennyi 475 Standard of Russian Federation, Government Committee of 476 the Russia for Standards, 1994. (In Russian); 478 [TLS] The TLS Protocol Version 1.0. T. Dierks, C. Allen. 479 January 1999, RFC 2246. 481 Informative references: 483 [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, March 1997. 486 [Schneier95] B. Schneier, Applied cryptography, second edition, 487 John Wiley & Sons, Inc., 1995; 489 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, 490 J. and T. Wright, "Transport Layer Security (TLS) 491 Extensions", RFC 3546, June 2003. 493 [X.660] ITU-T Recommendation X.660 Information Technology - 494 ASN.1 encoding rules: Specification of Basic Encoding 495 Rules (BER), Canonical Encoding Rules (CER) and Distin- 496 guished Encoding Rules (DER), 1997. 498 [EAP-TLS] B. Aboba, D. Simon, "PPP EAP TLS Authentication Proto- 499 col", RFC 2716, October 1999. 501 Acknowledgments 503 This document was created in accordance with "Russian Cryptographic 504 Software Compatibility Agreement", signed by FGUE STC "Atlas", 505 CRYPTO-PRO, Factor-TS, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 506 Cryptocom, R-Alpha. The aim of this agreement is to achieve mutual 507 compatibility of the products and solutions. 509 The authors wish to thank: 511 Microsoft Corporation Russia for provided information about 512 company products and solutions, and also for technical consulting 513 in PKI. 515 RSA Security Russia and Demos Co Ltd for active colaboration and 516 critical help in creation of this document. 518 NIP Informzachita for compatibility testing of the proposed data 519 formats while incorporating them into company products. 521 Citrix Inc for help in compatibility testing Citrix products for 522 Microsoft Windows. 524 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 525 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative, 526 creating this document. 528 This document is based on a contribution of CRYPTO-PRO company. Any 529 substantial use of the text from this document must acknowledge 530 CRYPTO-PRO. CRYPTO-PRO requests that all material mentioning or 531 referencing this document identify this as "CRYPTO-PRO CPTLS". 533 Author's Addresses 535 Grigorij Chudov 536 CRYPTO-PRO 537 38, Obraztsova, 538 Moscow, 127018, Russian Federation 539 EMail: chudov@cryptopro.ru 541 Serguei Leontiev 542 CRYPTO-PRO 543 38, Obraztsova, 544 Moscow, 127018, Russian Federation 545 EMail: lse@cryptopro.ru 547 Alexandr Afanasiev 548 Factor-TS 549 office 711, 14, Presnenskij val, 550 Moscow, 123557, Russian Federation 551 EMail: afa1@factor-ts.ru 553 Nikolaj Nikishin 554 Infotecs GmbH 555 p/b 35, 80-5, Leningradskij prospekt, 556 Moscow, 125315, Russian Federation 557 EMail: nikishin@infotecs.ru 559 Boleslav Izotov 560 FGUE STC "Atlas" 561 38, Obraztsova, 562 Moscow, 127018, Russian Federation 563 EMail: izotov@nii.voskhod.ru 565 Elena Minaeva 566 MD PREI 567 build 3, 6A, Vtoroj Troitskij per., 568 Moscow, Russian Federation 569 EMail: evminaeva@mail.ru 571 Serguei Murugov 572 R-Alpha 573 4/1, Raspletina, 574 Moscow, 123060, Russian Federation 575 EMail: msm@top-cross.ru 577 Igor Ustinov 578 Cryptocom 579 office 239, 51, Leninskij prospekt, 580 Moscow, 119991, Russian Federation 581 EMail: igus@cryptocom.ru 583 Anatolij Erkin 584 SPRCIS (SPbRCZI) 585 1, Obrucheva, 586 St.Petersburg, 195220, Russian Federation 587 EMail: erkin@nevsky.net 589 Disclaimer of Validity 591 This document and the information contained herein are provided on an 592 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 593 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 594 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 595 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 596 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 599 Full Copyright Statement 601 Copyright (C) The Internet Society (2005). This document is subject 602 to the rights, licenses and restrictions contained in BCP 78, and 603 except as set forth therein, the authors retain all their rights. 605 Acknowledgment 607 Funding for the RFC Editor function is currently provided by the 608 Internet Society.