当前位置:首页 >> 信息与通信 >>

rfc4490.Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms


Network Working Group Request for Comments: 4490 Category: Standards Track

S. Leontiev, Ed. G. Chudov, Ed. CRYPTO-PRO May 2006

Using the GOST 28147-89, GOST R 34.11-94,

GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 with the 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]

RFC 4490

Using GOST with CMS

May 2006

Table of Contents 1. Introduction ....................................................3 1.1. 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 ......................5 4. Key Management Algorithms .......................................5 4.1. Key Agreement Algorithms ...................................6 4.1.1. Key Agreement Algorithms Based on GOST R 34.10-94/2001 Public ................................6 4.2. Key Transport Algorithms ...................................8 4.2.1. Key Transport Algorithm Based on GOST R 34.10-94/2001 Public ................................8 5. Content Encryption Algorithms ...................................9 5.1. Content Encryption Algorithm GOST 28147-89 ................10 6. MAC Algorithms .................................................10 6.1. HMAC with GOST R 34.11-94 .................................10 7. Use with S/MIME ................................................11 7.1. Parameter micalg ..........................................11 7.2. Attribute SMIMECapabilities ...............................11 8. Security Considerations ........................................12 9. Examples .......................................................12 9.1. Signed Message ............................................12 9.2. Enveloped Message Using Key Agreement .....................14 9.3. Enveloped Message Using Key Transport .....................17 10. ASN.1 Modules .................................................19 10.1. GostR3410-EncryptionSyntax ...............................19 10.2. GostR3410-94-SignatureSyntax .............................21 10.3. GostR3410-2001-SignatureSyntax ...........................22 11. Acknowledgements ..............................................23 12. References ....................................................24 12.1. Normative References .....................................24 12.2. Informative References ...................................25

Leontiev & Chudov

Standards Track

[Page 2]

RFC 4490

Using GOST with CMS

May 2006

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 [GOST28147], GOST R 34.10-94 [GOST3431095, GOSTR341094], GOST R 34.10-2001 [GOST3431004, GOSTR341001], and GOST R 34.11-94 [GOST3431195, GOSTR341194] in CMS, as proposed by the CRYPTO-PRO Company for the "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 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.1.

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

The hash function GOST R 34.11-94 has been developed by "GUBS of Federal Agency Government Communication and Information" and "AllRussian 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 [GOSTR341194] in Russian. [Schneier95], ch. 18.11, p. 454, contains a brief technical description in English.

Leontiev & Chudov

Standards Track

[Page 3]

RFC 4490

Using GOST with CMS

May 2006

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-GostR341194-CryptoProParamSet (see Section 8.2 of [CPALGS]). When the Message Digest authenticated attribute is present, the DigestedData digest contains a 32-byte digest in little-endian representation: GostR3411-94-Digest ::= OCTET STRING (SIZE (32)) 3. Signature Algorithms This section specifies the CMS procedures for the 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 the 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:

Leontiev & Chudov

Standards Track

[Page 4]

RFC 4490

Using GOST with CMS

May 2006

id-GostR3410-94-signature OBJECT IDENTIFIER ::= id-GostR3410-94 id-GostR3410-94 is defined in Section 2.3.1 of [CPPK]. The signature algorithm GOST R 34.10-94 generates a digital signature in the form of two 256-bit numbers, r’ and s. Its octet string representation consists of 64 octets, where the first 32 octets contain the big-endian representation of s and the second 32 octets contain the big-endian representation of r’. 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 key algorithm identifier: id-GostR3410-2001-signature OBJECT IDENTIFIER ::= id-GostR3410-2001 id-GostR3410-2001 is defined in Section 2.3.2 of [CPPK]. The signature algorithm GOST R 34.10-2001 generates a digital signature in the form of two 256-bit numbers, r and s. Its octet string representation consists of 64 octets, where the first 32 octets contain the big-endian representation of s and the second 32 octets contain the big-endian representation of r. GostR3410-2001-Signature ::= OCTET STRING (SIZE (64)) 4. Key Management Algorithms This chapter describes the key agreement and key transport algorithms, based on the VKO GOST R 34.10-94 and VKO GOST R 34.102001 key derivation algorithms, and the CryptoPro and GOST 28147-89 key wrap algorithms, described in [CPALGS]. They MUST be used only with the content encryption algorithm GOST 28147-89, defined in Section 5 of this document.

Leontiev & Chudov

Standards Track

[Page 5]

RFC 4490

Using GOST with CMS

May 2006

4.1.

Key Agreement Algorithms

This section specifies the conventions employed by CMS implementations that support key agreement using both the 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: The version MUST be 3. The 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]). 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 keyencryption 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) }

Leontiev & Chudov

Standards Track

[Page 6]

RFC 4490

Using GOST with CMS

