<?xml version="1.0" encoding="UTF-8"?> <!--[CS][ST] updated byChris 10/18/22Sarah 01/03/24 --> <!-- draft submitted in xml v3 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent" category="info" docName="draft-pkcs12-gost-08" number="9548" ipr="trust200902" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" updates="" obsoletes="" xml:lang="en" version="3"> <!-- xml2rfc v2v3 conversion 3.12.10 --> <front> <title abbrev="GOST Usage in Password-Based PKCS #12">Generating Transport Key Containers Using the GOST Algorithms</title> <!-- [rfced] We updated the front-page title and the running title (PDF file) as follows. Please let us know any objections. Original: Generating the Transport Key Containers Using the GOST Algorithms GOST usage in password-basedpkcs12">pkcs12 Currently: GeneratingtheTransport Key Containers Using the GOST Algorithms</title>GOST Usage in Password-Based PKCS #12 --> <seriesInfo name="RFC" value="9548"/> <author fullname="Ekaterina Karelina" initials="E." role="editor" surname="Karelina"> <organization>InfoTeCS</organization> <address> <postal> <street>2B stroenie 1, ul. Otradnaya</street> <city>Moscow</city> <code>127273</code> <country>Russian Federation</country> </postal> <email>Ekaterina.Karelina@infotecs.ru</email> </address> </author> <dateyear="2023" month="December"/> <keyword>the transport key containers, certificates, GOST algorithms, pkcs12, gost, PFX</keyword>year="2024" month="February"/> <keyword>transport key containers</keyword> <keyword>certificates</keyword> <keyword>GOST algorithms</keyword> <keyword>pkcs12</keyword> <keyword>gost</keyword> <keyword>PFX</keyword> <abstract> <t> This document specifies how to use "PKCS #12: Personal Information Exchange Syntax v1.1" (RFC 7292) to generatethetransport key containers for storing keys and certificates in conjunction with the Russian national standard GOST algorithms. </t> <t> This specification has been developed outside the IETF. The purpose of publicationbeingis to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not imply IETF endorsement of the cryptographic algorithms used here. </t> </abstract> </front> <middle> <section anchor="Introduction"> <name>Introduction</name> <!-- [rfced] Sections 1 and subsequent: When viewing the "diff" files, please note that in addition to our other updates, per our current process, we changed non-ASCII hyphens in such entries as "34.10-2012", "q > 3 – prime", and "GostR3410–2012-256-PublicKey". Please review, and let us know any concerns. --> <t> This document provides a specification of the usage of GOST algorithms with PKCS #12 v1.1. </t> <t> PKCS #12 v1.1 describes a syntax for transfer of personal information such as private keys, certificates, and various secrets. </t> <t> This memo describes thecreatingcreation of transport key containers for keys and certificates of electronic signature verification keys which are created in accordance with the GOST R34.10–201234.10-2012 algorithm. The GOST R 34.11-2012 algorithm is used to ensure the integrity of transport key containers. <!-- [rfced] Section 1: To what does "which" refer in this sentence - the containers or the verification keys? If neither suggestion below is correct, please clarify the text. Original: This memo describes the creating of transport key containers for keys and certificates of electronic signature verification keys which are created in accordance with GOST R 34.10–2012 algorithm. Suggestion #1 (the containers): This memo describes the creation of transport key containers for keys and certificates of electronic signature verification keys. These transport key containers are created in accordance with the GOST R 34.10-2012 algorithm. Suggestion #2 (the verification keys): This memo describes the creation of transport key containers for keys and certificates of electronic signature verification keys. The signature verification keys are created in accordance with the GOST R 34.10-2012 algorithm. --> </t> </section> <section> <name>Conventions Used in This Document</name><t> The<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere. </t>here.</t> </section> <section anchor="Definition"> <name>Basic Terms and Definitions</name> <t> Throughout this document, the followingnotation isnotations are used: </t><table align="center"> <name>Terms<!-- [rfced] Section 3: Please note that because Tables 1 andDefinitions</name> <thead> <tr> <th>Notation</th> <th>Definition</th> </tr> </thead> <tbody> <tr> <td align="left">P</td> <td align="left">a2 are lists of definitions, we converted them to definition lists. The superscripting and subscripting are preserved in the HTML and PDF output files. Please review, and let us know any objections. --> <dl spacing="normal" newline="false"> <dt>P</dt> <dd>a password encoded as a Unicode UTF-8string</td> </tr> <tr> <td align="left">S</td> <td align="left">astring</dd> <dt>S</dt> <dd>a random initializingvalue</td> </tr> <tr> <td align="left">V<sup>*</sup></td> <td align="left">thevalue</dd> <dt>V<sup>*</sup></dt> <dd>the set of all binary row vectors of finite length (hereinafter referred to as vectors) including emptystring</td> </tr> <tr> <td align="left">V<sub>s</sub></td> <td align="left">thestring <!-- [rfced] Section 3: Does "all binary row vectors of finite length (hereinafter referred to as vectors) including empty string" mean (1) "all binary row vectors of finite length (hereinafter referred to as vectors), including an empty string" (or "including empty strings"), (2) "all binary row vectors of finite length (hereinafter referred to as vectors) that include an empty string" (or "that include empty strings"), or (3) something else? Please clarify. Original: | V^(*) | the set of all binary row vectors of finite length | | | (hereinafter referred to as vectors) including | | | empty string | --> </dd> <dt>V<sub>s</sub></dt> <dd>the set of all binary row vectors of length s, where s >= 0; if s = 0, then the set V<sub>s</sub> consists of an empty string of length0</td> </tr> <tr> <td align="left">|A|</td> <td align="left">the0</dd> <dt>|A|</dt> <dd>the number of components (a length) of the vector A belonging to V<sup>*</sup> (if A is an empty string, then |A| =0)</td> </tr> <tr> <td align="left">A||C</td> <td align="left">a0)</dd> <dt>A||C</dt> <dd>a concatenation of two octet strings A, C, i.e., a vector from V<sub>|A|+|C|</sub>, where the left subvector from V<sub>|A|</sub> is equal to the vector A and the right subvector from V<sub>|C|</sub> is equal to the vector C: A = (a<sub>n<sub>1</sub></sub>,...,a<sub>1</sub>) in V<sub>n<sub>1</sub></sub> and C = (c<sub>n<sub>2</sub></sub>,..., c<sub>1</sub>) in V<sub>n<sub>2</sub></sub>, res = (a<sub>n<sub>1</sub></sub>,...,a<sub>1</sub>,c<sub>n<sub>2</sub></sub>,..., c<sub>1</sub>) inV<sub>n<sub>1</sub>+n<sub>2</sub></sub>)</td> </tr> <tr> <td align="left">F_q</td> <td align="left">aV<sub>n<sub>1</sub>+n<sub>2</sub></sub>) <!-- [rfced] Section 3: Please confirm that "two octet strings A, C" will be clear to readers. We also see this text in RFC 9337, but this document provides an opportunity to clarify the text, if needed. (For example, does it mean "two octet strings, A and C"?) Original: | A||C | a concatenation of two octet strings A, C, i.e., a | | | vector from V_(|A|+|C|), where the left subvector | | | from V_(|A|) is equal to the vector A and the | | | right subvector from V_(|C|) is equal to the | | | vector C: A = (a_(n_1),...,a_1) in V_(n_1) and C = | | | (c_(n_2),..., c_1) in V_(n_2), res = | | | (a_(n_1),...,a_1,c_(n_2),..., c_1) in V_(n_1+n_2)) | --> </dd> <dt>F_q</dt> <dd>a finite prime field represented as a set of q integers {0,1,..., q - 1}, where q > 3–- primenumber</td> </tr> <tr> <td align="left">bnumber</dd> <dt>b modq</td> <td align="left">theq</dt> <dd>the minimum non-negative number comparable to b modulop</td> </tr> </tbody> </table>p</dd> </dl> <t> This document uses the followingabbreviationsterms anddefinitions:</t> <table align="center"> <name>Abbreviations and Definition</name> <thead> <tr> <th>Abbreviations and Terms</th> <th>Definition</th> </tr> </thead> <tbody> <tr> <td align="left">Signature</td> <td align="left">oneabbreviations:</t> <dl spacing="normal" newline="false"> <dt>Signature</dt> <dd>one or more data elements resulting from the signature process(clause(Clause 3.12 of <xref target="ISO14888-1"/>). Note:theThe terms "digital signature", "electronic signature", and "electronic digital signature" are considered equivalent in thisdocument. </td> </tr> <tr> <td align="left">Signature key</td> <td align="left">setdocument.</dd> <dt>Signature key</dt> <dd>set of private data elements specific to an entity and usable only by this entity in the signature process(clause(Clause 3.13 of <xref target="ISO14888-1"/>). Note: Sometimes called a privatekey.</td> </tr> <tr> <td align="left">Verification key</td> <td align="left">setkey.</dd> <dt>Verification key</dt> <dd>set of public data elementswhichthat is mathematically related to an entity's signature key andwhichis used by the verifier in the verification process(clause(Clause 3.16 of <xref target="ISO14888-1"/>). Note: Sometimes called a publickey.</td> </tr> <tr> <td align="left">ASN.1</td> <td align="left">Abstractkey.</dd> <dt>ASN.1</dt> <dd>Abstract Syntax Notation One, as defined in <xreftarget="X.680"/>.</td> </tr> <tr> <td align="left">BER</td> <td align="left">Basictarget="X.680"/>.</dd> <dt>BER</dt> <dd>Basic Encoding Rules, as defined in <xreftarget="X.690"/>.</td> </tr> <tr> <td align="left">HMAC_GOSTR3411</td> <td align="left">Hashed-Basedtarget="X.690"/>.</dd> <dt>HMAC_GOSTR3411</dt> <!--[rfced] Section 3: In RFC 2104, we do not see specific mention of "512-bit output". Please confirm if this is the correct reference or if an update is needed. Original: HMAC_GOSTR3411 Hashed-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]. --> <dd>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 <xref target="RFC6986"/>) with 512-bit output in accordance with <xreftarget="RFC2104"/>.</td> </tr> </tbody> </table>target="RFC2104"/>.</dd> </dl> </section> <section anchor="PFX"> <name>PFX</name> <t> The transport key container(PFX,(PFX; see <xref target="RFC7292"/>) is designed for secure storage and data transfer. The scope of this document is to define how the transport key container is used for private key and certificate protection with a password when GOST R 34.10-2012 is applied..<!-- [rfced] Section 4: This sentence as written seems to indicate that "PFX" means "transport key container". However, we see that RFC 7292 says that "PFX" is sometimes expanded as "Personal Information Exchange". Are some words missing from this sentence, or do "PFX", "transport key container", and "Personal Information Exchange" all mean the same thing? Original: The transport key container (PFX, see [RFC7292]) is designed for secure storage and data transfer. Possibly (if all three terms mean the same thing): The transport key container (PFX, which is sometimes expanded as "Personal Information Exchange"; see [RFC7292]) is designed for secure storage and data transfer. --> </t> <section anchor="StrucurePFX"> <name>Structure of PFX</name> <t>In accordance with <xreftarget="RFC7292"/>target="RFC7292"/>, the transport key container has the following structure:</t> <!-- [rfced] Please review the "type" attribute of each sourcecode element in the XML file to ensure correctness. For example, in Appendix A, should some of the sourcecode entries with type = "asn.1" be type = "test-vectors" instead (possibly the data that follows "This section contains a test certificate ..." and "Decrypted key value in BASE64 format")? Please see <https://www.rfc-editor.org/materials/sourcecode-types.txt>. If the current list of preferred values for "type" on that page does not contain an applicable type, please let us know. Also, it is acceptable to leave the "type" attribute not set. --> <sourcecode type="asn.1"><![CDATA[ PFX ::= SEQUENCE { version INTEGER {v3(3)}(v3,...), authSafe ContentInfo, macData MacData OPTIONAL }]]></sourcecode> <t>The fields of the PFX have the following meanings:</t> <ul spacing="normal"><li>version is the syntax version number; the only allowed value for this specification is3;</li>3.</li> <li>authSafe contains the data of type ContentInfo. In the case of password integritymodemode, the authSafe.content field has a Data type value and contains a BER-encoded value of the AuthenticatedSafestructure;</li>structure.</li> <li>macData has a MacDatatype andtype; in the case of password integritymodemode, the macData field should containtheinformation about the algorithm and parameters forapassword key generation.The integrityIntegrity control is ensured by using the HMAC_GOSTR3411_2012_512 algorithm: the macData.mac.digestAlgorithm.algorithm field contains the HMAC_GOSTR3411_2012_512 algorithm identifier (see <xref target="SecurityM"/>). When processing a transport key container, this field should be checked first.</li> </ul> </section> <section anchor="AuthenticatedSafe"> <name>AuthenticatedSafe</name> <t>The AuthenticatedSafe structure is a sequence of ContentInfo values (see <xref target="RFC5652"/>):</t> <sourcecode type="asn.1"><![CDATA[ AuthenticatedSafe ::= SEQUENCE OF ContentInfo -- Data if unencrypted -- EncryptedData if password-encrypted -- EnvelopedData if public key-encrypted ]]></sourcecode> <section anchor="Unencrypted"> <name>Unencrypted Data</name> <t>If the data is notencryptedencrypted, then the content field is the BER-encoded value of the SafeContents structure. The contentType field is set to the id-data type.</t> </section> <section anchor="Password-encrypted"><name>Password-encrypted data</name><name>Password-Encrypted Data</name> <t>When password integrity mode isusedused, the data is represented as an EncryptedData structure(<xref(see <xref target="RFC5652"/>). The encryption algorithm and parameters have the followingvalues:</t>values: <!-- [rfced] Section 4.2, Section 4.3, and Appendix A: We do not see "Data structure" or "EncryptedData structure" in RFC 5652. Will these sentences be clear to readers? Original: When password integrity mode is used the data is represented as an EncryptedData structure ([RFC5652]). ... 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]). ... In this example the PKCS8SHroudedKeybag structure is used to store the key, which is placed in the Data structure. The certBag structure is used to store the certificate, which is placed in the Data structure. ... In this example the PKCS8SHroudedKeybag structure is used to store the key, which is placed in the Data structure (see [RFC5652]). The certBag structure is used to store the certificate, which is placed in the EncryptedData structure (see [RFC5652]). --> </t> <sourcecode type="asn.1"><![CDATA[ ContentEncryptionAlgorithmIdentifier ::= SEQUENCE { encryptionAlgorithmOID OBJECT IDENTIFIER, parameters PBES2-params } ]]></sourcecode> <t>The PBES2-params type is defined in <xref target="RFC9337"/>. The content should be encrypted according to the encryption algorithm in the PBES2 scheme, as described in <xref target="RFC9337"/>. The following identifierMUST<bcp14>MUST</bcp14> be specified in the EncryptedData.EncryptedContentInfo.contentEncryptionAlgorithm.encryptionAlgorithmOIDfield:</t>field: <!-- [rfced] Section 4.2.2: This field name is too long to fit on one line. Would you like to insert an appropriate line break and add a note for the reader that the line break is used for readability? Please note that the line break is bad in the HTML output file but is OK in the text and PDF output files. Original: The following identifier MUST be specified in EncryptedData.EncryptedContentInfo.contentEncryptionAlgorithm.encr yptionAlgorithmOID field: Currently: The following identifier MUST be specified in the EncryptedData.EncryptedContentInfo.contentEncryption Algorithm.encryptionAlgorithmOID field: --> </t> <sourcecode type="asn.1"><![CDATA[ { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-5(5) pbes2(13) } ]]></sourcecode> <t>The encrypted content is specified in the EncryptedData.EncryptedContentInfo.encryptedContent field.</t> </section> </section> <section anchor="SC"> <name>SafeContents and SafeBag</name> <t>In accordance with <xreftarget="RFC7292"/>target="RFC7292"/>, the SafeContents structure is a sequence of SafeBag:</t> <sourcecode type="asn.1"><![CDATA[ SafeContents ::= SEQUENCE OF SafeBag ]]></sourcecode> <t>where</t> <sourcecode type="asn.1"><![CDATA[ SafeBag ::= SEQUENCE { bagId BAG-TYPE.&id ({PKCS12BagSet}) bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId}) bagAttributes SET OF PKCS12Attribute OPTIONAL } ]]></sourcecode> <t>The fields of SafeBag have the following meanings:</t> <ul spacing="normal"><li>bagId is an objectidentifier,identifier; it defines the type ofobject;</li>object.</li> <li>bagValue is the value of anobject;</li>object.</li> <li>bagAttributes contains theusersusers' names, the keyidentifiersidentifiers, and other additional information.ItThis field is optional.</li> </ul> <t>See <xreftarget="RFC7292"/> Section 4.2.target="RFC7292" sectionFormat="comma" section="4.2"/> for the different bag types. This document describes the2two object types of the SafeBag structure:</t><ul<ol spacing="normal"><li>pkcs8ShroudedKeyBag,</li> <li>certBag.</li> </ul><li>pkcs8ShroudedKeyBag</li> <li>certBag</li> </ol> <t>When password integrity mode isusedused, the private key has the following structure:</t> <sourcecode type="asn.1"><![CDATA[ pkcs8ShroudedKeyBag BAG-TYPE ::= { PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2} } ]]></sourcecode> <t>The bagValue field contains the key and information about the key, in encrypted form, in the EncryptedPrivateKeyInfo structure. <!-- [rfced] Section 4.3: As it appears that "it" refers to the key and not to the bagValue field, we updated this sentence accordingly. If this is incorrect, please provide clarifying text. Original: The bagValue field contains the key and information about it in the encrypted form in the EncryptedPrivateKeyInfostructure.</t>structure. Currently: The bagValue field contains the key and information about the key, in encrypted form, in the EncryptedPrivateKeyInfo structure. --> </t> <t>A certBag contains a certificate of a certain type. Object identifiers are used to distinguish between different certificate types.</t> <sourcecode type="asn.1"><![CDATA[ certBag BAG-TYPE ::= { CertBag IDENTIFIED BY { bagtypes 3 } } ]]></sourcecode> <t>If the certificate is not encrypted, the CertBag structure is placed in the Data structure (see <xref target="RFC5652"/>). If the certificate is encrypted, the CertBag structure is placed in the EncryptedData structure (see <xref target="RFC5652"/>).</t> </section> </section> <section anchor="Key_repres"> <name>GOST R34.10–2012 key representation</name>34.10-2012 Key Representation</name> <t>This section describes the GOST R34.10–201234.10-2012 privatekeyskey representation for asymmetric key pairs. Masked keys should be used to ensurethe protection ofthat private keys are protected fromleaksleaking throughtheside channels when reading and performing operations with keys.</t> <section anchor="Key_mask"> <name>Masking GOST R34.10–2012 keys</name>34.10-2012 Keys</name> <t>The masking algorithm is defined by the basic cryptographic transformation operation of the algorithm: multiplication in the F_q field for GOST R34.10–201234.10-2012 keys.</t> <t>Let M<sub>1</sub>, M<sub>2</sub>, ..., M<sub>k</sub> be a sequence of k masks. Let M<sub>i</sub>() denote the operation of applying the i-th mask and M<sub>i</sub><sup>-1</sup>() denote the operation of removing the i-th mask, 1 <= i <= k. Let K be a key. The masked key K<sub>M</sub> is obtained by applying the masking operation k times:</t><ul empty="true" spacing="normal"> <li>K<sub>M</sub><t indent="3">K<sub>M</sub> = M<sub>k</sub>(...(M<sub>2</sub>(M<sub>1</sub>(K)...).</li> </ul>(...(M<sub>2</sub>(M<sub>1</sub>(K)...).</t> <t>Unmasking is performed by applying theremovingremoval operation k times, but in reverse order:</t><ul empty="true" spacing="normal"> <li>K<t indent="3">K =M<sub>1</sub><sup>-1</sup>(...(M<sub>k-1</sub><sup>-1</sup>(M<sub>k</sub><sup>-1</sup>(K<sub>M</sub>))...).</li> </ul>M<sub>1</sub><sup>-1</sup>(...(M<sub>k-1</sub><sup>-1</sup>(M<sub>k</sub><sup>-1</sup>(K<sub>M</sub>))...).</t> <t>The masked key is represented as the sequence</t><ul empty="true" spacing="normal"> <li>I<t indent="3">I =K<sub>M</sub>||M<sub>1</sub>||M<sub>2</sub>||...||M<sub>k</sub>.</li> </ul>K<sub>M</sub>||M<sub>1</sub>||M<sub>2</sub>||...||M<sub>k</sub>.</t> <!-- [rfced] Section 5.1: Are the periods at the end of these standalone equations part of the equations, or should they be removed? Original: K_M = M_k (...(M_2(M_1(K)...). K = M_1^-1(...(M_(k-1)^-1(M_k^-1(K_M))...). I = K_M||M_1||M_2||...||M_k. --> <t>Let the key K be n bits inlength, thenlength; 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, K<sub>M</sub> = K). The masking operation is the multiplication of the key by the inverse of the mask: K<sub>M</sub> = K * M<sup>-1</sup> 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: K = K<sub>M</sub> * M mod Q. The public key is specified by a pair of coordinates (x, y) as defined in GOST R34.10–2012,34.10-2012, presented in the following format:</t> <ul spacing="normal"> <li>a public key corresponding to the GOST R34.10–201234.10-2012 algorithm with a key length of 256 bits has theGostR3410–2012-256-PublicKeyGostR3410-2012-256-PublicKey representation. It is specified by a 64-byte string, where the first 32 bytes contain the little-endian representation of the xcoordinate,coordinate and the last 32 bytes contain the little-endian representation of the ycoordinate;</li>coordinate.</li> <li>a public key corresponding to the GOST R34.10–201234.10-2012 algorithm with a key length of 512 bits has theGostR3410–2012-512-PublicKeyGostR3410-2012-512-PublicKey representation. It is specified by a 128-byte string, where the first 64 bytes contain the little-endian representation of the xcoordinate,coordinate and the last 64 bytes contain the little-endian representation of the y coordinate.</li> </ul> <t>The public keys GostR3410-2012-256-PublicKey and GostR3410-2012-512-PublicKeyMUST<bcp14>MUST</bcp14> beDER-encodedDER encoded as an octet string in accordance with <xreftarget="RFC9215"/> (section 4.3):</t> <ul empty="true" spacing="normal"> <li>GostR3410–2012-256-PublicKeytarget="RFC9215" sectionFormat="of" section="4.3"/>:</t> <sourcecode type="asn.1"><![CDATA[ GostR3410-2012-256-PublicKey ::= OCTET STRING(64),</li> <li>GostR3410–2012-512-PublicKey(64), GostR3410-2012-512-PublicKey ::= OCTET STRING(128).</li> </ul>(128). ]]></sourcecode> </section> <section anchor="KeyBag"> <name>KeyBagstructureStructure for GOST R34.10–2012 key</name>34.10-2012 Key</name> <t> In accordance with <xreftarget="RFC7292"/>target="RFC7292"/>, a KeyBag is defined as information about a private key represented as the PrivateKeyInfo structure:</t> <sourcecode type="asn.1"><![CDATA[ KeyBag := PrivateKeyInfo ]]></sourcecode> <!-- [rfced] Section 5.2: Should the two " := " entries be " ::= "? Original: KeyBag := PrivateKeyInfo ... PrivateKeyInfo := OneAsymmetricKey --> <t>In accordance with <xref target="RFC5958"/>, information about a private key is presented in the following form:</t> <sourcecode type="asn.1"><![CDATA[ PrivateKeyInfo := OneAsymmetricKey ]]></sourcecode> </section> <section anchor="OneAsymmetricKey"> <name>OneAsymmetricKeystructure</name>Structure</name> <t>In accordance with <xreftarget="RFC5958"/>target="RFC5958"/>, OneAsymmetricKey has the following structure: </t> <sourcecode type="asn.1"><![CDATA[ OneAsymmetricKey::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] Attributes OPTIONAL, ..., [[2:publicKey [1] PublicKey OPTIONAL]], ... } Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2) PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier PrivateKey ::= OCTET STRING PublicKey ::= BIT STRING Attributes ::= SET OF Attribute ]]></sourcecode> <t>The fields have the following meanings:</t> <ul spacing="normal"> <li>version identifies the version of OneAsymmetricKey. If publicKey is present, then version is set to2 else2; else, version is set to 1.</li> <li>privateKeyAlgorithm identifies theprivate-keyprivate key algorithm and optionally contains parameters associated with the asymmetric key pair. For GOST R34.10–201234.10-2012 privatekeyskeys, the identifiers of the corresponding public keys areused,used; they are defined inthe<xref target="RFC9215"/>. The use of identifiers and public key parameters is defined inthe<xref target="RFC9215"/>.</li> <li>privateKey is an OCTET STRING that contains the value of the masked private key I.</li> <li>attributes are optional. They contain information corresponding to the public key (e.g., certificates).</li> <li>publicKey contains the value of the public keyGostR3410–2012-256-PublicKeyGostR3410-2012-256-PublicKey orGostR3410–2012-512-PublicKeyGostR3410-2012-512-PublicKey encoded in a BIT STRING.ItThis field isan optional field.</li>optional.</li> </ul> </section> <section anchor="PKCS8ShroudedKeyBag"> <name>EncryptedPrivateKeyInfostructureStructure for GOST R34.10–2012 key</name>34.10-2012 Key</name> <t>In accordance with <xreftarget="RFC7292"/>target="RFC7292"/>, the encrypted informationofregarding the private key is defined as the PKCS8ShroudedKeyBag structure:</t> <sourcecode type="asn.1"><![CDATA[ PKCS8ShroudedKeyBag::= EncryptedPrivateKeyInfo ]]></sourcecode> <t>In accordance with <xreftarget="RFC5958"/> thetarget="RFC5958"/>, EncryptedPrivateKeyInfo has the following structure:</t> <sourcecode type="asn.1"><![CDATA[ EncryptedPrivateKeyInfo ::= SEQUENCE { encryptionAlgorithm EncryptionAlgorithmIdentifier, encryptedData EncryptedData } EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier EncryptedData ::= OCTET STRING ]]></sourcecode> <t>The fields have the following meanings:</t> <ul spacing="normal"> <li>encryptionAlgorithm identifies the algorithm under which the private key information is encrypted. EncryptionMUST<bcp14>MUST</bcp14> use the PBES2 scheme. The algorithm and parameters of this scheme are presented in <xref target="RFC9337"/>.</li> <li>encryptedData is the DER-encoded PrivateKeyInfo structure.</li> </ul> </section> </section> <section anchor="Cert_repres"> <name>GOST R34.10–2012 certificate representation</name>34.10-2012 Certificate Representation</name> <t> In accordance with <xreftarget="RFC7292"/>target="RFC7292"/>, a CertBag is defined as information about a certificate andrepresented ashas the following structure:</t> <sourcecode type="asn.1"><![CDATA[ CertBag ::= SEQUENCE { certId BAG-TYPE.&id ({CertTypes}), certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId}) } ]]></sourcecode> <t>The fields have the following meanings:</t> <ul spacing="normal"> <li>certId identifies the type of certificate.</li> <li>certValue contains the certificate.</li> </ul> </section> <section anchor="SecurityM"> <name>Security Mechanisms</name> <t>Let the sender and receiver have apre-agreedpreviously agreed-upon password P. The sender generates a password key using the PBKDF2 algorithm in accordance with <xref target="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 <xref target="RFC9337"/> and uses it to extract the private key from the PFX.</t> <t>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 passwordMUST<bcp14>MUST</bcp14> be encoded as a Unicode UTF-8 string and fed into the PBKDF2 algorithm as a Pparameter.</t>parameter. <!-- [rfced] Section 7: We changed "using different random initializing value S" to "using a different random initializing value S". If this is incorrect, please clarify the text (for example, was "different random initializing values for S" intended?). Original: The same password P is used to encrypt different sections of the PFX using 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. Currently: 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. --> </t> <t>The integrity of the PFX is ensured by using the HMAC_GOSTR3411_2012_512 algorithm in accordance with <xref target="RFC7836"/>.For checkingTo check the integrity of the PFX with the HMAC_GOSTR3411_2012_512algorithmalgorithm, the key for this algorithm is also generated by using the PBKDF2 algorithm in accordance with <xreftarget="RFC9337"/>target="RFC9337"/>, with the same valueoffor the P parameter and a different initializing value S with a length of 8 to 32 bytes. The dkLen parameter for the PBKDF2 algorithm is set to 96 bytes. The key for the HMAC_GOSTR3411_2012_512 algorithm must be the last 32 bytes of the 96-byte sequence generated by the PBKDF2 algorithm. The PBKDF2 algorithm parameters S and c are saved in the macData.Salt and macData.iterationsfiledsfields, respectively. The HMAC_GOSTR3411_2012_512 function is calculated from the content field of the authSafe structure field. The authSafe structure field is a PFX structure field. The value of the calculated checksum is saved in the macData.mac.digest field. The macData.mac.digestAlgorithm.algorithm field contains the following algorithm identifier:</t> <sourcecode type="asn.1"><![CDATA[ id-tc26-gost3411-12-512 :: = { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms (1) digest(2)gost3411–2012-512(3)gost3411-2012-512(3) } ]]></sourcecode> <!-- [rfced] Section 7: <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.1.2.3&a=display> shows "gost3411-12-512(3)". Should "2012" be "12" per the OID repository, or is the repository incorrect? Original: id-tc26-gost3411-12-512 :: = { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms (1) digest(2) gost3411–2012-512(3) } --> <t>The macData.mac.digestAlgorithm.parameters field isn't used and should be omitted.</t> </section> <section anchor="Security"> <name>Security Considerations</name> <t>The masked keysSHOULD<bcp14>SHOULD</bcp14> be used to ensurethe protection ofthat private keys are protected from leaking through side channels when reading and performing operations with keys. ApplicationsMUST<bcp14>MUST</bcp14> use unique values for ukm and S in the PBKDF2 algorithm. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that parameter S consist of at least 32 octets ofpseudo-randompseudorandom data in order to reduce the probability of collisions of keys generated from the same password. The passwordMUST<bcp14>MUST</bcp14> be encoded as a Unicode UTF-8 string and fed into the PBKDF2 algorithm as a P parameter. For moreinformationinformation, see <xref target="RFC9337"/>. EncryptionMUST<bcp14>MUST</bcp14> use the PBES2 schemefor encryptionto encrypt private keys. Public keysMUST<bcp14>MUST</bcp14> beDER-encodedDER encoded as an octet string in accordance with <xref target="RFC9215"/>. PasswordsSHOULD<bcp14>SHOULD</bcp14> be stored in a secure way. For information on security considerations for generatingthetransport keycontainerscontainers, see <xref target="RFC7292"/>.</t> </section> <section anchor="IANA_Considerations"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> <section anchor="ASN"> <name>ASN.1 Modules</name> <sourcecode type="asn.1"><![CDATA[ PKCS-12RU { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) modules(0) pkcs-12ruSyntax(5) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTSGostR3410–2012-PublicKeyGostR3410-2012-PublicKey FROMGostR3410–2012-PKISyntaxGostR3410-2012-PKISyntax { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) modules(0)gostR3410–2012-PKISyntax(2)gostR3410-2012-PKISyntax(2) }; END ]]></sourcecode> <!-- [rfced] Section 10: a) We could not get output for "pkcs-12ruSyntax(5)" on the OID repository (http://www.oid-info.com/index.htm). 1.2.643.7.1.0.5 yields an error, as seen on <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0.5&a=display>. Original: PKCS-12RU { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) modules(0) pkcs-12ruSyntax(5) } Backing out one level, we see the following on <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0&action=display>: modules(0) child OIDs: gostR3411-2012-PKISyntax(2) ruStrongCertsSyntax(6) Please let us know if any updates are needed. Is "pkcs-12ruSyntax(5)" an unregistered entry? b) We did not find a match for "gostR3410-2012-PKISyntax(2)" on <http://www.oid-info.com/index.htm>. Original: FROM GostR3410–2012-PKISyntax { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) modules(0) gostR3410–2012-PKISyntax(2) }; We see the following on <http://www.oid-info.com/cgi-bin/display?oid=1.2.643.7.1.0.2&a=display>: gostR3411-2012-PKISyntax(2) Is the "3410" entry an unregistered entry? We also see gostR3410-2012-PKISyntax(2) at the beginning of Appendix A of RFC 9215. --> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7292.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7292.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7836.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7836.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6986.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6986.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9215.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9215.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9337.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9337.xml"/> <referenceanchor="X.680">anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680"> <front> <title>Information Technology - Abstract Syntax NotationOne:One (ASN.1): Specification ofBasic Notation.</title>basic notation</title> <author> <organization>ITU-T</organization> </author> <dateyear="2002"/>month="February" year="2021"/> </front><refcontent>ITU-T,<seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/> </reference> <!-- [rfced] [X.680]: ISO/IEC 8824-1:2002 has been withdrawn, as have the 2008 and 2015 versions. We have updated this listing as follows. Please let us know any concerns. Original: [X.680] ITU-T, "Information Technology - Abstract Syntax Notation One: Specification of Basic Notation.", ITU-T, Recommendation X.680, ISO/IEC8824-1:2002</refcontent> </reference>8824-1:2002, 2002. Currently: [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, February 2021, <https://www.itu.int/rec/T-REC-X.680>. --> <referenceanchor="X.690">anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690"> <front> <title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules(DER).</title>(DER)</title> <author> <organization>ITU-T</organization> </author> <datemonth="November" year="2008"/>month="February" year="2021"/> </front><refcontent>ITU-T,<seriesInfo name="ITU-T Recommendation" value="X.690"/> <seriesInfo name="ISO/IEC International Standard" value="8825-1:2021"/> </reference> <!-- [rfced] [X.690]: ISO/IEC 8825-1:2008 has been withdrawn, as has the 2015 version. We have updated this listing as follows. Please let us know any concerns. Original: [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 Standard8825-1:2008</refcontent> </reference>8825-1:2008, November 2008. Currently: [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, February 2021, <https://www.itu.int/rec/T-REC-X.690>. --> </references> <references> <name>Informative References</name> <referenceanchor="ISO14888-1">anchor="ISO14888-1" target="https://www.iso.org/standard/44226.html"> <front> <title>Information technology - Security techniques - Digital signatures with appendix - Part 1:General.</title>General</title> <author> <organization>ISO/IEC</organization> </author> <date month="April" year="2008"/> </front><refcontent>ISO/IEC 14888-1</refcontent><seriesInfo name="ISO/IEC" value="14888-1"/> </reference> <reference anchor="GostPkcs12"> <front> <title>Information technology. Cryptographic Data Security.The transportTransport keycontainers.</title>container</title> <author initials="A." surname="Potashnikov" fullname="A. Potashnikov"> <organization/> </author> <author initials="E." surname="Karelina" fullname="E. Karelina"> <organization/> </author> <author initials="S." surname="Pianov" fullname="S. Pianov"> <organization/> </author> <author initials="A." surname="Naumenko" fullname="A. Naumenko"> <organization/> </author> </front> <refcontent>R1323565.1.041–2022.1323565.1.041-2022. Federal Agency on Technical Regulating and Metrology (In Russian)</refcontent> </reference> <!-- [rfced] Informative References: [GostPkcs12] does not have a corresponding citation in this document. Please let us know where it should be cited; otherwise, the reference listing will be removed. Original: [GostPkcs12] Potashnikov, A., Karelina, E., Pianov, S., and A. Naumenko, "Information technology. Cryptographic Data Security. The transport key containers.", R 1323565.1.041-2022. Federal Agency on Technical Regulating and Metrology (In Russian). --> </references> </references> <section anchor="Examples"> <name>Examples</name> <t>This section contains examples of using GOST cryptographic algorithms to create a PFX.</t> <section anchor="Data"> <name>Testdata</name>Data</name> <t>In allexamplesexamples, the following data is used.</t> <section anchor="Test_cert"> <name>Testcertificate</name>Certificate</name> <t>This section contains a testcertififcatecertificate in BASE64 format.</t> <sourcecode type="asn.1"><![CDATA[ MIICLjCCAdugAwIBAgIEAYy6hDAKBggqhQMHAQEDAjA4MQ0wCwYDVQQKEwRUSzI2 MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwHhcNMDEw MTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA7MQ0wCwYDVQQKEwRUSzI2MSowKAYD VQQDEyFPUklHSU5BVE9SOiBHT1NUIDM0LjEwLTEyIDUxMi1iaXQwgaAwFwYIKoUD BwEBAQIwCwYJKoUDBwECAQIBA4GEAASBgLSLt1q8KQ4YZVxioU+1LV9QhE7MHR9g BEh7S1yVNGlqt7+rNG5VFqmrPM74rbUsOlhV8M+zZKprXdk35Oz8lSW/n2oIUHZx ikXIH/SSHj4rv3K/Puvz7hYTQSZl/xPdp78nUmjrEa6d5wfX8biEy2z0dgufFvAk Mw1Ua4gdXqDOo4GHMIGEMGMGA1UdIwRcMFqAFKxsDkxEZqJCluKfCTslZvPLpFMq oTykOjA4MQ0wCwYDVQQKEwRUSzI2MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0 LjEwLTEyIDI1Ni1iaXSCBAGMuoEwHQYDVR0OBBYEFH4GVwmYDK1rCKhX7nkAWDrJ 16CkMAoGCCqFAwcBAQMCA0EACl6p8dAbpi9Hk+3mgMyI0WIh17IrlrSp/mB0F7Zz Mt8XUD1Dwz3JrrnxeXnfMvOA5BdUJ9hCyDgMVAGs/IcEEA== ]]></sourcecode> </section> <section anchor="Test_key"> <name>Testkey</name>Key</name> <t>This section contains a test key bytes inhexadecimal.</t>hexadecimal. <!-- [rfced] Appendix A.1.2: Should "a test key bytes" be "test key bytes" or something else? Are some words missing from this sentence? Original: This section contains a test key bytes in hexadecimal. --> </t> <sourcecode type="asn.1"><![CDATA[ F95A5D44C5245F63F2E7DF8E782C1924EADCB8D06C52D91023179786154CBDB1 561B4DF759D69F67EE1FBD5B68800E134BAA12818DA4F3AC75B0E5E6F9256911 ]]></sourcecode> </section> </section> <section anchor="PFXUnencrypted"><name>The example<name>Example of a PFX with apassword-protected keyPassword-Protected Key andunencrypted certificate.</name>Unencrypted Certificate</name> <t>In thisexampleexample, the PKCS8SHroudedKeybag structure is used to store the key, which is placed in the Data structure. The certBag structure is used to store the certificate, which is placed in the Data structure.AThe following password is used to encrypt the key andcontrol the integrity:provide integrity control: "Пароль для PFX". The password is inhexadecimal:</t>hexadecimal: <!-- [rfced] Appendices A.2 and A.3: As it appears that "A following password" means "The following password", we updated these sentences accordingly. If these updates are incorrect, please provide clarifying text. Original: A following password is used to encrypt the key and control the integrity: ... A following password is used to encrypt the key and control the integrity. Currently: The following password is used to encrypt the key and provide integrity control: ... The following password is used to encrypt the key and provide integrity control. --> </t> <sourcecode type="asn.1"><![CDATA[ D09FD0B0D180D0BED0BBD18C20D0B4D0BBD18F20504658 ]]></sourcecode> <t>The key encryption algorithm identifier:</t> <sourcecode type="asn.1"><![CDATA[ 1.2.643.7.1.1.5.2.2 ]]></sourcecode> <section anchor="PFX_BASE64"> <name>PFX in BASE64format</name>Format</name> <sourcecode type="asn.1"><![CDATA[ MIIFKwIBAzCCBMQGCSqGSIb3DQEHAaCCBLUEggSxMIIErTCCAswGCSqGSIb3DQEH AaCCAr0EggK5MIICtTCCArEGCyqGSIb3DQEMCgEDoIICSjCCAkYGCiqGSIb3DQEJ FgGgggI2BIICMjCCAi4wggHboAMCAQICBAGMuoQwCgYIKoUDBwEBAwIwODENMAsG A1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsyNjogR09TVCAzNC4xMC0xMiAyNTYt Yml0MB4XDTAxMDEwMTAwMDAwMFoXDTQ5MTIzMTAwMDAwMFowOzENMAsGA1UEChME VEsyNjEqMCgGA1UEAxMhT1JJR0lOQVRPUjogR09TVCAzNC4xMC0xMiA1MTItYml0 MIGgMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQOBhAAEgYC0i7davCkOGGVcYqFP tS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO+K21LDpYVfDPs2Sqa13ZN+Ts /JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0EmZf8T3ae/J1Jo6xGunecH1/G4 hMts9HYLnxbwJDMNVGuIHV6gzqOBhzCBhDBjBgNVHSMEXDBagBSsbA5MRGaiQpbi nwk7JWbzy6RTKqE8pDowODENMAsGA1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsy NjogR09TVCAzNC4xMC0xMiAyNTYtYml0ggQBjLqBMB0GA1UdDgQWBBR+BlcJmAyt awioV+55AFg6ydegpDAKBggqhQMHAQEDAgNBAApeqfHQG6YvR5Pt5oDMiNFiIdey K5a0qf5gdBe2czLfF1A9Q8M9ya658Xl53zLzgOQXVCfYQsg4DFQBrPyHBBAxVDAj BgkqhkiG9w0BCRUxFgQUeVV0+dS25MICJChpmGc/8AoUwE0wLQYJKoZIhvcNAQkU MSAeHgBwADEAMgBGAHIAaQBlAG4AZABsAHkATgBhAG0AZTCCAdkGCSqGSIb3DQEH AaCCAcoEggHGMIIBwjCCAb4GCyqGSIb3DQEMCgECoIIBVzCCAVMwWQYJKoZIhvcN AQUNMEwwKQYJKoZIhvcNAQUMMBwECKf4N7NMwugqAgIIADAMBggqhQMHAQEEAgUA MB8GCSqFAwcBAQUCAjASBBAlmt2WDfaPJlsAs0mLKglzBIH1DMvEacbbWRNDVSnX JLWygYrKoipdOjDA/2HEnBZ34uFOLNheUqiKpCPoFpbR2GBiVYVTVK9ibiczgaca EQYzDXtcS0QCZOxpKWfteAlbdJLC/SqPurPYyKi0MVRUPROhbisFASDT38HDH1Dh 0dL5f6ga4aPWLrWbbgWERFOoOPyh4DotlPF37AQOwiEjsbyyRHq3HgbWiaxQRuAh eqHOn4QVGY92/HFvJ7u3TcnQdLWhTe/lh1RHLNF3RnXtN9if9zC23laDZOiWZplU yLrUiTCbHrtn1RppPDmLFNMt9dJ7KKgCkOi7Zm5nhqPChbywX13wcfYxVDAjBgkq hkiG9w0BCRUxFgQUeVV0+dS25MICJChpmGc/8AoUwE0wLQYJKoZIhvcNAQkUMSAe HgBwADEAMgBGAHIAaQBlAG4AZABsAHkATgBhAG0AZTBeME4wCgYIKoUDBwEBAgME QAkBKw4ihn7pSIYTEhu0bcvTPZjI3WgVxCkUVlOsc80G69EKFEOTnObGJGSKJ51U KkOsXF0a7+VBZf3BcVVQh9UECIVEtO+VpuskAgIIAA== ]]></sourcecode> </section> <section anchor="PFX_ASN"> <name>PFX in ASN.1format</name>Format</name> <!-- [rfced] Appendices A.2.2 and subsequent: Please note that when creating the output files, we receive quite a few "Too long line" warnings. Entries that are 1, 2, or 3 characters too long can be left as is, but anything that is 4 or more characters too long - approx. 22 entries, by our count - will need to have line breaks inserted. Please review the list of warnings below, and let us know where proper line breaks can be placed (e.g., perhaps between strings and corresponding bracketed numbers or after colons (":"), as has already been done on some lines, such as lines containing "OBJECT IDENTIFIER:" and "OCTET STRING:"; also, the octet strings following Lines "1010 229" and "1344 64" in Appendix A.3.2 create lines that are too long). draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L796), 3 characters longer than 72 characters: : authorityKeyIdentifier [2.5.29.35] draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L810), 2 characters longer than 72 characters: 505 4: PRINTABLE STRING:'TK26' draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L814), 1 characters longer than 72 characters: : commonName [2.5.4.3] draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L822), 2 characters longer than 72 characters: : subjectKeyIdentifier [2.5.29.14] draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L828), 1 characters longer than 72 characters: 591 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.3.2] draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L853), 1 characters longer than 72 characters: 785 11: OBJECT IDENTIFIER:pkcs-12-pkcs-8ShroudedKeyBag draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L858), 1 characters longer than 72 characters: 808 9: OBJECT IDENTIFIER:[1.2.840.113549.1.5.13] draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L871), 2 characters longer than 72 characters: 866 9: OBJECT IDENTIFIER:[1.2.643.7.1.1.5.2.2] draft-pkcs12-gost-08.xml(735): Warning: Too long line found (L898), 1 characters longer than 72 characters: : 795574F9D4B6E4C20224286998673FF00A14C04D draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1006), 4 characters longer than 72 characters: 38 9: OBJECT IDENTIFIER:encryptedData [1.2.840.113549.1.7.6] draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1076), 31 characters longer than 72 characters: 902 11: OBJECT IDENTIFIER:pkcs-12-pkcs-8ShroudedKeyBag [1.2.840.113549.1.12.10.1.2] draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1080), 2 characters longer than 72 characters: 925 9: OBJECT IDENTIFIER:[1.2.840.113549.1.5.13] draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1083), 5 characters longer than 72 characters: 940 9: OBJECT IDENTIFIER:[1.2.840.113549.1.5.12] draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1089), 4 characters longer than 72 characters: 969 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.4.2] draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1092), 3 characters longer than 72 characters: 983 9: OBJECT IDENTIFIER:[1.2.643.7.1.1.5.1.1] draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1097), 22 characters longer than 72 characters: : 2A8FD988DD10DF2B984C77411E630B3B7E864AFF900DAF6C1484FE6A9C38C draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1098), 22 characters longer than 72 characters: : 06609FBEA513127EC2EBE59D2F4F0A17D656E82F765FFD5C9810BEFAFD0AE draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1099), 22 characters longer than 72 characters: : E293A1E08097A65721732D1D1A4FCCCC8B474550B9C0ADA74F1C10E242939 draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1100), 22 characters longer than 72 characters: : 06F7184B173A03D7A761B6A5F4FBF75083D1BCA44E44CC20486115CB9B502 draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1101), 22 characters longer than 72 characters: : B733F64ECA56C4C9B8D32316BAFB110BAE4EBF340134903ADB2AE74CE9172 draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1102), 22 characters longer than 72 characters: : AE9CE754F182ACE7488E9CA667135DBF0E3C6D9C6A4ED4550F1098013386A draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1103), 22 characters longer than 72 characters: : B3D29C070A55942C70FD2C86A32CC0761A104AC90C3ABA322596D26CD13F9 draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1107), 11 characters longer than 72 characters: 1246 9: OBJECT IDENTIFIER:localKeyID [1.2.840.113549.1.9.21] draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1110), 2 characters longer than 72 characters: : 795574F9D4B6E4C20224286998673FF00A14C04D draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1112), 13 characters longer than 72 characters: 1283 9: OBJECT IDENTIFIER:friendlyName [1.2.840.113549.1.9.20] draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1120), 35 characters longer than 72 characters: : E9E1EDB62665DD9EF474C40F7DC90BB342E27CA7105E3A9B0B9B675942AB771637B9CEA5B5BA4FFB54E71F57 --> <sourcecode type="asn.1"><![CDATA[ 0 1323:SEQUENCE: 4 1: INTEGER: 3 7 1220: SEQUENCE: 11 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1] 22 1205: CONTEXT SPECIFIC (0): 26 1201: OCTET STRING: 30 1197: SEQUENCE: 34 716: SEQUENCE: 38 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1] 49 701: CONTEXT SPECIFIC (0): 53 697: OCTET STRING: 57 693: SEQUENCE: 61 689: SEQUENCE: 65 11: OBJECT IDENTIFIER:pkcs-12-certBag : [1.2.840.113549.1.12.10.1.3] 78 586: CONTEXT SPECIFIC (0): 82 582: SEQUENCE: 86 10: OBJECT IDENTIFIER:x509Certificate : [1.2.840.113549.1.9.22.1] 98 566: CONTEXT SPECIFIC (0): 102 562: OCTET STRING: 106 558: SEQUENCE: 110 475: SEQUENCE: 114 3: CONTEXT SPECIFIC (0): 116 1: INTEGER:2 119 4: INTEGER:26000004 125 10: SEQUENCE: 127 8: OBJECT IDENTIFIER: : [1.2.643.7.1.1.3.2] 137 56: SEQUENCE: 139 13: SET: 141 11: SEQUENCE: 143 3: OBJECT IDENTIFIER: : organizationName [2.5.4.10] 148 4: PRINTABLE STRING:'TK26' 154 39: SET: 156 37: SEQUENCE: 158 3: OBJECT IDENTIFIER:commonName : [2.5.4.3] 163 30: PRINTABLE STRING: : 'CA TK26: GOST 34.10-12 256-bit' 195 30: SEQUENCE: 197 13: UTC TIME:'010101000000Z' 212 13: UTC TIME:'491231000000Z' 227 59: SEQUENCE: 229 13: SET: 231 11: SEQUENCE: 233 3: OBJECT IDENTIFIER: : organizationName [2.5.4.10] 238 4: PRINTABLE STRING:'TK26' 244 42: SET: 246 40: SEQUENCE: 248 3: OBJECT IDENTIFIER:commonName : [2.5.4.3] 253 33: PRINTABLE STRING: : 'ORIGINATOR: : GOST 34.10-12 512-bit' 288 160: SEQUENCE: 291 23: SEQUENCE: 293 8: OBJECT IDENTIFIER: : [1.2.643.7.1.1.1.2] 303 11: SEQUENCE: 305 9: OBJECT IDENTIFIER: : [1.2.643.7.1.2.1.2.1] 316 132: BIT STRING UnusedBits:0: 320 128: OCTET STRING: : B48BB75ABC290E18655C62A : 14FB52D5F50844ECC1D1F60 : 04487B4B5C9534696AB7BFA : B346E5516A9AB3CCEF8ADB5 : 2C3A5855F0CFB364AA6B5DD : 937E4ECFC9525BF9F6A0850 : 76718A45C81FF4921E3E2BB : F72BF3EEBF3EE1613412665 : FF13DDA7BF275268EB11AE9 : DE707D7F1B884CB6CF4760B : 9F16F024330D546B881D5EA0CE 451 135: CONTEXT SPECIFIC (3): 454 132: SEQUENCE: 457 99: SEQUENCE: 459 3: OBJECT IDENTIFIER: : authorityKeyIdentifier [2.5.29.35] 464 92: OCTET STRING: 466 90: SEQUENCE: 468 20: CONTEXT SPECIFIC (0): : AC6C0E4C4466A24296E2 : 9F093B2566F3CBA4532A 490 60: CONTEXT SPECIFIC (1): 492 58: CONTEXT SPECIFIC (4): 494 56: SEQUENCE: 496 13: SET: 498 11: SEQUENCE: 500 3: OBJECT IDENTIFIER: : organizationName : [2.5.4.10] 505 4: PRINTABLE STRING:'TK26' 511 39: SET: 513 37: SEQUENCE: 515 3: OBJECT IDENTIFIER: : commonName [2.5.4.3] 520 30: PRINTABLE STRING: : 'CA TK26: GOST ' : '34.10-12 256-bit' 552 4: CONTEXT SPECIFIC (2): : 018CBA81 558 29: SEQUENCE: 560 3: OBJECT IDENTIFIER: : subjectKeyIdentifier [2.5.29.14] 565 22: OCTET STRING: 567 20: OCTET STRING: : 7E065709980CAD6B08A8 : 57EE7900583AC9D7A0A4 589 10: SEQUENCE: 591 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.3.2] 601 65: BIT STRING UnusedBits:0: : 0A5EA9F1D01BA62F4793EDE680CC88D1 : 6221D7B22B96B4A9FE607417B67332DF : 17503D43C33DC9AEB9F17979DF32F380 : E4175427D842C8380C5401ACFC870410 668 84: SET: 670 35: SEQUENCE: 672 9: OBJECT IDENTIFIER:localKeyID : [1.2.840.113549.1.9.21] 683 22: SET: 685 20: OCTET STRING: : 795574F9D4B6E4C20224 : 286998673FF00A14C04D 707 45: SEQUENCE: 709 9: OBJECT IDENTIFIER:friendlyName : [1.2.840.113549.1.9.20] 720 32: SET: 722 30: BMP STRING:'p12FriendlyName' 754 473: SEQUENCE: 758 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1] 769 458: CONTEXT SPECIFIC (0): 773 454: OCTET STRING: 777 450: SEQUENCE: 781 446: SEQUENCE: 785 11: OBJECT IDENTIFIER:pkcs-12-pkcs-8ShroudedKeyBag : [1.2.840.113549.1.12.10.1.2] 798 343: CONTEXT SPECIFIC (0): 802 339: SEQUENCE: 806 89: SEQUENCE: 808 9: OBJECT IDENTIFIER:[1.2.840.113549.1.5.13] 819 76: SEQUENCE: 821 41: SEQUENCE: 823 9: OBJECT IDENTIFIER: : [1.2.840.113549.1.5.12] 834 28: SEQUENCE: 836 8: OCTET STRING:'A7F837B34CC2E82A' 846 2: INTEGER:2048 850 12: SEQUENCE: 852 8: OBJECT IDENTIFIER: : [1.2.643.7.1.1.4.2] 862 0: NULL: 864 31: SEQUENCE: 866 9: OBJECT IDENTIFIER:[1.2.643.7.1.1.5.2.2] 877 18: SEQUENCE: 879 16: OCTET STRING: : 259ADD960DF68F265B00B3498B2A0973 897 245: OCTET STRING: : 0CCBC469C6DB5913435529D724B5B281 : 8ACAA22A5D3A30C0FF61C49C1677E2E1 : 4E2CD85E52A88AA423E81696D1D86062 : 55855354AF626E273381A71A1106330D : 7B5C4B440264EC692967ED78095B7492 : C2FD2A8FBAB3D8C8A8B43154543D13A1 : 6E2B050120D3DFC1C31F50E1D1D2F97F : A81AE1A3D62EB59B6E05844453A838FC : A1E03A2D94F177EC040EC22123B1BCB2 : 447AB71E06D689AC5046E0217AA1CE9F : 8415198F76FC716F27BBB74DC9D074B5 : A14DEFE58754472CD1774675ED37D89F : F730B6DE568364E896669954C8BAD489 : 309B1EBB67D51A693C398B14D32DF5D2 : 7B28A80290E8BB666E6786A3C285BCB0 : 5F5DF071F6 1145 84: SET: 1147 35: SEQUENCE: 1149 9: OBJECT IDENTIFIER:localKeyID : [1.2.840.113549.1.9.21] 1160 22: SET: 1162 20: OCTET STRING: : 795574F9D4B6E4C20224286998673FF00A14C04D 1184 45: SEQUENCE: 1186 9: OBJECT IDENTIFIER:friendlyName : [1.2.840.113549.1.9.20] 1197 32: SET: 1199 30: BMP STRING:'p12FriendlyName' 1231 94: SEQUENCE: 1233 78: SEQUENCE: 1235 10: SEQUENCE: 1237 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.2.3] 1247 64: OCTET STRING: : 09012B0E22867EE9488613121BB46DCB : D33D98C8DD6815C429145653AC73CD06 : EBD10A1443939CE6C624648A279D542A : 43AC5C5D1AEFE54165FDC171555087D5 1313 8: OCTET STRING:'8544B4EF95A6EB24' 1323 2: INTEGER:2048 ]]></sourcecode> </section> <section anchor="Dec_key"> <name>Decryptedkey valueKey Value in BASE64format</name>Format</name> <sourcecode type="asn.1"><![CDATA[ MIHiAgEBMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQRAEWkl+eblsHWs86SNgRKq SxMOgGhbvR/uZ5/WWfdNG1axvUwVhpcXIxDZUmzQuNzqJBkseI7f5/JjXyTFRF1a +YGBgQG0i7davCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO +K21LDpYVfDPs2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0Em Zf8T3ae/J1Jo6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzg== ]]></sourcecode> </section> <section anchor="Dec_key_ASN"> <name>Decryptedkey valueKey Value in ASN.1format</name>Format</name> <sourcecode type="asn.1"><![CDATA[ 0 226:SEQUENCE : 3 1: INTEGER : 1 6 23: SEQUENCE : 8 8: OBJECT IDENTIFIER : [1.2.643.7.1.1.1.2] 18 11: SEQUENCE : 20 9: OBJECT IDENTIFIER : [1.2.643.7.1.2.1.2.1] 31 64: OCTET STRING : : 116925F9E6E5B075ACF3A48D8112AA4B130E80685BBD1FEE679FD6 : 59F74D1B56B1BD4C158697172310D9526CD0B8DCEA24192C788EDF : E7F2635F24C5445D5AF9 97 129: CONTEXT SPECIFIC (1) : : 01B48BB75ABC290E18655C62A14FB52D5F50844ECC1D1F6004487B : 4B5C9534696AB7BFAB346E5516A9AB3CCEF8ADB52C3A5855F0CFB3 : 64AA6B5DD937E4ECFC9525BF9F6A085076718A45C81FF4921E3E2B : BF72BF3EEBF3EE1613412665FF13DDA7BF275268EB11AE9DE707D7 : F1B884CB6CF4760B9F16F024330D546B881D5EA0CE ]]></sourcecode> </section> </section> <section anchor="PFXEncrypted"><name>The example<name>Example of a PFX with apassword-protected keyPassword-Protected Key and apassword-protected certificate.</name>Password-Protected Certificate</name> <t>In thisexampleexample, the PKCS8SHroudedKeybag structure is used to store the key, which is placed in the Data structure (see <xref target="RFC5652"/>). The certBag structure is used to store the certificate, which is placed in the EncryptedData structure (see <xref target="RFC5652"/>).AThe following password is used to encrypt the key andcontrol the integrity.provide integrity control. The password is in hexadecimal.</t> <sourcecode type="asn.1"><![CDATA[ 0xD09FD0B0D180D0BED0BBD18C20D0B4D0BBD18F20504658 ]]></sourcecode> <t>The key encryption algorithm identifier:</t> <sourcecode type="asn.1"><![CDATA[ 1.2.643.7.1.1.5.1.1 ]]></sourcecode> <t>The certificate encryption algorithm identifier:</t> <sourcecode type="asn.1"><![CDATA[ 1.2.643.7.1.1.5.1.2 ]]></sourcecode> <section anchor="PFX_BASE64_Ex2"> <name>PFX in BASE64format</name>Format</name> <sourcecode type="asn.1"><![CDATA[ MIIFjAIBAzCCBSUGCSqGSIb3DQEHAaCCBRYEggUSMIIFDjCCA0EGCSqGSIb3DQEH BqCCAzIwggMuAgEAMIIDJwYJKoZIhvcNAQcBMFUGCSqGSIb3DQEFDTBIMCkGCSqG SIb3DQEFDDAcBAgUuSVGsSwGjQICCAAwDAYIKoUDBwEBBAIFADAbBgkqhQMHAQEF AQIwDgQM9Hk3dagtS48+G/x+gIICwWGPqxxN+sTrKbruRf9R5Ya9cf5AtO1frqMn f1eULfmZmTg/BdE51QQ+Vbnh3v1kmspr6h2+e4Wli+ndEeCWG6A6X/G22h/RAHW2 YrVmf6cCWxW+YrqzT4h/8RQL/9haunD5LmHPLVsYrEai0OwbgXayDSwARVJQLQYq sLNmZK5ViN+fRiS5wszVJ3AtVq8EuPt41aQEKwPy2gmH4S6WmnQRC6W7aoqmIifF PJENJNn5K2M1J6zNESs6bFtYNKMArNqtvv3rioY6eAaaLy6AV6ljsekmqodHmQjv Y4eEioJs0xhpXhZY69PXT+ZBeHv6MSheBhwXqxAd1DqtPTafMjNK8rqKCap9TtPG vONvo5W9dgwegxRRQzlum8dzV4m1W9Aq4W7t8/UcxDWRz3k6ijFPlGaA9+8ZMTEO RHhBRvM6OY2/VNNxbgxWfGYuPxpSi3YnCZIPmBEe5lU/Xv7KjzFusGM38F8YR61k 4/QNpKI1QUv714YKfaUQznshGGzILv1NGID62pl1+JI3vuawi2mDMrmkuM9QFU9v /kRP+c2uBHDuOGEUUSNhF08p7+w3vxplatGWXH9fmIsPBdk2f3wkn+rwoqrEuijM I/bCAylU/M0DMKhAo9j31UYSZdi4fsfRWYDJMq/8FPn96tuo+oCpbqv3NUwpZM/8 Li4xqgTHtYw/+fRG0/P6XadNEiII/TYjenLfVHXjAHOVJsVeCu/t3EsMYHQddNCh rFk/Ic2PdIQOyB4/enpW0qrKegSbyZNuF1WI4zl4mI89L8dTQBUkhy45yQXZlDD8 k1ErYdtdEsPtz/4zuSpbnmwCEIRoOuSXtGuJP+tbcWEXRKM2UBgi3qBjpn7DU18M tsrRM9pDdadl8mT/Vfh9+B8dZBZVxgQu70lMPEGexbUkYHuFCCnyi9J0V92StbIz Elxla1VebjCCAcUGCSqGSIb3DQEHAaCCAbYEggGyMIIBrjCCAaoGCyqGSIb3DQEM CgECoIIBQzCCAT8wVQYJKoZIhvcNAQUNMEgwKQYJKoZIhvcNAQUMMBwECP0EQk0O 1twvAgIIADAMBggqhQMHAQEEAgUAMBsGCSqFAwcBAQUBATAOBAzwxSqgAAAAAAAA AAAEgeUqj9mI3RDfK5hMd0EeYws7foZK/5ANr2wUhP5qnDjAZgn76lExJ+wuvlnS 9PChfWVugvdl/9XJgQvvr9Cu4pOh4ICXplchcy0dGk/MzItHRVC5wK2nTxwQ4kKT kG9xhLFzoD16dhtqX0+/dQg9G8pE5EzCBIYRXLm1Arcz9k7KVsTJuNMjFrr7EQuu Tr80ATSQOtsq50zpFyrpznVPGCrOdIjpymZxNdvw48bZxqTtRVDxCYATOGqz0pwH ClWULHD9LIajLMB2GhBKyQw6ujIlltJs0T+WNdX/AT2FLi1LFSS3+Cj9MVQwIwYJ KoZIhvcNAQkVMRYEFHlVdPnUtuTCAiQoaZhnP/AKFMBNMC0GCSqGSIb3DQEJFDEg Hh4AcAAxADIARgByAGkAZQBuAGQAbAB5AE4AYQBtAGUwXjBOMAoGCCqFAwcBAQID BEDp4e22JmXdnvR0xA99yQuzQuJ8pxBeOpsLm2dZQqt3Fje5zqW1uk/7VOcfV5r2 bKm8nsLOs2rPT8hBOoeAZvOIBAjGIUHw6IjG2QICCAA= ]]></sourcecode> </section> <section anchor="PFX_ASN_Ex2"> <name>PFX in ASN.1format</name>Format</name> <sourcecode type="asn.1"><![CDATA[ 0 1420:SEQUENCE: 4 1: INTEGER:3 7 1317: SEQUENCE: 11 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1] 22 1302: CONTEXT SPECIFIC (0): 26 1298: OCTET STRING: 30 1294: SEQUENCE: 34 833: SEQUENCE: 38 9: OBJECT IDENTIFIER:encryptedData [1.2.840.113549.1.7.6] 49 818: CONTEXT SPECIFIC (0): 53 814: SEQUENCE: 57 1: INTEGER:0 60 807: SEQUENCE: 64 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1] 75 85: SEQUENCE: 77 9: OBJECT IDENTIFIER:[1.2.840.113549.1.5.13] 88 72: SEQUENCE: 90 41: SEQUENCE: 92 9: OBJECT IDENTIFIER:[1.2.840.113549.1.5.12] 103 28: SEQUENCE: 105 8: OCTET STRING:'14B92546B12C068D' 115 2: INTEGER:2048 119 12: SEQUENCE: 121 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.4.2] 131 0: NULL: 133 27: SEQUENCE: 135 9: OBJECT IDENTIFIER:[1.2.643.7.1.1.5.1.2] 146 14: SEQUENCE: 148 12: OCTET STRING: : F4793775A82D4B8F3E1BFC7E 162 705: CONTEXT SPECIFIC (0): : 618FAB1C4DFAC4EB29BAEE45FF51E586BD7 : 1FE40B4ED5FAEA3277F57942DF99999383F : 05D139D5043E55B9E1DEFD649ACA6BEA1DB : E7B85A58BE9DD11E0961BA03A5FF1B6DA1F : D10075B662B5667FA7025B15BE62BAB34F8 : 87FF1140BFFD85ABA70F92E61CF2D5B18AC : 46A2D0EC1B8176B20D2C004552502D062AB : 0B36664AE5588DF9F4624B9C2CCD527702D : 56AF04B8FB78D5A4042B03F2DA0987E12E9 : 69A74110BA5BB6A8AA62227C53C910D24D9 : F92B633527ACCD112B3A6C5B5834A300ACD : AADBEFDEB8A863A78069A2F2E8057A963B1 : E926AA87479908EF6387848A826CD318695 : E1658EBD3D74FE641787BFA31285E061C17 : AB101DD43AAD3D369F32334AF2BA8A09AA7 : D4ED3C6BCE36FA395BD760C1E8314514339 : 6E9BC7735789B55BD02AE16EEDF3F51CC43 : 591CF793A8A314F946680F7EF1931310E44 : 784146F33A398DBF54D3716E0C567C662E3 : F1A528B762709920F98111EE6553F5EFECA : 8F316EB06337F05F1847AD64E3F40DA4A23 : 5414BFBD7860A7DA510CE7B21186CC82EFD : 4D1880FADA9975F89237BEE6B08B698332B : 9A4B8CF50154F6FFE444FF9CDAE0470EE38 : 6114512361174F29EFEC37BF1A656AD1965 : C7F5F988B0F05D9367F7C249FEAF0A2AAC4 : BA28CC23F6C2032954FCCD0330A840A3D8F : 7D5461265D8B87EC7D15980C932AFFC14F9 : FDEADBA8FA80A96EABF7354C2964CFFC2E2 : E31AA04C7B58C3FF9F446D3F3FA5DA74D12 : 2208FD36237A72DF5475E300739526C55E0 : AEFEDDC4B0C60741D74D0A1AC593F21CD8F : 74840EC81E3F7A7A56D2AACA7A049BC9936 : E175588E33978988F3D2FC753401524872E : 39C905D99430FC93512B61DB5D12C3EDCFF : E33B92A5B9E6C021084683AE497B46B893F : EB5B71611744A336501822DEA063A67EC35 : 35F0CB6CAD133DA4375A765F264FF55F87D : F81F1D641655C6042EEF494C3C419EC5B52 : 4607B850829F28BD27457DD92B5B233125C : 656B555E6E 871 453: SEQUENCE: 875 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1] 886 438: CONTEXT SPECIFIC (0): 890 434: OCTET STRING: 894 430: SEQUENCE: 898 426: SEQUENCE: 902 11: OBJECT IDENTIFIER:pkcs-12-pkcs-8ShroudedKeyBag [1.2.840.113549.1.12.10.1.2] 915 323: CONTEXT SPECIFIC (0): 919 319: SEQUENCE: 923 85: SEQUENCE: 925 9: OBJECT IDENTIFIER:[1.2.840.113549.1.5.13] 936 72: SEQUENCE: 938 41: SEQUENCE: 940 9: OBJECT IDENTIFIER:[1.2.840.113549.1.5.12] 951 28: SEQUENCE: 953 8: OCTET STRING: : FD04424D0ED6DC2F 963 2: INTEGER:2048 967 12: SEQUENCE: 969 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.4.2] 979 0: NULL: 981 27: SEQUENCE: 983 9: OBJECT IDENTIFIER:[1.2.643.7.1.1.5.1.1] 994 14: SEQUENCE: 996 12: OCTET STRING: : F0C52AA00000000000000000 1010 229: OCTET STRING: : 2A8FD988DD10DF2B984C77411E630B3B7E864AFF900DAF6C1484FE6A9C38C : 06609FBEA513127EC2EBE59D2F4F0A17D656E82F765FFD5C9810BEFAFD0AE : E293A1E08097A65721732D1D1A4FCCCC8B474550B9C0ADA74F1C10E242939 : 06F7184B173A03D7A761B6A5F4FBF75083D1BCA44E44CC20486115CB9B502 : B733F64ECA56C4C9B8D32316BAFB110BAE4EBF340134903ADB2AE74CE9172 : AE9CE754F182ACE7488E9CA667135DBF0E3C6D9C6A4ED4550F1098013386A : B3D29C070A55942C70FD2C86A32CC0761A104AC90C3ABA322596D26CD13F9 : 635D5FF013D852E2D4B1524B7F828FD 1242 84: SET: 1244 35: SEQUENCE: 1246 9: OBJECT IDENTIFIER:localKeyID [1.2.840.113549.1.9.21] 1257 22: SET: 1259 20: OCTET STRING: : 795574F9D4B6E4C20224286998673FF00A14C04D 1281 45: SEQUENCE: 1283 9: OBJECT IDENTIFIER:friendlyName [1.2.840.113549.1.9.20] 1294 32: SET: 1296 30: BMP STRING:'p12FriendlyName' 1328 94: SEQUENCE: 1330 78: SEQUENCE: 1332 10: SEQUENCE: 1334 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.2.3] 1344 64: OCTET STRING: : E9E1EDB62665DD9EF474C40F7DC90BB342E27CA7105E3A9B0B9B675942AB771637B9CEA5B5BA4FFB54E71F57 : 9AF66CA9BC9EC2CEB36ACF4FC8413A878066F388 1410 8: OCTET STRING:'C62141F0E888C6D9' 1420 2: INTEGER:2048 ]]></sourcecode> </section> <section anchor="Dec_key_Ex2"> <name>Decryptedkey valueKey Value in BASE64format</name>Format</name> <sourcecode type="asn.1"><![CDATA[ MIHiAgEBMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQRAEWkl+eblsHWs86SNgRKq SxMOgGhbvR/uZ5/WWfdNG1axvUwVhpcXIxDZUmzQuNzqJBkseI7f5/JjXyTFRF1a +YGBgQG0i7davCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO +K21LDpYVfDPs2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0Em Zf8T3ae/J1Jo6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzg== ]]></sourcecode> </section> <section anchor="Dec_key_ASN_Ex2"> <name>Decryptedkey valueKey Value in ASN.1format</name>Format</name> <sourcecode type="asn.1"><![CDATA[ 0 226:SEQUENCE : 3 1: INTEGER : 1 6 23: SEQUENCE : 8 8: OBJECT IDENTIFIER : [1.2.643.7.1.1.1.2] 18 11: SEQUENCE : 20 9: OBJECT IDENTIFIER : [1.2.643.7.1.2.1.2.1] 31 64: OCTET STRING : : 116925F9E6E5B075ACF3A48D8112AA4B130E80685BBD1FEE679FD6 : 59F74D1B56B1BD4C158697172310D9526CD0B8DCEA24192C788EDF : E7F2635F24C5445D5AF9 97 129: CONTEXT SPECIFIC (1) : : 01B48BB75ABC290E18655C62A14FB52D5F50844ECC1D1F6004487B : 4B5C9534696AB7BFAB346E5516A9AB3CCEF8ADB52C3A5855F0CFB3 : 64AA6B5DD937E4ECFC9525BF9F6A085076718A45C81FF4921E3E2B : BF72BF3EEBF3EE1613412665FF13DDA7BF275268EB11AE9DE707D7 : F1B884CB6CF4760B9F16F024330D546B881D5EA0CE ]]></sourcecode> </section> </section> </section> <section anchor="Acknowledgments" numbered="false"> <name>Acknowledgments</name> <t>The author thanks <contact fullname="Potashnikov Alexander"/>, <contact fullname="PianovSemen"/>Semen"/>, and <contact fullname="Smyslov Valery"/> for their careful readings and usefulcomments.</t>comments. <!-- [rfced] Acknowledgments and Author's Address section: Please advise regarding the following: * Are the names listed in the Acknowledgments section shown as last name followed by first name? * For example, we ask these questions because we see "Semen Pianov" in RFC 9215 but "Pianov Semen" in RFC 9337 and this document. Will one way of writing the names be preferred in this document and subsequent RFCs, or are both ways OK? * We have "E. Karelina, Ed." in our database records for RFC 9337 and this document. Is this correct? --> </t> </section> </back> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> <!-- [rfced] Please let us know if any changes are needed for the following: a) The following terms appear to be used inconsistently in this document. Please let us know which form is preferred. certBag / CertBag ("A certBag contains", "a CertBag is defined", "the CertBag structure", "The certBag structure") octet string / OCTET STRING ("an octet string", "an OCTET STRING") PKCS8ShroudedKeyBag (3 instances) / PKCS8SHroudedKeybag (2 instances in Appendix A) (We see "8ShroudedKeyBag" on <http://www.oid-info.com/cgi-bin/ display?oid=1.2.840.113549.1.12.10.1.2&a=display> and in RFC 7292.) b) Should spacing be made consistent for the following? We see spaces before the colons in the "SEQUENCE", "INTEGER", "OBJECT IDENTIFIER", "OCTET STRING", and "CONTEXT SPECIFIC" entries in Appendices A.2.4 and A.3.4 but not in the other appendices. Is the different spacing as intended (i.e., OK in the case of "Decrypted Key Value in ASN.1 Format" entries)? ,...,a_1 vs. ,..., c_1 --> </rfc>