rfc9548.original.xml		rfc9548.xml
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!-- [CS] updated by Chris 10/18/22 -->		<!-- [ST] updated by Sarah 01/03/24 -->
	<!-- draft submitted in xml v3 -->		<!-- draft submitted in xml v3 -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent" cat		<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
	egory="info" docName="draft-pkcs12-gost-08" ipr="trust200902" tocInclude="true"		submissionType="independent"
	tocDepth="4" symRefs="true" sortRefs="true" updates="" obsoletes="" xml:lang="en		category="info"
	" version="3">		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 -->		<!-- xml2rfc v2v3 conversion 3.12.10 -->
	<front>		<front>
	<title abbrev="GOST usage in password-based pkcs12">		<title abbrev="GOST Usage in Password-Based PKCS #12">Generating
	Generating the Transport Key Containers Using the GOST Algorithms		Transport Key Containers Using the GOST Algorithms</title>
	</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-based pkcs12
			Currently:
			Generating Transport Key Containers Using the GOST Algorithms
			GOST Usage in Password-Based PKCS #12 -->
			<seriesInfo name="RFC" value="9548"/>
	<author fullname="Ekaterina Karelina" initials="E." role="editor" surname="K arelina">		<author fullname="Ekaterina Karelina" initials="E." role="editor" surname="K arelina">
	<organization>InfoTeCS</organization>		<organization>InfoTeCS</organization>
	<address>		<address>
	<postal>		<postal>
	<street>2B stroenie 1, ul. Otradnaya</street>		<street>2B stroenie 1, ul. Otradnaya</street>
	<city>Moscow</city>		<city>Moscow</city>
	<code>127273</code>		<code>127273</code>
	<country>Russian Federation</country>		<country>Russian Federation</country>
	</postal>		</postal>
	<email>Ekaterina.Karelina@infotecs.ru</email>		<email>Ekaterina.Karelina@infotecs.ru</email>
	</address>		</address>
	</author>		</author>
	<date year="2023" month="December"/>		<date year="2024" month="February"/>
	<keyword>the transport key containers, certificates, GOST algorithms, pkcs12, go
	st, PFX</keyword>		<keyword>transport key containers</keyword>
			<keyword>certificates</keyword>
			<keyword>GOST algorithms</keyword>
			<keyword>pkcs12</keyword>
			<keyword>gost</keyword>
			<keyword>PFX</keyword>
	<abstract>		<abstract>
	<t> This document specifies how to use "PKCS #12: Personal Information Exchang e Syntax v1.1" (RFC 7292) to generate the transport key containers for storing k eys and certificates in conjunction with the		<t> This document specifies how to use "PKCS #12: Personal Information Exchang e Syntax v1.1" (RFC 7292) to generate transport key containers for storing keys and certificates in conjunction with the
	Russian national standard GOST algorithms.		Russian national standard GOST algorithms.
	</t>		</t>
	<t>		<t>
	This specification has been developed outside the IETF. The purpose of publication being to		This specification has been developed outside the IETF. The purpose of publication is to
	facilitate interoperable implementations that wish to support the		facilitate interoperable implementations that wish to support the
	GOST algorithms. This document does not imply IETF endorsement of th e cryptographic algorithms		GOST algorithms. This document does not imply IETF endorsement of th e cryptographic algorithms
	used here.		used here.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="Introduction">		<section anchor="Introduction">
	<name>Introduction</name>		<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>		<t>
	This document provides a specification of the usage of GOST algorith ms with PKCS #12 v1.1.		This document provides a specification of the usage of GOST algorith ms with PKCS #12 v1.1.
	</t>		</t>
	<t>		<t>
	PKCS #12 v1.1 describes a syntax for transfer of personal informatio n such as private keys, certificates, various secrets.		PKCS #12 v1.1 describes a syntax for transfer of personal informatio n such as private keys, certificates, and various secrets.
	</t>		</t>
	<t>		<t>
	This memo describes the creating of transport key containers for key		This memo describes the creation of transport key containers for key
	s and certificates of electronic signature verification keys which are created i		s and certificates of electronic signature verification keys which are created i
	n accordance with GOST R 34.10–2012 algorithm.		n accordance with the GOST R 34.10-2012 algorithm.
	The GOST R 34.11-2012 algorithm is used to ensure integrity of trans		The GOST R 34.11-2012 algorithm is used to ensure the integrity of t
	port key containers.		ransport 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>		</t>
	</section>		</section>
	<section>		<section>
	<name>Conventions Used in This Document</name>		<name>Conventions Used in This Document</name>
	<t>		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>		"<bcp14>SHOULD NOT</bcp14>",
	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	be interpreted as		are to be interpreted as described in BCP&nbsp;14
	described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>		<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
	when, and only when, they appear in all capitals, as shown here.		when, they appear in all capitals, as shown here.</t>
	</t>
	</section>		</section>
	<section anchor="Definition">		<section anchor="Definition">
	<name>Basic Terms and Definitions</name>		<name>Basic Terms and Definitions</name>
	<t>		<t>
	Throughout this document, the following notation is used:		Throughout this document, the following notations are used:
	</t>		</t>
	<table align="center">
	<name>Terms and Definitions</name>		<!-- [rfced] Section 3: Please note that because Tables 1 and 2 are
	<thead>		lists of definitions, we converted them to definition lists. The
	<tr>		superscripting and subscripting are preserved in the HTML and PDF
	<th>Notation</th>		output files. Please review, and let us know any objections. -->
	<th>Definition</th>
	</tr>		<dl spacing="normal" newline="false">
	</thead>		<dt>P</dt>
	<tbody>		<dd>a password encoded as a Unicode UTF-8 string</dd>
	<tr>		<dt>S</dt>
	<td align="left">P</td>		<dd>a random initializing value</dd>
	<td align="left">a password encoded as a Unicode UTF-8 string</td>		<dt>V<sup>*</sup></dt>
	</tr>		<dd>the set of all binary row vectors of finite length (hereinafter
	<tr>		referred to as vectors) including empty string
	<td align="left">S</td>
	<td align="left">a random initializing value</td>		<!-- [rfced] Section 3: Does "all binary row vectors of finite
	</tr>		length (hereinafter referred to as vectors) including empty string"
	<tr>		mean (1) "all binary row vectors of finite length (hereinafter
	<td align="left">V<sup>*</sup></td>		referred to as vectors), including an empty string" (or "including
	<td align="left">the set of all binary row vectors of finite length		empty strings"), (2) "all binary row vectors of finite length
	(hereinafter referred to as vectors) including empty string</td>		(hereinafter referred to as vectors) that include an empty string"
	</tr>		(or "that include empty strings"), or (3) something else?
	<tr>		Please clarify.
	<td align="left">V<sub>s</sub></td>
	<td align="left">the set of all binary row vectors of length s, s &g		Original:
	t;= 0; if s = 0, then the set V<sub>s</sub> consists of an empty string of lengt		| V^(*) | the set of all binary row vectors of finite length |
	h 0</td>		| | (hereinafter referred to as vectors) including |
	</tr>		| | empty string | -->
	<tr>
	<td align="left">|A|</td>		</dd>
	<td align="left">the number of components (a length) of the vector A		<dt>V<sub>s</sub></dt>
	belonging to V<sup>*</sup> (if A is an empty string, then |A| = 0)</td>		<dd>the set of all binary row vectors of length s, where s &gt;= 0;
	</tr>		if s = 0, then the set V<sub>s</sub> consists of an empty string of length 0</dd
	<tr>		>
	<td align="left">A||C</td>		<dt>|A|</dt>
	<td align="left">a concatenation of two octet strings A, C, i.e.,		<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)</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<s ub>|A|</sub>		a vector from V<sub>|A|+|C|</sub>, where the left subvector from V<s ub>|A|</sub>
	is equal to the vector A and the right subvector from V<sub>|C|</sub > is		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</s ub>) in V<sub>n<sub>1</sub></sub> and C =		equal to the vector C: A = (a<sub>n<sub>1</sub></sub>,...,a<sub>1</s ub>) 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>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>) in V<sub>n<sub>1</sub>+n<sub>2</sub></sub>)</td>		c<sub>1</sub>) in V<sub>n<sub>1</sub>+n<sub>2</sub></sub>)
	</tr>
	<tr>		<!-- [rfced] Section 3: Please confirm that "two octet strings A, C"
	<td align="left">F_q</td>		will be clear to readers. We also see this text in RFC 9337, but
	<td align="left">a finite prime field represented as a set of q inte		this document provides an opportunity to clarify the text, if needed.
	gers {0,1,..., q - 1}, where q > 3 – prime number</td>		(For example, does it mean "two octet strings, A and C"?)
	</tr>
	<tr>		Original:
	<td align="left">b mod q</td>		| A||C | a concatenation of two octet strings A, C, i.e., a |
	<td align="left">the minimum non-negative number comparable to b mod		| | vector from V_(|A|+|C|), where the left subvector |
	ulo p</td>		| | from V_(|A|) is equal to the vector A and the |
	</tr>		| | right subvector from V_(|C|) is equal to the |
	</tbody>		| | vector C: A = (a_(n_1),...,a_1) in V_(n_1) and C = |
	</table>		| | (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 - prime number</dd>
			<dt>b mod q</dt>
			<dd>the minimum non-negative number comparable to b modulo p</dd>
			</dl>
	<t>		<t>
	This document uses the following abbreviations and definitions:</t>		This document uses the following terms and abbreviations:</t>
	<table align="center">		<dl spacing="normal" newline="false">
	<name>Abbreviations and Definition</name>		<dt>Signature</dt>
	<thead>		<dd>one or more data elements resulting from the signature process (
	<tr>		Clause 3.12 of <xref target="ISO14888-1"/>).
	<th>Abbreviations and Terms</th>		Note: The terms "digital signature", "electronic signature", and "el
	<th>Definition</th>		ectronic digital signature" are considered
	</tr>		equivalent in this document.</dd>
	</thead>		<dt>Signature key</dt>
	<tbody>		<dd>set of private data elements specific to an entity and usable on
	<tr>		ly by this entity
	<td align="left">Signature</td>		in the signature process (Clause 3.13 of <xref target="ISO14
	<td align="left">one or more data elements resulting from the signat		888-1"/>).
	ure process (clause 3.12 of <xref target="ISO14888-1"/>).		Note: Sometimes called a private key.</dd>
	Note: the terms "digital signature", "electronic signature", and "el		<dt>Verification key</dt>
	ectronic digital signature" are considered		<dd>set of public data elements that is mathematically related to an
	equivalent in this document.		entity's signature key
	</td>		and is used by the verifier in the verification process (Cla
	</tr>		use 3.16 of <xref target="ISO14888-1"/>).
	<tr>		Note: Sometimes called a public key.</dd>
	<td align="left">Signature key</td>		<dt>ASN.1</dt>
	<td align="left">set of private data elements specific to an entity		<dd>Abstract Syntax Notation One, as defined in <xref target="X.680"
	and usable only by this entity		/>.</dd>
	in the signature process (clause 3.13 of <xref target="ISO14		<dt>BER</dt>
	888-1"/>).		<dd>Basic Encoding Rules, as defined in <xref target="X.690"/>.</dd>
	Note: Sometimes called a private key.</td>		<dt>HMAC_GOSTR3411</dt>
	</tr>
	<tr>		<!--[rfced] Section 3: In RFC 2104, we do not see specific mention of "512-bit
	<td align="left">Verification key</td>		output". Please confirm if this is the correct reference or if an
	<td align="left">set of public data elements which is mathematically		update is needed.
	related to an entity's signature key
	and which is used by the verifier in the verification proces		Original:
	s (clause 3.16 of <xref target="ISO14888-1"/>).		HMAC_GOSTR3411 Hashed-Based Message Authentication Code. A function
	Note: Sometimes called a public key.</td>		for calculating a Message Authentication Code (MAC) based on the
	</tr>		GOST R 34.11-2012 hash function (see [RFC6986]) with 512-bit
	<tr>		output in accordance with [RFC2104].
	<td align="left">ASN.1</td>		-->
	<td align="left">Abstract Syntax Notation One, as defined in <xref t		<dd>Hash-Based Message Authentication Code. A
	arget="X.680"/>.</td>
	</tr>
	<tr>
	<td align="left">BER</td>
	<td align="left">Basic Encoding Rules, as defined in <xref target="X
	.690"/>.</td>
	</tr>
	<tr>
	<td align="left">HMAC_GOSTR3411</td>
	<td align="left">Hashed-Based Message Authentication Code. A
	function for calculating a Message Authentication Code (MAC) based		function for calculating a Message Authentication Code (MAC) based
	on the GOST R 34.11-2012 hash function (see <xref		on the GOST R 34.11-2012 hash function (see <xref
	target="RFC6986"/>) with 512-bit output in accordance with <xref		target="RFC6986"/>) with 512-bit output in accordance with <xref
	target="RFC2104"/>.</td>		target="RFC2104"/>.</dd>
	</tr>		</dl>
	</tbody>
	</table>
	</section>		</section>
	<section anchor="PFX">		<section anchor="PFX">
	<name>PFX</name>		<name>PFX</name>
	<t>		<t>
	The transport key container (PFX, see <xref target="RFC7292"/>) is d esigned for secure storage and data transfer.		The transport key container (PFX; see <xref target="RFC7292"/>) is d esigned for secure storage and data transfer.
	The scope of this document is to define how the transport key contai ner is used for private key and certificate protection with a password when GOST R 34.10-2012 is applied.		The scope of this document is to define how the transport key contai ner 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>		</t>
	<section anchor="StrucurePFX">		<section anchor="StrucurePFX">
	<name>Structure of PFX</name>		<name>Structure of PFX</name>
	<t>In accordance with <xref target="RFC7292"/> the transport key		<t>In accordance with <xref target="RFC7292"/>, the transport ke
	container has the following structure:</t>		y 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[		<sourcecode type="asn.1"><![CDATA[
	PFX ::= SEQUENCE		PFX ::= SEQUENCE
	{		{
	version INTEGER {v3(3)}(v3,...),		version INTEGER {v3(3)}(v3,...),
	authSafe ContentInfo,		authSafe ContentInfo,
	macData MacData OPTIONAL		macData MacData OPTIONAL
	}]]></sourcecode>		}]]></sourcecode>
	<t>The fields of PFX have the following meanings:</t>		<t>The fields of the PFX have the following meanings:</t>
	<ul spacing="normal"><li>version is the syntax version numbe		<ul spacing="normal"><li>version is the syntax version numbe
	r; the only allowed value for this specification is 3;</li>		r; the only allowed value for this specification is 3.</li>
	<li>authSafe contains the data of type ContentInfo. In the c		<li>authSafe contains the data of type ContentInfo. In the c
	ase of password integrity mode the authSafe.content field has a Data type value		ase of password integrity mode, the authSafe.content field has a Data type value
	and contains a BER-encoded value of AuthenticatedSafe structure;</li>		and contains a BER-encoded value of the AuthenticatedSafe structure.</li>
	<li>macData has a MacData type and in the case of password i		<li>macData has a MacData type; in the case of password inte
	ntegrity mode the macData field should contain the information about algorithm a		grity mode, the macData field should contain information about the algorithm and
	nd parameters for a password key generation.		parameters for password key generation.
	The integrity control is ensured by using the HMAC_GOSTR		Integrity control is ensured by using the HMAC_GOSTR3411
	3411_2012_512 algorithm: the macData.mac.digestAlgorithm.algorithm field contain		_2012_512 algorithm: the macData.mac.digestAlgorithm.algorithm field contains th
	s the HMAC_GOSTR3411_2012_512 algorithm identifier (see <xref target="SecurityM"		e HMAC_GOSTR3411_2012_512 algorithm identifier (see <xref target="SecurityM"/>).
	/>).
	When processing a transport key container, this field sh ould be checked first.</li>		When processing a transport key container, this field sh ould be checked first.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="AuthenticatedSafe">		<section anchor="AuthenticatedSafe">
	<name>AuthenticatedSafe</name>		<name>AuthenticatedSafe</name>
	<t>The AuthenticatedSafe structure is a sequence of ContentInfo v alues (see <xref target="RFC5652"/>):</t>		<t>The AuthenticatedSafe structure is a sequence of ContentInfo v alues (see <xref target="RFC5652"/>):</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	AuthenticatedSafe ::= SEQUENCE OF ContentInfo		AuthenticatedSafe ::= SEQUENCE OF ContentInfo
	-- Data if unencrypted		-- Data if unencrypted
	-- EncryptedData if password-encrypted		-- EncryptedData if password-encrypted
	-- EnvelopedData if public key-encrypted		-- EnvelopedData if public key-encrypted
	]]></sourcecode>		]]></sourcecode>
	<section anchor="Unencrypted">		<section anchor="Unencrypted">
	<name>Unencrypted Data</name>		<name>Unencrypted Data</name>
	<t>If the data is not encrypted then the content field is the BE R-encoded value of the SafeContents structure. The contentType field is set to t he id-data type.</t>		<t>If the data is not encrypted, then the content field is the B ER-encoded value of the SafeContents structure. The contentType field is set to the id-data type.</t>
	</section>		</section>
	<section anchor="Password-encrypted">		<section anchor="Password-encrypted">
	<name>Password-encrypted data</name>		<name>Password-Encrypted Data</name>
	<t>When password integrity mode is used the data is represented a		<t>When password integrity mode is used, the data is represented
	s an EncryptedData structure (<xref target="RFC5652"/>).		as an EncryptedData structure (see <xref target="RFC5652"/>).
	The encryption algorithm and parameters have the following values		The encryption algorithm and parameters have the following values
	:</t>		:
			<!-- [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[		<sourcecode type="asn.1"><![CDATA[
	ContentEncryptionAlgorithmIdentifier ::= SEQUENCE		ContentEncryptionAlgorithmIdentifier ::= SEQUENCE
	{		{
	encryptionAlgorithmOID OBJECT IDENTIFIER,		encryptionAlgorithmOID OBJECT IDENTIFIER,
	parameters PBES2-params		parameters PBES2-params
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>The PBES2-params type is defined in <xref target="RFC9337"/>.		<t>The PBES2-params type is defined in <xref target="RFC9337"/>.
	The content should be encrypted according to the encryption algorithm in the PB		The content should be encrypted according to the encryption algorithm in the PB
	ES2 scheme, described in <xref target="RFC9337"/>.		ES2 scheme, as described in <xref target="RFC9337"/>.
	The following identifier MUST be specified in EncryptedData.Encr		The following identifier <bcp14>MUST</bcp14> be specified in the
	yptedContentInfo.contentEncryptionAlgorithm.encryptionAlgorithmOID field:</t>		EncryptedData.EncryptedContentInfo.contentEncryptionAlgorithm.encryptionAlgorit
			hmOID 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[		<sourcecode type="asn.1"><![CDATA[
	{		{
	iso(1) member-body(2) us(840) rsadsi(113549)		iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-5(5) pbes2(13)		pkcs(1) pkcs-5(5) pbes2(13)
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>The encrypted content is specified in EncryptedData.Encrypted ContentInfo.encryptedContent field.</t>		<t>The encrypted content is specified in the EncryptedData.Encry ptedContentInfo.encryptedContent field.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="SC">		<section anchor="SC">
	<name>SafeContents and SafeBag</name>		<name>SafeContents and SafeBag</name>
	<t>In accordance with <xref target="RFC7292"/> the SafeContents structure is a sequence of SafeBag:</t>		<t>In accordance with <xref target="RFC7292"/>, the SafeContents structure is a sequence of SafeBag:</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	SafeContents ::= SEQUENCE OF SafeBag		SafeContents ::= SEQUENCE OF SafeBag
	]]></sourcecode>		]]></sourcecode>
	<t>where</t>		<t>where</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	SafeBag ::= SEQUENCE		SafeBag ::= SEQUENCE
	{		{
	bagId BAG-TYPE.&id ({PKCS12BagSet})		bagId BAG-TYPE.&id ({PKCS12BagSet})
	bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId})		bagValue [0] EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagId})
	bagAttributes SET OF PKCS12Attribute OPTIONAL		bagAttributes SET OF PKCS12Attribute OPTIONAL
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>The fields of SafeBag have the following meanings:</t>		<t>The fields of SafeBag have the following meanings:</t>
	<ul spacing="normal"><li>bagId is an object identifier, it d		<ul spacing="normal"><li>bagId is an object identifier; it d
	efines the type of object;</li>		efines the type of object.</li>
	<li>bagValue is the value of an object;</li>		<li>bagValue is the value of an object.</li>
	<li>bagAttributes contains the users names, the key identifi		<li>bagAttributes contains the users' names, the key identif
	ers and other additional information. It is optional.</li>		iers, and other additional information. This field is optional.</li>
	</ul>
	<t>See <xref target="RFC7292"/> Section 4.2. for the different b
	ag types.
	This document describes the 2 object types of SafeBag structure:
	</t>
	<ul spacing="normal">
	<li>pkcs8ShroudedKeyBag,</li>
	<li>certBag.</li>
	</ul>		</ul>
	<t>When password integrity mode is used the private key has the		<t>See <xref target="RFC7292" sectionFormat="comma" section="4.2
	following structure:</t>		"/>
			for the different bag types.
			This document describes the two object types of the SafeBag stru
			cture:</t>
			<ol spacing="normal">
			<li>pkcs8ShroudedKeyBag</li>
			<li>certBag</li>
			</ol>
			<t>When password integrity mode is used, the private key has the
			following structure:</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	pkcs8ShroudedKeyBag BAG-TYPE ::=		pkcs8ShroudedKeyBag BAG-TYPE ::=
	{		{
	PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}		PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>The bagValue field contains the key and information about it		<t>The bagValue field contains the key and information about the
	in the encrypted form in the EncryptedPrivateKeyInfo structure.</t>		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 EncryptedPrivateKeyInfo 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 id entifiers are used to distinguish between different certificate types.</t>		<t>A certBag contains a certificate of a certain type. Object id entifiers are used to distinguish between different certificate types.</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	certBag BAG-TYPE ::=		certBag BAG-TYPE ::=
	{		{
	CertBag IDENTIFIED BY { bagtypes 3 }		CertBag IDENTIFIED BY { bagtypes 3 }
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>If the certificate is not encrypted, the CertBag structure is placed in the Data structure (see <xref target="RFC5652"/>).		<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>		If the certificate is encrypted, the CertBag structure is placed in the EncryptedData structure (see <xref target="RFC5652"/>).</t>
	</section>		</section>
	</section>		</section>
	<section anchor="Key_repres">		<section anchor="Key_repres">
	<name>GOST R 34.10–2012 key representation</name>		<name>GOST R 34.10-2012 Key Representation</name>
	<t>This section describes the GOST R 34.10–2012 private keys represe		<t>This section describes the GOST R 34.10-2012 private key represen
	ntation for asymmetric key pairs.		tation for asymmetric key pairs.
	Masked keys should be used to ensure the protection of private keys		Masked keys should be used to ensure that private keys are protected
	from leaks through the side channels when reading and performing operations with		from leaking through side channels when reading and performing operations with
	keys.</t>		keys.</t>
	<section anchor="Key_mask">		<section anchor="Key_mask">
	<name>Masking GOST R 34.10–2012 keys</name>		<name>Masking GOST R 34.10-2012 Keys</name>
	<t>The masking algorithm is defined by the basic cryptographic t		<t>The masking algorithm is defined by the basic cryptographic t
	ransformation operation of the algorithm: multiplication in the F_q field for G		ransformation operation of the algorithm: multiplication in the F_q field for G
	OST R 34.10–2012 keys.</t>		OST R 34.10-2012 keys.</t>
	<t>Let M<sub>1</sub>, M<sub>2</sub>, ..., M<sub>k</sub> be a seq uence 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 &lt;= i &lt;= k.		<t>Let M<sub>1</sub>, M<sub>2</sub>, ..., M<sub>k</sub> be a seq uence 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 &lt;= i &lt;= k.
	Let K be a key. The masked key K<sub>M</sub> is obtained by appl ying the masking operation k times:</t>		Let K be a key. The masked key K<sub>M</sub> is obtained by appl ying the masking operation k times:</t>
	<ul empty="true" spacing="normal">		<t indent="3">K<sub>M</sub> = M<sub>k</sub> (...(M<sub>2</sub>(M
	<li>K<sub>M</sub> = M<sub>k</sub> (...(M<sub>2</sub>(M<sub>1</su		<sub>1</sub>(K)...).</t>
	b>(K)...).</li>		<t>Unmasking is performed by applying the removal operation k ti
	</ul>		mes, but in reverse order:</t>
	<t>Unmasking is performed by applying the removing operation k t		<t indent="3">K = M<sub>1</sub><sup>-1</sup>(...(M<sub>k-1</sub>
	imes, but in reverse order:</t>		<sup>-1</sup>(M<sub>k</sub><sup>-1</sup>(K<sub>M</sub>))...).</t>
	<ul empty="true" spacing="normal">
	<li>K = M<sub>1</sub><sup>-1</sup>(...(M<sub>k-1</sub><sup>-1</s
	up>(M<sub>k</sub><sup>-1</sup>(K<sub>M</sub>))...).</li>
	</ul>
	<t>The masked key is represented as the sequence</t>		<t>The masked key is represented as the sequence</t>
	<ul empty="true" spacing="normal">		<t indent="3">I = K<sub>M</sub>||M<sub>1</sub>||M<sub>2</sub>||.
	<li>I = K<sub>M</sub>||M<sub>1</sub>||M<sub>2</sub>||...||M<sub>		..||M<sub>k</sub>.</t>
	k</sub>.</li>
	</ul>		<!-- [rfced] Section 5.1: Are the periods at the end of these
	<t>Let the key K be n bits in length, then the sequence I is rep		standalone equations part of the equations, or should they be
	resented in memory as a sequence of (k + 1)*n bits. I is represented in little-e		removed?
	ndian format.
			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 in length; then, the sequence I is re
			presented 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<su b>M</sub> = K).		It is possible to use an unmasked private key (i.e., k = 0, K<su b>M</sub> = K).
	The masking operation is the multiplication of the key by the in verse of the mask: K<sub>M</sub> = K * M<sup>-1</sup> mod Q, where the Q value i s taken from the key parameters.		The masking operation is the multiplication of the key by the in verse of the mask: K<sub>M</sub> = K * M<sup>-1</sup> mod Q, where the Q value i s 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 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) defi ned in GOST R 34.10–2012, presented in the following format:</t>		The public key is specified by a pair of coordinates (x, y) as d efined in GOST R 34.10-2012, presented in the following format:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>a public key corresponding to the GOST R 34.10–2012 algorith		<li>a public key corresponding to the GOST R 34.10-2012 algorith
	m with a key length of 256 bits		m with a key length of 256 bits
	has the GostR3410–2012-256-PublicKey representation. It is speci		has the GostR3410-2012-256-PublicKey representation. It is speci
	fied by a 64-byte string, where the first 32 bytes contain the little-endian rep		fied by a 64-byte string, where the first 32 bytes contain the little-endian rep
	resentation of the x coordinate,		resentation of the x coordinate
	and the last 32 bytes contain the little-endian representation o		and the last 32 bytes contain the little-endian representation o
	f the y coordinate;</li>		f the y coordinate.</li>
	<li>a public key corresponding to the GOST R 34.10–2012 algorith		<li>a public key corresponding to the GOST R 34.10-2012 algorith
	m with a key length of 512 bits		m with a key length of 512 bits
	has the GostR3410–2012-512-PublicKey representation. It is speci		has the GostR3410-2012-512-PublicKey representation. It is speci
	fied by a 128-byte string, where the first 64 bytes contain the little-endian re		fied by a 128-byte string, where the first 64 bytes contain the little-endian re
	presentation of the x coordinate,		presentation of the x coordinate
	and the last 64 bytes contain the little-endian representation o f the y coordinate.</li>		and the last 64 bytes contain the little-endian representation o f the y coordinate.</li>
	</ul>		</ul>
	<t>The public keys GostR3410-2012-256-PublicKey and GostR3410-20		<t>The public keys GostR3410-2012-256-PublicKey and GostR3410-20
	12-512-PublicKey MUST be DER-encoded as an octet string in accordance with <xref		12-512-PublicKey <bcp14>MUST</bcp14> be DER encoded as an octet string in accord
	target="RFC9215"/> (section 4.3):</t>		ance with <xref target="RFC9215" sectionFormat="of" section="4.3"/>:</t>
	<ul empty="true" spacing="normal">		<sourcecode type="asn.1"><![CDATA[
	<li>GostR3410–2012-256-PublicKey ::= OCTET STRING (64),</li>		GostR3410-2012-256-PublicKey ::= OCTET STRING (64),
	<li>GostR3410–2012-512-PublicKey ::= OCTET STRING (128).</li>		GostR3410-2012-512-PublicKey ::= OCTET STRING (128).
	</ul>		]]></sourcecode>
	</section>		</section>
	<section anchor="KeyBag">		<section anchor="KeyBag">
	<name>KeyBag structure for GOST R 34.10–2012 key</name>		<name>KeyBag Structure for GOST R 34.10-2012 Key</name>
	<t>		<t>
	In accordance with <xref target="RFC7292"/> a KeyBag is defined as information about a private key represented as the PrivateKeyInfo structure:< /t>		In accordance with <xref target="RFC7292"/>, a KeyBag is defined as information about a private key represented as the PrivateKeyInfo structure: </t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	KeyBag := PrivateKeyInfo		KeyBag := PrivateKeyInfo
	]]></sourcecode>		]]></sourcecode>
			<!-- [rfced] Section 5.2: Should the two " := " entries be
			" ::= "?
			Original:
			KeyBag := PrivateKeyInfo
			...
			PrivateKeyInfo := OneAsymmetricKey -->
	<t>In accordance with <xref target="RFC5958"/>, information abou t a private key is presented in the following form:</t>		<t>In accordance with <xref target="RFC5958"/>, information abou t a private key is presented in the following form:</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	PrivateKeyInfo := OneAsymmetricKey		PrivateKeyInfo := OneAsymmetricKey
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="OneAsymmetricKey">		<section anchor="OneAsymmetricKey">
	<name>OneAsymmetricKey structure</name>		<name>OneAsymmetricKey Structure</name>
	<t>In accordance with <xref target="RFC5958"/> OneAsymmetricKey		<t>In accordance with <xref target="RFC5958"/>, OneAsymmetricKey
	has the following structure: </t>		has the following structure: </t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	OneAsymmetricKey::= SEQUENCE		OneAsymmetricKey::= SEQUENCE
	{		{
	version Version,		version Version,
	privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,		privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
	privateKey PrivateKey,		privateKey PrivateKey,
	attributes [0] Attributes OPTIONAL,		attributes [0] Attributes OPTIONAL,
	...,		...,
	[[2:publicKey [1] PublicKey OPTIONAL]],		[[2:publicKey [1] PublicKey OPTIONAL]],
	...		...
	}		}
	Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2)		Version ::= INTEGER { v1(0), v2(1) } (v1, ..., v2)
	PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier		PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
	PrivateKey ::= OCTET STRING		PrivateKey ::= OCTET STRING
	PublicKey ::= BIT STRING		PublicKey ::= BIT STRING
	Attributes ::= SET OF Attribute		Attributes ::= SET OF Attribute
	]]></sourcecode>		]]></sourcecode>
	<t>The fields have the following meanings:</t>		<t>The fields have the following meanings:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>version identifies the version of OneAsymmetricKey. If publi		<li>version identifies the version of OneAsymmetricKey. If publi
	cKey is present, then version is set to 2 else version is set to 1.</li>		cKey is present, then version is set to 2; else, version is set to 1.</li>
	<li>privateKeyAlgorithm identifies the private-key algorithm and		<li>privateKeyAlgorithm identifies the private key algorithm and
	optionally contains parameters associated with the asymmetric key		optionally contains parameters associated with the asymmetric key
	pair. For GOST R 34.10–2012 private keys the identifiers of the		pair. For GOST R 34.10-2012 private keys, the identifiers of the
	corresponding public keys are used, they are defined in the <xref target="RFC921		corresponding public keys are used; they are defined in <xref target="RFC9215"/
	5"/>.		>.
	The use of identifiers and public key parameters is defined in t		The use of identifiers and public key parameters is defined in <
	he <xref target="RFC9215"/>.</li>		xref target="RFC9215"/>.</li>
	<li>privateKey is an OCTET STRING that contains the value of the masked private key I.</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 correspond ing to the public key (e.g., certificates).</li>		<li>attributes are optional. They contain information correspond ing to the public key (e.g., certificates).</li>
	<li>publicKey contains the value of the public key GostR3410–201 2-256-PublicKey or GostR3410–2012-512-PublicKey encoded in a BIT STRING. It is a n optional field.</li>		<li>publicKey contains the value of the public key GostR3410-201 2-256-PublicKey or GostR3410-2012-512-PublicKey encoded in a BIT STRING. This fi eld is optional.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="PKCS8ShroudedKeyBag">		<section anchor="PKCS8ShroudedKeyBag">
	<name>EncryptedPrivateKeyInfo structure for GOST R 34.10–2012 ke		<name>EncryptedPrivateKeyInfo Structure for GOST R 34.10-2012 Ke
	y</name>		y</name>
	<t>In accordance with <xref target="RFC7292"/> the encrypted inf		<t>In accordance with <xref target="RFC7292"/>, the encrypted in
	ormation of the private key is defined as the PKCS8ShroudedKeyBag structure:</t>		formation regarding the private key is defined as the PKCS8ShroudedKeyBag struct
			ure:</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	PKCS8ShroudedKeyBag::= EncryptedPrivateKeyInfo		PKCS8ShroudedKeyBag::= EncryptedPrivateKeyInfo
	]]></sourcecode>		]]></sourcecode>
	<t>In accordance with <xref target="RFC5958"/> the EncryptedPriv ateKeyInfo has the following structure:</t>		<t>In accordance with <xref target="RFC5958"/>, EncryptedPrivate KeyInfo has the following structure:</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	EncryptedPrivateKeyInfo ::= SEQUENCE		EncryptedPrivateKeyInfo ::= SEQUENCE
	{		{
	encryptionAlgorithm EncryptionAlgorithmIdentifier,		encryptionAlgorithm EncryptionAlgorithmIdentifier,
	encryptedData EncryptedData		encryptedData EncryptedData
	}		}
	EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier		EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
	EncryptedData ::= OCTET STRING		EncryptedData ::= OCTET STRING
	]]></sourcecode>		]]></sourcecode>
	<t>The fields have the following meanings:</t>		<t>The fields have the following meanings:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>encryptionAlgorithm identifies the algorithm under which the private key information is encrypted. Encryption MUST use PBES2 scheme. The alg orithm and parameters of this scheme are presented in <xref target="RFC9337"/>.< /li>		<li>encryptionAlgorithm identifies the algorithm under which the private key information is encrypted. Encryption <bcp14>MUST</bcp14> use the PB ES2 scheme. The algorithm and parameters of this scheme are presented in <xref t arget="RFC9337"/>.</li>
	<li>encryptedData is the DER-encoded PrivateKeyInfo structure.</ li>		<li>encryptedData is the DER-encoded PrivateKeyInfo structure.</ li>
	</ul>		</ul>
	</section>		</section>
	</section>		</section>
	<section anchor="Cert_repres">		<section anchor="Cert_repres">
	<name>GOST R 34.10–2012 certificate representation</name>		<name>GOST R 34.10-2012 Certificate Representation</name>
	<t>		<t>
	In accordance with <xref target="RFC7292"/> a CertBag is defined as info rmation about a certificate and represented as the following structure:</t>		In accordance with <xref target="RFC7292"/>, a CertBag is defined as inf ormation about a certificate and has the following structure:</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	CertBag ::= SEQUENCE		CertBag ::= SEQUENCE
	{		{
	certId BAG-TYPE.&id ({CertTypes}),		certId BAG-TYPE.&id ({CertTypes}),
	certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})		certValue [0] EXPLICIT BAG-TYPE.&Type ({CertTypes}{@certId})
	}		}
	]]></sourcecode>		]]></sourcecode>
	<t>The fields have the following meanings:</t>		<t>The fields have the following meanings:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>certId identifies the type of certificate.</li>		<li>certId identifies the type of certificate.</li>
	<li>certValue contains certificate.</li>		<li>certValue contains the certificate.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="SecurityM">		<section anchor="SecurityM">
	<name>Security Mechanisms</name>		<name>Security Mechanisms</name>
	<t>Let the sender and receiver have a pre-agreed password P. The sender generates a password key using the PBKDF2 algorithm in accordance with <xref tar get="RFC9337"/> and uses it to encrypt the transmitted private key.		<t>Let the sender and receiver have a previously agreed-upon password P. The sender generates a password key using the PBKDF2 algorithm in accordance wi th <xref target="RFC9337"/> and uses it to encrypt the transmitted private key.
	The recipient independently generates a password key using the same PBKD F2 diversification algorithm in accordance with <xref target="RFC9337"/> and use s it to extract the private key from the PFX.</t>		The recipient independently generates a password key using the same PBKD F2 diversification algorithm in accordance with <xref target="RFC9337"/> and use s it to extract the private key from the PFX.</t>
	<t>The same password P is used to encrypt different sections of the PFX		<t>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,		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 passw		where S and P are the input parameters of the PBKDF2 function. The passw
	ord MUST be encoded as a Unicode UTF-8 string and fed into the PBKDF2 algorithm		ord <bcp14>MUST</bcp14> be encoded as a Unicode UTF-8 string and fed into the PB
	as a P parameter.</t>		KDF2 algorithm as a P parameter.
	<t>The integrity of PFX is ensured by using the HMAC_GOSTR3411_2012_512		<!-- [rfced] Section 7: We changed "using different random
	algorithm in accordance with <xref target="RFC7836"/>. For checking the integrit		initializing value S" to "using a different random initializing
	y of PFX with the HMAC_GOSTR3411_2012_512 algorithm		value S". If this is incorrect, please clarify the text
	the key for this algorithm is also generated by using the PBKDF2 algorit		(for example, was "different random initializing values for S"
	hm in accordance with <xref target="RFC9337"/> with the same value of the P para		intended?).
	meter and a different initializing value S with a length of 8 to 32 bytes.
			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"/>. To check the integrit
			y of the PFX with the HMAC_GOSTR3411_2012_512 algorithm,
			the key for this algorithm is also generated by using the PBKDF2 algorit
			hm in accordance with <xref target="RFC9337"/>, with the same value for the P pa
			rameter 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-b yte sequence generated by the PBKDF2 algorithm.		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-b yte sequence generated by the PBKDF2 algorithm.
	The PBKDF2 algorithm parameters S and c are saved in macData.Salt and ma cData.iterations fileds respectively.		The PBKDF2 algorithm parameters S and c are saved in the macData.Salt an d macData.iterations fields, respectively.
	The HMAC_GOSTR3411_2012_512 function is calculated from the content fiel d of the authSafe structure field. The authSafe structure field is a PFX structu re field.		The HMAC_GOSTR3411_2012_512 function is calculated from the content fiel d of the authSafe structure field. The authSafe structure field is a PFX structu re field.
	The value of the calculated checksum is saved in the macData.mac.digest field. The macData.mac.digestAlgorithm.algorithm field contains the following al gorithm identifier:</t>		The value of the calculated checksum is saved in the macData.mac.digest field. The macData.mac.digestAlgorithm.algorithm field contains the following al gorithm identifier:</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	id-tc26-gost3411-12-512 :: =		id-tc26-gost3411-12-512 :: =
	{		{
	iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)		iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)
	algorithms (1) digest(2) gost3411–2012-512(3)		algorithms (1) digest(2) gost3411-2012-512(3)
	}		}
	]]></sourcecode>		]]></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 shoul d be omitted.</t>		<t>The macData.mac.digestAlgorithm.parameters field isn't used and shoul d be omitted.</t>
	</section>		</section>
	<section anchor="Security">		<section anchor="Security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>The masked keys SHOULD be used to ensure the protection of private ke ys from leaking through side channels when reading and performing operations wit h keys.		<t>The masked keys <bcp14>SHOULD</bcp14> be used to ensure that private keys are protected from leaking through side channels when reading and performin g operations with keys.
	Applications MUST use unique values for ukm and S in the PBKDF2 algorith		Applications <bcp14>MUST</bcp14> use unique values for ukm and S in the
	m.		PBKDF2 algorithm.
	It is RECOMMENDED that parameter S consist of at least 32 octets of pseu		It is <bcp14>RECOMMENDED</bcp14> that parameter S consist of at least 32
	do-random data in order to reduce the probability of collisions of keys generate		octets of pseudorandom data in order to reduce the probability of collisions of
	d from the same password.		keys generated from the same password.
	The password MUST be encoded as a Unicode UTF-8 string and fed into the		The password <bcp14>MUST</bcp14> be encoded as a Unicode UTF-8 string an
	PBKDF2 algorithm as a P parameter.		d fed into the PBKDF2 algorithm as a P parameter.
	For more information see <xref target="RFC9337"/>.		For more information, see <xref target="RFC9337"/>.
	Encryption MUST use PBES2 scheme for encryption private keys. Public key		Encryption <bcp14>MUST</bcp14> use the PBES2 scheme to encrypt private k
	s MUST be DER-encoded as an octet string in accordance with <xref target="RFC921		eys. Public keys <bcp14>MUST</bcp14> be DER encoded as an octet string in accord
	5"/>.		ance with <xref target="RFC9215"/>.
	Passwords SHOULD be stored in secure way.		Passwords <bcp14>SHOULD</bcp14> be stored in a secure way.
	For information on security considerations for generating the transport		For information on security considerations for generating transport key
	key containers see <xref target="RFC7292"/>.</t>		containers, see <xref target="RFC7292"/>.</t>
	</section>		</section>
	<section anchor="IANA_Considerations">		<section anchor="IANA_Considerations">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document has no IANA actions.</t>		<t>This document has no IANA actions.</t>
	</section>		</section>
	<section anchor="ASN">		<section anchor="ASN">
	<name>ASN.1 Modules</name>		<name>ASN.1 Modules</name>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	PKCS-12RU		PKCS-12RU
	{		{
	iso(1) member-body(2) ru(643) rosstandart(7)		iso(1) member-body(2) ru(643) rosstandart(7)
	tc26(1) modules(0) pkcs-12ruSyntax(5)		tc26(1) modules(0) pkcs-12ruSyntax(5)
	}		}
	DEFINITIONS EXPLICIT TAGS ::=		DEFINITIONS EXPLICIT TAGS ::=
	BEGIN		BEGIN
	IMPORTS		IMPORTS
	GostR3410–2012-PublicKey		GostR3410-2012-PublicKey
	FROM GostR3410–2012-PKISyntax		FROM GostR3410-2012-PKISyntax
	{		{
	iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)		iso(1) member-body(2) ru(643) rosstandart(7) tc26(1)
	modules(0) gostR3410–2012-PKISyntax(2)		modules(0) gostR3410-2012-PKISyntax(2)
	};		};
	END		END
	]]></sourcecode>		]]></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>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.210
	.2104.xml"/>		4.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
	.2119.xml"/>		9.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
	.8174.xml"/>		4.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.729
	.7292.xml"/>		2.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.595
	.5958.xml"/>		8.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.565
	.5652.xml"/>		2.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.783
	.7836.xml"/>		6.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.698
	.6986.xml"/>		6.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.921
	.9215.xml"/>		5.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.933
	.9337.xml"/>		7.xml"/>
	<reference anchor="X.680">
			<reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680">
	<front>		<front>
	<title>Information Technology - Abstract Syntax Notation One: Specific ation of Basic Notation.</title>		<title>Information Technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
	<author>		<author>
	<organization>ITU-T</organization>		<organization>ITU-T</organization>
	</author>		</author>
	<date year="2002"/>		<date month="February" year="2021"/>
	</front>		</front>
	<refcontent>ITU-T, Recommendation X.680, ISO/IEC 8824-1:2002</refcontent		<seriesInfo name="ITU-T Recommendation" value="X.680"/>
	>		<seriesInfo name="ISO/IEC" value="8824-1:2021"/>
	</reference>		</reference>
	<reference anchor="X.690">
			<!-- [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/IEC 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>. -->
			<reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690">
	<front>		<front>
	<title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical		<title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical
	Encoding Rules (CER) and Distinguished Encoding Rules (DER).</titl e>		Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title >
	<author>		<author>
	<organization>ITU-T</organization>		<organization>ITU-T</organization>
	</author>		</author>
	<date month="November" year="2008"/>		<date month="February" year="2021"/>
	</front>		</front>
	<refcontent>ITU-T, Recommendation X.690, ISO/IEC International Standard		<seriesInfo name="ITU-T Recommendation" value="X.690"/>
	8825-1:2008</refcontent>		<seriesInfo name="ISO/IEC International Standard" value="8825-1:2021"/>
	</reference>		</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 Standard 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>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="ISO14888-1">
			<reference anchor="ISO14888-1" target="https://www.iso.org/standard/44226.
			html">
	<front>		<front>
	<title>Information technology - Security techniques - Digital signatur es with appendix - Part 1: General.</title>		<title>Information technology - Security techniques - Digital signatur es with appendix - Part 1: General</title>
	<author>		<author>
	<organization>ISO/IEC</organization>		<organization>ISO/IEC</organization>
	</author>		</author>
	<date year="2008"/>		<date month="April" year="2008"/>
	</front>		</front>
	<refcontent>ISO/IEC 14888-1</refcontent>		<seriesInfo name="ISO/IEC" value="14888-1"/>
	</reference>		</reference>
	<reference anchor="GostPkcs12">		<reference anchor="GostPkcs12">
	<front>		<front>
	<title>Information technology. Cryptographic Data Security. The transp ort key containers.</title>		<title>Information technology. Cryptographic Data Security. Transport key container</title>
	<author initials="A." surname="Potashnikov" fullname="A. Potashnikov ">		<author initials="A." surname="Potashnikov" fullname="A. Potashnikov ">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="E." surname="Karelina" fullname="E. Karelina">		<author initials="E." surname="Karelina" fullname="E. Karelina">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="S." surname="Pianov" fullname="S. Pianov">		<author initials="S." surname="Pianov" fullname="S. Pianov">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="A." surname="Naumenko" fullname="A. Naumenko">		<author initials="A." surname="Naumenko" fullname="A. Naumenko">
	<organization/>		<organization/>
	</author>		</author>
	</front>		</front>
	<refcontent>R 1323565.1.041–2022. Federal Agency on Technical Regulating and Metrology (In Russian)</refcontent>		<refcontent>R 1323565.1.041-2022. Federal Agency on Technical Regulating and Metrology (In Russian)</refcontent>
	</reference>		</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>
	</references>		</references>
	<section anchor="Examples">		<section anchor="Examples">
	<name>Examples</name>		<name>Examples</name>
	<t>This section contains examples of using GOST cryptographic algorithms to create a PFX.</t>		<t>This section contains examples of using GOST cryptographic algorithms to create a PFX.</t>
	<section anchor="Data">		<section anchor="Data">
	<name>Test data</name>		<name>Test Data</name>
	<t>In all examples the following data is used.</t>		<t>In all examples, the following data is used.</t>
	<section anchor="Test_cert">		<section anchor="Test_cert">
	<name>Test certificate</name>		<name>Test Certificate</name>
	<t>This section contains a test certififcate in BASE64 format.</t>		<t>This section contains a test certificate in BASE64 format.</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	MIICLjCCAdugAwIBAgIEAYy6hDAKBggqhQMHAQEDAjA4MQ0wCwYDVQQKEwRUSzI2		MIICLjCCAdugAwIBAgIEAYy6hDAKBggqhQMHAQEDAjA4MQ0wCwYDVQQKEwRUSzI2
	MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwHhcNMDEw		MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwHhcNMDEw
	MTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA7MQ0wCwYDVQQKEwRUSzI2MSowKAYD		MTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA7MQ0wCwYDVQQKEwRUSzI2MSowKAYD
	VQQDEyFPUklHSU5BVE9SOiBHT1NUIDM0LjEwLTEyIDUxMi1iaXQwgaAwFwYIKoUD		VQQDEyFPUklHSU5BVE9SOiBHT1NUIDM0LjEwLTEyIDUxMi1iaXQwgaAwFwYIKoUD
	BwEBAQIwCwYJKoUDBwECAQIBA4GEAASBgLSLt1q8KQ4YZVxioU+1LV9QhE7MHR9g		BwEBAQIwCwYJKoUDBwECAQIBA4GEAASBgLSLt1q8KQ4YZVxioU+1LV9QhE7MHR9g
	BEh7S1yVNGlqt7+rNG5VFqmrPM74rbUsOlhV8M+zZKprXdk35Oz8lSW/n2oIUHZx		BEh7S1yVNGlqt7+rNG5VFqmrPM74rbUsOlhV8M+zZKprXdk35Oz8lSW/n2oIUHZx
	ikXIH/SSHj4rv3K/Puvz7hYTQSZl/xPdp78nUmjrEa6d5wfX8biEy2z0dgufFvAk		ikXIH/SSHj4rv3K/Puvz7hYTQSZl/xPdp78nUmjrEa6d5wfX8biEy2z0dgufFvAk
	Mw1Ua4gdXqDOo4GHMIGEMGMGA1UdIwRcMFqAFKxsDkxEZqJCluKfCTslZvPLpFMq		Mw1Ua4gdXqDOo4GHMIGEMGMGA1UdIwRcMFqAFKxsDkxEZqJCluKfCTslZvPLpFMq
	oTykOjA4MQ0wCwYDVQQKEwRUSzI2MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0		oTykOjA4MQ0wCwYDVQQKEwRUSzI2MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0
	LjEwLTEyIDI1Ni1iaXSCBAGMuoEwHQYDVR0OBBYEFH4GVwmYDK1rCKhX7nkAWDrJ		LjEwLTEyIDI1Ni1iaXSCBAGMuoEwHQYDVR0OBBYEFH4GVwmYDK1rCKhX7nkAWDrJ
	16CkMAoGCCqFAwcBAQMCA0EACl6p8dAbpi9Hk+3mgMyI0WIh17IrlrSp/mB0F7Zz		16CkMAoGCCqFAwcBAQMCA0EACl6p8dAbpi9Hk+3mgMyI0WIh17IrlrSp/mB0F7Zz
	Mt8XUD1Dwz3JrrnxeXnfMvOA5BdUJ9hCyDgMVAGs/IcEEA==		Mt8XUD1Dwz3JrrnxeXnfMvOA5BdUJ9hCyDgMVAGs/IcEEA==
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="Test_key">		<section anchor="Test_key">
	<name>Test key</name>		<name>Test Key</name>
	<t>This section contains a test key bytes in hexadecimal.</t>		<t>This section contains a test key bytes in 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[		<sourcecode type="asn.1"><![CDATA[
	F95A5D44C5245F63F2E7DF8E782C1924EADCB8D06C52D91023179786154CBDB1		F95A5D44C5245F63F2E7DF8E782C1924EADCB8D06C52D91023179786154CBDB1
	561B4DF759D69F67EE1FBD5B68800E134BAA12818DA4F3AC75B0E5E6F9256911		561B4DF759D69F67EE1FBD5B68800E134BAA12818DA4F3AC75B0E5E6F9256911
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="PFXUnencrypted">		<section anchor="PFXUnencrypted">
	<name>The example of a PFX with a password-protected key and unencry		<name>Example of a PFX with a Password-Protected Key and Unencrypted
	pted certificate.</name>		Certificate</name>
	<t>In this example the PKCS8SHroudedKeybag structure is used to stor		<t>In this example, the PKCS8SHroudedKeybag structure is used to sto
	e the key, which is placed in the Data structure.		re the key, which is placed in the Data structure.
	The certBag structure is used to store the certificate, which is pla ced in the Data structure.		The certBag structure is used to store the certificate, which is pla ced in the Data structure.
	A following password is used to encrypt the key and control the inte grity:		The following password is used to encrypt the key and provide integr ity control:
	"Пароль для PFX".		"Пароль для PFX".
	The password is in hexadecimal:</t>		The password is in 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[		<sourcecode type="asn.1"><![CDATA[
	D09FD0B0D180D0BED0BBD18C20D0B4D0BBD18F20504658		D09FD0B0D180D0BED0BBD18C20D0B4D0BBD18F20504658
	]]></sourcecode>		]]></sourcecode>
	<t>The key encryption algorithm identifier:</t>		<t>The key encryption algorithm identifier:</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	1.2.643.7.1.1.5.2.2		1.2.643.7.1.1.5.2.2
	]]></sourcecode>		]]></sourcecode>
	<section anchor="PFX_BASE64">		<section anchor="PFX_BASE64">
	<name>PFX in BASE64 format</name>		<name>PFX in BASE64 Format</name>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	MIIFKwIBAzCCBMQGCSqGSIb3DQEHAaCCBLUEggSxMIIErTCCAswGCSqGSIb3DQEH		MIIFKwIBAzCCBMQGCSqGSIb3DQEHAaCCBLUEggSxMIIErTCCAswGCSqGSIb3DQEH
	AaCCAr0EggK5MIICtTCCArEGCyqGSIb3DQEMCgEDoIICSjCCAkYGCiqGSIb3DQEJ		AaCCAr0EggK5MIICtTCCArEGCyqGSIb3DQEMCgEDoIICSjCCAkYGCiqGSIb3DQEJ
	FgGgggI2BIICMjCCAi4wggHboAMCAQICBAGMuoQwCgYIKoUDBwEBAwIwODENMAsG		FgGgggI2BIICMjCCAi4wggHboAMCAQICBAGMuoQwCgYIKoUDBwEBAwIwODENMAsG
	A1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsyNjogR09TVCAzNC4xMC0xMiAyNTYt		A1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsyNjogR09TVCAzNC4xMC0xMiAyNTYt
	Yml0MB4XDTAxMDEwMTAwMDAwMFoXDTQ5MTIzMTAwMDAwMFowOzENMAsGA1UEChME		Yml0MB4XDTAxMDEwMTAwMDAwMFoXDTQ5MTIzMTAwMDAwMFowOzENMAsGA1UEChME
	VEsyNjEqMCgGA1UEAxMhT1JJR0lOQVRPUjogR09TVCAzNC4xMC0xMiA1MTItYml0		VEsyNjEqMCgGA1UEAxMhT1JJR0lOQVRPUjogR09TVCAzNC4xMC0xMiA1MTItYml0
	MIGgMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQOBhAAEgYC0i7davCkOGGVcYqFP		MIGgMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQOBhAAEgYC0i7davCkOGGVcYqFP
	tS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO+K21LDpYVfDPs2Sqa13ZN+Ts		tS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO+K21LDpYVfDPs2Sqa13ZN+Ts
	/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0EmZf8T3ae/J1Jo6xGunecH1/G4		/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0EmZf8T3ae/J1Jo6xGunecH1/G4
	skipping to change at line 618 ¶		skipping to change at line 949 ¶
	0dL5f6ga4aPWLrWbbgWERFOoOPyh4DotlPF37AQOwiEjsbyyRHq3HgbWiaxQRuAh		0dL5f6ga4aPWLrWbbgWERFOoOPyh4DotlPF37AQOwiEjsbyyRHq3HgbWiaxQRuAh
	eqHOn4QVGY92/HFvJ7u3TcnQdLWhTe/lh1RHLNF3RnXtN9if9zC23laDZOiWZplU		eqHOn4QVGY92/HFvJ7u3TcnQdLWhTe/lh1RHLNF3RnXtN9if9zC23laDZOiWZplU
	yLrUiTCbHrtn1RppPDmLFNMt9dJ7KKgCkOi7Zm5nhqPChbywX13wcfYxVDAjBgkq		yLrUiTCbHrtn1RppPDmLFNMt9dJ7KKgCkOi7Zm5nhqPChbywX13wcfYxVDAjBgkq
	hkiG9w0BCRUxFgQUeVV0+dS25MICJChpmGc/8AoUwE0wLQYJKoZIhvcNAQkUMSAe		hkiG9w0BCRUxFgQUeVV0+dS25MICJChpmGc/8AoUwE0wLQYJKoZIhvcNAQkUMSAe
	HgBwADEAMgBGAHIAaQBlAG4AZABsAHkATgBhAG0AZTBeME4wCgYIKoUDBwEBAgME		HgBwADEAMgBGAHIAaQBlAG4AZABsAHkATgBhAG0AZTBeME4wCgYIKoUDBwEBAgME
	QAkBKw4ihn7pSIYTEhu0bcvTPZjI3WgVxCkUVlOsc80G69EKFEOTnObGJGSKJ51U		QAkBKw4ihn7pSIYTEhu0bcvTPZjI3WgVxCkUVlOsc80G69EKFEOTnObGJGSKJ51U
	KkOsXF0a7+VBZf3BcVVQh9UECIVEtO+VpuskAgIIAA==		KkOsXF0a7+VBZf3BcVVQh9UECIVEtO+VpuskAgIIAA==
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="PFX_ASN">		<section anchor="PFX_ASN">
	<name>PFX in ASN.1 format</name>		<name>PFX in ASN.1 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 characte
			rs 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 charact
			ers 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 characte
			rs 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 characte
			rs 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 characte
			rs 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 characte
			rs 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 charact
			ers longer than 72 characters:
			: 2A8FD988DD10DF2B984C77411E630B3B7E864AFF900DAF6
			C1484FE6A9C38C
			draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1098), 22 charact
			ers longer than 72 characters:
			: 06609FBEA513127EC2EBE59D2F4F0A17D656E82F765FFD5
			C9810BEFAFD0AE
			draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1099), 22 charact
			ers longer than 72 characters:
			: E293A1E08097A65721732D1D1A4FCCCC8B474550B9C0ADA
			74F1C10E242939
			draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1100), 22 charact
			ers longer than 72 characters:
			: 06F7184B173A03D7A761B6A5F4FBF75083D1BCA44E44CC2
			0486115CB9B502
			draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1101), 22 charact
			ers longer than 72 characters:
			: B733F64ECA56C4C9B8D32316BAFB110BAE4EBF340134903
			ADB2AE74CE9172
			draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1102), 22 charact
			ers longer than 72 characters:
			: AE9CE754F182ACE7488E9CA667135DBF0E3C6D9C6A4ED45
			50F1098013386A
			draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1103), 22 charact
			ers longer than 72 characters:
			: B3D29C070A55942C70FD2C86A32CC0761A104AC90C3ABA3
			22596D26CD13F9
			draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1107), 11 charact
			ers 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 characte
			rs longer than 72 characters:
			: 795574F9D4B6E4C20224286998673FF00A14C04D
			draft-pkcs12-gost-08.xml(1024): Warning: Too long line found (L1112), 13 charact
			ers 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 charact
			ers longer than 72 characters:
			: E9E1EDB62665DD9EF474C40F7DC90BB342E27CA7105E3A9B0B9B675942AB7
			71637B9CEA5B5BA4FFB54E71F57 -->
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	0 1323:SEQUENCE:		0 1323:SEQUENCE:
	4 1: INTEGER: 3		4 1: INTEGER: 3
	7 1220: SEQUENCE:		7 1220: SEQUENCE:
	11 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1]		11 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1]
	22 1205: CONTEXT SPECIFIC (0):		22 1205: CONTEXT SPECIFIC (0):
	26 1201: OCTET STRING:		26 1201: OCTET STRING:
	30 1197: SEQUENCE:		30 1197: SEQUENCE:
	34 716: SEQUENCE:		34 716: SEQUENCE:
	38 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1]		38 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1]
	skipping to change at line 823 ¶		skipping to change at line 1221 ¶
	1247 64: OCTET STRING:		1247 64: OCTET STRING:
	: 09012B0E22867EE9488613121BB46DCB		: 09012B0E22867EE9488613121BB46DCB
	: D33D98C8DD6815C429145653AC73CD06		: D33D98C8DD6815C429145653AC73CD06
	: EBD10A1443939CE6C624648A279D542A		: EBD10A1443939CE6C624648A279D542A
	: 43AC5C5D1AEFE54165FDC171555087D5		: 43AC5C5D1AEFE54165FDC171555087D5
	1313 8: OCTET STRING:'8544B4EF95A6EB24'		1313 8: OCTET STRING:'8544B4EF95A6EB24'
	1323 2: INTEGER:2048		1323 2: INTEGER:2048
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="Dec_key">		<section anchor="Dec_key">
	<name>Decrypted key value in BASE64 format</name>		<name>Decrypted Key Value in BASE64 Format</name>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	MIHiAgEBMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQRAEWkl+eblsHWs86SNgRKq		MIHiAgEBMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQRAEWkl+eblsHWs86SNgRKq
	SxMOgGhbvR/uZ5/WWfdNG1axvUwVhpcXIxDZUmzQuNzqJBkseI7f5/JjXyTFRF1a		SxMOgGhbvR/uZ5/WWfdNG1axvUwVhpcXIxDZUmzQuNzqJBkseI7f5/JjXyTFRF1a
	+YGBgQG0i7davCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO		+YGBgQG0i7davCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO
	+K21LDpYVfDPs2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0Em		+K21LDpYVfDPs2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0Em
	Zf8T3ae/J1Jo6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzg==		Zf8T3ae/J1Jo6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzg==
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="Dec_key_ASN">		<section anchor="Dec_key_ASN">
	<name>Decrypted key value in ASN.1 format</name>		<name>Decrypted Key Value in ASN.1 Format</name>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	0 226:SEQUENCE :		0 226:SEQUENCE :
	3 1: INTEGER : 1		3 1: INTEGER : 1
	6 23: SEQUENCE :		6 23: SEQUENCE :
	8 8: OBJECT IDENTIFIER : [1.2.643.7.1.1.1.2]		8 8: OBJECT IDENTIFIER : [1.2.643.7.1.1.1.2]
	18 11: SEQUENCE :		18 11: SEQUENCE :
	20 9: OBJECT IDENTIFIER : [1.2.643.7.1.2.1.2.1]		20 9: OBJECT IDENTIFIER : [1.2.643.7.1.2.1.2.1]
	31 64: OCTET STRING :		31 64: OCTET STRING :
	: 116925F9E6E5B075ACF3A48D8112AA4B130E80685BBD1FEE679FD6		: 116925F9E6E5B075ACF3A48D8112AA4B130E80685BBD1FEE679FD6
	: 59F74D1B56B1BD4C158697172310D9526CD0B8DCEA24192C788EDF		: 59F74D1B56B1BD4C158697172310D9526CD0B8DCEA24192C788EDF
	skipping to change at line 855 ¶		skipping to change at line 1253 ¶
	97 129: CONTEXT SPECIFIC (1) :		97 129: CONTEXT SPECIFIC (1) :
	: 01B48BB75ABC290E18655C62A14FB52D5F50844ECC1D1F6004487B		: 01B48BB75ABC290E18655C62A14FB52D5F50844ECC1D1F6004487B
	: 4B5C9534696AB7BFAB346E5516A9AB3CCEF8ADB52C3A5855F0CFB3		: 4B5C9534696AB7BFAB346E5516A9AB3CCEF8ADB52C3A5855F0CFB3
	: 64AA6B5DD937E4ECFC9525BF9F6A085076718A45C81FF4921E3E2B		: 64AA6B5DD937E4ECFC9525BF9F6A085076718A45C81FF4921E3E2B
	: BF72BF3EEBF3EE1613412665FF13DDA7BF275268EB11AE9DE707D7		: BF72BF3EEBF3EE1613412665FF13DDA7BF275268EB11AE9DE707D7
	: F1B884CB6CF4760B9F16F024330D546B881D5EA0CE		: F1B884CB6CF4760B9F16F024330D546B881D5EA0CE
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="PFXEncrypted">		<section anchor="PFXEncrypted">
	<name>The example of a PFX with a password-protected key and a passw		<name>Example of a PFX with a Password-Protected Key and a Password-
	ord-protected certificate.</name>		Protected Certificate</name>
	<t>In this example the PKCS8SHroudedKeybag structure is used to stor		<t>In this example, the PKCS8SHroudedKeybag structure is used to sto
	e the key, which is placed in the Data structure (see <xref target="RFC5652"/>).		re the key, which is placed in the Data structure (see <xref target="RFC5652"/>)
			.
	The certBag structure is used to store the certificate, which is pla ced in the EncryptedData structure (see <xref target="RFC5652"/>).		The certBag structure is used to store the certificate, which is pla ced in the EncryptedData structure (see <xref target="RFC5652"/>).
	A following password is used to encrypt the key and control the inte grity. The password is in hexadecimal.</t>		The following password is used to encrypt the key and provide integr ity control. The password is in hexadecimal.</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	0xD09FD0B0D180D0BED0BBD18C20D0B4D0BBD18F20504658		0xD09FD0B0D180D0BED0BBD18C20D0B4D0BBD18F20504658
	]]></sourcecode>		]]></sourcecode>
	<t>The key encryption algorithm identifier:</t>		<t>The key encryption algorithm identifier:</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	1.2.643.7.1.1.5.1.1		1.2.643.7.1.1.5.1.1
	]]></sourcecode>		]]></sourcecode>
	<t>The certificate encryption algorithm identifier:</t>		<t>The certificate encryption algorithm identifier:</t>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	1.2.643.7.1.1.5.1.2		1.2.643.7.1.1.5.1.2
	]]></sourcecode>		]]></sourcecode>
	<section anchor="PFX_BASE64_Ex2">		<section anchor="PFX_BASE64_Ex2">
	<name>PFX in BASE64 format</name>		<name>PFX in BASE64 Format</name>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	MIIFjAIBAzCCBSUGCSqGSIb3DQEHAaCCBRYEggUSMIIFDjCCA0EGCSqGSIb3DQEH		MIIFjAIBAzCCBSUGCSqGSIb3DQEHAaCCBRYEggUSMIIFDjCCA0EGCSqGSIb3DQEH
	BqCCAzIwggMuAgEAMIIDJwYJKoZIhvcNAQcBMFUGCSqGSIb3DQEFDTBIMCkGCSqG		BqCCAzIwggMuAgEAMIIDJwYJKoZIhvcNAQcBMFUGCSqGSIb3DQEFDTBIMCkGCSqG
	SIb3DQEFDDAcBAgUuSVGsSwGjQICCAAwDAYIKoUDBwEBBAIFADAbBgkqhQMHAQEF		SIb3DQEFDDAcBAgUuSVGsSwGjQICCAAwDAYIKoUDBwEBBAIFADAbBgkqhQMHAQEF
	AQIwDgQM9Hk3dagtS48+G/x+gIICwWGPqxxN+sTrKbruRf9R5Ya9cf5AtO1frqMn		AQIwDgQM9Hk3dagtS48+G/x+gIICwWGPqxxN+sTrKbruRf9R5Ya9cf5AtO1frqMn
	f1eULfmZmTg/BdE51QQ+Vbnh3v1kmspr6h2+e4Wli+ndEeCWG6A6X/G22h/RAHW2		f1eULfmZmTg/BdE51QQ+Vbnh3v1kmspr6h2+e4Wli+ndEeCWG6A6X/G22h/RAHW2
	YrVmf6cCWxW+YrqzT4h/8RQL/9haunD5LmHPLVsYrEai0OwbgXayDSwARVJQLQYq		YrVmf6cCWxW+YrqzT4h/8RQL/9haunD5LmHPLVsYrEai0OwbgXayDSwARVJQLQYq
	sLNmZK5ViN+fRiS5wszVJ3AtVq8EuPt41aQEKwPy2gmH4S6WmnQRC6W7aoqmIifF		sLNmZK5ViN+fRiS5wszVJ3AtVq8EuPt41aQEKwPy2gmH4S6WmnQRC6W7aoqmIifF
	PJENJNn5K2M1J6zNESs6bFtYNKMArNqtvv3rioY6eAaaLy6AV6ljsekmqodHmQjv		PJENJNn5K2M1J6zNESs6bFtYNKMArNqtvv3rioY6eAaaLy6AV6ljsekmqodHmQjv
	Y4eEioJs0xhpXhZY69PXT+ZBeHv6MSheBhwXqxAd1DqtPTafMjNK8rqKCap9TtPG		Y4eEioJs0xhpXhZY69PXT+ZBeHv6MSheBhwXqxAd1DqtPTafMjNK8rqKCap9TtPG
	skipping to change at line 907 ¶		skipping to change at line 1305 ¶
	kG9xhLFzoD16dhtqX0+/dQg9G8pE5EzCBIYRXLm1Arcz9k7KVsTJuNMjFrr7EQuu		kG9xhLFzoD16dhtqX0+/dQg9G8pE5EzCBIYRXLm1Arcz9k7KVsTJuNMjFrr7EQuu
	Tr80ATSQOtsq50zpFyrpznVPGCrOdIjpymZxNdvw48bZxqTtRVDxCYATOGqz0pwH		Tr80ATSQOtsq50zpFyrpznVPGCrOdIjpymZxNdvw48bZxqTtRVDxCYATOGqz0pwH
	ClWULHD9LIajLMB2GhBKyQw6ujIlltJs0T+WNdX/AT2FLi1LFSS3+Cj9MVQwIwYJ		ClWULHD9LIajLMB2GhBKyQw6ujIlltJs0T+WNdX/AT2FLi1LFSS3+Cj9MVQwIwYJ
	KoZIhvcNAQkVMRYEFHlVdPnUtuTCAiQoaZhnP/AKFMBNMC0GCSqGSIb3DQEJFDEg		KoZIhvcNAQkVMRYEFHlVdPnUtuTCAiQoaZhnP/AKFMBNMC0GCSqGSIb3DQEJFDEg
	Hh4AcAAxADIARgByAGkAZQBuAGQAbAB5AE4AYQBtAGUwXjBOMAoGCCqFAwcBAQID		Hh4AcAAxADIARgByAGkAZQBuAGQAbAB5AE4AYQBtAGUwXjBOMAoGCCqFAwcBAQID
	BEDp4e22JmXdnvR0xA99yQuzQuJ8pxBeOpsLm2dZQqt3Fje5zqW1uk/7VOcfV5r2		BEDp4e22JmXdnvR0xA99yQuzQuJ8pxBeOpsLm2dZQqt3Fje5zqW1uk/7VOcfV5r2
	bKm8nsLOs2rPT8hBOoeAZvOIBAjGIUHw6IjG2QICCAA=		bKm8nsLOs2rPT8hBOoeAZvOIBAjGIUHw6IjG2QICCAA=
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="PFX_ASN_Ex2">		<section anchor="PFX_ASN_Ex2">
	<name>PFX in ASN.1 format</name>		<name>PFX in ASN.1 Format</name>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	0 1420:SEQUENCE:		0 1420:SEQUENCE:
	4 1: INTEGER:3		4 1: INTEGER:3
	7 1317: SEQUENCE:		7 1317: SEQUENCE:
	11 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1]		11 9: OBJECT IDENTIFIER:data [1.2.840.113549.1.7.1]
	22 1302: CONTEXT SPECIFIC (0):		22 1302: CONTEXT SPECIFIC (0):
	26 1298: OCTET STRING:		26 1298: OCTET STRING:
	30 1294: SEQUENCE:		30 1294: SEQUENCE:
	34 833: SEQUENCE:		34 833: SEQUENCE:
	38 9: OBJECT IDENTIFIER:encryptedData [1.2.840.113549.1.7.6]		38 9: OBJECT IDENTIFIER:encryptedData [1.2.840.113549.1.7.6]
	skipping to change at line 1003 ¶		skipping to change at line 1401 ¶
	938 41: SEQUENCE:		938 41: SEQUENCE:
	940 9: OBJECT IDENTIFIER:[1.2.840.113549.1.5.12]		940 9: OBJECT IDENTIFIER:[1.2.840.113549.1.5.12]
	951 28: SEQUENCE:		951 28: SEQUENCE:
	953 8: OCTET STRING:		953 8: OCTET STRING:
	: FD04424D0ED6DC2F		: FD04424D0ED6DC2F
	963 2: INTEGER:2048		963 2: INTEGER:2048
	967 12: SEQUENCE:		967 12: SEQUENCE:
	969 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.4.2]		969 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.4.2]
	979 0: NULL:		979 0: NULL:
	981 27: SEQUENCE:		981 27: SEQUENCE:
	983 9: OBJECT IDENTIFIER:[1.2.643.7.1.1.5.1.1]		983 9: OBJECT IDENTIFIER:[1.2.643.7.1.1.5.1.1]
	994 14: SEQUENCE:		994 14: SEQUENCE:
	996 12: OCTET STRING:		996 12: OCTET STRING:
	: F0C52AA00000000000000000		: F0C52AA00000000000000000
	1010 229: OCTET STRING:		1010 229: OCTET STRING:
	: 2A8FD988DD10DF2B984C77411E630B3B7E864AFF900DAF6C14 84FE6A9C38C		: 2A8FD988DD10DF2B984C77411E630B3B7E864AFF900DAF6C14 84FE6A9C38C
	: 06609FBEA513127EC2EBE59D2F4F0A17D656E82F765FFD5C98 10BEFAFD0AE		: 06609FBEA513127EC2EBE59D2F4F0A17D656E82F765FFD5C98 10BEFAFD0AE
	: E293A1E08097A65721732D1D1A4FCCCC8B474550B9C0ADA74F 1C10E242939		: E293A1E08097A65721732D1D1A4FCCCC8B474550B9C0ADA74F 1C10E242939
	: 06F7184B173A03D7A761B6A5F4FBF75083D1BCA44E44CC2048 6115CB9B502		: 06F7184B173A03D7A761B6A5F4FBF75083D1BCA44E44CC2048 6115CB9B502
	: B733F64ECA56C4C9B8D32316BAFB110BAE4EBF340134903ADB 2AE74CE9172		: B733F64ECA56C4C9B8D32316BAFB110BAE4EBF340134903ADB 2AE74CE9172
	: AE9CE754F182ACE7488E9CA667135DBF0E3C6D9C6A4ED4550F 1098013386A		: AE9CE754F182ACE7488E9CA667135DBF0E3C6D9C6A4ED4550F 1098013386A
	skipping to change at line 1038 ¶		skipping to change at line 1436 ¶
	1332 10: SEQUENCE:		1332 10: SEQUENCE:
	1334 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.2.3]		1334 8: OBJECT IDENTIFIER:[1.2.643.7.1.1.2.3]
	1344 64: OCTET STRING:		1344 64: OCTET STRING:
	: E9E1EDB62665DD9EF474C40F7DC90BB342E27CA7105E3A9B0B9B675942AB7716 37B9CEA5B5BA4FFB54E71F57		: E9E1EDB62665DD9EF474C40F7DC90BB342E27CA7105E3A9B0B9B675942AB7716 37B9CEA5B5BA4FFB54E71F57
	: 9AF66CA9BC9EC2CEB36ACF4FC8413A878066F388		: 9AF66CA9BC9EC2CEB36ACF4FC8413A878066F388
	1410 8: OCTET STRING:'C62141F0E888C6D9'		1410 8: OCTET STRING:'C62141F0E888C6D9'
	1420 2: INTEGER:2048		1420 2: INTEGER:2048
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="Dec_key_Ex2">		<section anchor="Dec_key_Ex2">
	<name>Decrypted key value in BASE64 format</name>		<name>Decrypted Key Value in BASE64 Format</name>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	MIHiAgEBMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQRAEWkl+eblsHWs86SNgRKq		MIHiAgEBMBcGCCqFAwcBAQECMAsGCSqFAwcBAgECAQRAEWkl+eblsHWs86SNgRKq
	SxMOgGhbvR/uZ5/WWfdNG1axvUwVhpcXIxDZUmzQuNzqJBkseI7f5/JjXyTFRF1a		SxMOgGhbvR/uZ5/WWfdNG1axvUwVhpcXIxDZUmzQuNzqJBkseI7f5/JjXyTFRF1a
	+YGBgQG0i7davCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO		+YGBgQG0i7davCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO
	+K21LDpYVfDPs2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0Em		+K21LDpYVfDPs2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0Em
	Zf8T3ae/J1Jo6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzg==		Zf8T3ae/J1Jo6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzg==
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="Dec_key_ASN_Ex2">		<section anchor="Dec_key_ASN_Ex2">
	<name>Decrypted key value in ASN.1 format</name>		<name>Decrypted Key Value in ASN.1 Format</name>
	<sourcecode type="asn.1"><![CDATA[		<sourcecode type="asn.1"><![CDATA[
	0 226:SEQUENCE :		0 226:SEQUENCE :
	3 1: INTEGER : 1		3 1: INTEGER : 1
	6 23: SEQUENCE :		6 23: SEQUENCE :
	8 8: OBJECT IDENTIFIER : [1.2.643.7.1.1.1.2]		8 8: OBJECT IDENTIFIER : [1.2.643.7.1.1.1.2]
	18 11: SEQUENCE :		18 11: SEQUENCE :
	20 9: OBJECT IDENTIFIER : [1.2.643.7.1.2.1.2.1]		20 9: OBJECT IDENTIFIER : [1.2.643.7.1.2.1.2.1]
	31 64: OCTET STRING :		31 64: OCTET STRING :
	: 116925F9E6E5B075ACF3A48D8112AA4B130E80685BBD1FEE679FD6		: 116925F9E6E5B075ACF3A48D8112AA4B130E80685BBD1FEE679FD6
	: 59F74D1B56B1BD4C158697172310D9526CD0B8DCEA24192C788EDF		: 59F74D1B56B1BD4C158697172310D9526CD0B8DCEA24192C788EDF
	skipping to change at line 1072 ¶		skipping to change at line 1470 ¶
	: 4B5C9534696AB7BFAB346E5516A9AB3CCEF8ADB52C3A5855F0CFB3		: 4B5C9534696AB7BFAB346E5516A9AB3CCEF8ADB52C3A5855F0CFB3
	: 64AA6B5DD937E4ECFC9525BF9F6A085076718A45C81FF4921E3E2B		: 64AA6B5DD937E4ECFC9525BF9F6A085076718A45C81FF4921E3E2B
	: BF72BF3EEBF3EE1613412665FF13DDA7BF275268EB11AE9DE707D7		: BF72BF3EEBF3EE1613412665FF13DDA7BF275268EB11AE9DE707D7
	: F1B884CB6CF4760B9F16F024330D546B881D5EA0CE		: F1B884CB6CF4760B9F16F024330D546B881D5EA0CE
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="Acknowledgments" numbered="false">		<section anchor="Acknowledgments" numbered="false">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>The author thanks <contact fullname="Potashnikov Alexander"/>, <contact		<t>The author thanks <contact fullname="Potashnikov Alexander"/>, <contact
	fullname="Pianov Semen"/> and <contact fullname="Smyslov Valery"/> for their ca		fullname="Pianov Semen"/>, and <contact fullname="Smyslov Valery"/> for their c
	reful readings and useful comments.</t>		areful readings and useful 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>		</section>
	</back> </rfc>		</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>
End of changes. 98 change blocks.
	349 lines changed or deleted		790 lines changed or added
This html diff was produced by rfcdiff 1.48.