May 2006

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-CryptoProKeyWrap 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-89CryptoPro-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]. KeyWrapAlgorithm algorithm parameters MUST be present. for KeyWrapAlgorithm algorithm parameters is The syntax

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.

Leontiev & Chudov

Standards Track

[Page 7]

RFC 4490

Using GOST with CMS

May 2006

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-89KeyWrapParameters encryptionParamSet is used for all encryption operations. The resulting encrypted key (CEK_ENC) is placed in the Gost28147-89EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the Gost28147-89-EncryptedKey macKey field, and UKM is placed in the KeyAgreeRecipientInfo ukm field. 4.2. Key Transport Algorithms

This section specifies the conventions employed by CMS implementations that support key transport using both the 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. 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: The version MUST be 0 or 3. keyEncryptionAlgorithm and parameters MUST be identical to the recipient public key algorithm and parameters.

Leontiev & Chudov

Standards Track

[Page 8]

RFC 4490

Using GOST with CMS

May 2006

encryptedKey encapsulates GostR3410-KeyTransport, which consists of encrypted content-encryption key, its MAC, GOST 28147-89 algorithm parameters used for key encryption, the sender’s ephemeral public key, and UKM (UserKeyingMaterial; see [CMS], Section 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 GostR3410TransportParameters 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 the Gost28147-89EncryptedKey encryptedKey field, its mac (CEK_MAC) is placed in the Gost28147-89-EncryptedKey macKey field, and UKM is placed in the 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.

Leontiev & Chudov

Standards Track

[Page 9]

RFC 4490

Using GOST with CMS

May 2006

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 object identifier (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-89ParamSetParameters (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. 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].

Leontiev & Chudov

Standards Track

[Page 10]

RFC 4490

Using GOST with CMS

May 2006

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 the GOST R 34.11-94 digest algorithm and uses the same OIDs for their identification (see [CPPK]). 7. Use with S/MIME This section defines the use of the algorithms defined in this document with S/MIME [RFC3851]. 7.1. Parameter micalg

When using the algorithms defined in this document, micalg parameter SHOULD be set to "gostr3411-94"; otherwise, it MUST be set to "unknown". 7.2. Attribute SMIMECapabilities

The SMIMECapability value that 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 that 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 Gost28147-89Parameters structure. Recipients MUST ignore the Gost28147-89Parameters iv field and assume that the sender supports the parameters specified in the 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:

Leontiev & Chudov

Standards Track

[Page 11]

RFC 4490

Using GOST with CMS

May 2006

30 1D 06 06 00 00 00 00 8.

2A 85 03 02 00 00 06 07

02 15 30 13 2A 85 03 02

04 08 00 00 02 1F 01

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 that signature values, subject public keys, and algorithm parameters conform to [GOSTR341001] and [GOSTR341094] standards prior to their use. Cryptographic algorithm parameters affect algorithm strength. The use of parameters not listed in [CPALGS] is NOT RECOMMENDED (see the 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 Electronic Digital Signature Law [RFEDSL], 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 submitted for examination by an authorized agency in appropriate levels of target_of_evaluation (TOE), according to [RFEDSL], [RFLLIC], and [CRYPTOLIC].

9.

Examples Examples here are stored in the same format as the examples in [RFC4134] 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 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 4 15 19 23 296: SEQUENCE { 9: OBJECT IDENTIFIER signedData 281: [0] { 277: SEQUENCE { 1: INTEGER 1

Leontiev & Chudov

Standards Track

[Page 12]

RFC 4490

Using GOST with CMS

May 2006

26 28 30 38

40 42 53 55

69 72 75 78 81 83 85 87 92

116 118 120 125

136 138 140 145

149 151 153 164

192

210 212 220

12: 10: 6: 0: : : 27: 9: 14: 12: : : 228: 225: 1: 129: 109: 31: 29: 3: 22: : : 18: 16: 3: 9: : : 11: 9: 3: 2: : : 41: 39: 9: 26: : : : 16: : : 10: 6: 0:

SET { SEQUENCE { OBJECT IDENTIFIER id-GostR3411-94 NULL } } SEQUENCE { OBJECT IDENTIFIER data [0] { OCTET STRING 73 61 6D 70 6C 65 20 74 65 78 74 0A } } SET { SEQUENCE { INTEGER 1 SEQUENCE { SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER commonName UTF8String ’GostR3410-2001 example’ } } SET { SEQUENCE { OBJECT IDENTIFIER organizationName UTF8String ’CryptoPro’ } } SET { SEQUENCE { OBJECT IDENTIFIER countryName PrintableString ’RU’ } } SET { SEQUENCE { OBJECT IDENTIFIER emailAddress IA5String ’GostR3410-2001@example.com’ } } } INTEGER 2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21 } SEQUENCE { OBJECT IDENTIFIER id-GostR3411-94 NULL

Leontiev & Chudov

Standards Track

[Page 13]

RFC 4490

Using GOST with CMS

May 2006

222 224 232 234

: 10: 6: 0: : 64: : : : : : : : : :

} SEQUENCE { OBJECT IDENTIFIER NULL } OCTET STRING C0 C3 42 D9 3F 8F 83 42 04 D6 20 F9 F8 D5 B4 DA FB E1 7B FD 10 25 C6 51 } } } } }

