rfc-4491

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

S. Leontiev (Editor), D. Shefanovski (Editor)
date2006-05 streamIETF areasec wgpkix statusPROPOSED STANDARD pages20 canonicalhttps://www.rfc-editor.org/rfc/rfc4491 doi10.17487/RFC4491
This document supplements RFC 3279. It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509 Public Key Infrastructure (PKI). [STANDARDS-TRACK]

updates

Extracted elements (20)

design-rationale §1

This document supplements RFC 3279 specifically to support the 'Russian Cryptographic Software Compatibility Agreement' community, providing encoding formats and identifiers for GOST algorithms to achieve mutual compatibility among Russian PKI products and solutions.

crypto, pkix

interoperability-note §2.3.2

Some erroneous applications discard zero bits at the end of the BIT STRING containing the GOST R 34.10-2001 public key. It is RECOMMENDED to pad the bit string with zeroes up to 528 bits (66 octets) on decoding to handle such applications.

pkix, crypto

normative-requirement §2 MUST

Certification authorities (CAs) and/or applications conforming to this standard MUST support at least one of the specified public key and signature algorithms.

crypto, pkix

normative-requirement §2.2 MUST

The GOST R 34.10-94 and GOST R 34.10-2001 signature algorithms MUST always be used with the one-way hash function GOST R 34.11-94.

crypto, pkix

normative-requirement §2.1.1 MUST

The GOST R 34.11-94 hash function MUST always be used with parameter set identified by id-GostR3411-94-CryptoProParamSet.

crypto, pkix

normative-requirement §2.3.1 MUST NOT

The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly for a certificate containing a GOST R 34.10-94 public key.

pkix, crypto

normative-requirement §2.2.1 SHALL

To convert a GOST signature octet string to a bit string for use in certificates and CRLs, the most significant bit of the first octet SHALL become the first bit of the bit string, continuing through the least significant bit of the last octet.

crypto, pkix

normative-requirement §2.3 SHOULD NOT

Use of the same GOST key for both signature and key derivation is NOT RECOMMENDED. The intended application for the key MAY be indicated in the keyUsage certificate extension.

crypto, pkix

normative-requirement §2.3.1 SHALL

When parameters are absent from a GOST R 34.10-94 or GOST R 34.10-2001 AlgorithmIdentifier, they are inherited per RFC 3280 Section 6.1. When working_public_key_parameters is null, the certificate and any verifiable signature SHALL be rejected.

pkix, crypto

protocol-element §2.3.2

GOST R 34.10-2001 public keys are identified by OID id-GostR3410-2001 (1 2 643 2 2 19). The SubjectPublicKeyInfo.algorithm.algorithm field MUST be set to id-GostR3410-2001 for such keys.

crypto, pkix

protocol-element §2.3.1

GOST R 34.10-94 public keys are identified by OID id-GostR3410-94 (1 2 643 2 2 20). The SubjectPublicKeyInfo.algorithm.algorithm field MUST be set to this OID for such keys.

crypto, pkix

protocol-element §2.2.2

The OID for the GOST R 34.10-2001 signature algorithm combined with GOST R 34.11-94 hash is id-GostR3411-94-with-GostR3410-2001 (1 2 643 2 2 3). When this identifier appears in an AlgorithmIdentifier, the parameters field SHALL be omitted.

crypto, pkix

security-consideration §3 RECOMMENDED

It is RECOMMENDED that applications verify signature values and subject public keys conform to GOST R 34.10-2001 and GOST R 34.10-94 standards prior to use.

crypto, pkix, security

security-consideration §3 RECOMMENDED

It is RECOMMENDED that CAs and applications ensure the private key for creating signatures is not used beyond its allowed validity period, typically 15 months for both GOST R 34.10-94 and GOST R 34.10-2001 algorithms.

crypto, pkix, security

security-consideration §3 MUST

When a certificate is used to support digital signatures as an analogue to manual signatures under Russian Federal Electronic Digital Signature Law, the certificate MUST contain a critical keyUsage extension, and keyUsage MUST NOT include keyEncipherment or keyAgreement.

pkix, security, crypto

wire-format §2.3.2

The GOST R 34.10-2001 public key (GostR3410-2001-PublicKey) MUST be an OCTET STRING of exactly 64 octets: the first 32 octets contain the little-endian representation of the elliptic curve point x-coordinate, and the second 32 octets contain the little-endian representation of the y-coordinate.

crypto, pkix

wire-format §2.2.2

The GOST R 34.10-2001 signature value is a 64-octet string: the first 32 octets contain the big-endian representation of s, and the second 32 octets contain the big-endian representation of r. The same octet-string-to-bit-string conversion process as GOST R 34.10-94 MUST be used for certificates and CRLs.

crypto, pkix

wire-format §2.3.1

The GOST R 34.10-94 public key (GostR3410-94-PublicKey) MUST be ASN.1 DER encoded as an OCTET STRING of 128 octets containing the little-endian representation of Y = a^x (mod p), encapsulated within the BIT STRING subjectPublicKey field.

crypto, pkix

wire-format §2.2.1

The GOST R 34.10-94 signature value is a 64-octet string: the first 32 octets contain the big-endian representation of s, and the second 32 octets contain the big-endian representation of r'. When used in certificates and CRLs, this octet string must be converted to a bit string.

crypto, pkix

wire-format §2.3.1

The GostR3410-94-PublicKeyParameters structure is a SEQUENCE containing publicKeyParamSet (OID), digestParamSet (OID), and optionally encryptionParamSet (OID, defaulting to id-Gost28147-89-CryptoPro-A-ParamSet).

crypto, pkix