doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc4490.txt b/doc/rfc/rfc4490.txt
new file mode 100644
index 0000000..664b6a9
--- /dev/null
+++ b/doc/rfc/rfc4490.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+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-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  420: SEQUENCE {
+   4    9:  OBJECT IDENTIFIER envelopedData
+  15  405:  [0] {
+  19  401:   SEQUENCE {
+  23    1:    INTEGER 2
+  26  336:    SET {
+  30  332:     [1] {
+  34    1:      INTEGER 3
+  37  101:      [0] {
+  39   99:       [1] {
+  41   28:        SEQUENCE {
+  43    6:         OBJECT IDENTIFIER id-GostR3410-2001
+  51   18:         SEQUENCE {
+  53    7:          OBJECT IDENTIFIER
+         :           id-GostR3410-2001-CryptoPro-XchA-ParamSet
+  62    7:          OBJECT IDENTIFIER
+
+
+
+Leontiev & Chudov           Standards Track                    [Page 14]
+
+RFC 4490                  Using GOST with CMS                   May 2006
+
+
+         :           id-GostR3411-94-CryptoProParamSet
+         :          }
+         :         }
+  71   67:        BIT STRING, encapsulates {
+  74   64:         OCTET STRING
+         :          B3 55 39 F4 67 81 97 2B A5 C4 D9 84 1F 27 FB 81
+         :          ED 08 32 E6 9A D4 F2 00 78 B8 FF 83 64 EA D2 1D
+         :          B0 78 3C 7D FE 03 C1 F4 06 E4 3B CC 16 B9 C5 F6
+         :          F6 19 37 1C 17 B8 A0 AA C7 D1 A1 94 B3 A5 36 20
+         :         }
+         :        }
+         :       }
+ 140   10:      [1] {
+ 142    8:       OCTET STRING 2F F0 F6 D1 86 4B 32 8A
+         :       }
+ 152   30:      SEQUENCE {
+ 154    6:       OBJECT IDENTIFIER id-GostR3410-2001-CryptoPro-ESDH
+ 162   20:       SEQUENCE {
+ 164    7:        OBJECT IDENTIFIER id-Gost28147-89-None-KeyWrap
+ 173    9:        SEQUENCE {
+ 175    7:         OBJECT IDENTIFIER
+         :          id-Gost28147-89-CryptoPro-A-ParamSet
+         :         }
+         :        }
+         :       }
+ 184  179:      SEQUENCE {
+ 187  176:       SEQUENCE {
+ 190  129:        SEQUENCE {
+ 193  109:         SEQUENCE {
+ 195   31:          SET {
+ 197   29:           SEQUENCE {
+ 199    3:            OBJECT IDENTIFIER commonName
+ 204   22:            UTF8String 'GostR3410-2001 example'
+         :            }
+         :           }
+ 228   18:          SET {
+ 230   16:           SEQUENCE {
+ 232    3:            OBJECT IDENTIFIER organizationName
+ 237    9:            UTF8String 'CryptoPro'
+         :            }
+         :           }
+ 248   11:          SET {
+ 250    9:           SEQUENCE {
+ 252    3:            OBJECT IDENTIFIER countryName
+ 257    2:            PrintableString 'RU'
+         :            }
+         :           }
+ 261   41:          SET {
+
+
+
+Leontiev & Chudov           Standards Track                    [Page 15]
+
+RFC 4490                  Using GOST with CMS                   May 2006
+
+
+ 263   39:           SEQUENCE {
+ 265    9:            OBJECT IDENTIFIER emailAddress
+ 276   26:            IA5String 'GostR3410-2001@example.com'
+         :            }
+         :           }
+         :          }
+ 304   16:         INTEGER
+         :          2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21
+         :         }
+ 322   42:        OCTET STRING, encapsulates {
+ 324   40:         SEQUENCE {
+ 326   32:          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
+ 360    4:          OCTET STRING
+         :           93 FD 86 7E
+         :          }
+         :         }
+         :        }
+         :       }
+         :      }
+         :     }
+ 366   56:    SEQUENCE {
+ 368    9:     OBJECT IDENTIFIER data
+ 379   29:     SEQUENCE {
+ 381    6:      OBJECT IDENTIFIER id-Gost28147-89
+ 389   19:      SEQUENCE {
+ 391    8:       OCTET STRING B7 35 E1 7A 07 35 A2 1D
+ 401    7:       OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet
+         :       }
+         :      }
+ 410   12:     [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  423: SEQUENCE {
+   4    9:  OBJECT IDENTIFIER envelopedData
+  15  408:  [0] {
+  19  404:   SEQUENCE {
+  23    1:    INTEGER 0
+  26  339:    SET {
+  30  335:     SEQUENCE {
+  34    1:      INTEGER 0
+  37  129:      SEQUENCE {
+  40  109:       SEQUENCE {
+  42   31:        SET {
+  44   29:         SEQUENCE {
+  46    3:          OBJECT IDENTIFIER commonName
+  51   22:          UTF8String 'GostR3410-2001 example'
+         :          }
+         :         }
+  75   18:        SET {
+  77   16:         SEQUENCE {
+  79    3:          OBJECT IDENTIFIER organizationName
+  84    9:          UTF8String 'CryptoPro'
+         :          }
+         :         }
+  95   11:        SET {
+  97    9:         SEQUENCE {
+  99    3:          OBJECT IDENTIFIER countryName
+ 104    2:          PrintableString 'RU'
+         :          }
+         :         }
+ 108   41:        SET {
+ 110   39:         SEQUENCE {
+ 112    9:          OBJECT IDENTIFIER emailAddress
+ 123   26:          IA5String 'GostR3410-2001@example.com'
+         :          }
+         :         }
+         :        }
+ 151   16:       INTEGER
+         :        2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21
+         :       }
+ 169   28:      SEQUENCE {
+ 171    6:       OBJECT IDENTIFIER id-GostR3410-2001
+ 179   18:       SEQUENCE {
+ 181    7:        OBJECT IDENTIFIER
+
+
+
+Leontiev & Chudov           Standards Track                    [Page 17]
+
+RFC 4490                  Using GOST with CMS                   May 2006
+
+
+         :         id-GostR3410-2001-CryptoPro-XchA-ParamSet
+ 190    7:        OBJECT IDENTIFIER
+         :         id-GostR3411-94-CryptoProParamSet
+         :        }
+         :       }
+ 199  167:      OCTET STRING, encapsulates {
+ 202  164:       SEQUENCE {
+ 205   40:        SEQUENCE {
+ 207   32:         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
+ 241    4:         OCTET STRING
+         :          36 6D 98 B7
+         :         }
+ 247  120:        [0] {
+ 249    7:         OBJECT IDENTIFIER
+         :          id-Gost28147-89-CryptoPro-A-ParamSet
+ 258   99:         [0] {
+ 260   28:          SEQUENCE {
+ 262    6:           OBJECT IDENTIFIER id-GostR3410-2001
+ 270   18:           SEQUENCE {
+ 272    7:            OBJECT IDENTIFIER
+         :             id-GostR3410-2001-CryptoPro-XchA-ParamSet
+ 281    7:            OBJECT IDENTIFIER
+         :             id-GostR3411-94-CryptoProParamSet
+         :            }
+         :           }
+ 290   67:          BIT STRING encapsulates {
+ 293   64:           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
+         :           }
+         :          }
+ 359    8:         OCTET STRING
+         :          97 95 E3 2C 2B AD 2B 0C
+         :         }
+         :        }
+         :       }
+         :      }
+         :     }
+ 369   56:    SEQUENCE {
+ 371    9:     OBJECT IDENTIFIER data
+ 382   29:     SEQUENCE {
+ 384    6:      OBJECT IDENTIFIER id-Gost28147-89
+ 392   19:      SEQUENCE {
+ 394    8:       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    7:       OBJECT IDENTIFIER id-Gost28147-89-CryptoPro-A-ParamSet
+         :       }
+         :      }
+ 413   12:     [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.  References
+
+12.1.  Normative References
+
+   [CMS]         Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+                 3852, July 2004.
+
+   [CPALGS]      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.
+
+   [CPPK]        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.
+
+   [GOST28147]   "Cryptographic Protection for Data Processing System",
+                 GOST 28147-89, Gosudarstvennyi Standard of USSR,
+                 Government Committee of the USSR for Standards, 1989.
+                 (In Russian)
+
+   [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.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3851]     Ramsdell, B., "Secure/Multipurpose Internet Mail
+                 Extensions (S/MIME) Version 3.1 Message Specification",
+                 RFC 3851, July 2004.
+
+   [X.208-88]    CCITT.  Recommendation X.208: Specification of Abstract
+                 Syntax Notation One (ASN.1).  1988.
+
+   [X.209-88]    CCITT.  Recommendation X.209: Specification of Basic
+                 Encoding Rules for Abstract Syntax Notation One
+                 (ASN.1).  1988.
+
+12.2.  Informative References
+
+   [CRYPTOLIC]   "Russian Federal Government Regulation on Licensing of
+                 Selected Activity Categories in Cryptography Area", 23
+                 Sep 2002 N 691.
+
+   [RFC4134]     Hoffman, P., "Examples of S/MIME Messages", RFC 4134,
+                 July 2005.
+
+   [RFEDSL]      "Russian Federal Electronic Digital Signature Law", 10
+                 Jan 2002 N 1-FZ.
+
+
+
+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.
+
+   [Schneier95]  B. Schneier, Applied Cryptography, Second Edition, John
+                 Wiley & Sons, Inc., 1995.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+