Network Working Group A.O. Makarov, Ed. Internet-Draft G.A. Sadofev Intended status: Informational CryptoPro Expires: 12 December 2026 10 June 2026 Using GOST Cryptographic Algorithms for JWT security draft-makarov-gostjwa-00 Abstract This specification registers cryptographic algorithms and identifiers for GOST R 34.10 digital signatures and public keys, GOST R 34.11 hash functions, GOST 34.12 encryption algorithms to be used with JSON Web Signatures (JWS), JSON Web Encryption (JWE), and JSON Web Keys (JWK) specifications. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Makarov & Sadofev Expires 12 December 2026 [Page 1] Internet-Draft Using GOST Algorithms for JWT June 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Cryptographic Algorithms for Digital Signatures and MACs . . 4 2.1. "alg" (Algorithm) Header Parameter Values for JWS . . . . 4 2.2. Digital Signature with GOST R 34.10-2012 . . . . . . . . 5 2.3. HMAC with GOST R 34.11-2012 Functions . . . . . . . . . . 6 3. Cryptographic Algorithms for Key Management . . . . . . . . . 7 3.1. "alg" (Algorithm) Header Parameter Values for JWE . . . . 7 3.2. Key agreement using KEG algorithm . . . . . . . . . . . . 8 4. Cryptographic Algorithms for Content Encryption . . . . . . . 9 4.1. "enc" (Encryption Algorithm) Header Parameter Values for JWE . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Content encryption with GM256MGM . . . . . . . . . . 10 4.1.2. Content encryption with GK256MGM . . . . . . . . . . 10 5. Cryptographic Algorithms for Keys . . . . . . . . . . . . . . 10 5.1. Parameters for Elliptic Curve Keys . . . . . . . . . . . 10 5.1.1. Parameters for Elliptic Curve Public Keys . . . . . . 11 5.1.2. Parameters for Elliptic Curve Private Keys . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Algorithm Identifier Cross-Reference . . . . . . . . 16 A.1. Digital Signature Algorithm Identifier Cross-Reference . 16 Appendix B. Values of the Parameter Sets . . . . . . . . . . . . 17 Appendix C. JWS Examples . . . . . . . . . . . . . . . . . . . . 20 C.1. Example JWS Using GS256 G01-256XA . . . . . . . . . . . . 20 C.1.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 20 C.1.2. Validating . . . . . . . . . . . . . . . . . . . . . 23 C.2. Example JWS Using GS512 G12-512B . . . . . . . . . . . . 23 C.2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 23 C.2.2. Validating . . . . . . . . . . . . . . . . . . . . . 26 C.3. Example JWS Using HMAC HG256 . . . . . . . . . . . . . . 26 C.3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 26 C.3.2. Validating . . . . . . . . . . . . . . . . . . . . . 28 C.4. Example JWS Using HMAC HG512 . . . . . . . . . . . . . . 28 C.4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . 28 C.4.2. Validating . . . . . . . . . . . . . . . . . . . . . 30 Appendix D. JWE Examples . . . . . . . . . . . . . . . . . . . . 30 D.1. Using GKEG-KEXP15M GS256 G01-256XA with GM256MGM . . . . 30 D.1.1. Content Encryption Key (CEK) . . . . . . . . . . . . 31 D.1.2. Key Encryption . . . . . . . . . . . . . . . . . . . 31 D.1.3. Encoding JWE Protected Header . . . . . . . . . . . . 32 D.1.4. Initialization Vector . . . . . . . . . . . . . . . . 33 D.1.5. Additional Authenticated Data . . . . . . . . . . . . 33 Makarov & Sadofev Expires 12 December 2026 [Page 2] Internet-Draft Using GOST Algorithms for JWT June 2026 D.1.6. Content Encryption . . . . . . . . . . . . . . . . . 34 D.1.7. Complete Representation . . . . . . . . . . . . . . . 34 D.1.8. Validation . . . . . . . . . . . . . . . . . . . . . 35 D.2. Using GKEG-KEXP15K GS512 G12-512B with GK256MGM . . . . . 35 D.2.1. Content Encryption Key (CEK) . . . . . . . . . . . . 36 D.2.2. Key Encryption . . . . . . . . . . . . . . . . . . . 36 D.2.3. Encoding JWE Protected Header . . . . . . . . . . . . 37 D.2.4. Initialization Vector . . . . . . . . . . . . . . . . 39 D.2.5. Additional Authenticated Data . . . . . . . . . . . . 39 D.2.6. Content Encryption . . . . . . . . . . . . . . . . . 39 D.2.7. Complete Representation . . . . . . . . . . . . . . . 40 D.2.8. Validation . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 1. Introduction This document specifies cryptographic algorithms and identifiers for GOST R 34.10 digital signatures and public keys, GOST R 34.11 hash functions, GOST 34.12 encryption algorithms to be used with JSON Web Signatures (JWS) [RFC7515], JSON Web Encryption (JWE) [RFC7516] and JSON Web Keys (JWK) [RFC7517] specifications. This document also describes the semantics and operations that are specific to these algorithms and key types. 1.1. Terminology The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14 [RFC2119], [RFC8174] when, and only when, they appear in all capitals, as shown here. The terms "JSON Web Signature (JWS)", "Base64url Encoding", "Header Parameter", "JOSE Header", "JWS Payload", "JWS Protected Header", "JWS Signature", "JWS Signing Input", and "Unsecured JWS" are defined by the JWS specification [RFC7515]. The terms "JSON Web Encryption (JWE)", "Additional Authenticated Data (AAD)", "Authentication Tag", "Content Encryption Key (CEK)", "Direct Encryption", "Direct Key Agreement", "JWE Authentication Tag", "JWE Ciphertext", "JWE Encrypted Key", "JWE Initialization Vector", "JWE Protected Header", "Key Agreement with Key Wrapping", "Key Encryption", "Key Management Mode", and "Key Wrapping" are defined by the JWE specification [RFC7516]. Makarov & Sadofev Expires 12 December 2026 [Page 3] Internet-Draft Using GOST Algorithms for JWT June 2026 The terms "JSON Web Key (JWK)" and "JWK Set" are defined by the JWK specification [RFC7517]. The terms "Ciphertext", "Digital Signature", "Initialization Vector", "Message Authentication Code (MAC)", and "Plaintext" are defined by the "Internet Security Glossary, Version 2" [RFC4949]. The term "Base64urlUInt" is defined by the JWA specification [RFC7518]. 2. Cryptographic Algorithms for Digital Signatures and MACs JWS uses cryptographic algorithms to digitally sign or create a MAC of the contents of the JWS Protected Header and the JWS Payload. 2.1. "alg" (Algorithm) Header Parameter Values for JWS The table below is the set of "alg" (algorithm) Header Parameter values defined by this specification for use with JWS, each of which is explained in more detail in the following sections: +=============+=========================+================+ | "alg" Param | Digital Signature or | Implementation | | Value | MAC Algorithm | requirements | +=============+=========================+================+ | GS256 | GOST R 34.10-2012 (256) | Required | | | Digital Signature using | | | | GOST R 34.11-2012 (256) | | +-------------+-------------------------+----------------+ | GS512 | GOST R 34.10-2012 (512) | Recommended+ | | | Digital Signature using | | | | GOST R 34.11-2012 (512) | | +-------------+-------------------------+----------------+ | HG256 | HMAC using GOST R | Recommended+ | | | 34.11-2012 (256) | | +-------------+-------------------------+----------------+ | HG512 | HMAC using GOST R | Recommended+ | | | 34.11-2012 (512) | | +-------------+-------------------------+----------------+ Table 1 The use of "+" in the Implementation Requirements column indicates that the requirement strength is likely to be increased in a future version of the specification. Makarov & Sadofev Expires 12 December 2026 [Page 4] Internet-Draft Using GOST Algorithms for JWT June 2026 See Appendix A.1 for a table cross-referencing the JWS digital signature and MAC "alg" (algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages. 2.2. Digital Signature with GOST R 34.10-2012 This section defines the use of the GOST R 34.10-2012 signature algorithm as defined in Section 6 of [RFC7091], using GOST R 34.11-2012 [RFC6986] cryptographic hash function. GOST R 34.10-2012 SHOULD be instantiated using elliptic curve parameters from [RFC7836] and Section 5.1.1.2 of this document. The GOST R 34.10-2012 (256) signature using GOST R 34.11-2012 (256) is generated as follows: 1. Generate a digital signature of the JWS Signing Input using GOST R 34.10-2012 (256) with GOST R 34.11-2012 (256) hash with the desired private key. The output will be the pair (R, S), where R and S are 256-bit unsigned integers. 2. Turn R and S into octet sequences in big-endian order, with each array being 32 octets long. The octet sequence representations MUST NOT be shortened to omit any leading zero octets contained in the values. 3. Concatenate the two octet sequences in the order S and then R. (Note that some GOST R 34.10-2012 implementations will directly produce this concatenation as their output.) 4. The resulting 64-octet sequence is the JWS Signature value. The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is a digital signature value computed using the corresponding algorithm: +===================+=========================================+ | "alg" Param Value | Digital Signature Algorithm | +===================+=========================================+ | GS256 | GOST R 34.10-2012 (256) Digital | | | Signature using GOST R 34.11-2012 (256) | +-------------------+-----------------------------------------+ | GS512 | GOST R 34.10-2012 (512) Digital | | | Signature using GOST R 34.11-2012 (512) | +-------------------+-----------------------------------------+ Table 2 Makarov & Sadofev Expires 12 December 2026 [Page 5] Internet-Draft Using GOST Algorithms for JWT June 2026 The GOST R 34.10-2012 (256) digital signature using GOST R 34.11-2012 for a JWS is validated as follows: 1. The JWS Signature value MUST be a 64-octet sequence. If it is not a 64-octet sequence, the validation has failed. 2. Split the 64-octet sequence into two 32-octet sequences. The first octet sequence represents S, and the second R. The values S and R are represented as octet sequences in big-endian octet order. Turn S and R into 256-bit unsigned integers. 3. Submit the JWS Signing Input, (R, S) and the public key (x, y) to the GOST R 34.10-2012 (256) validator using GOST R 34.11-2012 (256). Signing and validation with the GOST R 34.10-2012 (512) using GOST R 34.11-2012 (512) algorithm is performed identically to the procedure for GOST R 34.10-2012 (256) using GOST R 34.11-2012 (256), just using the corresponding hash algorithms with correspondingly larger result values. For GOST R 34.10-2012 (512) using GOST R 34.11-2012 (512), S and R will be 512 bits each, resulting in a 128-octet sequence. 2.3. HMAC with GOST R 34.11-2012 Functions Hash-based Message Authentication Codes (HMACs) enable one to use a secret plus a cryptographic hash function to generate a MAC. This can be used to demonstrate that whoever generated the MAC was in possession of the MAC key. The algorithm for implementing and validating HMACs is provided in [RFC2104]. HMAC transformations based on GOST R 34.11-2012 [!RFC6986] cryptographic hash function defined in [RFC7836]. A key of the same size as the hash output (for instance, 256 bits for "HG256") or larger MUST be used with this algorithm. The HMAC GOST R 34.11-2012 (256) MAC is generated per [RFC2104], using GOST R 34.11-2012 (256) as the hash algorithm "H", using the JWS Signing Input as the "text" value, and using the shared key. The HMAC output value is the JWS Signature. The following "alg" (algorithm) Header Parameter values are used to indicate that the JWS Signature is an HMAC value computed using the corresponding algorithm: Makarov & Sadofev Expires 12 December 2026 [Page 6] Internet-Draft Using GOST Algorithms for JWT June 2026 +===================+====================================+ | "alg" Param Value | Digital Signature Algorithm | +===================+====================================+ | HG256 | HMAC using GOST R 34.11-2012 (256) | +-------------------+------------------------------------+ | HG512 | HMAC using GOST R 34.11-2012 (512) | +-------------------+------------------------------------+ Table 3 The HMAC GOST R 34.11-2012 (256) for a JWS is validated by computing an HMAC value per [RFC2104], using GOST R 34.11-2012 (256) as the hash algorithm "H", using the received JWS Signing Input as the "text" value, and using the shared key. This computed HMAC value is then compared to the result of base64url decoding the received encoded JWS Signature value. The comparison of the computed HMAC value to the JWS Signature value MUST be done in a constant-time manner to thwart timing attacks. Alternatively, the computed HMAC value can be base64url encoded and compared to the received encoded JWS Signature value (also in a constant-time manner), as this comparison produces the same result as comparing the unencoded values. In either case, if the values match, the HMAC has been validated. Securing content and validation with the GOST R 34.11-2012 (512) algorithm is performed identically to the procedure for HMAC GOST R 34.11-2012 (512), just using the corresponding hash algorithms with correspondingly larger minimum key sizes and result values of 512 bits each for GOST R 34.11-2012 (512). 3. Cryptographic Algorithms for Key Management JWE uses cryptographic algorithms to encrypt or determine the Content Encryption Key (CEK). 3.1. "alg" (Algorithm) Header Parameter Values for JWE The table below is the set of "alg" (algorithm) Header Parameter values that are defined by this specification for use with JWE. These algorithms are used to encrypt the CEK, producing the JWE Encrypted Key, or to use key agreement to agree upon the CEK. Makarov & Sadofev Expires 12 December 2026 [Page 7] Internet-Draft Using GOST Algorithms for JWT June 2026 +==============+==========================+========+================+ | "alg" Param | Key Management | More | Implementation | | Value | Algorithm | Header | requirements | | | | Params | | +==============+==========================+========+================+ | GKEG-KEXP15M | Key agreement using | ukm, | Required | | | KEG algorithm and | epk | | | | KExp15 Magma key | | | | | wrap algorithm | | | +--------------+--------------------------+--------+----------------+ | GKEG-KEXP15K | Key agreement using | ukm, | Required | | | KEG algorithm and | epk | | | | KExp15 Kuznechik | | | | | key wrap algorithm | | | +--------------+--------------------------+--------+----------------+ Table 4 The More Header Params column indicates what additional Header Parameters are used by the algorithm, beyond "alg", which all use. All produce a JWE Encrypted Key value. 3.2. Key agreement using KEG algorithm The KEG algorithm for a content encryption key CEK is defined in section 8.3.1 of [RFC9189]. * Generate a new ephemeral private key d_eph using the algorithm and parameters of the recipient's public key. A new key MUST be generated for each key agreement operation. * Compute a point on the elliptic curve E using the fixed point P specified in the curve's parameters (see Section 5.1.1.2): Q_eph = d_eph * P * The public key Q_eph is placed in the "epk" header parameter value. This key is represented as a JSON Web Key [RFC7517] public key value (see Section 5.1.1). The algorithm and parameters of the generated public key MUST match the algorithm and parameters of the recipient's public key. * Generate at random a unique 32-octet string UKM. The base64url encoded UKM value is placed in the value of the "ukm" header parameter. * Calculate K_Exp_MAC || K_Exp_ENC = KEG(d_eph, Q_r, UKM) Makarov & Sadofev Expires 12 December 2026 [Page 8] Internet-Draft Using GOST Algorithms for JWT June 2026 * Calculate the export representation of the CEK using KExp15 algorithm defined in section 8.2.1 of [RFC9189]: K_EXP = KExp15(CEK, K_Exp_MAC, K_Exp_ENC, UKM[25..(24 + n/2)]) where either Kuznyechik [RFC7801] (for the "GKEG-KEXP15K" key agreement algorithm) or Magma [RFC8891] (for the "GKEG-KEXP15M" key agreement algorithm) is used as a base block cipher for the encryption and MAC algorithm. n denotes the block length in bytes of the corresponding base encryption algorithm. 4. Cryptographic Algorithms for Content Encryption JWE uses cryptographic algorithms to encrypt and integrity-protect the plaintext and to integrity-protect the Additional Authenticated Data. All algorithms defined by this specification operate in MGM mode described by [RFC9058]. 4.1. "enc" (Encryption Algorithm) Header Parameter Values for JWE The table below is the set of "enc" (encryption algorithm) Header Parameter values that are defined by this specification for use with JWE. +==========+=================================+================+ | "enc" | Content Encryption Algorithm | Implementation | | Param | | Requirements | | Value | | | +==========+=================================+================+ | GM256MGM | Authenticated encryption using | Required | | | MGM mode ([RFC9058]) with GOST | | | | 34.12-2015 Magma algorithm | | | | ([RFC8891]) as E_K function | | +----------+---------------------------------+----------------+ | GK256MGM | Authenticated encryption using | Required | | | MGM mode ([RFC9058]) with GOST | | | | 34.12-2015 Kuznechik algorithm | | | | ([RFC7801]) as the E_K function | | +----------+---------------------------------+----------------+ Table 5 All encryption algorithms use a JWE Initialization Vector value and produce JWE Ciphertext and JWE Authentication Tag values. Makarov & Sadofev Expires 12 December 2026 [Page 9] Internet-Draft Using GOST Algorithms for JWT June 2026 The (n-1)-bit ICN value used in MGM mode [RFC9058] MUST be unique for each message that is encrypted under the given key, where n is the block size in bits of the corresponding cipher. The value included in the "iv" parameter is formed from the MGM mode ICN value, represented as an n/8-octet big-endian string with the most significant bit set to 0. 4.1.1. Content encryption with GM256MGM This section defines the specifics of performing authenticated encryption with the GOST 34.12-2015 block cipher algorithm with 64-bit block size and 256-bit key length (Magma) as specified in [RFC8891]. The algorithms operates in MGM mode as described by [RFC9058]. An ICN of size 63 bits MUST be used. The requested size of the Authentication Tag output MUST be equal to 64 bits. 4.1.2. Content encryption with GK256MGM This section defines the specifics of performing authenticated encryption with the GOST 34.12-2015 block cipher algorithm with 128-bit block size and 256-bit key length (Kuznechik) as specified in [RFC7801]. The algorithms operates in MGM mode as described by [RFC9058]. An ICN of size 127 bits MUST be used. The requested size of the Authentication Tag output MUST be equal to 128 bits. 5. Cryptographic Algorithms for Keys This specification defines asymmetric keys to use with the GOST R 34.10-2012 signature algorithm. 5.1. Parameters for Elliptic Curve Keys JWKs can represent Elliptic Curve [RFC7091] keys. Makarov & Sadofev Expires 12 December 2026 [Page 10] Internet-Draft Using GOST Algorithms for JWT June 2026 5.1.1. Parameters for Elliptic Curve Public Keys An Elliptic Curve public key is represented by a pair of coordinates drawn from a finite field, which together define a point on an Elliptic Curve. The following members MUST be present for all Elliptic Curve public keys defined by this specification: * "kty", * "crv" * "x" * "y" 5.1.1.1. "kty" (Key Type) Parameter The "kty" (key type) parameter identifies the cryptographic algorithm family used with the key as defined in [RFC7517]. Key type value used by this specification is "EC". 5.1.1.2. "crv" (Curve) Parameter The "crv" (curve) parameter identifies the cryptographic curve used with the key. Curve values for algorithms used by this specification are: * G01-256A * G01-256B * G01-256C * G12-256A * G12-256B * G12-256C * G12-256D * G12-512A * G12-512B * G12-512C The "crv" parameter values correspond to the following curve identifiers: Makarov & Sadofev Expires 12 December 2026 [Page 11] Internet-Draft Using GOST Algorithms for JWT June 2026 +=========+===========================================+============+ |"crv" | Curve Identifier Value | Coordinate | |value | | Size | +=========+===========================================+============+ |G01-256A | id-GostR3410-2001-CryptoPro-A-ParamSet | 32 octets | +---------+-------------------------------------------+------------+ |G01-256B | id-GostR3410-2001-CryptoPro-B-ParamSet | 32 octets | +---------+-------------------------------------------+------------+ |G01-256C | id-GostR3410-2001-CryptoPro-C-ParamSet | 32 octets | +---------+-------------------------------------------+------------+ |G01-256XA| id-GostR3410-2001-CryptoPro-XchA-ParamSet | 32 octets | +---------+-------------------------------------------+------------+ |G01-256XB| id-GostR3410-2001-CryptoPro-XchB-ParamSet | 32 octets | +---------+-------------------------------------------+------------+ |G12-256A | id-tc26-gost-3410-2012-256-paramSetA | 32 octets | +---------+-------------------------------------------+------------+ |G12-256B | id-tc26-gost-3410-2012-256-paramSetB | 32 octets | +---------+-------------------------------------------+------------+ |G12-256C | id-tc26-gost-3410-2012-256-paramSetC | 32 octets | +---------+-------------------------------------------+------------+ |G12-256D | id-tc26-gost-3410-2012-256-paramSetD | 32 octets | +---------+-------------------------------------------+------------+ |G12-512A | id-tc26-gost-3410-12-512-paramSetA | 64 octets | +---------+-------------------------------------------+------------+ |G12-512B | id-tc26-gost-3410-12-512-paramSetB | 64 octets | +---------+-------------------------------------------+------------+ |G12-512C | id-tc26-gost-3410-2012-512-paramSetC | 64 octets | +---------+-------------------------------------------+------------+ Table 6 Curve identifiers * id-GostR3410-2001-CryptoPro-A-ParamSet * id-GostR3410-2001-CryptoPro-B-ParamSet * id-GostR3410-2001-CryptoPro-C-ParamSet * id-GostR3410-2001-CryptoPro-XchA-ParamSet * id-GostR3410-2001-CryptoPro-XchB-ParamSet are defined in [RFC4357]; * id-tc26-gost-3410-2012-256-paramSetA * id-tc26-gost-3410-12-512-paramSetA * id-tc26-gost-3410-12-512-paramSetB * id-tc26-gost-3410-2012-512-paramSetC are defined in [RFC7836]. Makarov & Sadofev Expires 12 December 2026 [Page 12] Internet-Draft Using GOST Algorithms for JWT June 2026 In addition to these parameter sets, this specification defines the following three parameter sets according to [R-1323565.1.024-2019]: id-tc26-gost-3410-2012-256-paramSetB ::= {iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) constants(2) sign-constants(1) gost-3410-12-256-constants(1) paramSeB(2)} id-tc26-gost-3410-2012-256-paramSetC ::= {iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) constants(2) sign-constants(1) gost-3410-12-256-constants(1) paramSeB(3)} id-tc26-gost-3410-2012-256-paramSetD ::= {iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) constants(2) sign-constants(1) gost-3410-12-256-constants(1) paramSeB(4)} The corresponding values of the parameter sets can be found in Appendix B. 5.1.1.3. "x" (X Coordinate) Parameter The "x" (x coordinate) parameter contains the x coordinate for the Elliptic Curve point. It is represented as the base64url encoding of the octet string containing the little-endian representation of the coordinate. The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter. For example, if the value of "crv" is "G12-256A", the octet string MUST be 32 octets long, and 64 octets long for "G12-512A". 5.1.1.4. "y" (Y Coordinate) Parameter The "y" (y coordinate) parameter contains the y coordinate for the Elliptic Curve point. It is represented as the base64url encoding of the octet string containing the little-endian representation of the coordinate. The length of this octet string MUST be the full size of a coordinate for the curve specified in the "crv" parameter. For example, if the value of "crv" is "G12-256A", the octet string MUST be 32 octets long, and 64 octets long for "G12-512A". 5.1.2. Parameters for Elliptic Curve Private Keys In addition to the members used to represent Elliptic Curve public keys, the following member MUST be present to represent Elliptic Curve private keys. Makarov & Sadofev Expires 12 December 2026 [Page 13] Internet-Draft Using GOST Algorithms for JWT June 2026 5.1.2.1. "d" (ECC Private Key) Parameter The "d" (ECC private key) parameter contains the Elliptic Curve private key value. It is represented as the base64url encoding of the octet string containing the little-endian representation. The length of this octet string MUST be ceiling(log-base-2(n)/8) octets (where n is the order of the curve). 6. Security Considerations This entire document is about security considerations. 7. IANA Considerations This document has no IANA actions. 8. References 8.1. Normative References [R-1323565.1.023-2018] Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic information security. Usage of GOST R 34.10-2012 and GOST R 34.11-2012 algorithms in certificate, CRL and PKCS#10 certificate request in X.509 public key infrastructure", R 1323565.1.023-2018, 2018. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4357] 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, DOI 10.17487/RFC4357, January 2006, . [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 2013, . Makarov & Sadofev Expires 12 December 2026 [Page 14] Internet-Draft Using GOST Algorithms for JWT June 2026 [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: Digital Signature Algorithm", RFC 7091, DOI 10.17487/RFC7091, December 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC7801] Dolmatov, V., Ed., "GOST R 34.12-2015: Block Cipher "Kuznyechik"", RFC 7801, DOI 10.17487/RFC7801, March 2016, . [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012", RFC 7836, DOI 10.17487/RFC7836, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8891] Dolmatov, V., Ed. and D. Baryshkov, "GOST R 34.12-2015: Block Cipher "Magma"", RFC 8891, DOI 10.17487/RFC8891, September 2020, . [RFC9058] Smyshlyaev, S., Ed., Nozdrunov, V., Shishkin, V., and E. Griboedova, "Multilinear Galois Mode (MGM)", RFC 9058, DOI 10.17487/RFC9058, June 2021, . Makarov & Sadofev Expires 12 December 2026 [Page 15] Internet-Draft Using GOST Algorithms for JWT June 2026 [RFC9189] Smyshlyaev, S., Ed., Belyavsky, D., and E. Alekseev, "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2", RFC 9189, DOI 10.17487/RFC9189, March 2022, . 8.2. Informative References [GostXmlDsig] Smirnov, P., Paramonova, M., Khomenko, M., and A. Makarov, "Using GOST Algorithms for XML Digital Signatures", May 2022, . [R-1323565.1.024-2019] Federal Agency on Technical Regulating and Metrology, "Information technology. Cryptographic data security. Elliptic curve parameters for the cryptographic algorithms and protocols", R 1323565.1.024-2019, 2019. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . Appendix A. Algorithm Identifier Cross-Reference This appendix contains tables cross-referencing the cryptographic algorithm identifier values defined in this specification with the equivalent identifiers used by other standards and software packages. See [GostXmlDsig] for more information about the names defined by those documents. A.1. Digital Signature Algorithm Identifier Cross-Reference This section contains a table cross-referencing the JWS digital signature "alg" (algorithm) values defined in this specification with the equivalent identifiers used by other standards and software packages. The table uses the folding defined in [RFC8792]. [NOTE: '\' line wrapping per RFC 8792] Makarov & Sadofev Expires 12 December 2026 [Page 16] Internet-Draft Using GOST Algorithms for JWT June 2026 +=======+============================================+ | JWS | XML | +=======+============================================+ | GS256 | urn:ietf:params:xml:ns:cpxmlsec:\ | | | algorithms:gostr34102012-gostr34112012-256 | +-------+--------------------------------------------+ | GS512 | urn:ietf:params:xml:ns:cpxmlsec:\ | | | algorithms:gostr34102012-gostr34112012-512 | +-------+--------------------------------------------+ Table 7 +=======+===================+ | JWS | OID | +=======+===================+ | GS256 | 1.2.643.7.1.1.3.2 | +-------+-------------------+ | GS512 | 1.2.643.7.1.1.3.3 | +-------+-------------------+ Table 8 Appendix B. Values of the Parameter Sets Parameter set: id-tc26-gost-3410-2012-256-paramSetB Makarov & Sadofev Expires 12 December 2026 [Page 17] Internet-Draft Using GOST Algorithms for JWT June 2026 SEQUENCE { OBJECT IDENTIFIER id-tc26-gost-3410-2012-256-paramSetB SEQUENCE { INTEGER 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD 97 INTEGER 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FD 94 INTEGER A6 INTEGER 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 6C 61 10 70 99 5A Dl 00 45 84 IB 09 B7 61 B8 93 INTEGER 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 6C 61 10 70 99 5A Dl 00 45 84 IB 09 B7 61 B8 93 INTEGER 01 INTEGER 00 8D 91 E4 71 E0 98 9C DA 27 DF 50 5A 45 3F 2B 76 35 29 4F 2D DF 23 E3 B1 22 AC C9 9C 9E 9F 1E 14 } } Parameter set: id-tc26-gost-3410-2012-256-paramSetC Makarov & Sadofev Expires 12 December 2026 [Page 18] Internet-Draft Using GOST Algorithms for JWT June 2026 SEQUENCE { OBJECT IDENTIFIER id-tc26-gost-3410-2012-256-paramSetC SEQUENCE { INTEGER 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 OC 99 INTEGER 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 OC 96 INTEGER 3E 1A F4 19 A2 69 A5 F8 66 A7 D3 C2 5C 3D F8 0A E9 79 25 93 73 FF 2B 18 2F 49 D4 CE 7E 1B BC 8B INTEGER 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 5F 70 0C FF F1 A6 24 E5 E4 97 16 1B CC 8A 19 8F INTEGER 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 5F 70 0C FF F1 A6 24 E5 E4 97 16 1B CC 8A 19 8F INTEGER 01 INTEGER 3F A8 12 43 59 F9 66 80 B8 3D 1C 3E B2 C0 70 E5 C5 45 C9 85 8D 03 EC FB 74 4B F8 D7 17 71 7E FC } } Parameter set: id-tc26-gost-3410-2012-256-paramSetD Makarov & Sadofev Expires 12 December 2026 [Page 19] Internet-Draft Using GOST Algorithms for JWT June 2026 SEQUENCE { OBJECT IDENTIFIER id-tc26-gost-3410-2012-256-paramSetD SEQUENCE { INTEGER 00 9B 9F 60 5F 5A 85 81 07 AB IE C8 5E 6B 41 C8 AA CF 84 6E 86 78 90 51 D3 79 98 F7 B9 02 2D 75 9B INTEGER 00 9B 9F 60 5F 5A 85 81 07 AB IE C8 5E 6B 41 C8 AA CF 84 6E 86 78 90 51 D3 79 98 F7 B9 02 2D 75 98 INTEGER 80 5A INTEGER 00 9B 9F 60 5F 5A 85 81 07 AB IE C8 5E 6B 41 C8 AA 58 2C A3 51 IE DD FB 74 F0 2F 3A 65 98 98 OB B9 INTEGER 00 9B 9F 60 5F 5A 85 81 07 AB IE C8 5E 6B 41 C8 AA 58 2C A3 51 IE DD FB 74 F0 2F 3A 65 98 98 0B B9 INTEGER 00 INTEGER 41 EC E5 57 43 71 1A 8C 3C BF 37 83 CD 08 CO EE 4D 4D C4 40 D4 64 1A 8F 36 6E 55 0D FD B3 BB 67 } } Appendix C. JWS Examples The following samples was constructed using the X.509 certificates from Appendix A.1 and A.3 of [R-1323565.1.023-2018]. This section provides several examples of JWSs using GOST algorithms. C.1. Example JWS Using GS256 G01-256XA C.1.1. Encoding The JWS Protected Header used for this example is: {"alg":"GS256"} Makarov & Sadofev Expires 12 December 2026 [Page 20] Internet-Draft Using GOST Algorithms for JWT June 2026 The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 97, 108, 103, 34, 58, 34, 71, 83, 50, 53, 54, 34, 125] Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value: eyJhbGciOiJHUzI1NiJ9 The JWS Payload used in this example is the octets of the UTF-8 representation of the JSON object below. (Note that the payload can be any base64url-encoded octet sequence and need not be a base64url- encoded JSON object.) {"iss":"joe", "exp":1300819380, "http://example.com/is_root":true} To remove potential ambiguities in the representation of the JSON object above, the actual octet sequence representing UTF8(JWS Payload) used in this example is also included below. (Note that ambiguities can arise due to differing platform representations of line breaks (CRLF versus LF), differing spacing at the beginning and ends of lines, whether the last line has a terminating line break or not, and other causes. In the representation used in this example, the first line has no leading or trailing spaces, a CRLF line break (13, 10) occurs between the first, second and third lines, the second and third lines have one leading space (32) and no trailing spaces, and the last line does not have a terminating line break.) The octets representing UTF8(JWS Payload) representation for the JSON object above in this example (using JSON array notation) are: [123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10, 32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56, 48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97, 109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111, 111, 116, 34, 58, 116, 114, 117, 101, 125] Encoding this JWS Payload as BASE64URL(UTF8(JWS Payload)) gives this value (with line breaks for display purposes only): eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only): Makarov & Sadofev Expires 12 December 2026 [Page 21] Internet-Draft Using GOST Algorithms for JWT June 2026 eyJhbGciOiJHUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ The resulting JWS Signing Input value, which is the ASCII representation of the above string, is the following octet sequence (using JSON array notation): [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 72, 85, 122, 73, 49, 78, 105, 74, 57, 13, 10, 46, 13, 10, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81] This example uses the Elliptic Curve key represented in JSON Web Key [RFC7515] format below: {"kty":"EC", "crv":"G01-256XA", "x":"ut_Qw1MUq9KPqkdHC2xAF3K7TugHfo9n525D2s5mFZc", "y":"Q-acH_dP4uLxdJhZq_Z30cDGD-KND4NZjp-UZWlzWK0", "d":"JJk5-qg57cPyqv4PZD3kRjySSrvqxqcyMN1cPmIdz78"} The GOST R 34.10-2012 Signature Algorithm private part d is then passed to a GOST R 34.10-2012 signing function, which also takes the curve type (G01-256XA) and the JWS Signing Input as inputs. The result of the digital signature is the Elliptic Curve (EC) point (R, S), where R and S are unsigned integers. In this example, the signature algorithm uses the random k value in the following big- endian octet sequence representation (using JSON array notation): [87, 130, 197, 63, 17, 12, 89, 111, 145, 85, 211, 94, 189, 37, 160, 106, 137, 197, 3, 145, 133, 10, 143, 239, 227, 59, 14, 39, 3, 24, 133, 124] The S value, given as octet sequences representing big-endian integers, is: [45, 185, 213, 66, 201, 34, 203, 38, 204, 35, 107, 25, 88, 110, 89, 177, 208, 113, 62, 133, 236, 170, 57, 59, 39, 13, 27, 155, 171, 222, 166, 161] The R value, given as octet sequences representing big-endian integers, is: Makarov & Sadofev Expires 12 December 2026 [Page 22] Internet-Draft Using GOST Algorithms for JWT June 2026 [233, 50, 58, 94, 136, 221, 135, 251, 124, 114, 67, 131, 191, 254, 124, 236, 212, 185, 255, 162, 172, 51, 190, 239, 115, 165, 161, 247, 67, 64, 79, 107] The JWS Signature is the value S || R. Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only): LbnVQskiyybMI2sZWG5ZsdBxPoXsqjk7Jw0bm6vepqHpMjpeiN2H-3xyQ4O__nzs 1Ln_oqwzvu9zpaH3Q0BPaw Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only): eyJhbGciOiJHUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . LbnVQskiyybMI2sZWG5ZsdBxPoXsqjk7Jw0bm6vepqHpMjpeiN2H-3xyQ4O__nzs 1Ln_oqwzvu9zpaH3Q0BPaw C.1.2. Validating Since the "alg" Header Parameter is "GS256", we validate the GOST R 34.10-2012 G01-256XA digital signature contained in the JWS Signature. We need to split the 64 member octet sequence of the JWS Signature (which is base64url decoded from the value encoded in the JWS representation) into two 32 octet sequences, the first representing S and the second R. We then pass the public key (x, y), the signature (S, R), and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) to a GOST R 34.10-2012 signature verifier that has been configured to use the G01-256XA curve with the GOST R 34.11-2012 (256) hash function. C.2. Example JWS Using GS512 G12-512B C.2.1. Encoding The JWS Protected Header for this example is: {"alg":"GS512"} Makarov & Sadofev Expires 12 December 2026 [Page 23] Internet-Draft Using GOST Algorithms for JWT June 2026 The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 97, 108, 103, 34, 58, 34, 71, 83, 53, 49, 50, 34, 125] Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value: eyJhbGciOiJHUzUxMiJ9 The JWS Payload used in this example, which follows, is the same as in the previous examples. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here. {"iss":"joe", "exp":1300819380, "http://example.com/is_root":true} Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only): eyJhbGciOiJHUzUxMiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ The resulting JWS Signing Input value, which is the ASCII representation of the above string, is the following octet sequence: [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 72, 85, 122, 85, 120, 77, 105, 74, 57, 13, 10, 46, 13, 10, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81] This example uses the Elliptic Curve key represented in JSON Web Key [RFC7515] format below (with line breaks within values for display purposes only): Makarov & Sadofev Expires 12 December 2026 [Page 24] Internet-Draft Using GOST Algorithms for JWT June 2026 {"kty":"EC", "crv":"G12-512B", "x":"ExkPVQojORURgkPDBM9hdXQDaoWhLssGvAm8Tp072hiaRUFV0MJMLyxQCo e4ZOeNrzhLcaSrUwl3xn_OJ0YTBw", "y":"_Q9bZeAc2eO_yhxrsQhTBufa1Fuou2oe_jUOaG6RAtUUvRzhNTppRGGl1- EIY2vzzUua9j9Ol_gAoy_LNKQIfg", "d":"SwfLa04BTqTmfQxfF_0z_UiMtO7IdrmH5XwHQeYwdXU1JEbuWqArmWee_o 1SgPO3beZBTHeCtC6XX-zU3BzAPw"} The GOST R 34.10-2012 Signature Algorithm private part d is then passed to a GOST R 34.10-2012 signing function, which also takes the curve type (G12-512B) and the JWS Signing Input as inputs. The result of the digital signature is the Elliptic Curve (EC) point (R, S), where R and S are unsigned integers. In this example, the signature algorithm uses the random k value in the following big- endian octet sequence representation (using JSON array notation): [114, 171, 180, 69, 54, 101, 107, 241, 97, 140, 225, 11, 247, 234, 221, 64, 88, 35, 4, 165, 30, 228, 226, 162, 90, 10, 50, 203, 14, 119, 58, 187, 35, 183, 216, 253, 216, 250, 94, 238, 145, 180, 174, 69, 47, 34, 114, 200, 110, 30, 34, 33, 33, 93, 64, 95, 81, 181, 213, 1, 86, 22, 225, 246] The S value, given as octet sequences representing big-endian integers, is: [4, 77, 220, 231, 27, 212, 139, 107, 136, 53, 250, 89, 79, 252, 60, 30, 241, 66, 223, 9, 153, 223, 231, 102, 67, 84, 187, 225, 132, 246, 126, 103, 73, 214, 205, 47, 188, 3, 211, 249, 211, 235, 40, 182, 149, 197, 66, 14, 254, 184, 90, 167, 31, 247, 72, 208, 16, 193, 88, 248, 42, 97, 121, 124] The R value, given as octet sequences representing big-endian integers, is: [93, 191, 47, 76, 45, 106, 119, 5, 136, 15, 177, 69, 140, 197, 131, 53, 6, 91, 234, 86, 33, 252, 159, 188, 23, 108, 74, 202, 91, 193, 230, 114, 37, 69, 154, 142, 163, 119, 148, 52, 89, 13, 200, 114, 112, 64, 41, 54, 90, 131, 165, 59, 94, 179, 192, 105, 54, 181, 210, 135, 224, 169, 131, 231] The JWS Signature is the value S || R. Encoding the signature as BASE64URL(JWS Signature) produces this value (with line breaks for display purposes only): BE3c5xvUi2uINfpZT_w8HvFC3wmZ3-dmQ1S74YT2fmdJ1s0vvAPT-dPrKLaVxUIO _rhapx_3SNAQwVj4KmF5fF2_L0wtancFiA-xRYzFgzUGW-pWIfyfvBdsSspbweZy JUWajqN3lDRZDchycEApNlqDpTtes8BpNrXSh-Cpg-c Makarov & Sadofev Expires 12 December 2026 [Page 25] Internet-Draft Using GOST Algorithms for JWT June 2026 Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only): eyJhbGciOiJHUzUxMiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . BE3c5xvUi2uINfpZT_w8HvFC3wmZ3-dmQ1S74YT2fmdJ1s0vvAPT-dPrKLaVxUIO _rhapx_3SNAQwVj4KmF5fF2_L0wtancFiA-xRYzFgzUGW-pWIfyfvBdsSspbweZy JUWajqN3lDRZDchycEApNlqDpTtes8BpNrXSh-Cpg-c C.2.2. Validating Since the "alg" Header Parameter is "GS512", we validate the GOST R 34.10-2012 G12-512B digital signature contained in the JWS Signature. We need to split the 128 member octet sequence of the JWS Signature (which is base64url decoded from the value encoded in the JWS representation) into two 64 octet sequences, the first representing S and the second R. We then pass the public key (x, y), the signature (S, R), and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) to a GOST R 34.10-2012 signature verifier that has been configured to use the G12-512B curve with the GOST R 34.11-2012 (512) hash function. C.3. Example JWS Using HMAC HG256 C.3.1. Encoding The following example JWS Protected Header declares that the data structure is a JWT [RFC7519] and the JWS Signing Input is secured using the GOST R 34.11-2012 (256) algorithm. {"alg":"HG256"} The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 97, 108, 103, 34, 58, 34, 72, 71, 50, 53, 54, 34, 125] Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value: eyJhbGciOiJIRzI1NiJ9 Makarov & Sadofev Expires 12 December 2026 [Page 26] Internet-Draft Using GOST Algorithms for JWT June 2026 The JWS Payload used in this example, which follows, is the same as in the previous examples. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here. {"iss":"joe", "exp":1300819380, "http://example.com/is_root":true} Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only): eyJhbGciOiJIRzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ The resulting JWS Signing Input value, which is the ASCII representation of the above string, is the following octet sequence: [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 73, 82, 122, 73, 49, 78, 105, 74, 57, 13, 10, 46, 13, 10, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81] HMACs are generated using keys. This example uses the symmetric key represented in JSON Web Key [RFC7515] format below (with line breaks within values for display purposes only): {"kty":"oct", "k":"AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8"} Running the HMAC GOST R 34.11-2012 (256) algorithm on the JWS Signing Input with this key yields this JWS Signature octet sequence: [104, 41, 229, 119, 16, 188, 143, 143, 240, 156, 82, 164, 141, 142, 126, 104, 25, 153, 122, 60, 251, 186, 33, 112, 19, 137, 54, 106, 255, 194, 126, 40] Encoding this JWS Signature as BASE64URL(JWS Signature) gives this value: aCnldxC8j4_wnFKkjY5-aBmZejz7uiFwE4k2av_Cfig Makarov & Sadofev Expires 12 December 2026 [Page 27] Internet-Draft Using GOST Algorithms for JWT June 2026 Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only): eyJhbGciOiJIRzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . aCnldxC8j4_wnFKkjY5-aBmZejz7uiFwE4k2av_Cfig C.3.2. Validating Since the "alg" Header Parameter is "HG256", we validate the HMAC GOST R 34.11-2012 (256) value contained in the JWS Signature. To validate the HMAC value, we repeat the previous process of using the correct key and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) as input to the HMAC GOST R 34.11-2012 (256) function and then taking the output and determining if it matches the JWS Signature (which is base64url decoded from the value encoded in the JWS representation). If it matches exactly, the HMAC has been validated. C.4. Example JWS Using HMAC HG512 C.4.1. Encoding The following example JWS Protected Header declares that the data structure is a JWT [RFC7519] and the JWS Signing Input is secured using the GOST R 34.11-2012 (512) algorithm. {"alg":"HG512"} The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 97, 108, 103, 34, 58, 34, 72, 71, 53, 49, 50, 34, 125] Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value: eyJhbGciOiJIRzUxMiJ9 Makarov & Sadofev Expires 12 December 2026 [Page 28] Internet-Draft Using GOST Algorithms for JWT June 2026 The JWS Payload used in this example, which follows, is the same as in the previous examples. Since the BASE64URL(JWS Payload) value will therefore be the same, its computation is not repeated here. {"iss":"joe", "exp":1300819380, "http://example.com/is_root":true} Combining these as BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Payload) gives this string (with line breaks for display purposes only): eyJhbGciOiJIRzUxMiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ The resulting JWS Signing Input value, which is the ASCII representation of the above string, is the following octet sequence: [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 73, 82, 122, 85, 120, 77, 105, 74, 57, 13, 10, 46, 13, 10, 101, 121, 74, 112, 99, 51, 77, 105, 79, 105, 74, 113, 98, 50, 85, 105, 76, 65, 48, 75, 73, 67, 74, 108, 101, 72, 65, 105, 79, 106, 69, 122, 77, 68, 65, 52, 77, 84, 107, 122, 79, 68, 65, 115, 68, 81, 111, 103, 73, 109, 104, 48, 100, 72, 65, 54, 76, 121, 57, 108, 101, 71, 70, 116, 99, 71, 120, 108, 76, 109, 78, 118, 98, 83, 57, 112, 99, 49, 57, 121, 98, 50, 57, 48, 73, 106, 112, 48, 99, 110, 86, 108, 102, 81] HMACs are generated using keys. This example uses the symmetric key represented in JSON Web Key [RFC7515] format below (with line breaks within values for display purposes only): {"kty":"oct", "k":"AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8"} Running the HMAC GOST R 34.11-2012 (512) algorithm on the JWS Signing Input with this key yields this JWS Signature octet sequence: [132, 23, 160, 213, 116, 252, 203, 6, 213, 232, 32, 243, 120, 175, 164, 213, 152, 24, 186, 91, 137, 5, 166, 240, 218, 69, 92, 76, 197, 141, 225, 198, 48, 154, 219, 92, 247, 31, 8, 192, 182, 26, 162, 255, 146, 41, 211, 19, 100, 175, 232, 174, 172, 130, 21, 169, 208, 170, 75, 42, 152, 178, 32, 100] Encoding this JWS Signature as BASE64URL(JWS Signature) gives this value (with line breaks for display purposes only): Makarov & Sadofev Expires 12 December 2026 [Page 29] Internet-Draft Using GOST Algorithms for JWT June 2026 hBeg1XT8ywbV6CDzeK-k1ZgYuluJBabw2kVcTMWN4cYwmttc9x8IwLYaov-SKdMT ZK_orqyCFanQqksqmLIgZA Concatenating these values in the order Header.Payload.Signature with period ('.') characters between the parts yields this complete JWS representation using the JWS Compact Serialization (with line breaks for display purposes only): eyJhbGciOiJIRzUxMiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . hBeg1XT8ywbV6CDzeK-k1ZgYuluJBabw2kVcTMWN4cYwmttc9x8IwLYaov-SKdMT ZK_orqyCFanQqksqmLIgZA C.4.2. Validating Since the "alg" Header Parameter is "HG512", we validate the HMAC GOST R 34.11-2012 (512) value contained in the JWS Signature. To validate the HMAC value, we repeat the previous process of using the correct key and the JWS Signing Input (which is the initial substring of the JWS Compact Serialization representation up until but not including the second period character) as input to the HMAC GOST R 34.11-2012 (512) function and then taking the output and determining if it matches the JWS Signature (which is base64url decoded from the value encoded in the JWS representation). If it matches exactly, the HMAC has been validated. Appendix D. JWE Examples This section provides examples of JWE computations. D.1. Using GKEG-KEXP15M GS256 G01-256XA with GM256MGM This example encrypts the plaintext "The true sign of intelligence is not knowledge but imagination." to the recipient using GS256 with G01-256XA curve for key encryption and GM256MGM for content encryption. The representation of this plaintext (using JSON array notation) is: [84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32, 111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99, 101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108, 101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105, 110, 97, 116, 105, 111, 110, 46] Makarov & Sadofev Expires 12 December 2026 [Page 30] Internet-Draft Using GOST Algorithms for JWT June 2026 D.1.1. Content Encryption Key (CEK) Generate a 256-bit random CEK. In this example, the value (using JSON array notation) is: [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 234, 64, 252] D.1.2. Key Encryption Encrypt the CEK with the recipient's public key using the GKEG- KEXP15M algorithm to produce the JWE Encrypted Key. This example uses the GS256 recipient key pair represented in JSON Web Key format below (with line breaks within values for display purposes only): {"kty":"EC", "crv":"G01-256XA", "x":"ut_Qw1MUq9KPqkdHC2xAF3K7TugHfo9n525D2s5mFZc", "y":"Q-acH_dP4uLxdJhZq_Z30cDGD-KND4NZjp-UZWlzWK0", "d":"JJk5-qg57cPyqv4PZD3kRjySSrvqxqcyMN1cPmIdz78"} Generate a new ephemeral GS256 G01-256XA key pair (see Section 3.2). In this example, the ephemeral public key value (using JSON array notation) is: [192, 221, 37, 46, 21, 175, 110, 173, 22, 19, 159, 227, 245, 81, 245, 36, 48, 166, 108, 194, 243, 246, 218, 128, 97, 88, 193, 129, 252, 229, 79, 195, 104, 98, 81, 72, 189, 124, 9, 238, 151, 43, 110, 87, 158, 251, 247, 194, 53, 43, 142, 244, 171, 84, 4, 49, 109, 89, 166, 28, 155, 2, 9, 177] Generate a 256-bit random UKM. In this example, the value (using JSON array notation) is: [148, 110, 80, 122, 68, 78, 142, 160, 219, 61, 120, 213, 204, 72, 109, 148, 19, 64, 46, 101, 13, 47, 45, 64, 219, 176, 135, 199, 136, 180, 179, 50] Encoding this UKM as BASE64URL(UKM) gives this value: lG5QekROjqDbPXjVzEhtlBNALmUNLy1A27CHx4i0szI The resulting JWE Encrypted Key value is: [48, 129, 209, 48, 103, 48, 54, 4, 32, 223, 126, 204, 60, 86, 27, 72, 159, 132, 140, 34, 185, 76, 172, 216, 182, 39, 180, 0, 88, 14, 139, 162, 139, 117, 129, 231, 35, 127, 41, 50, 37, 4, 8, 166, 171, 114, 63, 139, 253, 138, 88, 6, 8, 42, 133, 3, 7, 1, 1, 5, 1, 48, 45, 4, 32, 148, 110, 80, 122, 68, 78, 142, 160, 219, 61, 120, 213, 204, 72, 109, 148, 19, 64, 46, 101, 13, 47, 45, 64, 219, 176, 135, 199, 136, 180, 179, 50, 6, 9, 42, 133, 3, 7, 1, 1, 7, 1, 1, 48, 102, 48, 31, 6, 8, 42, 133, 3, 7, 1, 1, 1, 1, 48, 19, 6, 7, 42, 133, 3, 2, 2, 36, 0, 6, 8, 42, 133, 3, 7, 1, 1, 2, 2, 3, 67, 0, 4, 64, 192, 221, 37, 46, 21, 175, 110, 173, 22, 19, 159, 227, 245, 81, 245, 36, 48, 166, 108, 194, 243, 246, 218, 128, 97, 88, Makarov & Sadofev Expires 12 December 2026 [Page 31] Internet-Draft Using GOST Algorithms for JWT June 2026 193, 129, 252, 229, 79, 195, 104, 98, 81, 72, 189, 124, 9, 238, 151, 43, 110, 87, 158, 251, 247, 194, 53, 43, 142, 244, 171, 84, 4, 49, 109, 89, 166, 28, 155, 2, 9, 177] Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives this value (with line breaks for display purposes only): MIHRMGcwNgQg337MPFYbSJ-EjCK5TKzYtie0AFgOi6KLdYHnI38pMiUECKarcj-L _YpYBggqhQMHAQEFATAtBCCUblB6RE6OoNs9eNXMSG2UE0AuZQ0vLUDbsIfHiLSz MgYJKoUDBwEBBwEBMGYwHwYIKoUDBwEBAQEwEwYHKoUDAgIkAAYIKoUDBwEBAgID QwAEQMDdJS4Vr26tFhOf4_VR9SQwpmzC8_bagGFYwYH85U_DaGJRSL18Ce6XK25X nvv3wjUrjvSrVAQxbVmmHJsCCbE D.1.3. Encoding JWE Protected Header The following example JWE Protected Header declares that: * The Content Encryption Key is encrypted to the recipient using the GKEG-KEXP15M algorithm to produce the JWE Encrypted Key. * Authenticated encryption is performed on the plaintext using the GM256MGM algorithm with a 256-bit key to produce the ciphertext and the Authentication Tag. * Key encryption in performed using the specified "ukm" and "epk" values as in Section 3.2. {"alg":"GKEG-KEXP15M", "enc":"GM256MGM", "ukm": lG5QekROjqDbPXjVzEhtlBNALmUNLy1A27CHx4i0szI, "epk": {"kty":"EC", "crv":"G01-256XA", "x":"wN0lLhWvbq0WE5_j9VH1JDCmbMLz9tqAYVjBgfzlT8M", "y":"aGJRSL18Ce6XK25Xnvv3wjUrjvSrVAQxbVmmHJsCCbE"}} In the representation used in this example, the first line has no leading or trailing spaces, a CRLF line break (13, 10) occurs between all lines, the second, third and fourth lines have one leading space (32) and no trailing spaces, fifth line have two leading spaces (32, 32), sixth, seventh and eighth lines have three leading spaces (32, 32, 32), the last (eighth) line does not have a terminating line break.) The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 97, 108, 103, 34, 58, 34, 71, 75, 69, 71, 45, 75, 69, 88, 80, 49, 53, 77, 34, 44, 13, 10, 32, 34, 101, 110, 99, 34, 58, 34, 71, 77, 50, 53, 54, 77, 71, 77, 34, 44, 13, 10, 32, 34, 117, 107, 109, 34, 58, 32, 108, 71, 53, 81, 101, 107, 82, 79, 106, 113, 68, 98, 80, 88, 106, 86, 122, 69, 104, 116, 108, 66, 78, 65, 76, 109, 85, 78, 76, 121, 49, 65, 50, 55, 67, 72, 120, 52, 105, 48, 115, 122, 73, 44, 13, 10, 32, 34, 101, 112, Makarov & Sadofev Expires 12 December 2026 [Page 32] Internet-Draft Using GOST Algorithms for JWT June 2026 107, 34, 58, 32, 13, 10, 32, 32, 123, 34, 107, 116, 121, 34, 58, 34, 69, 67, 34, 44, 13, 10, 32, 32, 32, 34, 99, 114, 118, 34, 58, 34, 71, 48, 49, 45, 50, 53, 54, 88, 65, 34, 44, 13, 10, 32, 32, 32, 34, 120, 34, 58, 34, 119, 78, 48, 108, 76, 104, 87, 118, 98, 113, 48, 87, 69, 53, 95, 106, 57, 86, 72, 49, 74, 68, 67, 109, 98, 77, 76, 122, 57, 116, 113, 65, 89, 86, 106, 66, 103, 102, 122, 108, 84, 56, 77, 34, 44, 13, 10, 32, 32, 32, 34, 121, 34, 58, 34, 97, 71, 74, 82, 83, 76, 49, 56, 67, 101, 54, 88, 75, 50, 53, 88, 110, 118, 118, 51, 119, 106, 85, 114, 106, 118, 83, 114, 86, 65, 81, 120, 98, 86, 109, 109, 72, 74, 115, 67, 67, 98, 69, 34, 125, 125] Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value: eyJhbGciOiJHS0VHLUtFWFAxNU0iLA0KICJlbmMiOiJHTTI1Nk1HTSIsDQogInVr bSI6IGxHNVFla1JPanFEYlBYalZ6RWh0bEJOQUxtVU5MeTFBMjdDSHg0aTBzekks DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMDEtMjU2WEEi LA0KICAgIngiOiJ3TjBsTGhXdmJxMFdFNV9qOVZIMUpEQ21iTUx6OXRxQVlWakJn ZnpsVDhNIiwNCiAgICJ5IjoiYUdKUlNMMThDZTZYSzI1WG52djN3alVyanZTclZB UXhiVm1tSEpzQ0NiRSJ9fQ D.1.4. Initialization Vector Generate a random 63-bit ICN value. JWE Initialization Vector is formed from the ICN value, represented as an n/8-octet big-endian string with the most significant bit set to 0. In this example, the value of JWE Initialization Vector is: [83, 43, 152, 248, 165, 29, 6, 100] Encoding this JWE Initialization Vector as BASE64URL(JWE Initialization Vector) gives this value: UyuY-KUdBmQ D.1.5. Additional Authenticated Data Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is: [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81] Makarov & Sadofev Expires 12 December 2026 [Page 33] Internet-Draft Using GOST Algorithms for JWT June 2026 D.1.6. Content Encryption Perform authenticated encryption on the plaintext with the GM256MGM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above, requesting a 64-bit Authentication Tag output. The resulting ciphertext is: [50, 91, 27, 183, 32, 83, 231, 241, 60, 4, 242, 50, 99, 252, 51, 184, 116, 25, 86, 66, 217, 233, 152, 41, 149, 36, 48, 64, 87, 149, 112, 40, 62, 198, 146, 20, 49, 154, 201, 149, 170, 253, 235, 108, 104, 112, 17, 37, 236, 132, 190, 10, 86, 35, 22, 184, 104, 200, 47, 124, 252, 162, 6] The resulting Authentication Tag value is: [29, 37, 204, 100, 127, 119, 138, 55] Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value (with line breaks for display purposes only): MlsbtyBT5_E8BPIyY_wzuHQZVkLZ6ZgplSQwQFeVcCg-xpIUMZrJlar962xocBEl 7IS-ClYjFrhoyC98_KIG Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value: HSXMZH93ijc D.1.7. Complete Representation Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). The final result in this example (with line breaks for display purposes only) is: Makarov & Sadofev Expires 12 December 2026 [Page 34] Internet-Draft Using GOST Algorithms for JWT June 2026 eyJhbGciOiJHS0VHLUtFWFAxNU0iLA0KICJlbmMiOiJHTTI1Nk1HTSIsDQogInVr bSI6IGxHNVFla1JPanFEYlBYalZ6RWh0bEJOQUxtVU5MeTFBMjdDSHg0aTBzekks DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMDEtMjU2WEEi LA0KICAgIngiOiJ3TjBsTGhXdmJxMFdFNV9qOVZIMUpEQ21iTUx6OXRxQVlWakJn ZnpsVDhNIiwNCiAgICJ5IjoiYUdKUlNMMThDZTZYSzI1WG52djN3alVyanZTclZB UXhiVm1tSEpzQ0NiRSJ9fQ . MIHRMGcwNgQg337MPFYbSJ-EjCK5TKzYtie0AFgOi6KLdYHnI38pMiUECKarcj-L _YpYBggqhQMHAQEFATAtBCCUblB6RE6OoNs9eNXMSG2UE0AuZQ0vLUDbsIfHiLSz MgYJKoUDBwEBBwEBMGYwHwYIKoUDBwEBAQEwEwYHKoUDAgIkAAYIKoUDBwEBAgID QwAEQMDdJS4Vr26tFhOf4_VR9SQwpmzC8_bagGFYwYH85U_DaGJRSL18Ce6XK25X nvv3wjUrjvSrVAQxbVmmHJsCCbE . UyuY-KUdBmQ . MlsbtyBT5_E8BPIyY_wzuHQZVkLZ6ZgplSQwQFeVcCg-xpIUMZrJlar962xocBEl 7IS-ClYjFrhoyC98_KIG . HSXMZH93ijc D.1.8. Validation This example illustrates the process of creating a JWE with GKEG- KEXP15M with GS256 G01-256XA for key encryption and GM256MGM for content encryption. These results can be used to validate JWE decryption implementations for these algorithms. Note that since the GKEG-KEXP15M with GS256 G01-256XA computation includes random values, the encryption results above will not be completely reproducible. However, since the GM256MGM computation is deterministic, the JWE Encrypted Ciphertext values will be the same for all encryptions performed using these inputs. D.2. Using GKEG-KEXP15K GS512 G12-512B with GK256MGM This example encrypts the plaintext "The true sign of intelligence is not knowledge but imagination." to the recipient using GS512 with G12-512B curve for key encryption and GK256MGM for content encryption. The representation of this plaintext (using JSON array notation) is: [84, 104, 101, 32, 116, 114, 117, 101, 32, 115, 105, 103, 110, 32, 111, 102, 32, 105, 110, 116, 101, 108, 108, 105, 103, 101, 110, 99, 101, 32, 105, 115, 32, 110, 111, 116, 32, 107, 110, 111, 119, 108, 101, 100, 103, 101, 32, 98, 117, 116, 32, 105, 109, 97, 103, 105, 110, 97, 116, 105, 111, 110, 46] Makarov & Sadofev Expires 12 December 2026 [Page 35] Internet-Draft Using GOST Algorithms for JWT June 2026 D.2.1. Content Encryption Key (CEK) Generate a 256-bit random CEK. In this example, the value (using JSON array notation) is: [177, 161, 244, 128, 84, 143, 225, 115, 63, 180, 3, 255, 107, 154, 212, 246, 138, 7, 110, 91, 112, 46, 34, 105, 47, 130, 203, 46, 122, 234, 64, 252] D.2.2. Key Encryption Encrypt the CEK with the recipient's public key using the GKEG- KEXP15K algorithm to produce the JWE Encrypted Key. This example uses the GS512 recipient key pair represented in JSON Web Key format below (with line breaks within values for display purposes only): {"kty":"EC", "crv":"G12-512B", "x":"ExkPVQojORURgkPDBM9hdXQDaoWhLssGvAm8Tp072hiaRUFV0MJMLyxQCo e4ZOeNrzhLcaSrUwl3xn_OJ0YTBw", "y":"_Q9bZeAc2eO_yhxrsQhTBufa1Fuou2oe_jUOaG6RAtUUvRzhNTppRGGl1- EIY2vzzUua9j9Ol_gAoy_LNKQIfg", "d":"SwfLa04BTqTmfQxfF_0z_UiMtO7IdrmH5XwHQeYwdXU1JEbuWqArmWee_o 1SgPO3beZBTHeCtC6XX-zU3BzAPw"} Generate a new ephemeral GS512 G12-512B key pair (see Section 3.2). In this example, the ephemeral public key value (using JSON array notation) is: [151, 247, 206, 137, 37, 38, 141, 50, 250, 217, 221, 125, 119, 138, 219, 237, 221, 160, 234, 67, 78, 70, 170, 235, 102, 65, 64, 206, 122, 117, 166, 72, 49, 201, 24, 182, 148, 235, 68, 106, 253, 203, 89, 187, 240, 218, 7, 214, 146, 242, 167, 99, 84, 50, 56, 100, 239, 197, 141, 181, 245, 163, 184, 58, 159, 37, 99, 198, 118, 28, 29, 194, 166, 4, 238, 230, 225, 60, 131, 34, 217, 185, 85, 244, 124, 122, 46, 98, 56, 93, 51, 98, 212, 183, 72, 207, 90, 184, 50, 220, 61, 242, 242, 33, 37, 81, 45, 24, 62, 61, 64, 104, 28, 195, 236, 222, 68, 42, 60, 201, 116, 54, 4, 0, 101, 149, 63, 124] Generate a 256-bit random UKM. In this example, the value (using JSON array notation) is: [173, 210, 100, 181, 116, 88, 223, 200, 188, 16, 110, 178, 209, 190, 142, 212, 61, 28, 164, 169, 183, 249, 36, 214, 190, 194, 56, 165, 238, 80, 226, 249] Encoding this UKM as BASE64URL(UKM) gives this value: rdJktXRY38i8EG6y0b6O1D0cpKm3-STWvsI4pe5Q4vk Makarov & Sadofev Expires 12 December 2026 [Page 36] Internet-Draft Using GOST Algorithms for JWT June 2026 The resulting JWE Encrypted Key value is: [48, 130, 1, 30, 48, 111, 48, 62, 4, 32, 132, 139, 65, 112, 240, 108, 131, 132, 143, 123, 234, 212, 93, 160, 181, 113, 175, 165, 108, 146, 142, 198, 86, 107, 112, 33, 182, 158, 235, 206, 60, 242, 4, 16, 123, 152, 177, 84, 181, 139, 166, 84, 63, 203, 78, 201, 99, 11, 208, 243, 6, 8, 42, 133, 3, 7, 1, 1, 5, 2, 48, 45, 4, 32, 173, 210, 100, 181, 116, 88, 223, 200, 188, 16, 110, 178, 209, 190, 142, 212, 61, 28, 164, 169, 183, 249, 36, 214, 190, 194, 56, 165, 238, 80, 226, 249, 6, 9, 42, 133, 3, 7, 1, 1, 7, 2, 1, 48, 129, 170, 48, 33, 6, 8, 42, 133, 3, 7, 1, 1, 1, 2, 48, 21, 6, 9, 42, 133, 3, 7, 1, 2, 1, 2, 2, 6, 8, 42, 133, 3, 7, 1, 1, 2, 3, 3, 129, 132, 0, 4, 129, 128, 151, 247, 206, 137, 37, 38, 141, 50, 250, 217, 221, 125, 119, 138, 219, 237, 221, 160, 234, 67, 78, 70, 170, 235, 102, 65, 64, 206, 122, 117, 166, 72, 49, 201, 24, 182, 148, 235, 68, 106, 253, 203, 89, 187, 240, 218, 7, 214, 146, 242, 167, 99, 84, 50, 56, 100, 239, 197, 141, 181, 245, 163, 184, 58, 159, 37, 99, 198, 118, 28, 29, 194, 166, 4, 238, 230, 225, 60, 131, 34, 217, 185, 85, 244, 124, 122, 46, 98, 56, 93, 51, 98, 212, 183, 72, 207, 90, 184, 50, 220, 61, 242, 242, 33, 37, 81, 45, 24, 62, 61, 64, 104, 28, 195, 236, 222, 68, 42, 60, 201, 116, 54, 4, 0, 101, 149, 63, 124] Encoding this JWE Encrypted Key as BASE64URL(JWE Encrypted Key) gives this value (with line breaks for display purposes only): MIIBHjBvMD4EIISLQXDwbIOEj3vq1F2gtXGvpWySjsZWa3Ahtp7rzjzyBBB7mLFU tYumVD_LTsljC9DzBggqhQMHAQEFAjAtBCCt0mS1dFjfyLwQbrLRvo7UPRykqbf5 JNa-wjil7lDi-QYJKoUDBwEBBwIBMIGqMCEGCCqFAwcBAQECMBUGCSqFAwcBAgEC AgYIKoUDBwEBAgMDgYQABIGAl_fOiSUmjTL62d19d4rb7d2g6kNORqrrZkFAznp1 pkgxyRi2lOtEav3LWbvw2gfWkvKnY1QyOGTvxY219aO4Op8lY8Z2HB3CpgTu5uE8 gyLZuVX0fHouYjhdM2LUt0jPWrgy3D3y8iElUS0YPj1AaBzD7N5EKjzJdDYEAGWV P3w D.2.3. Encoding JWE Protected Header The following example JWE Protected Header declares that: * The Content Encryption Key is encrypted to the recipient using the GKEG-KEXP15K algorithm to produce the JWE Encrypted Key. * Authenticated encryption is performed on the plaintext using the GK256MGM algorithm with a 256-bit key to produce the ciphertext and the Authentication Tag. * Key encryption in performed using the specified "ukm" and "epk" values as in Section 3.2. The line breaks in the example below are for display purposes only. Makarov & Sadofev Expires 12 December 2026 [Page 37] Internet-Draft Using GOST Algorithms for JWT June 2026 {"alg":"GKEG-KEXP15K", "enc":"GK256MGM", "ukm": rdJktXRY38i8EG6y0b6O1D0cpKm3-STWvsI4pe5Q4vk, "epk": {"kty":"EC", "crv":"G12-512B", "x":"l_fOiSUmjTL62d19d4rb7d2g6kNORqrrZkFAznp1pkgxyRi2lOtEav3L Wbvw2gfWkvKnY1QyOGTvxY219aO4Og", "y":"nyVjxnYcHcKmBO7m4TyDItm5VfR8ei5iOF0zYtS3SM9auDLcPfLyISVR LRg-PUBoHMPs3kQqPMl0NgQAZZU_fA"}} The octets representing UTF8(JWS Protected Header) in this example (using JSON array notation) are: [123, 34, 97, 108, 103, 34, 58, 34, 71, 75, 69, 71, 45, 75, 69, 88, 80, 49, 53, 75, 34, 44, 13, 10, 32, 34, 101, 110, 99, 34, 58, 34, 71, 75, 50, 53, 54, 77, 71, 77, 34, 44, 13, 10, 32, 34, 117, 107, 109, 34, 58, 32, 114, 100, 74, 107, 116, 88, 82, 89, 51, 56, 105, 56, 69, 71, 54, 121, 48, 98, 54, 79, 49, 68, 48, 99, 112, 75, 109, 51, 45, 83, 84, 87, 118, 115, 73, 52, 112, 101, 53, 81, 52, 118, 107, 44, 13, 10, 32, 34, 101, 112, 107, 34, 58, 32, 13, 10, 32, 32, 123, 34, 107, 116, 121, 34, 58, 34, 69, 67, 34, 44, 13, 10, 32, 32, 32, 34, 99, 114, 118, 34, 58, 34, 71, 49, 50, 45, 53, 49, 50, 66, 34, 44, 13, 10, 32, 32, 32, 34, 120, 34, 58, 34, 108, 95, 102, 79, 105, 83, 85, 109, 106, 84, 76, 54, 50, 100, 49, 57, 100, 52, 114, 98, 55, 100, 50, 103, 54, 107, 78, 79, 82, 113, 114, 114, 90, 107, 70, 65, 122, 110, 112, 49, 112, 107, 103, 120, 121, 82, 105, 50, 108, 79, 116, 69, 97, 118, 51, 76, 87, 98, 118, 119, 50, 103, 102, 87, 107, 118, 75, 110, 89, 49, 81, 121, 79, 71, 84, 118, 120, 89, 50, 49, 57, 97, 79, 52, 79, 103, 34, 44, 13, 10, 32, 32, 32, 34, 121, 34, 58, 34, 110, 121, 86, 106, 120, 110, 89, 99, 72, 99, 75, 109, 66, 79, 55, 109, 52, 84, 121, 68, 73, 116, 109, 53, 86, 102, 82, 56, 101, 105, 53, 105, 79, 70, 48, 122, 89, 116, 83, 51, 83, 77, 57, 97, 117, 68, 76, 99, 80, 102, 76, 121, 73, 83, 86, 82, 76, 82, 103, 45, 80, 85, 66, 111, 72, 77, 80, 115, 51, 107, 81, 113, 80, 77, 108, 48, 78, 103, 81, 65, 90, 90, 85, 95, 102, 65, 34, 125, 125] Encoding this JWS Protected Header as BASE64URL(UTF8(JWS Protected Header)) gives this value: eyJhbGciOiJHS0VHLUtFWFAxNUsiLA0KICJlbmMiOiJHSzI1Nk1HTSIsDQogInVr bSI6IHJkSmt0WFJZMzhpOEVHNnkwYjZPMUQwY3BLbTMtU1RXdnNJNHBlNVE0dmss DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMTItNTEyQiIs DQogICAieCI6ImxfZk9pU1VtalRMNjJkMTlkNHJiN2QyZzZrTk9ScXJyWmtGQXpu cDFwa2d4eVJpMmxPdEVhdjNMV2J2dzJnZldrdktuWTFReU9HVHZ4WTIxOWFPNE9n IiwNCiAgICJ5IjoibnlWanhuWWNIY0ttQk83bTRUeURJdG01VmZSOGVpNWlPRjB6 WXRTM1NNOWF1RExjUGZMeUlTVlJMUmctUFVCb0hNUHMza1FxUE1sME5nUUFaWlVf ZkEifX0 Makarov & Sadofev Expires 12 December 2026 [Page 38] Internet-Draft Using GOST Algorithms for JWT June 2026 D.2.4. Initialization Vector Generate a random 127-bit ICN value. JWE Initialization Vector is formed from the ICN value, represented as an n/8-octet big-endian string with the most significant bit set to 0. In this example, the value of JWE Initialization Vector is: [211, 184, 87, 139, 135, 193, 115, 153, 171, 62, 127, 65, 58, 208, 233, 14] Encoding this JWE Initialization Vector as BASE64URL(JWE Initialization Vector) gives this value: 07hXi4fBc5mrPn9BOtDpDg D.2.5. Additional Authenticated Data Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))). This value is: [101, 121, 74, 104, 98, 71, 99, 105, 79, 105, 74, 83, 85, 48, 69, 116, 84, 48, 70, 70, 85, 67, 73, 115, 73, 109, 86, 117, 89, 121, 73, 54, 73, 107, 69, 121, 78, 84, 90, 72, 81, 48, 48, 105, 102, 81] D.2.6. Content Encryption Perform authenticated encryption on the plaintext with the GM256MGM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value above, requesting a 128-bit Authentication Tag output. The resulting ciphertext is: [80, 97, 199, 79, 209, 179, 219, 183, 56, 223, 224, 182, 132, 21, 231, 171, 153, 253, 218, 90, 33, 80, 123, 163, 67, 104, 128, 238, 131, 115, 10, 106, 11, 201, 142, 173, 113, 72, 34, 47, 126, 199, 49, 187, 189, 69, 139, 113, 85, 246, 253, 183, 10, 108, 196, 5, 128, 111, 152, 87, 110, 88, 180] The resulting Authentication Tag value is: [189, 77, 119, 49, 71, 200, 0, 125, 197, 72, 201, 108, 80, 52, 231, 54] Encoding this JWE Ciphertext as BASE64URL(JWE Ciphertext) gives this value (with line breaks for display purposes only): UGHHT9Gz27c43-C2hBXnq5n92lohUHujQ2iA7oNzCmoLyY6tcUgiL37HMbu9RYtx Vfb9twpsxAWAb5hXbli0 Encoding this JWE Authentication Tag as BASE64URL(JWE Authentication Tag) gives this value: vU13MUfIAH3FSMlsUDTnNg Makarov & Sadofev Expires 12 December 2026 [Page 39] Internet-Draft Using GOST Algorithms for JWT June 2026 D.2.7. Complete Representation Assemble the final representation: The Compact Serialization of this result is the string BASE64URL(UTF8(JWE Protected Header)) || '.' || BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE Authentication Tag). The final result in this example (with line breaks for display purposes only) is: eyJhbGciOiJHS0VHLUtFWFAxNUsiLA0KICJlbmMiOiJHSzI1Nk1HTSIsDQogInVr bSI6IHJkSmt0WFJZMzhpOEVHNnkwYjZPMUQwY3BLbTMtU1RXdnNJNHBlNVE0dmss DQogImVwayI6IA0KICB7Imt0eSI6IkVDIiwNCiAgICJjcnYiOiJHMTItNTEyQiIs DQogICAieCI6ImxfZk9pU1VtalRMNjJkMTlkNHJiN2QyZzZrTk9ScXJyWmtGQXpu cDFwa2d4eVJpMmxPdEVhdjNMV2J2dzJnZldrdktuWTFReU9HVHZ4WTIxOWFPNE9n IiwNCiAgICJ5IjoibnlWanhuWWNIY0ttQk83bTRUeURJdG01VmZSOGVpNWlPRjB6 WXRTM1NNOWF1RExjUGZMeUlTVlJMUmctUFVCb0hNUHMza1FxUE1sME5nUUFaWlVf ZkEifX0 . MIIBHjBvMD4EIISLQXDwbIOEj3vq1F2gtXGvpWySjsZWa3Ahtp7rzjzyBBB7mLFU tYumVD_LTsljC9DzBggqhQMHAQEFAjAtBCCt0mS1dFjfyLwQbrLRvo7UPRykqbf5 JNa-wjil7lDi-QYJKoUDBwEBBwIBMIGqMCEGCCqFAwcBAQECMBUGCSqFAwcBAgEC AgYIKoUDBwEBAgMDgYQABIGAl_fOiSUmjTL62d19d4rb7d2g6kNORqrrZkFAznp1 pkgxyRi2lOtEav3LWbvw2gfWkvKnY1QyOGTvxY219aO4Op8lY8Z2HB3CpgTu5uE8 gyLZuVX0fHouYjhdM2LUt0jPWrgy3D3y8iElUS0YPj1AaBzD7N5EKjzJdDYEAGWV P3w . 07hXi4fBc5mrPn9BOtDpDg . UGHHT9Gz27c43-C2hBXnq5n92lohUHujQ2iA7oNzCmoLyY6tcUgiL37HMbu9RYtx Vfb9twpsxAWAb5hXbli0 . vU13MUfIAH3FSMlsUDTnNg D.2.8. Validation This example illustrates the process of creating a JWE with GKEG- KEXP15K with GS512 G12-512B for key encryption and GK256MGM for content encryption. These results can be used to validate JWE decryption implementations for these algorithms. Note that since the GKEG-KEXP15K with GS512 G12-512B computation includes random values, the encryption results above will not be completely reproducible. However, since the GK256MGM computation is deterministic, the JWE Encrypted Ciphertext values will be the same for all encryptions performed using these inputs. Makarov & Sadofev Expires 12 December 2026 [Page 40] Internet-Draft Using GOST Algorithms for JWT June 2026 Authors' Addresses Artyom O. Makarov (editor) CryptoPro 18, Suschevsky val Moscow 127018 Russian Federation Phone: +7 (495) 995-48-20 Email: makarov@cryptopro.ru Georgii A. Sadofev CryptoPro 18, Suschevsky val Moscow 127018 Russian Federation Phone: +7 (495) 995-48-20 Email: sadofiev@cryptopro.com Makarov & Sadofev Expires 12 December 2026 [Page 41]