idnits 2.17.1 draft-ietf-pkix-gost-cppk-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: ---------------------------------------------------------------------------- No issues found here. 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 ([RFC3280], [RFC3279]), 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 7330 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GOST3411' is mentioned on line 96, but not defined == Missing Reference: 'GOST341094' is mentioned on line 111, but not defined == Missing Reference: 'GOST34102001' is mentioned on line 112, but not defined == Missing Reference: 'GOSTR3411' is mentioned on line 146, but not defined -- Looks like a reference, but probably isn't: '0' on line 426 -- Looks like a reference, but probably isn't: '63' on line 431 == Unused Reference: 'GOST28147' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'GOSTR341194' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'TLS' is defined on line 539, but no explicit reference was found in the text -- No information found for draft-popov-crypto-pro-cpalgs - is the name correct? ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group Serguei Leontiev, CRYPTO-PRO 3 Internet Draft Dennis Shefanovskij, DEMOS Co Ltd 4 Expires October 1, 2004 April 1, 2004 5 Intended Category: Informational 7 Using the GOST R 34.10-94, GOST R 34.10-2001 and 8 GOST R 34.11-94 algorithms with the 9 Internet X.509 Public Key Infrastructure 10 Certificate and CRL Profile. 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Comments or suggestions for improvement may be done via "ietf-pkix" 36 mailing list, or directly to the authors. 38 Abstract 40 This document describes identifiers and appropriate parameters for 41 the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, 42 and also ASN.1 encoding scheme for digital signatures and public 43 keys, used in Internet X.509 Public Key Infrastructure (PKI). This 44 specification extends [RFC3279], "Algorithms and Identifiers for the 45 Internet X.509 Public Key Infrastructure Certificate and Certificate 46 Revocation List (CRL) Profile" and, correspondingly, [RFC3280], 47 "Internet X.509 Public Key Infrastructure: Certificate and 48 Certificate Revocation List (CRL) Profile". All implementations of 49 this specification MUST also satisfy the requirements of [RFC3280]. 51 Table of Contents 53 1 Introduction. . . . . . . . . . . . . . . . . . . . . . 2 54 2 Algorithm Support . . . . . . . . . . . . . . . . . . . 3 55 2.1 One-way Hash Function . . . . . . . . . . . . . . . . . 4 56 2.1.1 One-way Hash Function GOST R 34.11-94 . . . . . . . . . 4 57 2.2 Signature Algorithms. . . . . . . . . . . . . . . . . . 4 58 2.2.1 Signature Algorithm GOST R 34.10-94 . . . . . . . . . . 5 59 2.2.2 Signature Algorithm GOST R 34.10-2001 . . . . . . . . . 6 60 2.3 Subject Public Key Algorithms . . . . . . . . . . . . . 7 61 2.3.1 GOST R 34.10-94 Keys. . . . . . . . . . . . . . . . . . 7 62 2.3.2 GOST R 34.10-2001 Keys. . . . . . . . . . . . . . . . . 9 63 3 Security Considerations . . . . . . . . . . . . . . . . 14 64 4 References. . . . . . . . . . . . . . . . . . . . . . . 41 65 Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 42 66 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 43 67 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 44 69 1 Introduction 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 This document defines identifiers and corresponding algorithm 76 parameters and attributes proposed by CRYPTO-PRO Company within 77 "Russian Cryptographic Software Compatibility Agreement" community 78 for the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 79 34.11-94, key derivation algorithms based on GOST R 34.10-94 public 80 keys, key derivation algorithms based on GOST R 34.10-2001 public 81 keys, and also ASN.1 encoding [X.660] for digital signatures and 82 public keys, used in Internet X.509 Public Key Infrastructure (PKI). 84 This specification extends [RFC3279], "Algorithms and Identifiers for 85 the Internet X.509 Public Key Infrastructure Certificate and 86 Certificate Revocation List (CRL) Profile" and, correspondingly, 87 [RFC3280], "Internet X.509 Public Key Infrastructure: Certificate and 88 Certificate Revocation List (CRL) Profile". All implementations of 89 this specification MUST also satisfy the requirements of [RFC3280]. 91 This specification defines the content of the signatureAlgorithm, 92 signatureValue, signature, and subjectPublicKeyInfo fields within 93 Internet X.509 certificates and CRLs. 95 This document defines the use of one-way hash-function GOST R 96 34.11-94 [GOST3411] with digital signatures. This algorithm is used 97 in conjunction with digital signature algorithms. 99 This specification describes the encoding of digital signatures, 100 generated with the following cryptographic algorithms: 102 * GOST R 34.10-94; 103 * GOST R 34.10-2001. 105 This document also defines the contents of the subjectPublicKeyInfo 106 field for Internet X.509 certificates. For each algorithm, the 107 appropriate alternatives for the keyUsage extension are provided. 108 This specification describes encoding formats for public keys used 109 with the following cryptographic algorithms: 111 * GOST R 34.10-94 [GOST341094]; 112 * GOST R 34.10-2001 [GOST34102001]; 113 * Key derivation algorithm VKO GOST R 34.10-94 [CPALGS]; 114 * Key derivation algorithm VKO GOST R 34.10-2001 [CPALGS]; 116 ASN.1 modules, including all the definitions used in this document 117 can be found in [CPALGS]. 119 2 Algorithm Support 121 This section is an overview of cryptographic algorithms, that may be 122 used within the Internet X.509 certificates and CRL profile 123 [RFC3280]. It describes one-way hash functions and digital signature 124 algorithms, that may be used to sign certificates and CRLs, and 125 identifies OIDs and ASN.1 encoding for public keys contained in a 126 certificate. 128 The conforming CAs and/or applications MUST fully support digital 129 signatures and public keys for at least one of the specified 130 algorithms. 132 2.1 One-way Hash Function 134 This section identifies the use of one-way, collision free hash 135 function GOST R 34.11-94 - the only one that can be used in digital 136 signature algorithms GOST R 34.10-94/2001. The data that is hashed 137 for certificates and CRL signing is fully described in [RFC3280]. 139 2.1.1 One-way Hash Function GOST R 34.11-94 141 GOST R 34.11-94 has been developed by "GUBS of Federal Agency 142 Government Communication and Information" and "All-Russian Scientific 143 and Research Institute of Standardization". The algorithm GOST R 144 34.11-94 produces a 256-bit hash value of the arbitrary finite bit 145 length input. This document does not contain GOST R 34.11-94 full 146 specification, which can be found in [GOSTR3411] in Russian. It's 147 brief technical description in english can be found in [Schneier95], 148 ch. 18.11, p. 454. 150 This function is always used with default parameter set 151 gostR3411CryptoProParamSetAI (see section 8.2 of [CPALGS]). 153 2.2 Signature Algorithms 155 Conforming CAs may use GOST R 34.10-94 or GOST R 34.10-2001 signature 156 algorithms to sign certificates and CRLs. The signatureAlgorithm 157 field of Certificate or CertificateList indicates the signature 158 algorithm ID, and associated parameters. This section also defines 159 algorithm identifiers and parameters that MUST be used in the 160 signatureAlgorithm field in a Certificate or CertificateList. 162 Signature algorithms are always used conjointly with a one-way hash 163 function GOST R 34.11-94 as indicated in [GOSTR341094] and 164 [GOSTR34102001]. 166 This section identifies OIDs for GOST R 34.10-94 and GOST R 167 34.10-2001 algorithms. The contents of the parameters component for 168 each algorithm may vary and details are provided below for each 169 algorithm separately. 171 2.2.1 Signature Algorithm GOST R 34.10-94 173 GOST R 34.10-94 has been developed by "GUBS of Federal Agency 174 Government Communication and Information" and "All-Russian Scientific 175 and Research Institute of Standardization". This signature algorithm 176 MUST be used conjointly with one-way, collision free hash function 177 GOST R 34.11-94. This document does not contain GOST R 34.10-94 178 standard description, which is fully described in [GOSTR341094] in 179 Russian, and brief description in English could be found in 180 [Schneier95] ch. 20.3, p. 495. 182 The ASN.1 OID used to identify GOST R 34.10-94 signature algorithm in 183 fields signatureAlgorithm in Certificate and CertificateList is: 185 id-CryptoPro-algorithms OBJECT IDENTIFIER ::= 186 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) } 188 id-GostR3411-94-with-GostR3410-94 OBJECT IDENTIFIER ::= 189 { id-CryptoPro-algorithms gostR3411-94-with-gostR3410-94(4)} 191 GostR3410-94-CertificateSignatureAlgorithms 192 ALGORITHM-IDENTIFIER ::= { 193 { NULL IDENTIFIED BY 194 id-GostR3411-94-with-GostR3410-94 } | 195 { GostR3410-94-PublicKeyParameters IDENTIFIED BY 196 id-GostR3411-94-with-GostR3410-94 } } 198 GostR3410-94-PublicKeyParameters are defined in section 2.3.1. 200 When the id-GostR3411-94-with-GostR3410-94 algorithm identifier 201 appears in an AlgorithmIdentifier and parameters are omitted, the 202 parameters from the public key of the signer's certificate MUST be 203 used. If the parameters from the public key of the signer's 204 certificate are also omited, and it's issuer's certificate has the 205 same public key algorithm, parameters from the public key of the 206 issuer's certificate MUST be used, and so on. 208 Signature algorithm GOST R 34.10-94 generates digital signature in 209 the form of a binary 512-bit vector (256||256). That is, the 210 least-significant (1-st) bit of signatureValue BIT STRING contains 211 the least-significant (1-st) bit of , and the most-significant 212 (512th) bit of signatureValue contains the most-significant (256th) 213 bit of . 215 2.2.2 Signature Algorithm GOST R 34.10-2001 217 GOST R 34.10-2001 was developed by "GUBS of Federal Agency Government 218 Communication and Information" and "All-Russian Scientific and 219 Research Institute of Standardization". This signature algorithm 220 MUST be used conjointly with one-way, collision free hash function 221 GOST R 34.11-94. This document does not contain GOST R 34.10-2001 222 standard description, which is fully described in [GOSTR34102001]. 224 The ASN.1 OID used to identify GOST R 34.10-2001 signature algorithm 225 in fields signatureAlgorithm of Certificate and CertificateList is: 227 id-GostR3411-94-with-GostR3410-2001 OBJECT IDENTIFIER ::= 228 { id-CryptoPro-algorithms gostR3411-94-with-gostR3410-2001(3) } 230 GostR3410-2001-CertificateSignatureAlgorithms 231 ALGORITHM-IDENTIFIER ::= { 232 { NULL IDENTIFIED BY 233 id-GostR3411-94-with-GostR3410-2001 } | 234 { GostR3410-2001-PublicKeyParameters IDENTIFIED BY 235 id-GostR3411-94-with-GostR3410-2001 } } 237 GostR3410-2001-PublicKeyParameters are defined in section 2.3.2. 239 When the id-GostR3411-94-with-GostR3410-2001 algorithm identifier 240 appears in an AlgorithmIdentifier and parameters are omitted, the 241 parameters from the public key of the signer's certificate MUST be 242 used. If the parameters from the public key of the signer's 243 certificate are also omited, and it's issuer's certificate has the 244 same public key algorithm, parameters from the public key of the 245 issuer's certificate MUST be used, and so on. 247 Signature algorithm GOST R 34.10-2001 generates digital signature in 248 the form of a binary 512-bit vector (256||256). That is, the 249 least-significant (1-st) bit of signatureValue BIT STRING contains 250 the least-significant (1-st) bit of , and the most-significant 251 (512th) bit of signatureValue contains the most-significant (256th) 252 bit of . 254 2.3 Subject Public Key Algorithms 256 In according to [RFC3280] the certificates may contain a public key 257 for any algorithm. Within the framework of this specification the 258 only GOST R 34.10-94 and GOST R 34.10-2001 public key algorithms 259 defined. The algorithm and associated parameters are definable as OID 260 in certificate through ASN.1 structure AlgorithmIdentifier. 262 This section identifies defines OID and public key parameters for the 263 GOST R 34.10-94 and GOST R 34.10-2001 algorithms. The appropriate CA 264 MUST use the predefined OID issuing certificates containing public 265 keys for these algorithms. The appropriate applications supporting 266 any of these algorithms MUST fully recognize the OID identified in 267 this section 269 2.3.1 GOST R 34.10-94 Keys 271 This section defines OID and parameter encoding for inclusion of GOST 272 R 34.10-94 public key in certificate. Such public key can be used 273 for digital signature validation algorithm GOST R 34.10-94 274 [GOSTR341094], and for key derivation algorithm VKO GOST R 34.10-94 275 [CPALGS]. 277 An assumed cryptographic key usage MAY be specified by keyUsage 278 extension [RFC3280]. The usage of the same key for signature and key 279 derivation is NOT RECOMMENDED, but possible. 281 Public key OID for GOST R 34.10-94 declared in this document is: 283 id-GostR3410-94 OBJECT IDENTIFIER ::= 284 { id-CryptoPro-algorithms gostR3410-94(20) } 286 SubjectPublicKeyInfo.algorithm.algorithm field (see [RFC3280]) for 287 GOST R 34.10-94 keys MUST be id-GostR3410-94; 288 SubjectPublicKeyInfo.algorithm.parameters in this case MUST have the 289 following structure: 291 GostR3410-94-PublicKeyParameters ::= 292 SEQUENCE { 293 publicKeyParamSet 294 OBJECT IDENTIFIER, 295 digestParamSet 296 OBJECT IDENTIFIER, 297 encryptionParamSet 298 OBJECT IDENTIFIER OPTIONAL 299 } 301 where: 302 * publicKeyParamSet - public key parameters identifier for GOST R 303 34.10-94 (see section 8.3 of [CPALGS]) 304 * digestParamSet - parameters identifier for GOST R 34.11-94 (see 305 section 8.2 of [CPALGS]) 306 * encryptionParamSet - optional parameters identifier for GOST 307 28147-89 (see section 8.1 of [CPALGS]) MAY be present in any 308 certificate and MUST be present if keyUsage includes keyAgreement or 309 keyEnchiperment. 311 If GOST R 34.10-94 algorithm parameters are omitted in 312 subjectPublicKeyInfo, and CA signs subject certificate using GOST R 313 34.10-94, then GOST R 34.10-94 parameters taken from 314 subjectPublicKeyInfo field of issuer certificate are applicable to 315 public key of GOST R 34.10-94 subject. That is, cryptographic 316 parameters inheritance takes place. If subjectPublicKeyInfo 317 AlgorithmIdentifier field contain no parameters, but CA sign 318 certificate using signature algorithm different from GOST R 34.10-94, 319 such certificate MUST be rejected by conforming applications. 321 Public key GOST R 34.10-94 MUST be ASN.1 encoded in following way. 323 In GOST R 34.10-94 public key is a number y = a^x (mod p), where a 324 and p - parameters, and y is a bit-vector (1024), at that 325 encoding should present 1024 (BIT STRING) as a vector holding 326 data in a little-endian. At first, a key is presented as an OCTET 327 STRING, and then, being DER-encoded, presented as a BIT STRING. 329 GostR3410-94-PublicKey ::= BIT STRING 331 GostR3410-94-PublicKeyOctetString ::= OCTET STRING 333 If the keyUsage extension is present in an end-entity certificate, 334 which contains a GOST R 34.10-94 public key, the following values MAY 335 be present: 337 digitalSignature; 338 nonRepudiation. 339 keyEncipherment; 340 keyAgreement. 342 If the keyAgreement or keyEnchiperment extension is present in a 343 certificate GOST R 34.10-94 public key, the following values MAY be 344 present as well: 346 encipherOnly; 347 decipherOnly. 349 The keyUsage extension MUST NOT assert both encipherOnly and 350 decipherOnly. 352 If the keyUsage extension is present in an CA or CRL signer 353 certificate which contain a GOST R 34.10-94 public key, the following 354 values MAY be present: 356 digitalSignature; 357 nonRepudiation; 358 keyCertSign; 359 cRLSign. 361 2.3.2 GOST R 34.10-2001 Keys 363 This section defines OID and parameter encoding for inclusion of GOST 364 R 34.10-2001 public key in certificate. Such public key can be used 365 for digital signature validation algorithm GOST R 34.10-2001 366 [GOSTR34102001], and for key derivation algorithm VKO GOST R 367 34.10-2001 [CPALGS]. 369 An assumed cryptographic key usage MAY be specified by keyUsage 370 extension [RFC3280]. The usage of the same key for signature and key 371 derivation is NOT RECOMMENDED, but possible. 373 Public key OID for GOST R 34.10-2001 declared in this document is: 375 id-GostR3410-2001 OBJECT IDENTIFIER ::= 376 { id-CryptoPro-algorithms gostR3410-2001(19) } 378 SubjectPublicKeyInfo.algorithm.algorithm field (see [RFC3280]) for 379 GOST R 34.10-2001 keys MUST be id-GostR3410-2001; 381 SubjectPublicKeyInfo.algorithm.parameters in this case MUST have the 382 following structure: 384 GostR3410-2001-PublicKeyParameters ::= 385 SEQUENCE { 386 publicKeyParamSet 387 OBJECT IDENTIFIER, 388 digestParamSet 389 OBJECT IDENTIFIER, 390 encryptionParamSet 391 OBJECT IDENTIFIER OPTIONAL 392 } 394 where: 395 * publicKeyParamSet - public key parameters identifier for GOST R 396 34.10-2001 (see section 8.4 of [CPALGS]) 397 * digestParamSet - parameters identifier for GOST R 34.11-94 (see 398 section 8.2 of [CPALGS]) 399 * encryptionParamSet - optional parameters identifier for GOST 400 28147-89 (see section 8.1 of [CPALGS]) MAY be present in any 401 certificate and MUST be present if keyUsage includes keyAgreement or 402 keyEnchiperment. 404 If GOST R 34.10-2001 algorithm parameters are omitted in 405 subjectPublicKeyInfo, and CA signs subject certificate using GOST R 406 34.10-2001, then GOST R 34.10-2001 parameters taken from 407 subjectPublicKeyInfo field of issuer certificate are applicable to 408 public key of GOST R 34.10-2001 subject. That is, cryptographic 409 parameters inheritance takes place. If subjectPublicKeyInfo 410 AlgorithmIdentifier field contain no parameters, but CA sign 411 certificate using signature algorithm different from GOST R 412 34.10-2001, such certificate MUST be rejected by conforming 413 applications. 415 GOST R 34.10-2001 public key MUST be ASN.1 encoded in a following 416 way. GOST R 34.10-2001 specifies that public key is a point on the 417 elliptic curve Q = dP, where d is a private key, P is a base point, 418 and Q presents in a way of 512-bit vector (256||256). This 419 vector is DER-encoded as two data blocks. At first, 256 block, 420 then 256 block. subjectPublicKey field BIT STRING type is 421 presented as a taken up object GostR3410-2001-PublicKeyOctetString. 423 At that, least-significant of the first octet 424 (GostR3410-2001-PublicKeyOctetString[0]) corresponds to least- 425 significant (1-st) of vector 256||256 (Yq1 = 426 (GostR3410-2001-PublicKeyOctetString[0] & 1)). 428 Whereas most-significant of 64-th octet 429 (GostR3410-2001-PublicKeyOctetString[63]) corresponds to most- 430 significant (512-d) of vector 256||256 (Xq256 = 431 ((GostR3410-2001-PublicKeyOctetString[63] & 0x80)>>7)). 433 In other words, 256||256 vector is stored in little-endian, 434 that correspond binary vector form and their concatenation in GOST R 435 34.10-2001 ch. 5.3. At first, key is placed in OCTET STRING, than is 436 DER-encoded and placed in BIT STRING. 438 GostR3410-2001-PublicKey ::= BIT STRING 440 GostR3410-2001-PublicKeyOctetString ::= OCTET STRING 442 If the keyUsage extension is present in an end-entity certificate, 443 which conveys a GOST R 34.10-2001 public key, the following values 444 MAY be present: 446 digitalSignature, 447 nonRepudiation, 448 keyEncipherment, 449 keyAgreement. 451 If the keyAgreement or keyEnchiperment extension is present in a 452 certificate, the following values MAY be present: 454 encipherOnly, 455 decipherOnly. 457 The keyUsage extension MUST NOT assert both encipherOnly and 458 decipherOnly. 460 If the keyUsage extension is present in an CA or CRL signer 461 certificate which contain a GOST R 34.10-2001 public key, the 462 following values MAY be present: 464 digitalSignature, 465 nonRepudiation, 466 keyCertSign, 467 cRLSign. 469 3 Security Considerations 471 It is RECCOMENDED, that applications verify signature values and 472 subject public keys to conform to [GOSTR34102001], [GOSTR341094] 473 standards prior to their use. 475 When certificate is used as analogue to a manual signing, in the 476 context of Russian Federal Digital Signature Law [RFDSL], certificate 477 MUST contain keyUsage extension, it MUST be critical, and keyUsage 478 MUST NOT include keyEncipherment and keyAgreement. 480 When certificate validity period (typicaly 5 years for end entities 481 and 7 years for CAs in Russia) is not equal to the private key 482 validity period (typicaly 15 months in Russia) it is RECOMENDED to 483 use private key usage period extension. 485 For security discussion concerning use of algorithm parameters, see 486 section Security Considerations from [CPALGS]. 488 4 References 490 [GOST28147] "Cryptographic Protection for Data Processing Sys- 491 tem", GOST 28147-89, Gosudarstvennyi Standard of 492 USSR, Government Committee of the USSR for Standards, 493 1989. (In Russian); 495 [GOSTR341094] "Information technology. Cryptographic Data Security. 496 Produce and check procedures of Electronic Digital 497 Signatures based on Asymmetric Cryptographic Algo- 498 rithm.", GOST R 34.10-94, Gosudarstvennyi Standard of 499 Russian Federation, Government Committee of the Rus- 500 sia for Standards, 1994. (In Russian); 502 [GOSTR34102001] "Information technology. Cryptographic data security. 503 Signature and verification processes of [electronic] 504 digital signature.", GOST R 34.10-2001, Gosudarstven- 505 nyi Standard of Russian Federation, Government Com- 506 mittee of the Russia for Standards, 2001. (In Rus- 507 sian); 509 [GOSTR341194] "Information technology. Cryptographic Data Security. 510 Hashing function.", GOST R 34.10-94, Gosudarstvennyi 511 Standard of Russian Federation, Government Committee 512 of the Russia for Standards, 1994. (In Russian); 514 [RFDSL] Russian Federal Digital Signature Law, 10 Jan 2002 515 N1-FZ 517 [CPALGS] "Additional cryptographic algorithms for use with 518 GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, 519 and GOST R 34.11-94 algorithms", V. Popov, I. Kurep- 520 kin, S. Leontiev, February 2004, draft-popov-crypto- 521 pro-cpalgs-01.txt work in progress; 523 [Schneier95] B. Schneier, Applied cryptography, second edition, 524 John Wiley & Sons, Inc., 1995; 526 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, 527 "Internet X.509 Public Key Infrastructure Certificate 528 and Certificate Revocation List (CRL) Profile", RFC 529 3280, April 2002. 531 [RFC3279] Algorithms and Identifiers for the Internet X.509 532 Public Key Infrastructure Certificate and Certificate 533 Revocation List (CRL) Profile. L. Bassham, W. 534 Polk, R. Housley. April 2002. 536 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [TLS] The TLS Protocol Version 1.0. T. Dierks, C. Allen. 540 January 1999, RFC 2246. 542 [X.660] ITU-T Recommendation X.660 Information Technology - 543 ASN.1 encoding rules: Specification of Basic Encoding 544 Rules (BER), Canonical Encoding Rules (CER) and Dis- 545 tinguished Encoding Rules (DER), 1997. 547 Acknowledgments 549 This document was created in accordance with "Russian Cryptographic 550 Software Compatibility Agreement", signed by FGUE STC "Atlas", 551 CRYPTO-PRO, Factor-TC, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 552 Cryptocom, R-Alpha. The goal of this agreement is to achieve mutual 553 compatibility of the products and solutions. 555 The authors wish to thank: 557 Microsoft Corporation Russia for provided information about 558 company products and solutions, and also for technical consulting 559 in PKI. 561 RSA Security Russia and Demos Co Ltd for active colaboration and 562 critical help in creation of this document. 564 RSA Security Inc for compatibility testing of the proposed data 565 formats while incorporating them into RSA Keon product. 567 Baltimore Technology plc for compatibility testing of the proposed 568 data formats while incorporating them into UniCERT product. 570 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 571 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative 572 creating this document. 574 This document is based on a contribution of CRYPTO-PRO company. Any 575 substantial use of the text from this document must reference CRYPTO- 576 PRO. CRYPTO-PRO requests that all material mentioning or referencing 577 this document identify this as "CRYPTO-PRO CPPK". 579 Author's Addresses 581 Serguei Leontiev 582 CRYPTO-PRO 583 38, Obraztsova, 584 Moscow, 127018, Russian Federation 585 EMail: lse@cryptopro.ru 587 Dennis Shefanovski 588 DEMOS Co Ltd 589 6/1, Ovchinnikovskaja naberezhnaya, 590 Moscow, 113035, Russian Federation 591 EMail: sdb@dol.ru 593 Alexandr Afanasiev 594 Factor-TC 595 office 711, 14, Presnenskij val, 596 Moscow, 123557, Russian Federation 597 EMail: aaaf@factor-ts.ru 599 Nikolaj Nikishin 600 Infotecs GmbH 601 p/b 35, 80-5, Leningradskij prospekt, 602 Moscow, 125315, Russian Federation 603 EMail: nikishin@infotecs.ru 605 Boleslav Izotov 606 FGUE STC "Atlas" 607 38, Obraztsova, 608 Moscow, 127018, Russian Federation 609 EMail: izotov@stcnet.ru 611 Elena Minaeva 612 MD PREI 613 build 3, 6A, Vtoroj Troitskij per., 614 Moscow, Russian Federation 615 EMail: evminaeva@mo.msk.ru 617 Serguei Murugov 618 R-Alpha 619 4/1, Raspletina, 620 Moscow, 123060, Russian Federation 621 EMail: msm@office.ru 623 Igori Ustinov 624 Cryptocom 625 office 239, 51, Leninskij prospekt, 626 Moscow, 119991, Russian Federation 627 EMail: igus@cryptocom.ru 629 Anatolij Erkin 630 SPRCIS (SPbRCZI) 631 1, Obrucheva, 632 St.Petersburg, 195220, Russian Federation 633 EMail: erkin@nevsky.net 635 Full Copyright Statement 637 Copyright (C) The Internet Society (2003). All Rights Reserved. 639 This document and translations of it may be copied and furnished to 640 others, and derivative works that comment on or otherwise explain it 641 or assist in its implementation may be prepared, copied, published 642 and distributed, in whole or in part, without restriction of any 643 kind, provided that the above copyright notice and this paragraph are 644 included on all such copies and derivative works. However, this 645 document itself may not be modified in any way, such as by removing 646 the copyright notice or references to the Internet Society or other 647 Internet organizations, except as needed for the purpose of 648 developing Internet standards in which case the procedures for 649 copyrights defined in the Internet Standards process must be 650 followed, or as required to translate it into languages other than 651 English. 653 The limited permissions granted above are perpetual and will not be 654 revoked by the Internet Society or its successors or assigns. 656 This document and the information contained herein is provided on an 657 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 658 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 659 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 660 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 661 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.