S/MIME Working Group Serguei Leontiev, CRYPTO-PRO Internet Draft Gregory Chudov, CRYPTO-PRO Expires June 21, 2006 December 21, 2005 Intended Category: Standards Track Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94 and GOST R 34.10-2001 algorithms with the Cryptographic Message Syntax (CMS) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 21, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the conventions for using cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94, along with Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication and encryption of arbitrary message contents. Leontiev, Chudov Standards Track [Page 1] Internet-Draft Using GOST with CMS December 2005 Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Terminology. . . . . . . . . . . . . . . . . . . . . . . 3 2 Message Digest Algorithms. . . . . . . . . . . . . . . . 3 2.1 Message Digest Algorithm GOST R 34.11-94 . . . . . . . . 3 3 Signature Algorithms . . . . . . . . . . . . . . . . . . 4 3.1 Signature Algorithm GOST R 34.10-94. . . . . . . . . . . 4 3.2 Signature Algorithm GOST R 34.10-2001. . . . . . . . . . 4 4 Key Management Algorithms. . . . . . . . . . . . . . . . 5 4.1 Key Agreement Algorithms . . . . . . . . . . . . . . . . 5 4.1.1 Key Agreement Algorithms Based on GOST R 34.10-94/2001 Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Key Transport Algorithms. .. . . . . . . . . . . . . . . 7 4.2.1 Key Transport Algorithm Based on GOST R 34.10-94/2001 Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5 Content Encryption Algorithms. . . . . . . . . . . . . . 9 5.1 Key-Encryption Key Algorithm GOST 28147-89 . . . . . . . 9 6 MAC Algorithms . . . . . . . . . . . . . . . . . . . . . 9 6.1 HMAC with GOST R 34.11-94. . . . . . . . . . . . . . . . 10 7 Using with S/MIME. . . . . . . . . . . . . . . . . . . . 10 7.1 Parameter micalg . . . . . . . . . . . . . . . . . . . . 10 7.2 Atribute SMIMECapabilities . . . . . . . . . . . . . . . 10 8 Security Considerations. . . . . . . . . . . . . . . . . 11 9 Appendix Examples. . . . . . . . . . . . . . . . . . . . 11 9.1 Signed message . . . . . . . . . . . . . . . . . . . . . 12 9.2 Enveloped message using Key Agreement. . . . . . . . . . 13 9.3 Enveloped message using Key Transport. . . . . . . . . . 16 10 Appendix ASN.1 Modules . . . . . . . . . . . . . . . . . 18 10.1 GostR3410-EncryptionSyntax . . . . . . . . . . . . . . . 18 10.2 GostR3410-94-SignatureSyntax . . . . . . . . . . . . . . 20 10.3 GostR3410-2001-SignatureSyntax . . . . . . . . . . . . . 21 11 References . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 24 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 25 1 Introduction The Cryptographic Message Syntax [CMS] is used for digital signature, digest, authentication and encryption of arbitrary message contents. This companion specification describes the use of cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001 and GOST R 34.11-94 in CMS, as proposed by the CRYPTO-PRO Company for "Russian Cryptographic Software Compatibility Agreement" community. This document does not describe these cryptographic algorithms; they are defined in corresponding national standards. The CMS values are generated using ASN.1 [X.208-88], using BER- Leontiev, Chudov Standards Track [Page 2] Internet-Draft Using GOST with CMS December 2005 encoding [X.209-88]. This document specifies the algorithm identifiers for each algorithm, including ASN.1 for object identifiers and any associated parameters. The fields in the CMS employed by each algorithm are identified. 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2 Message Digest Algorithms This section specifies the conventions for using the digest algorithm GOST R 34.11-94 employed by CMS. Digest values are located in the DigestedData digest field and the Message Digest authenticated attribute. In addition, digest values are input to signature algorithms. 2.1 Message Digest Algorithm GOST R 34.11-94 Hash function GOST R 34.11-94 has been developed by "GUBS of Federal Agency Government Communication and Information" and "All-Russian Scientific and Research Institute of Standardization". The algorithm GOST R 34.11-94 produces a 256-bit hash value of the arbitrary finite bit length input. This document does not contain the full GOST R 34.11-94 specification, which can be found in [GOSTR3411] in Russian. [Schneier95] ch. 18.11, p. 454. contains a brief technical description in English. The hash algorithm GOST R 34.11-94 has the following identifier: id-GostR3411-94 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostr3411(9) } The AlgorithmIdentifier parameters field MUST be present, and the parameters field MUST contain NULL. Implementations MAY accept the GOST R 34.11-94 AlgorithmIdentifiers with absent parameters as well as NULL parameters. This function is always used with default parameters id- GostR3411-94-CryptoProParamSet (see section 8.2 of [CPALGS]). When Message Digest authenticated attribute is present, DigestedData digest contains a 32-byte digest in little-endian representation: Leontiev, Chudov Standards Track [Page 3] Internet-Draft Using GOST with CMS December 2005 GostR3411-94-Digest ::= OCTET STRING (SIZE (32)) 3 Signature Algorithms This section specifies the CMS procedures for GOST R 34.10-94 and GOST R 34.10-2001 signature algorithms. Signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData. Also, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of countersignature attributes. Signature values are located in the SignerInfo signature field of SignedData. Also, signature values are located in the SignerInfo signature field of countersignature attributes. 3.1 Signature Algorithm GOST R 34.10-94 GOST R 34.10-94 has been developed by "GUBS of Federal Agency Government Communication and Information" and "All-Russian Scientific and Research Institute of Standardization". This signature algorithm MUST be used conjointly with GOST R 34.11-94 message digest algorithm. This document does not contain the full GOST R 34.10-94 specification, which is fully described in [GOSTR341094] in Russian, and a brief description in English can be found in [Schneier95] ch. 20.3, p. 495. The GOST R 34.10-94 signature algorithm has the following public key algorithm identifier [CPPK]: id-GostR3410-94-signature OBJECT IDENTIFIER ::= id-GostR3410-94 Signature algorithm GOST R 34.10-94 generates a digital signature in the form of a binary 512-bit vector (256||256). signatureValue contains its little endian representation. GostR3410-94-Signature ::= OCTET STRING (SIZE (64)) 3.2 Signature Algorithm GOST R 34.10-2001 GOST R 34.10-2001 has been developed by "GUBS of Federal Agency Government Communication and Information" and "All-Russian Scientific and Research Institute of Standardization". This signature algorithm MUST be used conjointly with GOST R 34.11-94. This document does not contain the full GOST R 34.10-2001 specification, which is fully described in [GOSTR341001]. The signature algorithm GOST R 34.10-2001 has the following public Leontiev, Chudov Standards Track [Page 4] Internet-Draft Using GOST with CMS December 2005 key algorithm identifier from [CPPK]: id-GostR3410-2001-signature OBJECT IDENTIFIER ::= id-GostR3410-2001 Signature algorithm GOST R 34.10-2001 generates a digital signature in the form of a binary 512-bit vector (256||256). signatureValue contains its little endian representation. GostR3410-2001-Signature ::= OCTET STRING (SIZE (64)) 4 Key Management Algorithms This chapter describes the key agreement and key transport algorithms, based on VKO GOST R 34.10-94 and VKO GOST R 34.10-2001 key derivation algorithms, and the CryptoPro and GOST 28147-89 key wrap algorithms, described in [CPALGS]. They MUST be used only with content encryption algorithm GOST 28147-89, defined in section 5 of this document. 4.1 Key Agreement Algorithms This section specifies the conventions employed by CMS implementations that support key agreement using both VKO GOST R 34.10-94 and VKO GOST R 34.10-2001 algorithms, described in [CPALGS]. Key agreement algorithm identifiers are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and AuthenticatedData RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm fields. Wrapped content-encryption keys are located in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. Wrapped message-authentication keys are located in the AuthenticatedData RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys encryptedKey field. 4.1.1 Key Agreement Algorithms Based on GOST R 34.10-94/2001 Public Keys The EnvelopedData RecipientInfos KeyAgreeRecipientInfo field is used as follows: version MUST be 3. originator MUST be the originatorKey alternative. The originatorKey algorithm field MUST contain the object identifier id-GostR3410-94 or id-GostR3410-2001 and corresponding parameters (defined in sections 2.3.1, 2.3.2 of [CPPK]). Leontiev, Chudov Standards Track [Page 5] Internet-Draft Using GOST with CMS December 2005 The originatorKey publicKey field MUST contain the sender's public key. keyEncryptionAlgorithm MUST be the id-GostR3410-94-CryptoPro-ESDH or the id-GostR3410-2001-CryptoPro-ESDH algorithm identifier, depending on the recipient public key algorithm. The algorithm identifier parameter field for these algorithms is KeyWrapAlgorithm, and this parameter MUST be present. The KeyWrapAlgorithm denotes the algorithm and parameters used to encrypt the content-encryption key with the pairwise key- encryption key generated using the VKO GOST R 34.10-94 or the VKO GOST R 34.10-2001 key agreement algorithms. The algorithm identifiers and parameter syntax is: id-GostR3410-94-CryptoPro-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostR3410-94-CryptoPro-ESDH(97) } id-GostR3410-2001-CryptoPro-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostR3410-2001-CryptoPro-ESDH(96) } KeyWrapAlgorithm ::= AlgorithmIdentifier When keyEncryptionAlgorithm is id-GostR3410-94-CryptoPro-ESDH, KeyWrapAlgorithm algorithm MUST be the id-Gost28147-89-CryptoPro- KeyWrap algorithm identifier. id-Gost28147-89-CryptoPro-KeyWrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) keyWrap(13) cryptoPro(1) } The CryptoPro Key Wrap algorithm is described in sections 6.3 and 6.4 of [CPALGS]. When keyEncryptionAlgorithm is id-GostR3410-2001-CryptoPro-ESDH, KeyWrapAlgorithm algorithm MUST be either the id- Gost28147-89-CryptoPro-KeyWrap or id-Gost28147-89-None-KeyWrap algorithm identifier. id-Gost28147-89-None-KeyWrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) keyWrap(13) none(0) } The GOST 28147-89 Key Wrap algorithm is described in sections 6.1 and 6.2 of [CPALGS]. Leontiev, Chudov Standards Track [Page 6] Internet-Draft Using GOST with CMS December 2005 KeyWrapAlgorithm algorithm parameters MUST be present. The syntax for KeyWrapAlgorithm algorithm parameters is Gost28147-89-KeyWrapParameters ::= SEQUENCE { encryptionParamSet Gost28147-89-ParamSet, ukm OCTET STRING (SIZE (8)) OPTIONAL } Gost28147-89-ParamSet ::= OBJECT IDENTIFIER Gost28147-89-KeyWrapParameters ukm MUST be absent. KeyAgreeRecipientInfo ukm MUST be present, and contain eight octets. encryptedKey MUST encapsulate Gost28147-89-EncryptedKey, where maskKey MUST be absent. Gost28147-89-EncryptedKey ::= SEQUENCE { encryptedKey Gost28147-89-Key, maskKey [0] IMPLICIT Gost28147-89-Key OPTIONAL, macKey Gost28147-89-MAC } Using the secret key, corresponding to the originatorKey publicKey, and the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the KEK. Then the key wrap algorithm, specified by KeyWrapAlgorithm, is applied to produce CEK_ENC, CEK_MAC, and UKM. Gost28147-89-KeyWrapParameters encryptionParamSet is used for all encryption operations. The resulting encrypted key (CEK_ENC) is placed in Gost28147-89-EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in Gost28147-89-EncryptedKey macKey field, and UKM is placed in KeyAgreeRecipientInfo ukm field. 4.2 Key Transport Algorithms This section specifies the conventions employed by CMS implementations that support key transport using both VKO GOST R 34.10-94 and VKO GOST R 34.10-2001 algorithms, described in [CPALGS]. Key transport algorithm identifiers are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo keyEncryptionAlgorithm field. Leontiev, Chudov Standards Track [Page 7] Internet-Draft Using GOST with CMS December 2005 Key transport encrypted content-encryption keys are located in the EnvelopedData RecipientInfos KeyTransRecipientInfo encryptedKey field. 4.2.1 Key Transport Algorithm Based on GOST R 34.10-94/2001 Public Keys The EnvelopedData RecipientInfos KeyTransRecipientInfo field is used as follows: version MUST be 0 or 3. keyEncryptionAlgorithm and parameters MUST be identical to the recipient public key algorithm and parameters. encryptedKey encapsulates GostR3410-KeyTransport, which consists of encrypted content-encryption key, it's MAC, GOST 28147-89 algorithm parameters used for key encryption, sender's ephemeral public key, and UKM (UserKeyingMaterial, see [CMS], 10.2.6). transportParameters MUST be present. ephemeralPublicKey MUST be present, and its parameters, if present, MUST be equal to the recipient public key parameters; GostR3410-KeyTransport ::= SEQUENCE { sessionEncryptedKey Gost28147-89-EncryptedKey, transportParameters [0] IMPLICIT GostR3410-TransportParameters OPTIONAL } GostR3410-TransportParameters ::= SEQUENCE { encryptionParamSet OBJECT IDENTIFIER, ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL, ukm OCTET STRING } Using the secret key, corresponding to the GostR3410-TransportParameters ephemeralPublicKey, and the recipient's public key, the algorithm VKO GOST R 34.10-94 or VKO GOST R 34.10-2001 (described in [CPALGS]) is applied to produce the KEK. Then the CryptoPro key wrap algorithm is applied to produce CEK_ENC, CEK_MAC, and UKM. GostR3410-TransportParameters encryptionParamSet is used for all encryption operations. The resulting encrypted key (CEK_ENC) is placed in Gost28147-89-EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in Gost28147-89-EncryptedKey macKey field, and UKM is placed Leontiev, Chudov Standards Track [Page 8] Internet-Draft Using GOST with CMS December 2005 in GostR3410-TransportParameters ukm field. 5 Content Encryption Algorithms This section specifies the conventions employed by CMS implementations that support content encryption using GOST 28147-89. Content encryption algorithm identifiers are located in the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields. Content encryption algorithms are used to encipher the content located in the EnvelopedData EncryptedContentInfo encryptedContent field and the EncryptedData EncryptedContentInfo encryptedContent field. 5.1 Content Encryption Algorithm GOST 28147-89 This section specifies the use of GOST 28147-89 algorithm for data encipherment. GOST 28147-89 is fully described in [GOST28147] (in Russian). This document specifies the following OID for this algorithm: id-Gost28147-89 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gost28147-89(21) } Algorithm parameters MUST be present and have the following structure: Gost28147-89-Parameters ::= SEQUENCE { iv Gost28147-89-IV, encryptionParamSet OBJECT IDENTIFIER } Gost28147-89-IV ::= OCTET STRING (SIZE (8)) encryptionParamSet specifies the set of corresponding Gost28147-89-ParamSetParameters (see section 8.1 of [CPALGS]) 6 MAC Algorithms This section specifies the conventions employed by CMS implementations that support the message authentication code (MAC) based on GOST R 34.11-94. Leontiev, Chudov Standards Track [Page 9] Internet-Draft Using GOST with CMS December 2005 MAC algorithm identifiers are located in the AuthenticatedData macAlgorithm field. MAC values are located in the AuthenticatedData mac field. 6.1 HMAC with GOST R 34.11-94 HMAC_GOSTR3411 (K,text) function is based on hash function GOST R 34.11-94, as defined in section 3 of [CPALGS]. This document specifies the following OID for this algorithm: id-HMACGostR3411-94 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) hmacgostr3411(10) } This algorithm has the same parameters, as GOST R 34.11-94 digest algorithm, and uses the same OIDs for their identification (see [CPPK]). 7 Using with S/MIME This section defines use of the algorithms defined in this document together with S/MIME [RFC 3851]. 7.1 Parameter micalg When using the algorithms defined in this document, micalg parameter SHOULD be set to "gostr3411-94" or it MAY be set to "unknown". 7.2 Attribute SMIMECapabilities The SMIMECapability value which indicates support for the GOST R 34.11-94 digest algorithm is the SEQUENCE with the capabilityID field containing the object identifier id-GostR3411-94 and no parameters. The DER encoding is: 30 08 06 06 2A 85 03 02 02 09 The SMIMECapability value which indicates support for the GOST 28147-89 encryption algorithm is the SEQUENCE with the capabilityID field containing the object identifier id-Gost28147-89 and no parameters. The DER encoding is: 30 08 06 06 2A 85 03 02 02 15 If the sender wishes to indicate support for a specific parameter set, SMIMECapability parameters MUST contain the Leontiev, Chudov Standards Track [Page 10] Internet-Draft Using GOST with CMS December 2005 Gost28147-89-Parameters structure. Recipients MUST ignore the Gost28147-89-Parameters iv field, and assume that the sender supports parameters, specified in Gost28147-89-Parameters encryptionParamSet field. The DER encoding for the SMIMECapability, indicating support for GOST 28147-89 with id-Gost28147-89-CryptoPro-A-ParamSet (see [CPALGS]) is: 30 1D 06 06 2A 85 03 02 02 15 30 13 04 08 00 00 00 00 00 00 00 00 06 07 2A 85 03 02 02 1F 01 8 Security Considerations Conforming applications MUST use unique values for ukm and iv. Recipients MAY verify that ukm and iv, specified by the sender, are unique. It is RECOMMENDED that software applications verify signature values, subject public keys and algorithm parameters to conform to [GOSTR341001] [GOSTR341094] standards prior to their use. Cryptographic algorithm parameters affect rigidity of algorithms. The use of parameters not listed in [CPALGS] is NOT RECOMMENDED (see Security Considerations section of [CPALGS]). Use of the same key for signature and key derivation is NOT RECOMMENDED. When signed CMS documents are used as an analogue to a manual signing, in the context of Russian Federal Digital Signature Law [RFDSL], signer certificate MUST contain the keyUsage extension, it MUST be critical, and keyUsage MUST NOT include keyEncipherment or keyAgreement (see [PROFILE], section 4.2.1.3). Application SHOULD be submited for examination by an authorized agency in appropriate levels of target_of_evaluation (TOE), according to [RFDSL], [RFLLIC] and [CRYPTOLIC]. 9 Appendix Examples Examples here are stored in the same format as the examples in [RFC 4134], and can be extracted using the same program. If you want to extract without the program, copy all the lines between the "|>" and "|<" markers, remove any page breaks, and remove Leontiev, Chudov Standards Track [Page 11] Internet-Draft Using GOST with CMS December 2005 the "|" in the first column of each line. The result is a valid Base64 blob that can be processed by any Base64 decoder. 9.1 Signed message This message is signed using the sample certificate from section 4.2 of [CPPK]. The public key (x,y) from the same section can be used to verify the message signature. 0 296: SEQUENCE { 4 9: OBJECT IDENTIFIER signedData 15 281: [0] { 19 277: SEQUENCE { 23 1: INTEGER 1 26 12: SET { 28 10: SEQUENCE { 30 6: OBJECT IDENTIFIER id-GostR3411-94 38 0: NULL : } : } 40 27: SEQUENCE { 42 9: OBJECT IDENTIFIER data 53 14: [0] { 55 12: OCTET STRING 73 61 6D 70 6C 65 20 74 65 78 74 0A : } : } 69 228: SET { 72 225: SEQUENCE { 75 1: INTEGER 1 78 129: SEQUENCE { 81 109: SEQUENCE { 83 31: SET { 85 29: SEQUENCE { 87 3: OBJECT IDENTIFIER commonName 92 22: UTF8String 'GostR3410-2001 example' : } : } 116 18: SET { 118 16: SEQUENCE { 120 3: OBJECT IDENTIFIER organizationName 125 9: UTF8String 'CryptoPro' : } : } 136 11: SET { 138 9: SEQUENCE { 140 3: OBJECT IDENTIFIER countryName 145 2: PrintableString 'RU' : } Leontiev, Chudov Standards Track [Page 12] Internet-Draft Using GOST with CMS December 2005 : } 149 41: SET { 151 39: SEQUENCE { 153 9: OBJECT IDENTIFIER emailAddress 164 26: IA5String 'GostR3410-2001@example.com' : } : } : } 192 16: INTEGER : 2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21 : } 210 10: SEQUENCE { 212 6: OBJECT IDENTIFIER id-GostR3411-94 220 0: NULL : } 222 10: SEQUENCE { 224 6: OBJECT IDENTIFIER id-GostR3410-2001 232 0: NULL : } 234 64: OCTET STRING : C0 C3 42 D9 3F 8F FE 25 11 11 88 77 BF 89 C3 DB : 83 42 04 D6 20 F9 68 2A 99 F6 FE 30 3B E4 F4 C8 : F8 D5 B4 DA FB E1 C6 91 67 34 1F BC A6 7A 0D 12 : 7B FD 10 25 C6 51 DB 8D B2 F4 8C 71 7E ED 72 A9 : } : } : } : } : } |>GostR3410-2001-signed.bin |MIIBKAYJKoZIhvcNAQcCoIIBGTCCARUCAQExDDAKBgYqhQMCAgkFADAbBgkqhkiG |9w0BBwGgDgQMc2FtcGxlIHRleHQKMYHkMIHhAgEBMIGBMG0xHzAdBgNVBAMMFkdv |c3RSMzQxMC0yMDAxIGV4YW1wbGUxEjAQBgNVBAoMCUNyeXB0b1BybzELMAkGA1UE |BhMCUlUxKTAnBgkqhkiG9w0BCQEWGkdvc3RSMzQxMC0yMDAxQGV4YW1wbGUuY29t |AhAr9cYewhG9F8fc1GJmtC4hMAoGBiqFAwICCQUAMAoGBiqFAwICEwUABEDAw0LZ |P4/+JRERiHe/icPbg0IE1iD5aCqZ9v4wO+T0yPjVtNr74caRZzQfvKZ6DRJ7/RAl |xlHbjbL0jHF+7XKp |GostR3410-2001-keyagree.bin |MIIBpAYJKoZIhvcNAQcDoIIBlTCCAZECAQIxggFQoYIBTAIBA6BloWMwHAYGKoUD |AgITMBIGByqFAwICJAAGByqFAwICHgEDQwAEQLNVOfRngZcrpcTZhB8n+4HtCDLm |mtTyAHi4/4Nk6tIdsHg8ff4DwfQG5DvMFrnF9vYZNxwXuKCqx9GhlLOlNiChCgQI |L/D20YZLMoowHgYGKoUDAgJgMBQGByqFAwICDQAwCQYHKoUDAgIfATCBszCBsDCB |gTBtMR8wHQYDVQQDDBZHb3N0UjM0MTAtMjAwMSBleGFtcGxlMRIwEAYDVQQKDAlD |cnlwdG9Qcm8xCzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3N0UjM0MTAt |MjAwMUBleGFtcGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuIQQqMCgEIBajHOfOTukN |8ex0aQRoHsefOu24Ox8dSn75pdnLGdXoBAST/YZ+MDgGCSqGSIb3DQEHATAdBgYq |hQMCAhUwEwQItzXhegc1oh0GByqFAwICHwGADDmxivS/qeJlJbZVyQ== |GostR3410-2001-keytrans.bin |MIIBpwYJKoZIhvcNAQcDoIIBmDCCAZQCAQAxggFTMIIBTwIBADCBgTBtMR8wHQYD |VQQDDBZHb3N0UjM0MTAtMjAwMSBleGFtcGxlMRIwEAYDVQQKDAlDcnlwdG9Qcm8x |CzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3N0UjM0MTAtMjAwMUBleGFt |cGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuITAcBgYqhQMCAhMwEgYHKoUDAgIkAAYH |KoUDAgIeAQSBpzCBpDAoBCBqL6ghBpVon5/kR6qey2EVK35BYLxdjfv1PSgbGJr5 |dQQENm2Yt6B4BgcqhQMCAh8BoGMwHAYGKoUDAgITMBIGByqFAwICJAAGByqFAwIC |HgEDQwEEQE0rLzOQ5tyj3VUqzd/g7/sx93N+Tv+/eImKK8PNMZQESw5gSJYf28dd |Em/askCKd7W96vLsNMsjn5uL3Z4SwPYECJeV4ywrrSsMMDgGCSqGSIb3DQEHATAd |BgYqhQMCAhUwEwQIvBCLHwv/NCkGByqFAwICHwGADKqOch3uT7Mu4w+hNw== |