id-GostR3410-2001

FE 68 C6 DB

25 2A 91 8D

11 99 67 B2

11 F6 34 F4

88 FE 1F 8C

77 30 BC 71

BF 3B A6 7E

89 E4 7A ED

C3 F4 0D 72

DB C8 12 A9

|>GostR3410-2001-signed.bin |MIIBKAYJKoZIhvcNAQcCoIIBGTCCARUCAQExDDAKBgYqhQMCAgkFADAbBgkqhkiG |9w0BBwGgDgQMc2FtcGxlIHRleHQKMYHkMIHhAgEBMIGBMG0xHzAdBgNVBAMMFkdv |c3RSMzQxMC0yMDAxIGV4YW1wbGUxEjAQBgNVBAoMCUNyeXB0b1BybzELMAkGA1UE |BhMCUlUxKTAnBgkqhkiG9w0BCQEWGkdvc3RSMzQxMC0yMDAxQGV4YW1wbGUuY29t |AhAr9cYewhG9F8fc1GJmtC4hMAoGBiqFAwICCQUAMAoGBiqFAwICEwUABEDAw0LZ |P4/+JRERiHe/icPbg0IE1iD5aCqZ9v4wO+T0yPjVtNr74caRZzQfvKZ6DRJ7/RAl |xlHbjbL0jHF+7XKp |<GostR3410-2001-signed.bin 9.2. Enveloped Message Using Key Agreement

This message is encrypted using the sample certificate from Section 4.2 of [CPPK] as a recipient certificate. The private key ’d’ from the same section can be used to decrypt this message. 0 4 15 19 23 26 30 34 37 39 41 43 51 53 62 420: SEQUENCE { 9: OBJECT IDENTIFIER envelopedData 405: [0] { 401: SEQUENCE { 1: INTEGER 2 336: SET { 332: [1] { 1: INTEGER 3 101: [0] { 99: [1] { 28: SEQUENCE { 6: OBJECT IDENTIFIER id-GostR3410-2001 18: SEQUENCE { 7: OBJECT IDENTIFIER : id-GostR3410-2001-CryptoPro-XchA-ParamSet 7: OBJECT IDENTIFIER

Leontiev & Chudov

Standards Track

[Page 14]

RFC 4490

Using GOST with CMS

May 2006

71 74

140 142 152 154 162 164 173 175

184 187 190 193 195 197 199 204

228 230 232 237

248 250 252 257

261

: : : 67: 64: : : : : : : : 10: 8: : 30: 6: 20: 7: 9: 7: : : : : 179: 176: 129: 109: 31: 29: 3: 22: : : 18: 16: 3: 9: : : 11: 9: 3: 2: : : 41:

id-GostR3411-94-CryptoProParamSet } } BIT STRING, encapsulates { OCTET STRING B3 55 39 F4 67 81 97 2B A5 ED 08 32 E6 9A D4 F2 00 78 B0 78 3C 7D FE 03 C1 F4 06 F6 19 37 1C 17 B8 A0 AA C7 } }

C4 B8 E4 D1

D9 FF 3B A1

84 83 CC 94

1F 64 16 B3

27 EA B9 A5

FB D2 C5 36

81 1D F6 20

} [1] { OCTET STRING 2F F0 F6 D1 86 4B 32 8A } SEQUENCE { OBJECT IDENTIFIER id-GostR3410-2001-CryptoPro-ESDH SEQUENCE { OBJECT IDENTIFIER id-Gost28147-89-None-KeyWrap SEQUENCE { OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet } } } SEQUENCE { SEQUENCE { SEQUENCE { SEQUENCE { SET { SEQUENCE { OBJECT IDENTIFIER commonName UTF8String ’GostR3410-2001 example’ } } SET { SEQUENCE { OBJECT IDENTIFIER organizationName UTF8String ’CryptoPro’ } } SET { SEQUENCE { OBJECT IDENTIFIER countryName PrintableString ’RU’ } } SET {

Leontiev & Chudov

Standards Track

[Page 15]

RFC 4490

Using GOST with CMS

May 2006

263 265 276

304

322 324 326

360

366 368 379 381 389 391 401

410

39: 9: 26: : : : 16: : : 42: 40: 32: : : 4: : : : : : : : 56: 9: 29: 6: 19: 8: 7: : : 12: : : : :

SEQUENCE { OBJECT IDENTIFIER emailAddress IA5String ’GostR3410-2001@example.com’ } } } INTEGER 2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21 } OCTET STRING, encapsulates { SEQUENCE { OCTET STRING 16 A3 1C E7 CE 4E E9 0D F1 EC 74 69 04 68 1E C7 9F 3A ED B8 3B 1F 1D 4A 7E F9 A5 D9 CB 19 D5 E8 OCTET STRING 93 FD 86 7E } } } } } } SEQUENCE { OBJECT IDENTIFIER data SEQUENCE { OBJECT IDENTIFIER id-Gost28147-89 SEQUENCE { OCTET STRING B7 35 E1 7A 07 35 A2 1D OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet } } [0] 39 B1 8A F4 BF A9 E2 65 25 B6 55 C9 } } } }

