RFC 9548: Generating Transport Key Containers (PFX) Using the GOST Algorithms
- E. Karelina, Ed.
Abstract
This document specifies how to use "PKCS #12: Personal Information Exchange Syntax v1.1" (RFC 7292) to transport key containers (PFX) for storing keys and certificates in conjunction with the Russian national standard GOST algorithms.¶
This specification has been developed outside the IETF. The purpose of publication is to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used here.¶
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.¶
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2024 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://
1. Introduction
This document provides a specification of the usage of GOST algorithms with PKCS #12 v1.1.¶
PKCS #12 v1.1 describes a syntax for transfer of personal information such as private keys, certificates, and various secrets.¶
This memo describes the creation of transport key containers (PFX) for keys and certificates using the GOST R 34.10-2012 algorithm. The GOST R 34.11-2012 algorithm is used to ensure the integrity of PFX.¶
Caution:¶
This specification is not a standard and does not have IETF community consensus. It makes use of a cryptographic algorithm that is a national standard for Russia. Neither the IETF nor the IRTF has analyzed that algorithm for suitability for any given application, and it may contain either intended or unintended weaknesses.¶
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 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.¶
3. Basic Terms and Definitions
Throughout this document, the following notations are used:¶
- P
- a password encoded as a Unicode UTF-8 string¶
- S
- a random initializing value¶
- Vs
- the set of byte strings of length s, where s >= 0; the string b = (b1,...,bs) belongs to the set Vs if b1,...,bs belongs to {0,...,255}¶
- |A|
- the number of components (a length) of the vector A belonging to Vs (if A is an empty string, then |A| = 0)¶
- A||C
- a concatenation of two byte strings A, C from Vs, i.e., a string from V|A|+|C|, where the left substring from V|A| is equal to the string A and the right substring from V|C| is equal to the string C: A = (a1,...,an1) in Vn1 and C = (c1,...,cn2) in Vn2, res = (a1,...,an1,c1,...,cn2) in Vn1+n2¶
- F_q
- a finite prime field represented as a set of q integers {0,1,...,q - 1}, where q > 3 - prime number¶
- b mod q
- the minimum non-negative number comparable to b modulo p¶
- INT(b)
- integer INT(b) = b1 + b2 * 256 +...+ bs * 256s-1, where b belongs to Vs¶
This document uses the following terms and abbreviations:¶
- Signature
- one or more data elements resulting from the signature process (Clause 3.12 of [ISO14888-1]). Note: The terms "digital signature", "electronic signature", and "electronic digital signature" are considered equivalent in this document.¶
- Signature key
- set of private data elements specific to an entity and usable only by this entity in the signature process (Clause 3.13 of [ISO14888-1]). Note: Sometimes called a private key.¶
- Verification key
- set of public data elements that is mathematically related to an entity's signature key and is used by the verifier in the verification process (Clause 3.16 of [ISO14888-1]). Note: Sometimes called a public key.¶
- ASN.1
- Abstract Syntax Notation One, as defined in [X.680].¶
- BER
- Basic Encoding Rules, as defined in [X.690].¶
- HMAC_GOSTR3411
- Hash-Based Message Authentication Code. A function for calculating a Message Authentication Code (MAC) based on the GOST R 34.11-2012 hash function (see [RFC6986]) with 512-bit output in accordance with [RFC2104].¶
4. PFX
The PFX (see [RFC7292]) is designed for secure storage and data transfer. The scope of this document is to define how PFX is used for private key and certificate protection with a password when GOST R 34.10-2012 is applied.¶
4.1. Structure of PFX
In accordance with [RFC7292], PFX has the following structure:¶
The fields of the PFX have the following meanings:¶
4.2. AuthenticatedSafe
The Authenticated
4.2.1. Unencrypted Data
If the data is not encrypted, then the content field is the BER-encoded value of the SafeContents structure. The contentType field is set to the id-data type.¶
4.2.2. Password-Encrypted Data
When password integrity mode is used, the data is represented as an EncryptedData structure (see [RFC5652]). The encryption algorithm and parameters have the following values:¶
The PBES2-params type is defined in [RFC9337]. The content should be encrypted according to the encryption algorithm in the PBES2 scheme, as described in [RFC9337].
The following identifier MUST be specified in the Encrypted
encryption
The encrypted content is specified in the Encrypted
4.3. SafeContents and SafeBag
In accordance with [RFC7292], the SafeContents structure is a sequence of SafeBag:¶
where¶
The fields of SafeBag have the following meanings:¶
See [RFC7292], Section 4.2 for the different bag types. This document describes the two object types of the SafeBag structure:¶
When password integrity mode is used, the private key has the following structure:¶
The bagValue field contains the key and information about the key, in encrypted form, in the Encrypted
A certBag contains a certificate of a certain type. Object identifiers are used to distinguish between different certificate types.¶
If the certificate is not encrypted, the CertBag structure is placed in the Data structure (see [RFC5652]). If the certificate is encrypted, the CertBag structure is placed in the EncryptedData structure (see [RFC5652]).¶
5. GOST R 34.10-2012 Key Representation
This section describes the GOST R 34.10-2012 private key representation for asymmetric key pairs. Masked keys should be used to ensure that private keys are protected from leaking through side channels when reading and performing operations with keys.¶
5.1. Masking GOST R 34.10-2012 Keys
The masking algorithm is defined by the basic cryptographic transformation operation of the algorithm: multiplication in the F_q field for GOST R 34.10-2012 keys.¶
Let M1, M2, ..., Mk be a sequence of k masks. Let Mi() denote the operation of applying the i-th mask and Mi-1() denote the operation of removing the i-th mask, 1 <= i <= k. Let K be a key. The masked key KM is obtained by applying the masking operation k times:¶
KM = Mk (...(M2(M1(K)...).¶
Unmasking is performed by applying the removal operation k times, but in reverse order:¶
K = M1-1(...(Mk-1-1(Mk-1(KM))...).¶
The masked key is represented as the sequence¶
I = KM||M1||M2||...||Mk.¶
Let the key K be n bits in length; then, the sequence I is represented in memory as a sequence of (k + 1)*n bits. I is represented in little-endian format. It is possible to use an unmasked private key (i.e., k = 0, KM = K). For GOST R 34.10-2012 keys, the masking operation is the multiplication of the key by the inverse of the mask: INT(KM) = INT(K) * INT(M)-1 mod Q, where the Q value is taken from the key parameters. The operation of removing the mask is the multiplication of the masked key by the mask: INT(K) = INT(KM) * INT(M) mod Q. The public key is specified by a pair of coordinates (x, y) as defined in GOST R 34.10-2012, presented in the following format:¶
The public keys Gost
5.2. KeyBag Structure for GOST R 34.10-2012 Key
In accordance with [RFC7292], a KeyBag is defined as information about a private key represented as the PrivateKeyInfo structure:¶
In accordance with [RFC5958], information about a private key is presented in the following form:¶
5.3. OneAsymmetricKey Structure
In accordance with [RFC5958], One
The fields have the following meanings:¶
5.4. EncryptedPrivateKeyInfo Structure for GOST R 34.10-2012 Key
In accordance with [RFC7292], the encrypted information regarding the private key is defined as the PKCS8Shrouded
In accordance with [RFC5958], Encrypted
The fields have the following meanings:¶
6. GOST R 34.10-2012 Certificate Representation
In accordance with [RFC7292], a CertBag is defined as information about a certificate and has the following structure:¶
The fields have the following meanings:¶
7. Security Mechanisms
Let the sender and receiver have a previously agreed-upon password P. The sender generates a password key using the PBKDF2 algorithm in accordance with [RFC9337] and uses it to encrypt the transmitted private key. The recipient independently generates a password key using the same PBKDF2 diversification algorithm in accordance with [RFC9337] and uses it to extract the private key from the PFX.¶
The same password P is used to encrypt different sections of the PFX using a different random initializing value S with a length of 8 to 32 bytes, where S and P are the input parameters of the PBKDF2 function. The password MUST be encoded as a Unicode UTF-8 string and fed into the PBKDF2 algorithm as a P parameter.¶
The integrity of the PFX is ensured by using the HMAC
The mac
8. Security Considerations
The masked keys SHOULD be used to ensure that private keys are protected from leaking through side channels when reading and performing operations with keys. Applications MUST use unique values for ukm and S in the PBKDF2 algorithm. It is RECOMMENDED that parameter S consist of at least 32 octets of pseudorandom data in order to reduce the probability of collisions of keys generated from the same password. The password MUST be encoded as a Unicode UTF-8 string and fed into the PBKDF2 algorithm as a P parameter. For more information, see [RFC9337]. Encryption MUST use the PBES2 scheme to encrypt private keys. Public keys MUST be DER encoded as an octet string in accordance with [RFC9215]. Passwords SHOULD be stored in a secure way. For information on security considerations for generating PFX, see [RFC7292].¶
9. IANA Considerations
This document has no IANA actions.¶
11. References
11.1. Normative References
- [RFC2104]
-
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10
.17487 , , <https:///RFC2104 www >..rfc -editor .org /info /rfc2104 - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC5652]
-
Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10
.17487 , , <https:///RFC5652 www >..rfc -editor .org /info /rfc5652 - [RFC5958]
-
Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10
.17487 , , <https:///RFC5958 www >..rfc -editor .org /info /rfc5958 - [RFC6986]
-
Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: Hash Function", RFC 6986, DOI 10
.17487 , , <https:///RFC6986 www >..rfc -editor .org /info /rfc6986 - [RFC7292]
-
Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10
.17487 , , <https:///RFC7292 www >..rfc -editor .org /info /rfc7292 - [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 , , <https:///RFC7836 www >..rfc -editor .org /info /rfc7836 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC9215]
-
Baryshkov, D., Ed., Nikolaev, V., and A. Chelpanov, "Using GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with the Internet X.509 Public Key Infrastructure", RFC 9215, DOI 10
.17487 , , <https:///RFC9215 www >..rfc -editor .org /info /rfc9215 - [RFC9337]
-
Karelina, E., Ed., "Generating Password-Based Keys Using the GOST Algorithms", RFC 9337, DOI 10
.17487 , , <https:///RFC9337 www >..rfc -editor .org /info /rfc9337 - [X.680]
-
ITU-T, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1:2021, , <https://
www >..itu .int /rec /T -REC -X .680 - [X.690]
-
ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC International Standard 8825-1:2021, , <https://
www >..itu .int /rec /T -REC -X .690
11.2. Informative References
- [ISO14888-1]
-
ISO/IEC, "Information technology - Security techniques - Digital signatures with appendix - Part 1: General", ISO/IEC 14888-1, , <https://
www >..iso .org /standard /44226 .html
Appendix A. Examples
This section contains examples of using GOST cryptographic algorithms to create a PFX.¶
A.1. Test Data
In all examples, the following data is used.¶
A.1.1. Test Certificate
This section contains a test certificate in BASE64 format.¶
A.2. Example of a PFX with a Password-Protected Key and Unencrypted Certificate
In this example, the PKCS8SHrouded
The key encryption algorithm identifier:¶
A.3. Example of a PFX with a Password-Protected Key and a Password-Protected Certificate
In this example, the PKCS8SHrouded
The key encryption algorithm identifier:¶
The certificate encryption algorithm identifier:¶
Acknowledgments
The author thanks Potashnikov Alexander, Pianov Semen, and Smyslov Valery for their careful readings and useful comments, and Chelpanov Alexander for his help with the registration of identifiers.¶