idnits 2.17.1 draft-ietf-smime-gost-07.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1244. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1250. ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? 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. 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 (January 18, 2006) is 6670 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'CMS' on line 1099 looks like a reference -- Missing reference section? 'RFC2119' on line 112 looks like a reference -- Missing reference section? 'GOSTR3411' on line 129 looks like a reference -- Missing reference section? 'Schneier95' on line 1122 looks like a reference -- Missing reference section? 'CPALGS' on line 1064 looks like a reference -- Missing reference section? 'GOSTR341094' on line 1081 looks like a reference -- Missing reference section? 'CPPK' on line 1069 looks like a reference -- Missing reference section? 'GOSTR341001' on line 1088 looks like a reference -- Missing reference section? '0' on line 954 looks like a reference -- Missing reference section? 'GOST28147' on line 1076 looks like a reference -- Missing reference section? 'RFC 3851' on line 1106 looks like a reference -- Missing reference section? 'RFDSL' on line 1125 looks like a reference -- Missing reference section? 'PROFILE' on line 1102 looks like a reference -- Missing reference section? 'RFLLIC' on line 1128 looks like a reference -- Missing reference section? 'CRYPTOLIC' on line 1131 looks like a reference -- Missing reference section? '1' on line 658 looks like a reference -- Missing reference section? 'GOSTR341194' on line 1094 looks like a reference -- Missing reference section? 'RFC 2119' on line 1119 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 24 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 July 18, 2006 January 18, 2006 5 Intended Category: Standards Track 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, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "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 This Internet-Draft will expire on July 18, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 This document describes the conventions for using cryptographic 45 algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 46 34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is 47 used for digital signature, digest, authentication and encryption of 48 arbitrary message contents. 50 Table of Contents 52 1. Introduction..................................................2 53 1.2. Terminology..............................................3 54 2. Message Digest Algorithms.....................................3 55 2.1. Message Digest Algorithm GOST R 34.11-94.................3 56 3. Signature Algorithms..........................................4 57 3.1. Signature Algorithm GOST R 34.10-94......................4 58 3.2. Signature Algorithm GOST R 34.10-2001....................4 59 4. Key Management Algorithms.....................................5 60 4.1. Key Agreement Algorithms.................................5 61 4.1.1. Key Agreement Algorithms Based on 62 GOST R 34.10-94/2001 Public Keys........................5 63 4.2. Key Transport Algorithms.................................7 64 4.2.1. Key Transport Algorithm Based on 65 GOST R 34.10-94/2001 Public Keys........................8 66 5. Content Encryption Algorithms.................................9 67 5.1. Key-Encryption Key Algorithm GOST 28147-89...............9 68 6. MAC Algorithms................................................9 69 6.1. HMAC with GOST R 34.11-94...............................10 70 7. Using with S/MIME............................................10 71 7.1. Parameter micalg........................................10 72 7.2. Atribute SMIMECapabilities..............................10 73 8. Security Considerations......................................11 74 9. Appendix Examples............................................11 75 9.1. Signed message..........................................12 76 9.2. Enveloped message using Key Agreement...................13 77 9.3. Enveloped message using Key Transport...................16 78 10. Appendix ASN.1 Modules......................................18 79 10.1. GostR3410-EncryptionSyntax.............................18 80 10.2. GostR3410-94-SignatureSyntax...........................20 81 10.3. GostR3410-2001-SignatureSyntax.........................21 82 11. Acknowledgments.............................................22 83 12. References..................................................22 84 12.1. Normative References...................................23 85 12.2. Informative References.................................24 86 Contact Information.............................................24 87 Full Copyright Statement........................................26 89 1. Introduction 91 The Cryptographic Message Syntax [CMS] is used for digital signature, 92 digest, authentication and encryption of arbitrary message contents. 93 This companion specification describes the use of cryptographic 94 algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001 and GOST 95 R 34.11-94 in CMS, as proposed by the CRYPTO-PRO Company for "Russian 96 Cryptographic Software Compatibility Agreement" community. This 97 document does not describe these cryptographic algorithms; they are 98 defined in corresponding national standards. 100 The CMS values are generated using ASN.1 [X.208-88], using BER- 101 encoding [X.209-88]. This document specifies the algorithm 102 identifiers for each algorithm, including ASN.1 for object 103 identifiers and any associated parameters. 105 The fields in the CMS employed by each algorithm are identified. 107 1.2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 2. Message Digest Algorithms 115 This section specifies the conventions for using the digest algorithm 116 GOST R 34.11-94 employed by CMS. 118 Digest values are located in the DigestedData digest field and the 119 Message Digest authenticated attribute. In addition, digest values 120 are input to signature algorithms. 122 2.1. Message Digest Algorithm GOST R 34.11-94 124 Hash function GOST R 34.11-94 has been developed by "GUBS of Federal 125 Agency Government Communication and Information" and "All-Russian 126 Scientific and Research Institute of Standardization". The algorithm 127 GOST R 34.11-94 produces a 256-bit hash value of the arbitrary finite 128 bit length input. This document does not contain the full GOST R 129 34.11-94 specification, which can be found in [GOSTR3411] in Russian. 130 [Schneier95] ch. 18.11, p. 454. contains a brief technical 131 description in English. 133 The hash algorithm GOST R 34.11-94 has the following identifier: 135 id-GostR3411-94 OBJECT IDENTIFIER ::= 136 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 137 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 parameters id- 145 GostR3411-94-CryptoProParamSet (see section 8.2 of [CPALGS]). 147 When Message Digest authenticated attribute is present, DigestedData 148 digest contains a 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 the full GOST R 34.10-94 173 specification, which is fully described in [GOSTR341094] in Russian, 174 and a brief description in English can be found in [Schneier95] ch. 175 20.3, p. 495. 177 The GOST R 34.10-94 signature algorithm has the following public key 178 algorithm identifier: 180 id-GostR3410-94-signature OBJECT IDENTIFIER ::= id-GostR3410-94 182 id-GostR3410-94 is defined in Section 2.3.1 of [CPPK]. 184 Signature algorithm GOST R 34.10-94 generates a digital signature in 185 the form of a binary 512-bit vector (256||256). 186 signatureValue contains its little endian representation. 188 GostR3410-94-Signature ::= OCTET STRING (SIZE (64)) 190 3.2. Signature Algorithm GOST R 34.10-2001 192 GOST R 34.10-2001 has been developed by "GUBS of Federal Agency 193 Government Communication and Information" and "All-Russian Scientific 194 and Research Institute of Standardization". This signature algorithm 195 MUST be used conjointly with GOST R 34.11-94. This document does not 196 contain the full GOST R 34.10-2001 specification, which is fully 197 described in [GOSTR341001]. 199 The signature algorithm GOST R 34.10-2001 has the following public 200 key algorithm identifier: 202 id-GostR3410-2001-signature OBJECT IDENTIFIER ::= id-GostR3410-2001 204 id-GostR3410-2001 is defined in Section 2.3.2 of [CPPK]. 206 Signature algorithm GOST R 34.10-2001 generates a digital signature 207 in the form of a binary 512-bit vector (256||256). 208 signatureValue contains its little endian representation. 210 GostR3410-2001-Signature ::= OCTET STRING (SIZE (64)) 212 4. Key Management Algorithms 214 This chapter describes the key agreement and key transport 215 algorithms, based on VKO GOST R 34.10-94 and VKO GOST R 34.10-2001 216 key derivation algorithms, and the CryptoPro and GOST 28147-89 key 217 wrap algorithms, described in [CPALGS]. They MUST be used only with 218 content encryption algorithm GOST 28147-89, defined in section 5 of 219 this document. 221 4.1. Key Agreement Algorithms 223 This section specifies the conventions employed by CMS 224 implementations that support key agreement using both VKO GOST R 225 34.10-94 and VKO GOST R 34.10-2001 algorithms, described in [CPALGS]. 227 Key agreement algorithm identifiers are located in the EnvelopedData 228 RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and 229 AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 230 keyEncryptionAlgorithm fields. 232 Wrapped content-encryption keys are located in the EnvelopedData 233 RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys 234 encryptedKey field. Wrapped message-authentication keys are located 235 in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo 236 RecipientEncryptedKeys encryptedKey field. 238 4.1.1. Key Agreement Algorithms Based on GOST R 34.10-94/2001 Public 239 Keys 241 The EnvelopedData RecipientInfos KeyAgreeRecipientInfo field is used 242 as follows: 244 version MUST be 3. 246 originator MUST be the originatorKey alternative. The 247 originatorKey algorithm field MUST contain the object identifier 248 id-GostR3410-94 or id-GostR3410-2001 and corresponding parameters 249 (defined in sections 2.3.1, 2.3.2 of [CPPK]). 251 The originatorKey publicKey field MUST contain the sender's public 252 key. 254 keyEncryptionAlgorithm MUST be the id-GostR3410-94-CryptoPro-ESDH 255 or the id-GostR3410-2001-CryptoPro-ESDH algorithm identifier, 256 depending on the recipient public key algorithm. The algorithm 257 identifier parameter field for these algorithms is 258 KeyWrapAlgorithm, and this parameter MUST be present. The 259 KeyWrapAlgorithm denotes the algorithm and parameters used to 260 encrypt the content-encryption key with the pairwise key- 261 encryption key generated using the VKO GOST R 34.10-94 or the VKO 262 GOST R 34.10-2001 key agreement algorithms. 264 The algorithm identifiers and parameter syntax is: 266 id-GostR3410-94-CryptoPro-ESDH OBJECT IDENTIFIER ::= 267 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 268 gostR3410-94-CryptoPro-ESDH(97) } 270 id-GostR3410-2001-CryptoPro-ESDH OBJECT IDENTIFIER ::= 271 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 272 gostR3410-2001-CryptoPro-ESDH(96) } 274 KeyWrapAlgorithm ::= AlgorithmIdentifier 276 When keyEncryptionAlgorithm is id-GostR3410-94-CryptoPro-ESDH, 277 KeyWrapAlgorithm algorithm MUST be the id-Gost28147-89-CryptoPro- 278 KeyWrap algorithm identifier. 280 id-Gost28147-89-CryptoPro-KeyWrap OBJECT IDENTIFIER ::= 281 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 282 keyWrap(13) cryptoPro(1) } 284 The CryptoPro Key Wrap algorithm is described in sections 6.3 and 285 6.4 of [CPALGS]. 287 When keyEncryptionAlgorithm is id-GostR3410-2001-CryptoPro-ESDH, 288 KeyWrapAlgorithm algorithm MUST be either the id- 289 Gost28147-89-CryptoPro-KeyWrap or id-Gost28147-89-None-KeyWrap 290 algorithm identifier. 292 id-Gost28147-89-None-KeyWrap OBJECT IDENTIFIER ::= 293 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 294 keyWrap(13) none(0) } 296 The GOST 28147-89 Key Wrap algorithm is described in sections 6.1 297 and 6.2 of [CPALGS]. 299 KeyWrapAlgorithm algorithm parameters MUST be present. The syntax 300 for KeyWrapAlgorithm algorithm parameters is 302 Gost28147-89-KeyWrapParameters ::= 303 SEQUENCE { 304 encryptionParamSet Gost28147-89-ParamSet, 305 ukm OCTET STRING (SIZE (8)) OPTIONAL 306 } 307 Gost28147-89-ParamSet ::= OBJECT IDENTIFIER 309 Gost28147-89-KeyWrapParameters ukm MUST be absent. 311 KeyAgreeRecipientInfo ukm MUST be present, and contain eight 312 octets. 314 encryptedKey MUST encapsulate Gost28147-89-EncryptedKey, where 315 maskKey MUST be absent. 317 Gost28147-89-EncryptedKey ::= SEQUENCE { 318 encryptedKey Gost28147-89-Key, 319 maskKey [0] IMPLICIT Gost28147-89-Key 320 OPTIONAL, 321 macKey Gost28147-89-MAC 322 } 324 Using the secret key, corresponding to the originatorKey publicKey, 325 and the recipient's public key, the algorithm VKO GOST R 34.10-94 or 326 VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce 327 the KEK. 329 Then the key wrap algorithm, specified by KeyWrapAlgorithm, is 330 applied to produce CEK_ENC, CEK_MAC, and UKM. 331 Gost28147-89-KeyWrapParameters encryptionParamSet is used for all 332 encryption operations. 334 The resulting encrypted key (CEK_ENC) is placed in 335 Gost28147-89-EncryptedKey encryptedKey field, its mac (CEK_MAC) is 336 placed in Gost28147-89-EncryptedKey macKey field, and UKM is placed 337 in KeyAgreeRecipientInfo ukm field. 339 4.2. Key Transport Algorithms 340 This section specifies the conventions employed by CMS 341 implementations that support key transport using both VKO GOST R 342 34.10-94 and VKO GOST R 34.10-2001 algorithms, described in [CPALGS]. 344 Key transport algorithm identifiers are located in the EnvelopedData 345 RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. 347 Key transport encrypted content-encryption keys are located in the 348 EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey 349 field. 351 4.2.1. Key Transport Algorithm Based on GOST R 34.10-94/2001 Public 352 Keys 354 The EnvelopedData RecipientInfos KeyTransRecipientInfo field is used 355 as follows: 357 version MUST be 0 or 3. 359 keyEncryptionAlgorithm and parameters MUST be identical to the 360 recipient public key algorithm and parameters. 362 encryptedKey encapsulates GostR3410-KeyTransport, which consists 363 of encrypted content-encryption key, it's MAC, GOST 28147-89 364 algorithm parameters used for key encryption, sender's ephemeral 365 public key, and UKM (UserKeyingMaterial, see [CMS], 10.2.6). 367 transportParameters MUST be present. 369 ephemeralPublicKey MUST be present, and its parameters, if 370 present, MUST be equal to the recipient public key parameters; 372 GostR3410-KeyTransport ::= SEQUENCE { 373 sessionEncryptedKey Gost28147-89-EncryptedKey, 374 transportParameters 375 [0] IMPLICIT GostR3410-TransportParameters OPTIONAL 376 } 378 GostR3410-TransportParameters ::= SEQUENCE { 379 encryptionParamSet OBJECT IDENTIFIER, 380 ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL, 381 ukm OCTET STRING 382 } 384 Using the secret key, corresponding to the 385 GostR3410-TransportParameters ephemeralPublicKey, and the recipient's 386 public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 387 34.10-2001 (described in [CPALGS]) is applied to produce the KEK. 389 Then the CryptoPro key wrap algorithm is applied to produce CEK_ENC, 390 CEK_MAC, and UKM. GostR3410-TransportParameters encryptionParamSet is 391 used for all encryption operations. 393 The resulting encrypted key (CEK_ENC) is placed in 394 Gost28147-89-EncryptedKey encryptedKey field, its mac (CEK_MAC) is 395 placed in Gost28147-89-EncryptedKey macKey field, and UKM is placed 396 in GostR3410-TransportParameters ukm field. 398 5. Content Encryption Algorithms 400 This section specifies the conventions employed by CMS 401 implementations that support content encryption using GOST 28147-89. 403 Content encryption algorithm identifiers are located in the 404 EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the 405 EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. 407 Content encryption algorithms are used to encipher the content 408 located in the EnvelopedData EncryptedContentInfo encryptedContent 409 field and the EncryptedData EncryptedContentInfo encryptedContent 410 field. 412 5.1. Content Encryption Algorithm GOST 28147-89 414 This section specifies the use of GOST 28147-89 algorithm for data 415 encipherment. 417 GOST 28147-89 is fully described in [GOST28147] (in Russian). 419 This document specifies the following OID for this algorithm: 421 id-Gost28147-89 OBJECT IDENTIFIER ::= 422 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 423 gost28147-89(21) } 425 Algorithm parameters MUST be present and have the following 426 structure: 428 Gost28147-89-Parameters ::= 429 SEQUENCE { 430 iv Gost28147-89-IV, 431 encryptionParamSet OBJECT IDENTIFIER 432 } 434 Gost28147-89-IV ::= OCTET STRING (SIZE (8)) 436 encryptionParamSet specifies the set of corresponding 437 Gost28147-89-ParamSetParameters (see section 8.1 of [CPALGS]) 439 6. MAC Algorithms 441 This section specifies the conventions employed by CMS 442 implementations that support the message authentication code (MAC) 443 based on GOST R 34.11-94. 445 MAC algorithm identifiers are located in the AuthenticatedData 446 macAlgorithm field. 448 MAC values are located in the AuthenticatedData mac field. 450 6.1. HMAC with GOST R 34.11-94 452 HMAC_GOSTR3411 (K,text) function is based on hash function GOST R 453 34.11-94, as defined in section 3 of [CPALGS]. 455 This document specifies the following OID for this algorithm: 457 id-HMACGostR3411-94 OBJECT IDENTIFIER ::= 458 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) 459 hmacgostr3411(10) } 461 This algorithm has the same parameters, as GOST R 34.11-94 digest 462 algorithm, and uses the same OIDs for their identification (see 463 [CPPK]). 465 7. Using with S/MIME 467 This section defines use of the algorithms defined in this document 468 together with S/MIME [RFC 3851]. 470 7.1. Parameter micalg 472 When using the algorithms defined in this document, micalg parameter 473 SHOULD be set to "gostr3411-94", otherwise it MUST be set to 474 "unknown". 476 7.2. Attribute SMIMECapabilities 478 The SMIMECapability value which indicates support for the GOST R 479 34.11-94 digest algorithm is the SEQUENCE with the capabilityID field 480 containing the object identifier id-GostR3411-94 and no parameters. 481 The DER encoding is: 483 30 08 06 06 2A 85 03 02 02 09 485 The SMIMECapability value which indicates support for the GOST 486 28147-89 encryption algorithm is the SEQUENCE with the capabilityID 487 field containing the object identifier id-Gost28147-89 and no 488 parameters. The DER encoding is: 490 30 08 06 06 2A 85 03 02 02 15 492 If the sender wishes to indicate support for a specific parameter 493 set, SMIMECapability parameters MUST contain the 494 Gost28147-89-Parameters structure. Recipients MUST ignore the 495 Gost28147-89-Parameters iv field, and assume that the sender supports 496 parameters, specified in Gost28147-89-Parameters encryptionParamSet 497 field. 499 The DER encoding for the SMIMECapability, indicating support for GOST 500 28147-89 with id-Gost28147-89-CryptoPro-A-ParamSet (see [CPALGS]) is: 502 30 1D 06 06 2A 85 03 02 02 15 30 13 04 08 00 00 503 00 00 00 00 00 00 06 07 2A 85 03 02 02 1F 01 505 8. Security Considerations 507 Conforming applications MUST use unique values for ukm and iv. 508 Recipients MAY verify that ukm and iv, specified by the sender, are 509 unique. 511 It is RECOMMENDED that software applications verify signature values, 512 subject public keys and algorithm parameters to conform to 513 [GOSTR341001] [GOSTR341094] standards prior to their use. 515 Cryptographic algorithm parameters affect algorithm strength. The 516 use of parameters not listed in [CPALGS] is NOT RECOMMENDED (see 517 Security Considerations section of [CPALGS]). 519 Use of the same key for signature and key derivation is NOT 520 RECOMMENDED. When signed CMS documents are used as an analogue to a 521 manual signing, in the context of Russian Federal Digital Signature 522 Law [RFDSL], signer certificate MUST contain the keyUsage extension, 523 it MUST be critical, and keyUsage MUST NOT include keyEncipherment or 524 keyAgreement (see [PROFILE], section 4.2.1.3). Application SHOULD be 525 submited for examination by an authorized agency in appropriate 526 levels of target_of_evaluation (TOE), according to [RFDSL], [RFLLIC] 527 and [CRYPTOLIC]. 529 9. Appendix Examples 531 Examples here are stored in the same format as the examples in [RFC 532 4134], and can be extracted using the same program. 534 If you want to extract without the program, copy all the lines 535 between the "|>" and "|<" markers, remove any page breaks, and remove 536 the "|" in the first column of each line. The result is a valid 537 Base64 blob that can be processed by any Base64 decoder. 539 9.1. Signed message 541 This message is signed using the sample certificate from section 4.2 542 of [CPPK]. The public key (x,y) from the same section can be used to 543 verify the message signature. 545 0 296: SEQUENCE { 546 4 9: OBJECT IDENTIFIER signedData 547 15 281: [0] { 548 19 277: SEQUENCE { 549 23 1: INTEGER 1 550 26 12: SET { 551 28 10: SEQUENCE { 552 30 6: OBJECT IDENTIFIER id-GostR3411-94 553 38 0: NULL 554 : } 555 : } 556 40 27: SEQUENCE { 557 42 9: OBJECT IDENTIFIER data 558 53 14: [0] { 559 55 12: OCTET STRING 73 61 6D 70 6C 65 20 74 65 78 74 0A 560 : } 561 : } 562 69 228: SET { 563 72 225: SEQUENCE { 564 75 1: INTEGER 1 565 78 129: SEQUENCE { 566 81 109: SEQUENCE { 567 83 31: SET { 568 85 29: SEQUENCE { 569 87 3: OBJECT IDENTIFIER commonName 570 92 22: UTF8String 'GostR3410-2001 example' 571 : } 572 : } 573 116 18: SET { 574 118 16: SEQUENCE { 575 120 3: OBJECT IDENTIFIER organizationName 576 125 9: UTF8String 'CryptoPro' 577 : } 578 : } 579 136 11: SET { 580 138 9: SEQUENCE { 581 140 3: OBJECT IDENTIFIER countryName 582 145 2: PrintableString 'RU' 583 : } 584 : } 585 149 41: SET { 586 151 39: SEQUENCE { 587 153 9: OBJECT IDENTIFIER emailAddress 588 164 26: IA5String 'GostR3410-2001@example.com' 589 : } 590 : } 591 : } 592 192 16: INTEGER 593 : 2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21 594 : } 595 210 10: SEQUENCE { 596 212 6: OBJECT IDENTIFIER id-GostR3411-94 597 220 0: NULL 598 : } 599 222 10: SEQUENCE { 600 224 6: OBJECT IDENTIFIER id-GostR3410-2001 601 232 0: NULL 602 : } 603 234 64: OCTET STRING 604 : C0 C3 42 D9 3F 8F FE 25 11 11 88 77 BF 89 C3 DB 605 : 83 42 04 D6 20 F9 68 2A 99 F6 FE 30 3B E4 F4 C8 606 : F8 D5 B4 DA FB E1 C6 91 67 34 1F BC A6 7A 0D 12 607 : 7B FD 10 25 C6 51 DB 8D B2 F4 8C 71 7E ED 72 A9 608 : } 609 : } 610 : } 611 : } 612 : } 614 |>GostR3410-2001-signed.bin 615 |MIIBKAYJKoZIhvcNAQcCoIIBGTCCARUCAQExDDAKBgYqhQMCAgkFADAbBgkqhkiG 616 |9w0BBwGgDgQMc2FtcGxlIHRleHQKMYHkMIHhAgEBMIGBMG0xHzAdBgNVBAMMFkdv 617 |c3RSMzQxMC0yMDAxIGV4YW1wbGUxEjAQBgNVBAoMCUNyeXB0b1BybzELMAkGA1UE 618 |BhMCUlUxKTAnBgkqhkiG9w0BCQEWGkdvc3RSMzQxMC0yMDAxQGV4YW1wbGUuY29t 619 |AhAr9cYewhG9F8fc1GJmtC4hMAoGBiqFAwICCQUAMAoGBiqFAwICEwUABEDAw0LZ 620 |P4/+JRERiHe/icPbg0IE1iD5aCqZ9v4wO+T0yPjVtNr74caRZzQfvKZ6DRJ7/RAl 621 |xlHbjbL0jHF+7XKp 622 |GostR3410-2001-keyagree.bin 732 |MIIBpAYJKoZIhvcNAQcDoIIBlTCCAZECAQIxggFQoYIBTAIBA6BloWMwHAYGKoUD 733 |AgITMBIGByqFAwICJAAGByqFAwICHgEDQwAEQLNVOfRngZcrpcTZhB8n+4HtCDLm 734 |mtTyAHi4/4Nk6tIdsHg8ff4DwfQG5DvMFrnF9vYZNxwXuKCqx9GhlLOlNiChCgQI 735 |L/D20YZLMoowHgYGKoUDAgJgMBQGByqFAwICDQAwCQYHKoUDAgIfATCBszCBsDCB 736 |gTBtMR8wHQYDVQQDDBZHb3N0UjM0MTAtMjAwMSBleGFtcGxlMRIwEAYDVQQKDAlD 737 |cnlwdG9Qcm8xCzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3N0UjM0MTAt 738 |MjAwMUBleGFtcGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuIQQqMCgEIBajHOfOTukN 739 |8ex0aQRoHsefOu24Ox8dSn75pdnLGdXoBAST/YZ+MDgGCSqGSIb3DQEHATAdBgYq 740 |hQMCAhUwEwQItzXhegc1oh0GByqFAwICHwGADDmxivS/qeJlJbZVyQ== 741 |GostR3410-2001-keytrans.bin 850 |MIIBpwYJKoZIhvcNAQcDoIIBmDCCAZQCAQAxggFTMIIBTwIBADCBgTBtMR8wHQYD 851 |VQQDDBZHb3N0UjM0MTAtMjAwMSBleGFtcGxlMRIwEAYDVQQKDAlDcnlwdG9Qcm8x 852 |CzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3N0UjM0MTAtMjAwMUBleGFt 853 |cGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuITAcBgYqhQMCAhMwEgYHKoUDAgIkAAYH 854 |KoUDAgIeAQSBpzCBpDAoBCBqL6ghBpVon5/kR6qey2EVK35BYLxdjfv1PSgbGJr5 855 |dQQENm2Yt6B4BgcqhQMCAh8BoGMwHAYGKoUDAgITMBIGByqFAwICJAAGByqFAwIC 856 |HgEDQwEEQE0rLzOQ5tyj3VUqzd/g7/sx93N+Tv+/eImKK8PNMZQESw5gSJYf28dd 857 |Em/askCKd7W96vLsNMsjn5uL3Z4SwPYECJeV4ywrrSsMMDgGCSqGSIb3DQEHATAd 858 |BgYqhQMCAhUwEwQIvBCLHwv/NCkGByqFAwICHwGADKqOch3uT7Mu4w+hNw== 859 |