|>GostR3410-2001-keyagree.bin |MIIBpAYJKoZIhvcNAQcDoIIBlTCCAZECAQIxggFQoYIBTAIBA6BloWMwHAYGKoUD |AgITMBIGByqFAwICJAAGByqFAwICHgEDQwAEQLNVOfRngZcrpcTZhB8n+4HtCDLm |mtTyAHi4/4Nk6tIdsHg8ff4DwfQG5DvMFrnF9vYZNxwXuKCqx9GhlLOlNiChCgQI |L/D20YZLMoowHgYGKoUDAgJgMBQGByqFAwICDQAwCQYHKoUDAgIfATCBszCBsDCB |gTBtMR8wHQYDVQQDDBZHb3N0UjM0MTAtMjAwMSBleGFtcGxlMRIwEAYDVQQKDAlD |cnlwdG9Qcm8xCzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3N0UjM0MTAt |MjAwMUBleGFtcGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuIQQqMCgEIBajHOfOTukN |8ex0aQRoHsefOu24Ox8dSn75pdnLGdXoBAST/YZ+MDgGCSqGSIb3DQEHATAdBgYq |hQMCAhUwEwQItzXhegc1oh0GByqFAwICHwGADDmxivS/qeJlJbZVyQ== |<GostR3410-2001-keyagree.bin

Leontiev & Chudov

Standards Track

[Page 16]

RFC 4490

Using GOST with CMS

May 2006

9.3.

Enveloped Message Using Key Transport

This message is encrypted using the sample certificate from Section 4.2 of [CPPK] as a recipient certificate. The private key ’d’ from the same section can be used to decrypt this message. 0 4 15 19 23 26 30 34 37 40 42 44 46 51 423: SEQUENCE { 9: OBJECT IDENTIFIER envelopedData 408: [0] { 404: SEQUENCE { 1: INTEGER 0 339: SET { 335: SEQUENCE { 1: INTEGER 0 129: SEQUENCE { 109: SEQUENCE { 31: SET { 29: SEQUENCE { 3: OBJECT IDENTIFIER commonName 22: UTF8String ’GostR3410-2001 example’ : } : } 18: SET { 16: SEQUENCE { 3: OBJECT IDENTIFIER organizationName 9: UTF8String ’CryptoPro’ : } : } 11: SET { 9: SEQUENCE { 3: OBJECT IDENTIFIER countryName 2: PrintableString ’RU’ : } : } 41: SET { 39: SEQUENCE { 9: OBJECT IDENTIFIER emailAddress 26: IA5String ’GostR3410-2001@example.com’ : } : } : } 16: INTEGER : 2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21 : } 28: SEQUENCE { 6: OBJECT IDENTIFIER id-GostR3410-2001 18: SEQUENCE { 7: OBJECT IDENTIFIER

75 77 79 84

95 97 99 104

108 110 112 123

151

169 171 179 181

Leontiev & Chudov

Standards Track

[Page 17]

RFC 4490

Using GOST with CMS

May 2006

190

199 202 205 207

241

247 249 258 260 262 270 272 281

290 293

359

369 371 382 384 392 394

: 7: : : : 167: 164: 40: 32: : : 4: : : 120: 7: : 99: 28: 6: 18: 7: : 7: : : : 67: 64: : : : : : : 8: : : : : : : 56: 9: 29: 6: 19: 8:

id-GostR3410-2001-CryptoPro-XchA-ParamSet OBJECT IDENTIFIER id-GostR3411-94-CryptoProParamSet } } OCTET STRING, encapsulates { SEQUENCE { SEQUENCE { OCTET STRING 6A 2F A8 21 06 95 68 9F 9F E4 47 AA 9E CB 61 15 2B 7E 41 60 BC 5D 8D FB F5 3D 28 1B 18 9A F9 75 OCTET STRING 36 6D 98 B7 } [0] { OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet [0] { SEQUENCE { OBJECT IDENTIFIER id-GostR3410-2001 SEQUENCE { OBJECT IDENTIFIER id-GostR3410-2001-CryptoPro-XchA-ParamSet OBJECT IDENTIFIER id-GostR3411-94-CryptoProParamSet } } BIT STRING encapsulates { OCTET STRING 4D 2B 2F 33 90 E6 DC A3 DD 55 2A CD DF E0 EF FB 31 F7 73 7E 4E FF BF 78 89 8A 2B C3 CD 31 94 04 4B 0E 60 48 96 1F DB C7 5D 12 6F DA B2 40 8A 77 B5 BD EA F2 EC 34 CB 23 9F 9B 8B DD 9E 12 C0 F6 } } OCTET STRING 97 95 E3 2C 2B AD 2B 0C } } } } } SEQUENCE { OBJECT IDENTIFIER data SEQUENCE { OBJECT IDENTIFIER id-Gost28147-89 SEQUENCE { OCTET STRING BC 10 8B 1F 0B FF 34 29

Leontiev & Chudov

Standards Track

[Page 18]

RFC 4490

Using GOST with CMS

May 2006

404

413

7: : : 12: : : : :

OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet } } [0] AA 8E 72 1D EE 4F B3 2E E3 0F A1 37 } } } }

