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", May 2006

Errata ID: 1885
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-09-17
Rejected by: Tim Polk
Date Rejected: 2010-07-20

Section 2.3.1, 2.3.2 says:

a)  Section 2.3.1, page 7

|  GostR3410-94-PublicKey MUST contain 128 octets of the little-endian
   representation of the public key Y = a^x (mod p), where a and p are
   public key parameters, and x is a private key.

b) Section 2.3.2, page 9

   GostR3410-2001-PublicKey MUST contain 64 octets, where the first 32
|  octets contain the little-endian representation of x and the second
|  32 octets contain the little-endian representation of y.  [...]

It should say:

a)

|  GostR3410-94-PublicKey MUST contain 128 octets of the big-endian
   representation of the public key Y = a^x (mod p), where a and p are
   public key parameters, and x is a private key.

b)

   GostR3410-2001-PublicKey MUST contain 64 octets, where the first 32
|  octets contain the big-endian representation of x and the second
|  32 octets contain the big-endian representation of y.  [...]

Notes:

Rationale:
Inconsistency within the RFC.
Most parts of the memo make use of the Internet-standard
"network byte order". a.k.a. "big-endian byte order", which
also is at the heart of the ASN.1 BER/DER encoding.
Use of mixed endian-ness within a single context, or even
a single specification, is a likely source of implementation
errors and, consequently, interoperability problems.

Cf. the related Errata Note for RFC 4490, EID=1884.
--VERIFIER NOTES--
authors confirmed that little-endian encoding is correct.

Report New Errata