rfc-4490

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)

S. Leontiev (Editor), G. Chudov (Editor)
date2006-05 streamIETF areasec wgsmime statusPROPOSED STANDARD pages29 canonicalhttps://www.rfc-editor.org/rfc/rfc4490 doi10.17487/RFC4490 errataview
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. [STANDARDS-TRACK]

Extracted elements (27)

design-rationale §1

CMS values are generated using ASN.1 with BER encoding (not DER), following the base CMS specification [RFC 3852]. This document specifies algorithm identifiers and ASN.1 structures but does not re-specify the underlying GOST algorithms, which are defined in Russian national standards.

crypto, email

interoperability-note §1

This document was created in accordance with the "Russian Cryptographic Software Compatibility Agreement" to achieve mutual compatibility among Russian PKI products. The algorithms and structures target the S/MIME and CMS ecosystem as used in that community.

crypto, email

interoperability-note §4.1.1

When keyEncryptionAlgorithm is id-GostR3410-94-CryptoPro-ESDH, KeyWrapAlgorithm MUST be id-Gost28147-89-CryptoPro-KeyWrap; when it is id-GostR3410-2001-CryptoPro-ESDH, KeyWrapAlgorithm MUST be either id-Gost28147-89-CryptoPro-KeyWrap or id-Gost28147-89-None-KeyWrap.

crypto, email

normative-requirement §4.1.1 MUST

Gost28147-89-KeyWrapParameters ukm MUST be absent in key agreement contexts; KeyAgreeRecipientInfo ukm MUST be present and contain exactly eight octets.

crypto

normative-requirement §4.1.1 MUST

In KeyAgreeRecipientInfo for GOST-based key agreement, the version MUST be 3 and the originator MUST be the originatorKey alternative containing the sender's public key.

crypto, email

normative-requirement §4.2.1 MUST

In KeyTransRecipientInfo for GOST key transport, the version MUST be 0 or 3, keyEncryptionAlgorithm and parameters MUST be identical to the recipient public key algorithm, and transportParameters MUST be present with ephemeralPublicKey MUST be present.

crypto, email

normative-requirement §4 MUST

Key agreement and key transport algorithms based on VKO GOST R 34.10-94/2001 MUST be used only with the content encryption algorithm GOST 28147-89.

crypto

normative-requirement §3.2 MUST

Signature algorithm GOST R 34.10-2001 MUST be used conjointly with GOST R 34.11-94.

crypto, email

normative-requirement §3.1 MUST

Signature algorithm GOST R 34.10-94 MUST be used conjointly with the GOST R 34.11-94 message digest algorithm.

crypto, email

normative-requirement §2.1 MUST

The AlgorithmIdentifier parameters field for GOST R 34.11-94 MUST be present and MUST contain NULL. Implementations MAY also accept absent parameters.

crypto

normative-requirement §4.1.1 MUST

The keyEncryptionAlgorithm MUST be id-GostR3410-94-CryptoPro-ESDH or id-GostR3410-2001-CryptoPro-ESDH depending on the recipient's public key algorithm, and the KeyWrapAlgorithm parameter MUST be present.

crypto

normative-requirement §7.2 MUST

When indicating support for GOST 28147-89 via SMIMECapabilities with specific parameter sets, recipients MUST ignore the Gost28147-89-Parameters iv field and only consider the encryptionParamSet field.

email, crypto

normative-requirement §7.1 SHOULD

When using GOST algorithms with S/MIME, the micalg parameter SHOULD be set to "gostr3411-94"; otherwise it MUST be set to "unknown".

email, crypto

protocol-element §5.1

GOST 28147-89 content encryption is identified by OID id-Gost28147-89 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gost28147-89(21) }. Algorithm parameters MUST be present.

crypto, email

protocol-element §6.1

HMAC with GOST R 34.11-94 is identified by OID id-HMACGostR3411-94 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) hmacgostr3411(10) }. It uses the same parameters and OIDs as the GOST R 34.11-94 digest algorithm.

crypto, email

protocol-element §2.1

The GOST R 34.11-94 hash algorithm is identified by OID id-GostR3411-94 { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostr3411(9) }. It produces a 256-bit hash value and is always used with default parameters id-GostR3411-94-CryptoProParamSet.

crypto, email

security-consideration §8

Conforming applications MUST use unique values for ukm and iv. Recipients MAY verify that ukm and iv specified by the sender are unique, to prevent key reuse attacks.

crypto, security

security-consideration §8

It is RECOMMENDED that software verify that signature values, subject public keys, and algorithm parameters conform to GOSTR341001 and GOSTR341094 standards prior to use.

crypto, security

security-consideration §8

The use of GOST algorithm parameters not listed in [CPALGS] (RFC 4357) is NOT RECOMMENDED because cryptographic algorithm parameters directly affect algorithm strength.

crypto, security

security-consideration §8

Use of the same key for both signature and key derivation is NOT RECOMMENDED. Under Russian Federal Electronic Digital Signature Law, signer certificates MUST contain a critical keyUsage extension, and keyUsage MUST NOT include keyEncipherment or keyAgreement.

crypto, security, pkix

wire-format §4.1.1

Gost28147-89-EncryptedKey is a SEQUENCE containing encryptedKey (Gost28147-89-Key), an optional maskKey [0] IMPLICIT Gost28147-89-Key, and macKey (Gost28147-89-MAC). In key agreement, maskKey MUST be absent.

crypto

wire-format §4.1.1

Gost28147-89-KeyWrapParameters is a SEQUENCE containing encryptionParamSet (Gost28147-89-ParamSet OID) and an optional ukm OCTET STRING of SIZE 8.

crypto

wire-format §5.1

Gost28147-89-Parameters is a SEQUENCE containing iv (Gost28147-89-IV: OCTET STRING SIZE 8) and encryptionParamSet (OBJECT IDENTIFIER specifying the parameter set). Both fields are required.

crypto

wire-format §3.2

GostR3410-2001-Signature is an OCTET STRING of SIZE 64: the first 32 octets contain the big-endian representation of s, and the second 32 octets contain the big-endian representation of r, encoding two 256-bit numbers.

crypto

wire-format §3.1

GostR3410-94-Signature is an OCTET STRING of SIZE 64: the first 32 octets contain the big-endian representation of s, and the second 32 octets contain the big-endian representation of r', encoding the two 256-bit signature numbers.

crypto

wire-format §4.2.1

GostR3410-KeyTransport is a SEQUENCE containing sessionEncryptedKey (Gost28147-89-EncryptedKey) and optional transportParameters [0] IMPLICIT GostR3410-TransportParameters. GostR3410-TransportParameters contains encryptionParamSet OID, optional ephemeralPublicKey, and ukm OCTET STRING of SIZE 8.

crypto

wire-format §2.1

GostR3411-94-Digest is an OCTET STRING of SIZE 32, representing the 32-byte digest in little-endian byte order, placed in the DigestedData digest field or Message Digest authenticated attribute.

crypto