|>GostR3410-2001-keytrans.bin |MIIBpwYJKoZIhvcNAQcDoIIBmDCCAZQCAQAxggFTMIIBTwIBADCBgTBtMR8wHQYD |VQQDDBZHb3N0UjM0MTAtMjAwMSBleGFtcGxlMRIwEAYDVQQKDAlDcnlwdG9Qcm8x |CzAJBgNVBAYTAlJVMSkwJwYJKoZIhvcNAQkBFhpHb3N0UjM0MTAtMjAwMUBleGFt |cGxlLmNvbQIQK/XGHsIRvRfH3NRiZrQuITAcBgYqhQMCAhMwEgYHKoUDAgIkAAYH |KoUDAgIeAQSBpzCBpDAoBCBqL6ghBpVon5/kR6qey2EVK35BYLxdjfv1PSgbGJr5 |dQQENm2Yt6B4BgcqhQMCAh8BoGMwHAYGKoUDAgITMBIGByqFAwICJAAGByqFAwIC |HgEDQwAEQE0rLzOQ5tyj3VUqzd/g7/sx93N+Tv+/eImKK8PNMZQESw5gSJYf28dd |Em/askCKd7W96vLsNMsjn5uL3Z4SwPYECJeV4ywrrSsMMDgGCSqGSIb3DQEHATAd |BgYqhQMCAhUwEwQIvBCLHwv/NCkGByqFAwICHwGADKqOch3uT7Mu4w+hNw== |<GostR3410-2001-keytrans.bin 10. ASN.1 Modules Additional ASN.1 modules, referenced here, can be found in [CPALGS]. 10.1. GostR3410-EncryptionSyntax

GostR3410-EncryptionSyntax { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) other(1) modules(1) gostR3410-EncryptionSyntax(5) 2 } DEFINITIONS ::= BEGIN -- EXPORTS All --- The types and values defined in this module are exported for -- use in the other ASN.1 modules contained within the Russian -- Cryptography "GOST" & "GOST R" Specifications, and for the use -- of other applications which will use them to access Russian -- Cryptography services. Other applications may use them for -- their own purposes, but this will not constrain extensions and -- modifications needed to maintain or improve the Russian -- Cryptography service. IMPORTS id-CryptoPro-algorithms, gost28147-89-EncryptionSyntax, gostR3410-94-PKISyntax, gostR3410-2001-PKISyntax, ALGORITHM-IDENTIFIER, cryptographic-Gost-Useful-Definitions

Leontiev & Chudov

Standards Track

[Page 19]

RFC 4490

Using GOST with CMS

May 2006

FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS] { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) other(1) modules(1) cryptographic-Gost-Useful-Definitions(0) 1 } id-GostR3410-94 FROM GostR3410-94-PKISyntax -- in [CPALGS] gostR3410-94-PKISyntax id-GostR3410-2001 FROM GostR3410-2001-PKISyntax -- in [CPALGS] gostR3410-2001-PKISyntax Gost28147-89-ParamSet, Gost28147-89-EncryptedKey FROM Gost28147-89-EncryptionSyntax -- in [CPALGS] gost28147-89-EncryptionSyntax SubjectPublicKeyInfo FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} ; -- CMS/PKCS#7 key agreement algorithms & parameters Gost28147-89-KeyWrapParameters ::= SEQUENCE { encryptionParamSet Gost28147-89-ParamSet, ukm OCTET STRING (SIZE (8)) OPTIONAL } id-Gost28147-89-CryptoPro-KeyWrap OBJECT IDENTIFIER ::= { id-CryptoPro-algorithms keyWrap(13) cryptoPro(1) } id-Gost28147-89-None-KeyWrap OBJECT IDENTIFIER ::= { id-CryptoPro-algorithms keyWrap(13) none(0) } Gost28147-89-KeyWrapAlgorithms ALGORITHM-IDENTIFIER ::= { { Gost28147-89-KeyWrapParameters IDENTIFIED BY id-Gost28147-89-CryptoPro-KeyWrap } | { Gost28147-89-KeyWrapParameters IDENTIFIED BY id-Gost28147-89-None-KeyWrap } } id-GostR3410-2001-CryptoPro-ESDH OBJECT IDENTIFIER ::= { id-CryptoPro-algorithms gostR3410-2001-CryptoPro-ESDH(96) } id-GostR3410-94-CryptoPro-ESDH OBJECT IDENTIFIER ::= { id-CryptoPro-algorithms gostR3410-94-CryptoPro-ESDH(97) } -- CMS/PKCS#7 key transport algorithms & parameters -- OID for CMS/PKCS#7 Key transport is id-GostR3410-94 from -GostR3410-94-PKISyntax or id-GostR3410-2001 from -GostR3410-2001-PKISyntax -- Algorithms for CMS/PKCS#7 Key transport are -GostR3410-94-PublicKeyAlgorithms from -GostR3410-94-PKISyntax or

