Home   A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z  

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) :: RFC4490








Network Working Group                                   S. Leontiev, Ed.
Request for Comments: 4490                                G. Chudov, Ed.
Category: Standards Track                                     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 "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
   [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-GostR3411-
   94-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.10-
   2001 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 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) }



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-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].

      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.





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-89-
   KeyWrapParameters encryptionParamSet is used for all encryption
   operations.

   The resulting encrypted key (CEK_ENC) is placed in the Gost28147-89-
   EncryptedKey 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 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 the Gost28147-89-
   EncryptedKey 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-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.

   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-89-
   Parameters structure.  Recipients MUST ignore the Gost28147-89-
   Parameters 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  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 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  296: SEQUENCE {
   4    9:  OBJECT IDENTIFIER signedData
  15  281:  [0] {
  19  277:   SEQUENCE {
  23    1:    INTEGER 1



Leontiev & Chudov           Standards Track                    [Page 12]

RFC 4490                  Using GOST with CMS                   May 2006


  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'
         :          }
         :         }
 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



Leontiev & Chudov           Standards Track                    [Page 13]

RFC 4490                  Using GOST with CMS                   May 2006


         :       }
 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
|HgEDQwAEQE0rLzOQ5tyj3VUqzd/g7/sx93N+Tv+/eImKK8PNMZQESw5gSJYf28dd
|Em/askCKd7W96vLsNMsjn5uL3Z4SwPYECJeV4ywrrSsMMDgGCSqGSIb3DQEHATAd
|BgYqhQMCAhUwEwQIvBCLHwv/NCkGByqFAwICHwGADKqOch3uT7Mu4w+hNw==
|


 

RFC, FYI, BCP