idnits 2.17.1 draft-ietf-smime-gost-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1150. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1142), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 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. 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. (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 (February 5, 2005) is 7018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'GOSTR3411' is mentioned on line 124, but not defined -- Looks like a reference, but probably isn't: '0' on line 883 == Missing Reference: 'RFC 2633' is mentioned on line 420, but not defined ** Obsolete undefined reference: RFC 2633 (Obsoleted by RFC 3851) -- Looks like a reference, but probably isn't: '1' on line 571 == Unused Reference: 'GOSTR341194' is defined on line 993, but no explicit reference was found in the text == Unused Reference: 'RFC 3280' is defined on line 1001, but no explicit reference was found in the text == Unused Reference: 'RFC 3279' is defined on line 1006, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) == Outdated reference: A later version (-05) exists of draft-ietf-pkix-gost-cppk-02 == Outdated reference: A later version (-04) exists of draft-popov-cryptopro-cpalgs-02 Summary: 18 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group Serguei Leontiev, CRYPTO-PRO 3 Internet Draft Gregory Chudov, CRYPTO-PRO 4 Expires August 5, 2005 February 5, 2005 5 Intended Category: Informational 7 Using the GOST 28147-89, GOST R 34.11-94, 8 GOST R 34.10-94 and GOST R 34.10-2001 algorithms with the 9 Cryptographic Message Syntax (CMS) 11 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 20 This document is an Internet Draft and is subject to all provisions 21 of Section 10 of RFC2026. Internet Drafts are working documents of 22 the Internet Engineering Task Force (IETF), its areas, and its 23 working groups. Note that other groups may also distribute working 24 documents as Internet Drafts. Internet Drafts are draft documents 25 valid for a maximum of 6 months and may be updated, replaced, or 26 obsoleted by other documents at any time. It is inappropriate to use 27 Internet Drafts as reference material or to cite them other than as a 28 "work in progress". 30 The list of current Internet Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 This document describes the conventions for using cryptographic 41 algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 42 34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is 43 used for digital signature, digest, authentication and encryption 44 arbitrary message contents. 46 Table of Contents 47 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 48 1.2 Terminology. . . . . . . . . . . . . . . . . . . . . . . 3 49 2 Message Digest Algorithms. . . . . . . . . . . . . . . . 3 50 2.1 Message Digest Algorithm GOST R 34.11-94 . . . . . . . . 3 51 3 Signature Algorithms . . . . . . . . . . . . . . . . . . 4 52 3.1 Signature Algorithm GOST R 34.10-94. . . . . . . . . . . 4 53 3.2 Signature Algorithm GOST R 34.10-2001. . . . . . . . . . 4 54 4 Key Management Algorithms. . . . . . . . . . . . . . . . 5 55 4.1 Key Agreement Algorithms . . . . . . . . . . . . . . . . 5 56 4.1.1 Key Agreement Algorithm Based on GOST R 34.10-94/2001 57 Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2 Key Transport Algorithms. .. . . . . . . . . . . . . . . 6 59 4.2.1 Key Transport Algorithm Based on GOST R 34.10-94/2001 60 Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 5 Content Encryption Algorithms. . . . . . . . . . . . . . 8 62 5.1 Key-Encryption Key Algorithm GOST 28147-89 . . . . . . . 8 63 6 MAC Algorithms . . . . . . . . . . . . . . . . . . . . . 8 64 6.1 HMAC with GOST R 34.11-94. . . . . . . . . . . . . . . . 9 65 7 Using with S/MIME. . . . . . . . . . . . . . . . . . . . 9 66 7.1 Parameter micalg . . . . . . . . . . . . . . . . . . . . 9 67 7.2 Atribute SMIMECapabilities . . . . . . . . . . . . . . . 9 68 8 Security Considerations. . . . . . . . . . . . . . . . . 10 69 9 Appendix Examples. . . . . . . . . . . . . . . . . . . . 11 70 9.1 Signed message . . . . . . . . . . . . . . . . . . . . . 11 71 9.2 Enveloped message using Key Agreement. . . . . . . . . . 12 72 9.3 Enveloped message using Key Transport. . . . . . . . . . 15 73 10 Appendix ASN.1 Modules . . . . . . . . . . . . . . . . . 17 74 10.1 GostR3410-EncryptionSyntax . . . . . . . . . . . . . . . 19 75 10.2 GostR3410-94-SignatureSyntax . . . . . . . . . . . . . . 21 76 10.3 GostR3410-2001-SignatureSyntax . . . . . . . . . . . . . 22 77 11 References . . . . . . . . . . . . . . . . . . . . . . . 23 78 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 25 79 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 25 80 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 27 82 1 Introduction 84 The Cryptographic Message Syntax [CMS] is used for digital signature, 85 digest, authentication and encryption arbitrary message contents. 86 This companion specification describes the usage of cryptographic 87 algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001 and hash 88 algorithm GOST R 34.11-94 in CMS, proposed by CRYPTO-PRO Company for 89 "Russian Cryptographic Software Compatibility Agreement" community. 90 This document does not describe those cryptographic algorithms; they 91 are defined in corresponding national standards. 93 The CMS values are generated using ASN.1 [X.208-88], using BER- 94 encoding [X.209-88]. Algorithm identifiers (which include ASN.1 95 object identifiers) identify cryptographic algorithms, and some 96 algorithms require additional parameters. When needed, parameters 97 are specified with an ASN.1 structure. The algorithm identifier for 98 each algorithm is specified, and when needed, the parameter structure 99 is specified. The fields in the CMS employed by each algorithm are 100 identified. 102 1.2 Terminology 104 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 105 SHOULD NOT, RECOMMENDED, and MAY are to be interpreted as described 106 in [RFC 2119]. 108 2 Message Digest Algorithms 110 This section specifies the conventions for using digest algorithm 111 GOST R 34.11-94 employed by CMS. 113 Digest values are located in the DigestedData digest field and the 114 Message Digest authenticated attribute. In addition, digest values 115 are input to signature algorithms. 117 2.1 Message Digest Algorithm GOST R 34.11-94 119 Hash function GOST R 34.11-94 has been developed by "GUBS of Federal 120 Agency Government Communication and Information" and "All-Russian 121 Scientific and Research Institute of Standardization". The algorithm 122 GOST R 34.11-94 produces a 256-bit hash value of the arbitrary finite 123 bit length input. This document does not contain GOST R 34.11-94 full 124 specification, which can be found in [GOSTR3411] in Russian. 125 [Schneier95] ch. 18.11, p. 454. contain the brief technical 126 description in English. 128 id-CryptoPro OBJECT IDENTIFIER ::= 129 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) } 131 id-CryptoPro-algorithms OBJECT IDENTIFIER ::= 132 id-CryptoPro 134 The hash algorithm GOST R 34.11-94 has the following identifier: 136 id-GostR3411-94 OBJECT IDENTIFIER ::= 137 { id-CryptoPro-algorithms gostr3411(9) } 139 The AlgorithmIdentifier parameters field MUST be present, and the 140 parameters field MUST contain NULL. Implementations MAY accept the 141 GOST R 34.11-94 AlgorithmIdentifiers with absent parameters as well 142 as NULL parameters. 144 This function is always used with default parameter set 145 gostR3411CryptoProParamSetAI (see section 8.2 of [CPALGS]). 147 When Message Digest authenticated attribute is present, DigestedData 148 digest contains 32-byte digest in little-endian representation: 150 GostR3411-94-Digest ::= OCTET STRING (SIZE (32)) 152 3 Signature Algorithms 154 This section specifies the CMS procedures for GOST R 34.10-94 and 155 GOST R 34.10-2001 signature algorithms. 157 Signature algorithm identifiers are located in the SignerInfo 158 signatureAlgorithm field of SignedData. Also, signature algorithm 159 identifiers are located in the SignerInfo signatureAlgorithm field of 160 countersignature attributes. 162 Signature values are located in the SignerInfo signature field of 163 SignedData. Also, signature values are located in the SignerInfo 164 signature field of countersignature attributes. 166 3.1 Signature Algorithm GOST R 34.10-94 168 GOST R 34.10-94 has been developed by "GUBS of Federal Agency 169 Government Communication and Information" and "All-Russian Scientific 170 and Research Institute of Standardization". This signature algorithm 171 MUST be used conjointly with GOST R 34.11-94 message digest 172 algorithm. This document does not contain GOST R 34.10-94 standard 173 description, which is fully described in [GOSTR341094] in Russian, 174 and brief description in English could be found in [Schneier95] ch. 175 20.3, p. 495. 177 For a signature algorithm identifier, GOST R 34.10-94 public key 178 algorithm OID [CPPK] is used: 180 id-GostR3410-94-signatute OBJECT IDENTIFIER ::= id-GostR3410-94 182 Signature algorithm GOST R 34.10-94 generates digital signature in 183 the form of a binary 512-bit vector (256||256). 184 signatureValue contains its little endian representation. 186 GostR3410-94-Signature ::= OCTET STRING (SIZE (64)) 188 3.2 Signature Algorithm GOST R 34.10-2001 190 GOST R 34.10-2001 has been developed by "GUBS of Federal Agency 191 Government Communication and Information" and "All-Russian Scientific 192 and Research Institute of Standardization". This signature algorithm 193 MUST be used conjointly with GOST R 34.11-94. This document does not 194 contain GOST R 34.10-2001 standard description, which is fully 195 described in [GOSTR34102001]. 197 For a signature algorithm identifier, GOST R 34.10-2001 public key 198 algorithm OID [CPPK] is used: 200 id-GostR3410-2001-signatute OBJECT IDENTIFIER ::= id-GostR3410-2001 202 Signature algorithm GOST R 34.10-2001 generates digital signature in 203 the form of a binary 512-bit vector (256||256). 204 signatureValue contains its little endian representation. 206 GostR3410-2001-Signature ::= OCTET STRING (SIZE (64)) 208 4 Key Management Algorithms 210 This chapter describes the key agreement and key transport 211 algorithms, based on VKO GOST R 34.10-94 and VKO GOST R 34.10-2001 212 key derivation algorithms, CryptoPro and GOST 28147-89 key wrap 213 algorithms, described in [CPALGS]. They MUST be used only with 214 content encryption algorithm GOST 28147-89, defined in section 5 of 215 this document. 217 4.1 Key Agreement Algorithms 219 This section specifies the conventions employed by CMS 220 implementations that support key agreement using both VKO GOST R 221 34.10-94 and VKO GOST R 34.10-2001 algorithms, described in [CPALGS]. 223 Key agreement algorithm identifiers are located in the EnvelopedData 224 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 225 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 226 keyEncryptionAlgorithm fields. 228 Wrapped content-encryption keys are located in the EnvelopedData 229 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 230 encryptedKey field. Wrapped message-authentication keys are located 231 in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 232 RecipientEncryptedKeys encryptedKey field. 234 4.1.1 Key Agreement Algorithm Based on GOST R 34.10-94/2001 Public Keys 236 The EnvelopedData RecipientInfos KeyAgreeRecipientInfo field is used 237 as follows: 239 version MUST be 3. 241 originator MUST be the originatorKey alternative. The 242 originatorKey algorithm field MUST contain the object identifier 243 id-GostR3410-94 or id-GostR3410-2001 and corresponding parameters 244 (defined in sections 2.3.1, 2.3.2 of [CPPK]). 246 The originatorKey publicKey field MUST contain the sender's public 247 key. 249 keyEncryptionAlgorithm algorithm field MUST be identical to the 250 recipient public key algorithm identifier. 252 keyEncryptionAlgorithm parameters MUST encapsulate 253 GostR3410-TransportParameters, containing encryptionParamSet (GOST 254 28147-89 algorithm parameters used for key encryption), and UKM. 255 GostR3410-TransportParameters ephemeralPublicKey MUST NOT be 256 present. 258 GostR3410-TransportParameters ::= SEQUENCE { 259 encryptionParamSet OBJECT IDENTIFIER, 260 ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL, 261 ukm OCTET STRING 262 } 264 KeyAgreeRecipientInfo ukm MUST be absent, 265 GostR3410-TransportParameters ukm is used instead and is not 266 optional. 268 encryptedKey MUST encapsulate Gost28147-89-EncryptedKey, where 269 maskKey MUST be absent. 271 Gost28147-89-EncryptedKey ::= SEQUENCE { 272 encryptedKey Gost28147-89-Key, 273 maskKey [0] IMPLICIT Gost28147-89-Key 274 OPTIONAL, 275 macKey Gost28147-89-MAC 276 } 278 Using the secret key, corresponding to originatorKey publicKey, and 279 recipient's public key, algorithm VKO GOST R 34.10-94 or VKO GOST R 280 34.10-2001 (described in [CPALGS]) is applied to produce KEK. 282 Then key wrap algorithm, specified by encryptionParamSet, is applied 283 to produce CEK_ENC, CEK_MAC, and IV. GostR3410-TransportParameters 284 encryptionParamSet is used for all encryption operations. 286 The resulting encrypted key (CEK_ENC) is placed in 287 Gost28147-89-EncryptedKey encryptedKey field, it's mac (CEK_MAC) is 288 placed in Gost28147-89-EncryptedKey macKey field, and synchrovector 289 (IV) is placed in GostR3410-TransportParameters ukm field. 291 4.2 Key Transport Algorithms 293 This section specifies the conventions employed by CMS 294 implementations that support key transport using both VKO GOST R 295 34.10-94 and VKO GOST R 34.10-2001 algorithms, described in [CPALGS]. 297 Key transport algorithm identifiers are located in the EnvelopedData 298 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. 300 Key transport encrypted content-encryption keys are located in the 301 EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 302 field. 304 4.2.1 Key Transport Algorithm Based on GOST R 34.10-94/2001 Public Keys 306 The EnvelopedData RecipientInfos KeyTransRecipientInfo field is used 307 as follows: 309 version MUST be 0 or 3. 311 keyEncryptionAlgorithm and parameters MUST be identical to the 312 recipient public key algorithm and parameters. 314 encryptedKey encapsulates GostR3410-KeyTransport, which consists 315 of encrypted content-encryption key, it's MAC, GOST 28147-89 316 algorithm parameters used for key encryption, sender's ephemeral 317 public key, and UKM (UserKeyingMaterial, see [CMS], 10.2.6). 319 transportParameters MUST be present. 321 ephemeralPublicKey MUST be present, and its parameters, if 322 present, MUST be equal to the recipient public key parameters; 324 GostR3410-KeyTransport ::= SEQUENCE { 325 sessionEncryptedKey Gost28147-89-EncryptedKey, 326 transportParameters 327 [0] IMPLICIT GostR3410-TransportParameters OPTIONAL 328 } 330 GostR3410-TransportParameters ::= SEQUENCE { 331 encryptionParamSet OBJECT IDENTIFIER, 332 ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL, 333 ukm OCTET STRING 334 } 336 Using the secret key, corresponding to GostR3410-TransportParameters 337 ephemeralPublicKey, and recipient's public key, algorithm VKO GOST R 338 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied 339 to produce KEK. 341 Then key wrap algorithm, specified by encryptionParamSet, is applied 342 to produce CEK_ENC, CEK_MAC, and IV. GostR3410-TransportParameters 343 encryptionParamSet is used for all encryption operations. 345 The resulting encrypted key (CEK_ENC) is placed in 346 Gost28147-89-EncryptedKey encryptedKey field, it's mac (CEK_MAC) is 347 placed in Gost28147-89-EncryptedKey macKey field, and synchrovector 348 (IV) is placed in GostR3410-TransportParameters ukm field. 350 5 Content Encryption Algorithms 352 This section specifies the conventions employed by CMS 353 implementations that support content encryption using GOST 28147-89. 355 Content encryption algorithm identifiers are located in the 356 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 357 EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 359 Content encryption algorithms are used to encipher the content 360 located in the EnvelopedData EncryptedContentInfo encryptedContent 361 field and the EncryptedData EncryptedContentInfo encryptedContent 362 field. 364 5.1 Content Encryption Algorithm GOST 28147-89 366 This section specifies the use of GOST 28147-89 algorithm for data 367 encipherment. 369 GOST 28147-89 is fully described in [GOST28147] (in Russian). 371 This document specifies the following OID for this algorithm: 373 id-Gost28147-89 OBJECT IDENTIFIER ::= 374 { id-CryptoPro-algorithms gost28147-89(21) } 376 Algorithm parameters MUST be present and have the following 377 structure: 379 Gost28147-89-Parameters ::= 380 SEQUENCE { 381 iv Gost28147-89-IV, 382 encryptionParamSet OBJECT IDENTIFIER 383 } 385 Gost28147-89-IV ::= OCTET STRING (SIZE (8)) 387 encryptionParamSet specifies the set of corresponding 388 Gost28147-89-ParamSetParameters (see section 8.1 of [CPALGS]) 390 6 MAC Algorithms 392 This section specifies the conventions employed by CMS 393 implementations that support the message authentication code (MAC) 394 based on GOST R 34.11-94 HMAC. This MAC can also be used as a 395 pseudo-random function with 256 bits (32 bytes) internal state size, 396 which can be used to derive keys. 398 MAC algorithm identifiers are located in the AuthenticatedData 399 macAlgorithm field. 401 MAC values are located in the AuthenticatedData mac field 403 6.1 HMAC with GOST R 34.11-94 405 HMAC_GOSTR3411 (K,text) function is based on hash function GOST R 406 34.11-94, as defined in [HMAC]. See [CPALGS], section 3 for details. 408 OID for HMAC_GOSTR3411, defined by this document: 410 id-HMACGostR3411-94 OBJECT IDENTIFIER ::= 411 { id-CryptoPro-algorithms hmacgostr3411(10) } 413 This algorithm has the same parameters, as GOST R 34.11-94 digest 414 algorithm, and uses the same OIDs for their identification (see 415 [CPPK]). 417 7 Using with S/MIME 419 This section defines use of the algorithms defined in this document 420 together with S/MIME [RFC 2633]. 422 7.1 Parameter micalg 424 When using the algorithms defined in this document, micalg parameter 425 SHOULD be set to "gostr3411-94" or MAY be set to "unknown". 427 7.2 Attribute SMIMECapabilities 429 S/MIME message, which uses the algorithms defined in this document, 430 should contain the list of algorithm identifiers for digest and 431 encryption algorithms, defined in this document, with their 432 parameters, in it's SMIMECapabilities attribute. 434 The SMIMECapability value to indicate support for the GOST R 34.11-94 435 digest algorithm is the SEQUENCE with the capabilityID field 436 containing the object identifier id-GostR3411-94 and no parameters. 437 The DER encoding is: 439 30 08 06 06 2A 85 03 02 02 09 441 The SMIMECapability value to indicate support for the GOST 28147-89 442 encryption algorithm is the SEQUENCE with the capabilityID field 443 containing the object identifier id-Gost28147-89 and no parameters. 444 The DER encoding is: 446 30 08 06 06 2A 85 03 02 02 09 448 If the sender wishes to indicate support for specific parameter set, 449 SMIMECapability parameters MUST contain Gost28147-89-Parameters 450 structure. Recipient MUST ignore the Gost28147-89-Parameters iv 451 field, and assume that the sender supports parameters, specified in 452 Gost28147-89-Parameters encryptionParamSet field. 454 The DER encoding for the SMIMECapability, indicating support for GOST 455 28147-89 with id-Gost28147-89-CryptoPro-A-ParamSet (see [CPALGS]) is: 457 30 1D 06 06 2A 85 03 02 02 15 30 13 04 08 00 00 458 00 00 00 00 00 00 06 07 2A 85 03 02 02 1F 01 460 8 Security Considerations 462 Conforming applications MUST use unique values for ukm and iv. 463 Recipients MAY verify that ukm and iv, specified by the sender, are 464 unique. 466 It is RECCOMENDED, that applications verify signature values and 467 subject public keys to conform to [GOSTR34102001], [GOSTR341094] 468 standards prior to their use. 470 Cryptographic algorithm parameters affect rigidity of algorithms. 471 The use of parameters, which are not listed in [CPALGS], is NOT 472 RECOMENDED (see Security Considerations section of [CPALGS]). 474 Use of the same key for signature and key derivation is NOT 475 RECOMMENDED. When signed CMS document is used as analogue to a 476 manual signing, in the context of Russian Federal Digital Signature 477 Law [RFDSL], signer certificate MUST contain keyUsage extension, it 478 MUST be critical, and keyUsage MUST NOT include keyEncipherment or 479 keyAgreement. Application SHOULD be submited for examination by an 480 authorized agency in appropriate levels of target_of_evaluation 481 (TOE), according to [RFDSL], [RFLLIC] and [CRYPTOLIC]. 483 9 Appendix Examples 485 9.1 Signed message 487 0 30 296: SEQUENCE { 488 4 06 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 489 15 A0 281: [0] { 490 19 30 277: SEQUENCE { 491 23 02 1: INTEGER 1 492 26 31 12: SET { 493 28 30 10: SEQUENCE { 494 30 06 6: OBJECT IDENTIFIER id_GostR3411_94 ( 1 2 643 2 2 9) 495 38 05 0: NULL 496 : } 497 : } 498 40 30 27: SEQUENCE { 499 42 06 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 500 53 A0 14: [0] { 501 55 04 12: OCTET STRING 502 : 73 61 6D 70 6C 65 20 74 65 78 74 0A 503 : } 504 : } 505 69 31 228: SET { 506 72 30 225: SEQUENCE { 507 75 02 1: INTEGER 1 508 78 30 129: SEQUENCE { 509 81 30 109: SEQUENCE { 510 83 31 31: SET { 511 85 30 29: SEQUENCE { 512 87 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 513 92 0C 22: UTF8String 'GostR3410-2001 example' 514 : } 515 : } 516 116 31 18: SET { 517 118 30 16: SEQUENCE { 518 120 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 519 125 0C 9: UTF8String 'CryptoPro' 520 : } 521 : } 522 136 31 11: SET { 523 138 30 9: SEQUENCE { 524 140 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 525 145 13 2: PrintableString 'RU' 526 : } 527 : } 528 149 31 41: SET { 529 151 30 39: SEQUENCE { 530 153 06 9: OBJECT IDENTIFIER 531 : emailAddress (1 2 840 113549 1 9 1) 532 164 16 26: IA5String 'GostR3410-2001@example.com' 533 : } 534 : } 535 : } 536 192 02 16: INTEGER 537 : 48 E9 54 A5 CF E9 69 F5 C9 5C F7 55 E7 83 41 AF 538 : } 539 210 30 10: SEQUENCE { 540 212 06 6: OBJECT IDENTIFIER 541 : id_GostR3411_94 ( 1 2 643 2 2 9) 542 220 05 0: NULL 543 : } 544 222 30 10: SEQUENCE { 545 224 06 6: OBJECT IDENTIFIER 546 : id_GostR3410_2001 ( 1 2 643 2 2 19) 547 232 05 0: NULL 548 : } 549 234 04 64: OCTET STRING 550 : 6D C4 2D E5 C8 E8 8C 2E E0 77 AA 8C 75 0F C4 18 551 : 09 0B 8A 23 D4 50 F3 0E 2B 6F 59 E8 8D 54 5D F9 552 : A7 4D 36 41 48 36 22 17 32 A1 F5 CA 1C FD 56 FE 553 : C4 53 47 0D 5D 24 B9 88 70 D9 F6 0A 8A 54 DB 54 554 : } 555 : } 556 : } 557 : } 558 : } 560 9.2 Enveloped message using Key Agreement 562 0 30 452: SEQUENCE { 563 4 06 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 564 15 A0 437: [0] { 565 19 30 433: SEQUENCE { 566 23 02 1: INTEGER 2 567 26 31 377: SET { 568 30 A1 373: [1] { 569 34 02 1: INTEGER 3 570 37 A0 168: [0] { 571 40 A1 165: [1] { 572 43 30 28: SEQUENCE { 573 45 06 6: OBJECT IDENTIFIER 574 : GOST R 34.10-94 (1 2 643 2 2 20) 575 53 30 18: SEQUENCE { 576 55 06 7: OBJECT IDENTIFIER '1 2 643 2 2 32 2' 577 64 06 7: OBJECT IDENTIFIER '1 2 643 2 2 30 1' 578 : } 579 : } 580 73 03 132: BIT STRING 0 unused bits, encapsulates { 581 77 04 128: OCTET STRING 582 : 4D FC D3 19 15 65 E6 A8 CD 2E F4 94 1D E9 1D 8E 583 : 38 74 EF 67 CD 39 59 DB B3 F4 07 63 A0 A1 0D 72 584 : 1B 88 9A DB FC 0A C6 D6 27 1D 0A 40 8A 4E C7 E8 585 : FE 5B 36 C9 B9 A2 71 13 89 29 09 C7 73 AD 7E 07 586 : CD AB FA 4B FA FC 0D 1B 66 D2 60 49 87 B0 B2 ED 587 : 13 EE BA D2 2F BB 4B E5 DD 84 B7 65 85 10 49 8A 588 : 01 A5 F5 4C 24 FB 49 AB 1D 5D D8 A6 F4 F4 27 9B 589 : F7 F7 97 7A F9 D9 7B DB F5 A0 29 F6 8D C9 AB 46 590 : } 591 : } 592 : } 593 208 30 29: SEQUENCE { 594 210 06 6: OBJECT IDENTIFIER GOST R 34.10-94 (1 2 643 2 2 20) 595 218 30 19: SEQUENCE { 596 220 06 7: OBJECT IDENTIFIER '1 2 643 2 2 31 1' 597 229 04 8: OCTET STRING 598 : 97 27 17 E0 05 B0 D0 5A 599 : } 600 : } 601 239 30 165: SEQUENCE { 602 242 30 162: SEQUENCE { 603 245 30 116: SEQUENCE { 604 247 30 102: SEQUENCE { 605 249 31 11: SET { 606 251 30 9: SEQUENCE { 607 253 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 608 258 13 2: PrintableString 'RU' 609 : } 610 : } 611 262 31 15: SET { 612 264 30 13: SEQUENCE { 613 266 06 3: OBJECT IDENTIFIER localityName (2 5 4 7) 614 271 13 6: PrintableString 'Moscow' 615 : } 616 : } 617 279 31 23: SET { 618 281 30 21: SEQUENCE { 619 283 06 3: OBJECT IDENTIFIER 620 : organizationName (2 5 4 10) 621 288 13 14: PrintableString 'OOO Crypto-Pro' 622 : } 623 : } 624 304 31 20: SET { 625 306 30 18: SEQUENCE { 626 308 06 3: OBJECT IDENTIFIER 627 : organizationalUnitName (2 5 4 11) 628 313 13 11: PrintableString 'Development' 629 : } 630 : } 631 326 31 23: SET { 632 328 30 21: SEQUENCE { 633 330 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 634 335 13 14: PrintableString 'CP CSP Test CA' 635 : } 636 : } 637 : } 638 351 02 10: INTEGER 639 : 32 C7 ED 5B 00 03 00 00 12 82 640 : } 641 363 04 42: OCTET STRING, encapsulates { 642 365 30 40: SEQUENCE { 643 367 04 32: OCTET STRING 644 : 57 22 EF 5F 03 7C AF AD 74 7E 0C C4 52 9F 0D 96 645 : F2 5B 42 23 0D 6A EC 7A 98 90 7F CC D8 2F E5 72 646 401 04 4: OCTET STRING 647 : C6 E0 DE 69 648 : } 649 : } 650 : } 651 : } 652 : } 653 : } 654 407 30 47: SEQUENCE { 655 409 06 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 656 420 30 29: SEQUENCE { 657 422 06 6: OBJECT IDENTIFIER GOST 28147-89 (1 2 643 2 2 21) 658 430 30 19: SEQUENCE { 659 432 04 8: OCTET STRING 660 : BF 68 D1 74 95 19 F0 13 661 442 06 7: OBJECT IDENTIFIER '1 2 643 2 2 31 1' 662 : } 663 : } 664 451 80 3: [0] 665 : B1 7F 12 666 : } 667 : } 668 : } 669 : } 671 9.3 Enveloped message using Key Transport 673 0 30 468: SEQUENCE { 674 4 06 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 676 15 A0 453: [0] { 677 19 30 449: SEQUENCE { 678 23 02 1: INTEGER 0 679 26 31 393: SET { 680 30 30 389: SEQUENCE { 681 34 02 1: INTEGER 0 682 37 30 116: SEQUENCE { 683 39 30 102: SEQUENCE { 684 41 31 11: SET { 685 43 30 9: SEQUENCE { 686 45 06 3: OBJECT IDENTIFIER countryName (2 5 4 6) 687 50 13 2: PrintableString 'RU' 688 : } 689 : } 690 54 31 15: SET { 691 56 30 13: SEQUENCE { 692 58 06 3: OBJECT IDENTIFIER localityName (2 5 4 7) 693 63 13 6: PrintableString 'Moscow' 694 : } 695 : } 696 71 31 23: SET { 697 73 30 21: SEQUENCE { 698 75 06 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 699 80 13 14: PrintableString 'OOO Crypto-Pro' 700 : } 701 : } 702 96 31 20: SET { 703 98 30 18: SEQUENCE { 704 100 06 3: OBJECT IDENTIFIER 705 : organizationalUnitName (2 5 4 11) 706 105 13 11: PrintableString 'Development' 707 : } 708 : } 709 118 31 23: SET { 710 120 30 21: SEQUENCE { 711 122 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 712 127 13 14: PrintableString 'CP CSP Test CA' 713 : } 714 : } 715 : } 716 143 02 10: INTEGER 717 : 1A 04 13 2F 00 03 00 00 0F 61 718 : } 719 155 30 28: SEQUENCE { 720 157 06 6: OBJECT IDENTIFIER GOST R 34.10-94 (1 2 643 2 2 20) 721 165 30 18: SEQUENCE { 722 167 06 7: OBJECT IDENTIFIER '1 2 643 2 2 32 2' 723 176 06 7: OBJECT IDENTIFIER '1 2 643 2 2 30 1' 724 : } 725 : } 726 185 04 235: OCTET STRING, encapsulates { 727 188 30 232: SEQUENCE { 728 191 30 40: SEQUENCE { 729 193 04 32: OCTET STRING 730 : 6B B6 75 7D 48 FD FC 6C B1 51 48 4F 0D 92 1F B0 731 : 5D 3A 93 11 DC 8A 13 0D 42 77 6C DC 1A 5E 87 F7 732 227 04 4: OCTET STRING 733 : 0A A3 26 A0 734 : } 735 233 A0 187: [0] { 736 236 06 7: OBJECT IDENTIFIER '1 2 643 2 2 31 1' 737 245 A0 165: [0] { 738 248 30 28: SEQUENCE { 739 250 06 6: OBJECT IDENTIFIER 740 : GOST R 34.10-94 (1 2 643 2 2 20) 741 258 30 18: SEQUENCE { 742 260 06 7: OBJECT IDENTIFIER '1 2 643 2 2 32 2' 743 269 06 7: OBJECT IDENTIFIER '1 2 643 2 2 30 1' 744 : } 745 : } 746 278 03 132: BIT STRING 0 unused bits, encapsulates { 747 282 04 128: OCTET STRING 748 : 47 A6 19 5E D6 FF E2 6A 6C 32 94 9D 6D 8C 1A 82 749 : C2 C4 0D 73 09 4E 01 3B B0 32 FE EE 79 1F C7 CC 750 : DB 27 B0 52 4F E1 10 B1 26 B9 22 51 37 64 F2 06 751 : 33 13 00 D0 31 3F E4 B6 D2 D6 F7 31 B9 63 4F 02 752 : 05 DD 16 E1 AD 0E E4 B7 CC B8 89 D1 20 D3 EA 45 753 : 53 02 8C 03 21 7C F2 0C BE BB 0D 7F 4E 04 E5 A5 754 : 3D F6 7F 2A 1E 17 40 59 4D 9D C5 4A ED 03 15 93 755 : B9 76 E6 41 BC 3B 70 18 90 B7 4A 7C 8F 4B 06 7D 756 : } 757 : } 758 413 04 8: OCTET STRING 759 : CA CD 7B 87 B9 60 17 68 760 : } 761 : } 762 : } 763 : } 764 : } 765 423 30 47: SEQUENCE { 766 425 06 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 767 436 30 29: SEQUENCE { 768 438 06 6: OBJECT IDENTIFIER GOST 28147-89 (1 2 643 2 2 21) 769 446 30 19: SEQUENCE { 770 448 04 8: OCTET STRING 771 : 56 9C 94 5C 37 0F B2 59 773 458 06 7: OBJECT IDENTIFIER '1 2 643 2 2 31 1' 774 : } 775 : } 776 467 80 3: [0] 777 : E5 CE CA 778 : } 779 : } 780 : } 781 : } 783 10 Appendix ASN.1 Modules 785 Additional ASN.1 modules, referenced here, can be found in [CPALGS]. 787 10.1 GostR3410-EncryptionSyntax 789 GostR3410-EncryptionSyntax 790 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 791 other(1) modules(1) gostR3410-EncryptionSyntax(5) 2 } 792 DEFINITIONS ::= 793 BEGIN 794 -- EXPORTS All -- 795 -- The types and values defined in this module are exported for 796 -- use in the other ASN.1 modules contained within the Russian 797 -- Cryptography "GOST" & "GOST R" Specifications, and for the use 798 -- of other applications which will use them to access Russian 799 -- Cryptography services. Other applications may use them for 800 -- their own purposes, but this will not constrain extensions and 801 -- modifications needed to maintain or improve the Russian 802 -- Cryptography service. 803 IMPORTS 804 id-CryptoPro-algorithms, 805 gost28147-89-EncryptionSyntax, 806 gostR3410-94-PKISyntax, 807 gostR3410-2001-PKISyntax, 808 ALGORITHM-IDENTIFIER, 809 cryptographic-Gost-Useful-Definitions 810 FROM Cryptographic-Gost-Useful-Definitions 811 { iso(1) member-body(2) ru(643) rans(2) 812 cryptopro(2) other(1) modules(1) 813 cryptographic-Gost-Useful-Definitions(0) 1 } 814 id-GostR3410-94, 815 GostR3410-94-PublicKeyParameters, 816 GostR3410-94-PublicKeyAlgorithms 817 FROM GostR3410-94-PKISyntax gostR3410-94-PKISyntax 818 id-GostR3410-2001, 819 GostR3410-2001-PublicKeyParameters, 820 GostR3410-2001-PublicKeyAlgorithms 821 FROM GostR3410-2001-PKISyntax gostR3410-2001-PKISyntax 822 id-Gost28147-89-TestParamSet, 823 id-Gost28147-89-CryptoPro-A-ParamSet, 824 id-Gost28147-89-CryptoPro-B-ParamSet, 825 id-Gost28147-89-CryptoPro-C-ParamSet, 826 id-Gost28147-89-CryptoPro-D-ParamSet, 827 id-Gost28147-89-CryptoPro-Simple-A-ParamSet, 828 id-Gost28147-89-CryptoPro-Simple-B-ParamSet, 829 id-Gost28147-89-CryptoPro-Simple-C-ParamSet, 830 id-Gost28147-89-CryptoPro-Simple-D-ParamSet, 831 Gost28147-89-EncryptedKey 832 FROM Gost28147-89-EncryptionSyntax 833 gost28147-89-EncryptionSyntax 834 SubjectPublicKeyInfo, AlgorithmIdentifier 835 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 836 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 837 id-mod(0) id-pkix1-explicit-88(1)} 838 ; 839 -- CMS/PKCS#7 key transport algorithm & parameters 840 -- OID for CMS/PKCS#7 Key transport is id-GostR3410-94 from 841 -- GostR3410-94-PKISyntax or id-GostR3410-2001 from 842 -- GostR3410-2001-PKISyntax 843 -- Parameters for CMS/PKCS#7 Key transport are 844 -- GostR3410-94-PublicKeyParameters from 845 -- GostR3410-94-PKISyntax with encryptionParameterOID 846 or 847 -- GostR3410-2001-PublicKeyParameters from 848 -- GostR3410-2001-PKISyntax with encryptionParameterOI 849 D 850 -- Algorithm for CMS/PKCS#7 Key transport iare 851 -- GostR3410-94-PublicKeyAlgorithms from 852 -- GostR3410-94-PKISyntax or 853 -- GostR3410-2001-PublicKeyAlgorithms from 854 -- GostR3410-2001-PKISyntax 855 -- SMIMECapability for CMS/PKCS#7 Key transport are 856 -- id-GostR3410-94 from GostR3410-94-PKISyntax or 857 -- id-GostR3410-2001 from GostR3410-2001-PKISyntax 858 id-GostR3410-94-KeyTransportSMIMECapability 859 OBJECT IDENTIFIER ::= id-GostR3410-94 860 id-GostR3410-2001-KeyTransportSMIMECapability 861 OBJECT IDENTIFIER ::= id-GostR3410-2001 862 GostR3410-KeyTransport ::= 863 SEQUENCE { 864 sessionEncryptedKey Gost28147-89-EncryptedKey, 865 transportParameters [0] IMPLICIT GostR3410-TransportPar 866 ameters OPTIONAL 867 } 868 GostR3410-TransportParameters ::= 869 SEQUENCE { 870 encryptionParamSet 871 OBJECT IDENTIFIER ( 872 id-Gost28147-89-TestParamSet | -- Only for 873 testing purposes 874 id-Gost28147-89-CryptoPro-A-ParamSet | 875 id-Gost28147-89-CryptoPro-B-ParamSet | 876 id-Gost28147-89-CryptoPro-C-ParamSet | 877 id-Gost28147-89-CryptoPro-D-ParamSet | 878 id-Gost28147-89-CryptoPro-Simple-A-ParamSet | 879 id-Gost28147-89-CryptoPro-Simple-B-ParamSet | 880 id-Gost28147-89-CryptoPro-Simple-C-ParamSet | 881 id-Gost28147-89-CryptoPro-Simple-D-ParamSet 882 ), 883 ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo 884 OPTIONAL, 885 ukm OCTET STRING ( SIZE(8) ) 886 } 887 GostR3410-KeyEncryptionAlgorithms 888 ALGORITHM-IDENTIFIER ::= { 889 { GostR3410-94-PublicKeyParameters IDENTIFIED BY 890 id-GostR3410-94 } | 891 { GostR3410-2001-PublicKeyParameters IDENTIFIED BY 892 id-GostR3410-2001 } 893 } 894 END -- GostR3410-EncryptionSyntax 896 10.2 GostR3410-94-SignatureSyntax 898 GostR3410-94-SignatureSyntax 899 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 900 other(1) modules(1) gostR3410-94-SignatureSyntax(3) 1 } 901 DEFINITIONS ::= 902 BEGIN 903 -- EXPORTS All -- 904 -- The types and values defined in this module are exported for 905 -- use in the other ASN.1 modules contained within the Russian 906 -- Cryptography "GOST" & "GOST R" Specifications, and for the use 907 -- of other applications which will use them to access Russian 908 -- Cryptography services. Other applications may use them for 909 -- their own purposes, but this will not constrain extensions and 910 -- modifications needed to maintain or improve the Russian 911 -- Cryptography service. 912 IMPORTS 913 gostR3410-94-PKISyntax, ALGORITHM-IDENTIFIER, 914 cryptographic-Gost-Useful-Definitions 915 FROM Cryptographic-Gost-Useful-Definitions 916 { iso(1) member-body(2) ru(643) rans(2) 917 cryptopro(2) other(1) modules(1) 918 cryptographic-Gost-Useful-Definitions(0) 1 } 919 id-GostR3410-94, 920 GostR3410-94-PublicKeyParameters 921 FROM GostR3410-94-PKISyntax gostR3410-94-PKISyntax 922 ; 923 -- GOST R 34.10-94 signature data type 924 GostR3410-94-Signature ::= 925 OCTET STRING (SIZE (64)) 926 -- GOST R 34.10-94 signature algorithm & parameters 927 GostR3410-94-CMSSignatureAlgorithms ALGORITHM-IDENTIFIER ::= { 928 { GostR3410-94-PublicKeyParameters IDENTIFIED BY 929 id-GostR3410-94 } 930 } 932 END -- GostR3410-94-SignatureSyntax 934 10.3 GostR3410-2001-SignatureSyntax 936 GostR3410-2001-SignatureSyntax 937 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 938 other(1) modules(1) gostR3410-2001-SignatureSyntax(10) 1 } 939 DEFINITIONS ::= 940 BEGIN 941 -- EXPORTS All -- 942 -- The types and values defined in this module are exported for 943 -- use in the other ASN.1 modules contained within the Russian 944 -- Cryptography "GOST" & "GOST R" Specifications, and for the use 945 -- of other applications which will use them to access Russian 946 -- Cryptography services. Other applications may use them for 947 -- their own purposes, but this will not constrain extensions and 948 -- modifications needed to maintain or improve the Russian 949 -- Cryptography service. 950 IMPORTS 951 gostR3410-2001-PKISyntax, ALGORITHM-IDENTIFIER, 952 cryptographic-Gost-Useful-Definitions 953 FROM Cryptographic-Gost-Useful-Definitions 954 { iso(1) member-body(2) ru(643) rans(2) 955 cryptopro(2) other(1) modules(1) 956 cryptographic-Gost-Useful-Definitions(0) 1 } 957 id-GostR3410-2001, 958 GostR3410-2001-PublicKeyParameters 959 FROM GostR3410-2001-PKISyntax gostR3410-2001-PKISyntax 960 ; 961 -- GOST R 34.10-2001 signature data type 962 GostR3410-2001-Signature ::= 963 OCTET STRING (SIZE (64)) 964 -- GOST R 34.10-2001 signature algorithms and parameters 965 GostR3410-2001-CMSSignatureAlgorithms 966 ALGORITHM-IDENTIFIER ::= { 967 { GostR3410-2001-PublicKeyParameters IDENTIFIED BY 968 id-GostR3410-2001 } 969 } 970 END -- GostR3410-2001-SignatureSyntax 972 11 References 974 [GOST28147] "Cryptographic Protection for Data Processing Sys- 975 tem", GOST 28147-89, Gosudarstvennyi Standard of 976 USSR, Government Committee of the USSR for Standards, 977 1989. (In Russian); 979 [GOSTR341094] "Information technology. Cryptographic Data Security. 980 Produce and check procedures of Electronic Digital 981 Signatures based on Asymmetric Cryptographic Algo- 982 rithm.", GOST R 34.10-94, Gosudarstvennyi Standard of 983 Russian Federation, Government Committee of the Rus- 984 sia for Standards, 1994. (In Russian); 986 [GOSTR34102001] "Information technology. Cryptographic data security. 987 Signature and verification processes of [electronic] 988 digital signature.", GOST R 34.10-2001, Gosudarstven- 989 nyi Standard of Russian Federation, Government Com- 990 mittee of the Russia for Standards, 2001. (In Rus- 991 sian); 993 [GOSTR341194] "Information technology. Cryptographic Data Security. 994 Hashing function.", GOST R 34.10-94, Gosudarstvennyi 995 Standard of Russian Federation, Government Committee 996 of the Russia for Standards, 1994. (In Russian); 998 [Schneier95] B. Schneier, Applied cryptography, second edition, 999 John Wiley & Sons, Inc., 1995; 1001 [RFC 3280] Housley, R., Polk, W., Ford, W. and D. Solo, 1002 "Internet X.509 Public Key Infrastructure Certificate 1003 and Certificate Revocation List (CRL) Profile", RFC 1004 3280, April 2002. 1006 [RFC 3279] Algorithms and Identifiers for the Internet X.509 1007 Public Key Infrastructure Certificate and Certificate 1008 Revocation List (CRL) Profile. L. Bassham, W. 1009 Polk, R. Housley. April 2002. 1011 [RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indi- 1012 cateRequirement Levels", BCP 14, RFC 2119, March 1013 1997. 1015 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 3369, 1016 August 2002 1018 [X.208-88] CCITT. Recommendation X.208: Specification of 1019 Abstract Syntax Notation One (ASN.1). 1988. 1021 [X.209-88] CCITT. Recommendation X.209: Specification of Basic 1022 Encoding Rules for Abstract Syntax Notation One 1023 (ASN.1). 1988.. 1025 [CPPK] S. Leontiev, D. Shefanovskij, "Algorithms and Identi- 1026 fiers for the Internet X.509 Public Key Infrastruc- 1027 ture Certificates and Certificate Revocation List 1028 (CRL), corresponding to the algorithms GOST R 1029 34.10-94, GOST R 34.10-2001, GOST R 34.11-94", draft- 1030 ietf-pkix-gost-cppk-02.txt 1032 [CPALGS] V. Popov, I. Kurepkin, S. Leontiev "Additional cryp- 1033 tographic algorithms for use with GOST 28147-89, GOST 1034 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 1035 algorithms.", draft-popov-cryptopro-cpalgs-02.txt 1037 [HMAC] H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed- 1038 Hashing for Message Authentication", RFC 2104 Febru- 1039 ary 1997. 1041 [RFDSL] "Russian Federal Digital Signature Law", 10 Jan 2002 1042 N1-FZ 1044 [RFLLIC] "Russian Federal Law on Licensing of Selected Activ- 1045 ity Categories", 08 Aug 2001 N 128-FZ 1047 [CRYPTOLIC] "Russian Federal Goverment Regulation on Licensing of 1048 Selected Activity Categories in Cryptography Area", 1049 23 Sep 2002 N 691 1051 Acknowledgments 1053 This document was created in accordance with "Russian Cryptographic 1054 Software Compatibility Agreement", signed by FGUE STC "Atlas", 1055 CRYPTO-PRO, Factor-TC, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), 1056 Cryptocom, R-Alpha. The aim of this agreement is to achieve mutual 1057 compatibility of the products and solutions. 1059 The authors wish to thank: 1061 Microsoft Corporation Russia for provided information about 1062 company products and solutions, and also for technical consulting 1063 in PKI. 1065 RSA Security Russia and Demos Co Ltd for active collaboration and 1066 critical help in creation of this document. 1068 Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and 1069 Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative, 1070 creating this document. 1072 This document is based on a contribution of CRYPTO-PRO Company. Any 1073 substantial use of the text from this document must acknowledge 1074 CRYPTO-PRO. CRYPTO-PRO requests that all material mentioning or 1075 referencing this document identify this as "CRYPTO-PRO CPCMS". 1077 Author's Addresses 1079 Serguei Leontiev 1080 CRYPTO-PRO 1081 38, Obraztsova, 1082 Moscow, 127018, Russian Federation 1083 EMail: lse@cryptopro.ru 1085 Vladimir Popov 1086 CRYPTO-PRO 1087 38, Obraztsova, 1088 Moscow, 127018, Russian Federation 1089 EMail: vpopov@cryptopro.ru 1090 Gregory Chudov 1091 CRYPTO-PRO 1092 38, Obraztsova, 1093 Moscow, 127018, Russian Federation 1094 EMail: chudov@cryptopro.ru 1096 Alexandr Afanasiev 1097 Factor-TC 1098 office 711, 14, Presnenskij val, 1099 Moscow, 123557, Russian Federation 1100 EMail: aaaf@factor-ts.ru 1102 Nikolaj Nikishin 1103 Infotecs GmbH 1104 p/b 35, 80-5, Leningradskij prospekt, 1105 Moscow, 125315, Russian Federation 1106 EMail: nikishin@infotecs.ru 1108 Boleslav Izotov 1109 FGUE STC "Atlas" 1110 38, Obraztsova, 1111 Moscow, 127018, Russian Federation 1112 EMail: izotov@stcnet.ru 1114 Elena Minaeva 1115 MD PREI 1116 build 3, 6A, Vtoroj Troitskij per., 1117 Moscow, Russian Federation 1118 EMail: evminaeva@mo.msk.ru 1120 Serguei Murugov 1121 R-Alpha 1122 4/1, Raspletina, 1123 Moscow, 123060, Russian Federation 1124 EMail: msm@office.ru 1126 Igori Ustinov 1127 Cryptocom 1128 office 239, 51, Leninskij prospekt, 1129 Moscow, 119991, Russian Federation 1130 EMail: igus@cryptocom.ru 1132 Anatolij Erkin 1133 SPRCIS (SPbRCZI) 1134 1, Obrucheva, 1135 St.Petersburg, 195220, Russian Federation 1136 EMail: erkin@nevsky.net 1138 Full Copyright Statement 1140 Copyright (C) The Internet Society (2005). This document is subject 1141 to the rights, licenses and restrictions contained in BCP 78, and 1142 except as set forth therein, the authors retain all their rights. 1144 This document and the information contained herein are provided on an 1145 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1146 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1147 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1148 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1149 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1150 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.