Leontiev & Chudov

Standards Track

[Page 20]

RFC 4490

Using GOST with CMS

May 2006

-GostR3410-2001-PublicKeyAlgorithms from -GostR3410-2001-PKISyntax -- SMIMECapability for CMS/PKCS#7 Key transport are -id-GostR3410-94 from GostR3410-94-PKISyntax or -id-GostR3410-2001 from GostR3410-2001-PKISyntax id-GostR3410-94-KeyTransportSMIMECapability OBJECT IDENTIFIER ::= id-GostR3410-94 id-GostR3410-2001-KeyTransportSMIMECapability OBJECT IDENTIFIER ::= id-GostR3410-2001 GostR3410-KeyTransport ::= SEQUENCE { sessionEncryptedKey Gost28147-89-EncryptedKey, transportParameters [0] IMPLICIT GostR3410-TransportParameters OPTIONAL } GostR3410-TransportParameters ::= SEQUENCE { encryptionParamSet Gost28147-89-ParamSet, ephemeralPublicKey [0] IMPLICIT SubjectPublicKeyInfo OPTIONAL, ukm OCTET STRING ( SIZE(8) ) } END -- GostR3410-EncryptionSyntax 10.2. GostR3410-94-SignatureSyntax

GostR3410-94-SignatureSyntax { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) other(1) modules(1) gostR3410-94-SignatureSyntax(3) 1 } DEFINITIONS ::= BEGIN -- EXPORTS All --- The types and values defined in this module are exported for -- use in the other ASN.1 modules contained within the Russian -- Cryptography "GOST" & "GOST R" Specifications, and for the use -- of other applications which will use them to access Russian -- Cryptography services. Other applications may use them for -- their own purposes, but this will not constrain extensions and -- modifications needed to maintain or improve the Russian -- Cryptography service. IMPORTS gostR3410-94-PKISyntax, ALGORITHM-IDENTIFIER, cryptographic-Gost-Useful-Definitions FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS] { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) other(1) modules(1) cryptographic-Gost-Useful-Definitions(0) 1 } id-GostR3410-94,

Leontiev & Chudov

Standards Track

[Page 21]

RFC 4490

Using GOST with CMS

May 2006

GostR3410-94-PublicKeyParameters FROM GostR3410-94-PKISyntax -- in [CPALGS] gostR3410-94-PKISyntax ; -- GOST R 34.10-94 signature data type GostR3410-94-Signature ::= OCTET STRING (SIZE (64)) -- GOST R 34.10-94 signature algorithm & parameters GostR3410-94-CMSSignatureAlgorithms ALGORITHM-IDENTIFIER ::= { { GostR3410-94-PublicKeyParameters IDENTIFIED BY id-GostR3410-94 } } END -- GostR3410-94-SignatureSyntax 10.3. GostR3410-2001-SignatureSyntax

GostR3410-2001-SignatureSyntax { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) other(1) modules(1) gostR3410-2001-SignatureSyntax(10) 1 } DEFINITIONS ::= BEGIN -- EXPORTS All --- The types and values defined in this module are exported for -- use in the other ASN.1 modules contained within the Russian -- Cryptography "GOST" & "GOST R" Specifications, and for the use -- of other applications which will use them to access Russian -- Cryptography services. Other applications may use them for -- their own purposes, but this will not constrain extensions and -- modifications needed to maintain or improve the Russian -- Cryptography service. IMPORTS gostR3410-2001-PKISyntax, ALGORITHM-IDENTIFIER, cryptographic-Gost-Useful-Definitions FROM Cryptographic-Gost-Useful-Definitions -- in [CPALGS] { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) other(1) modules(1) cryptographic-Gost-Useful-Definitions(0) 1 } id-GostR3410-2001, GostR3410-2001-PublicKeyParameters -- in [CPALGS] FROM GostR3410-2001-PKISyntax gostR3410-2001-PKISyntax ; -- GOST R 34.10-2001 signature data type GostR3410-2001-Signature ::= OCTET STRING (SIZE (64)) -- GOST R 34.10-2001 signature algorithms and parameters GostR3410-2001-CMSSignatureAlgorithms

Leontiev & Chudov

Standards Track

[Page 22]

RFC 4490

Using GOST with CMS

May 2006

ALGORITHM-IDENTIFIER ::= { { GostR3410-2001-PublicKeyParameters IDENTIFIED BY id-GostR3410-2001 } } END -- GostR3410-2001-SignatureSyntax 11. Acknowledgements This document was created in accordance with "Russian Cryptographic Software Compatibility Agreement", signed by FGUE STC "Atlas", CRYPTO-PRO, Factor-TS, MD PREI, Infotecs GmbH, SPRCIS (SPbRCZI), Cryptocom, R-Alpha. The aim of this agreement is to achieve mutual compatibility of the products and solutions. The authors wish to thank: Microsoft Corporation Russia for providing information about company products and solutions, and also for technical consulting in PKI. RSA Security Russia and Demos Co Ltd for active collaboration and critical help in creation of this document. Russ Housley (Vigil Security, LLC, housley@vigilsec.com) and Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for encouraging the authors to create this document. Prikhodko Dmitriy (VSTU, PrikhodkoDV@volgablob.ru) for invaluable assistance in proofreading this document and verifying the form and the contents of the ASN.1 structures mentioned or used in this document.

Leontiev & Chudov

Standards Track

[Page 23]

RFC 4490

Using GOST with CMS

May 2006

12. 12.1.

References Normative References Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. Popov, V., Kurepkin, I., and S. Leontiev, "Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms", RFC 4357, January 2006. Leontiev, S., Ed. and D. Shefanovskij, Ed., "Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 4491, May 2006. "Cryptographic Protection for Data Processing System", GOST 28147-89, Gosudarstvennyi Standard of USSR, Government Committee of the USSR for Standards, 1989. (In Russian)

[CMS]

[CPALGS]

[CPPK]

[GOST28147]

[GOST3431195] "Information technology. Cryptographic Data Security. Cashing function.", GOST 34.311-95, Council for Standardization, Metrology and Certification of the Commonwealth of Independence States (EASC), Minsk, 1995. (In Russian) [GOST3431095] "Information technology. Cryptographic Data Security. Produce and check procedures of Electronic Digital Signature based on Asymmetric Cryptographic Algorithm.", GOST 34.310-95, Council for Standardization, Metrology and Certification of the Commonwealth of Independence States (EASC), Minsk, 1995. (In Russian) [GOST3431004] "Information technology. Cryptographic Data Security. Formation and verification processes of (electronic) digital signature based on Asymmetric Cryptographic Algorithm.", GOST 34.310-2004, Council for Standardization, Metrology and Certification of the Commonwealth of Independence States (EASC), Minsk, 2004. (In Russian)

Leontiev & Chudov

Standards Track

[Page 24]

RFC 4490

Using GOST with CMS

May 2006

[GOSTR341094] "Information technology. Cryptographic Data Security. Produce and check procedures of Electronic Digital Signatures based on Asymmetric Cryptographic Algorithm.", GOST R 34.10-94, Gosudarstvennyi Standard of Russian Federation, Government Committee of the Russia for Standards, 1994. (In Russian) [GOSTR341001] "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature.", GOST R 34.10-2001, Gosudarstvennyi Standard of Russian Federation, Government Committee of the Russia for Standards, 2001. (In Russian) [GOSTR341194] "Information technology. Cryptographic Data Security. Hashing function.", GOST R 34.10-94, Gosudarstvennyi Standard of Russian Federation, Government Committee of the Russia for Standards, 1994. (In Russian) [PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988. CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.

[RFC2119]

[RFC3851]

[X.208-88]

[X.209-88]

12.2.

Informative References "Russian Federal Government Regulation on Licensing of Selected Activity Categories in Cryptography Area", 23 Sep 2002 N 691. Hoffman, P., "Examples of S/MIME Messages", RFC 4134, July 2005. "Russian Federal Electronic Digital Signature Law", 10 Jan 2002 N 1-FZ.

[CRYPTOLIC]

[RFC4134]

[RFEDSL]

Leontiev & Chudov

Standards Track

[Page 25]

RFC 4490

Using GOST with CMS

May 2006

[RFLLIC]

"Russian Federal Law on Licensing of Selected Activity Categories", 08 Aug 2001 N 128-FZ. B. Schneier, Applied Cryptography, Second Edition, John Wiley & Sons, Inc., 1995.

[Schneier95]

Leontiev & Chudov

Standards Track

[Page 26]

RFC 4490

Using GOST with CMS

May 2006

Authors’ Addresses Serguei Leontiev, Ed. CRYPTO-PRO 38, Obraztsova, Moscow, 127018, Russian Federation EMail: lse@cryptopro.ru

Grigorij Chudov, Ed. CRYPTO-PRO 38, Obraztsova, Moscow, 127018, Russian Federation EMail: chudov@cryptopro.ru

Vladimir Popov CRYPTO-PRO 38, Obraztsova, Moscow, 127018, Russian Federation EMail: vpopov@cryptopro.ru

Alexandr Afanasiev Factor-TS office 711, 14, Presnenskij val, Moscow, 123557, Russian Federation EMail: afa1@factor-ts.ru

Nikolaj Nikishin Infotecs GmbH p/b 35, 80-5, Leningradskij prospekt, Moscow, 125315, Russian Federation EMail: nikishin@infotecs.ru

Boleslav Izotov FGUE STC "Atlas" 38, Obraztsova, Moscow, 127018, Russian Federation EMail: izotov@nii.voskhod.ru

Leontiev & Chudov

Standards Track

[Page 27]

RFC 4490

Using GOST with CMS

May 2006

Elena Minaeva MD PREI build 3, 6A, Vtoroj Troitskij per., Moscow, Russian Federation EMail: evminaeva@mail.ru

Igor Ovcharenko MD PREI Office 600, 14, B.Novodmitrovskaya, Moscow, Russian Federation EMail: igori@mo.msk.ru

Serguei Murugov R-Alpha 4/1, Raspletina, Moscow, 123060, Russian Federation EMail: msm@top-cross.ru

Igor Ustinov Cryptocom office 239, 51, Leninskij prospekt, Moscow, 119991, Russian Federation EMail: igus@cryptocom.ru

Anatolij Erkin SPRCIS (SPbRCZI) 1, Obrucheva, St.Petersburg, 195220, Russian Federation EMail: erkin@nevsky.net

Leontiev & Chudov

Standards Track

[Page 28]

RFC 4490

Using GOST with CMS

May 2006

Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

Leontiev & Chudov

Standards Track

[Page 29]


相关文章:
GOST-R 认证
/GOST-R 证书 СертификатсоответствияГОСТ Р翻译成英文是: Certificate of Conformity GOST R,中文翻译是:GOST-R 合格证书。...
GOST 白俄罗斯认证-俄罗斯标准(GOST-R)认证中心
g o s t r. c n GOST 白俄罗斯认证 俄罗斯 GOST 认证是白俄罗斯计量署授权下的认证机构所 进行的一种符合性确认的活动。白俄罗斯 GOST 证书是证明产 品符合...
GOST R如何办理
其中部分产品必须办理 GOST-R 认证。 GOST-R 认证是俄罗斯政府为保护广大消费者人身和动植物生命安全,保护环境,保护国家安全,加强产 品质量管理,依照法律法规实施的...
GOST-U认证乌克兰认证概述
g o s t r. c n GOST-U 乌克兰认证根据乌克兰有关规定,国际贸易商品目录中的 1~24 类商品在进入乌克兰关境时,均 须提供乌克兰商检部门出具的商品质量合格...
GOST俄罗斯国家标准
俄罗斯国家标准( 俄罗斯国家标准(GOST R)认证介绍 ) 1. GOST 认证的概念 俄罗斯国家标准认证(简称 GOST 认证),是一种证明生产活动的结果、商品、服务符 合俄罗斯...
GOST_8732-78
34.62 36.94 39.21 41.63 15.04 16.48 17.90 19.32 20.72 22.10 ...49.11 52.28 55.45 58.60 61.73 64.86 71.07 77.24 83.36 89.42 ...
俄罗斯GOST-R认证基本概况
俄罗斯GOST-R认证基本概况_机械/仪表_工程科技_专业资料。俄罗斯GOST-R认证基本概况GOST俄罗斯 GOST-R 认证基本概况 俄罗斯认证(GOST)自1995年俄罗斯联邦法律《产品...
GOST 俄罗斯认证标准目录
GOST 俄罗斯认证标准目录_工程科技_专业资料。GOST 俄罗斯认证标准目录,介绍俄罗斯认证标准,中英文对照。GOST 俄罗斯标准目录 GOST 6999-1968 现金出纳机纸 GOST ...
GOST 12815-80
5) 10-2400 per GOST 12820-80 0,6 (6) 10-1600 1,0(10) 10-1600 ...34 23 35 29 39 28 40 36 50 35 51 43 57 42 58 51 65 50 66 61 ...
GOST 21105-87, 26-03-02
GOST 12.2.032-78, GOST 12.2.033-78, GOST 12.2.061-81 and GOST ....10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 using ...
更多相关标签:
yy4490 | 4490高清影院 | ak4490 | ak4490 es9018 | ak4490解码芯片怎么样 | ak4490 cs4398 | ak4495与ak4490的对比 | ak4490 ak4495 |