rfc9629.original.xml		rfc9629.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<!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;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.5 (Ruby 3.0.2		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	) -->		-ietf-lamps-cms-kemri-08" number="9629" category="std" consensus="true" submissi
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft		onType="IETF" obsoletes="" updates="5652" tocInclude="true" sortRefs="true" symR
	-ietf-lamps-cms-kemri-08" category="std" consensus="true" submissionType="IETF"		efs="true" version="3" xml:lang="en">
	updates="5652" tocInclude="true" sortRefs="true" symRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.19.3 -->
	<front>		<front>
	<title abbrev="CMS KEMRecipientInfo">Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)</title>		<title abbrev="CMS KEMRecipientInfo">Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-kemri-08"/>		<seriesInfo name="RFC" value="9629"/>
	<author fullname="Russ Housley">		<author fullname="Russ Housley">
	<organization abbrev="Vigil Security">Vigil Security, LLC</organization>		<organization abbrev="Vigil Security">Vigil Security, LLC</organization>
	<address>		<address>
	<postal>		<postal>
	<city>Herndon, VA</city>		<city>Herndon</city>
	<country>US</country>		<region>VA</region>
			<country>United States of America</country>
	</postal>		</postal>
	<email>housley@vigilsec.com</email>		<email>housley@vigilsec.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="John Gray">		<author fullname="John Gray">
	<organization>Entrust</organization>		<organization>Entrust</organization>
	<address>		<address>
	<postal>		<postal>
	<city>Minneapolis, MN</city>		<city>Minneapolis</city>
	<country>US</country>		<region>MN</region>
			<country>United States of America</country>
	</postal>		</postal>
	<email>john.gray@entrust.com</email>		<email>john.gray@entrust.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="大久保　智史" asciiFullname="Tomofumi Okubo">		<author fullname="大久保　智史" asciiFullname="Tomofumi Okubo">
	<organization abbrev="DigiCert">DigiCert, Inc.</organization>		<organization>Penguin Securities Pte. Ltd.</organization>
	<address>		<address>
	<postal>		<postal>
	<city>Fairfax, VA</city>		<country>Singapore</country>
	<country>US</country>
	</postal>		</postal>
	<email>tomofumi.okubo+ietf@gmail.com</email>		<email>tomofumi.okubo+ietf@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2024" month="February" day="06"/>		<date year="2024" month="August"/>
	<area>Security</area>		<area>SEC</area>
	<workgroup>LAMPS Working Group</workgroup>		<workgroup>lamps</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>		<keyword>kemri</keyword>
	<?line 82?>		<keyword>KEMRecipientInfo</keyword>
			<abstract>
	<t>The Cryptographic Message Syntax (CMS) supports key transport and		<t>The Cryptographic Message Syntax (CMS) supports key transport and
	key agreement algorithms. In recent years, cryptographers have been		key agreement algorithms. In recent years, cryptographers have been
	specifying Key Encapsulation Mechanism (KEM) algorithms, including		specifying Key Encapsulation Mechanism (KEM) algorithms, including
	quantum-secure KEM algorithms. This document defines conventions for		quantum-secure KEM algorithms. This document defines conventions for
	the use of KEM algorithms by the originator and recipients to encrypt		the use of KEM algorithms by the originator and recipients to encrypt
	and decrypt CMS content. This document updates RFC 5652.</t>		and decrypt CMS content. This document updates RFC 5652.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<?line 91?>
	<section anchor="intro">		<section anchor="intro">
	<name>Introduction</name>		<name>Introduction</name>
	<t>This document updates the The Cryptographic Message Syntax (CMS) <xref		<t>This document updates "<xref target="RFC5652" format="title"/>" <xref t
	target="RFC5652"/>.</t>		arget="RFC5652" format="default"/>.</t>
	<t>The Cryptographic Message Syntax (CMS) enveloped-data content type		<t>The CMS enveloped-data content type
	<xref target="RFC5652"/> and the CMS authenticated-enveloped-data content type		<xref target="RFC5652"/> and the CMS authenticated-enveloped-data content type
	<xref target="RFC5083"/> support both key transport and key agreement algorithms to		<xref target="RFC5083"/> support both key transport and key agreement algorithms to
	establish the key used to encrypt and decrypt the content. In recent		establish the key used to encrypt and decrypt the content. In recent
	years, cryptographers have been specifying Key Encapsulation Mechanism		years, cryptographers have been specifying Key Encapsulation Mechanism
	(KEM) algorithms, including quantum-secure KEM algorithms. This document		(KEM) algorithms, including quantum-secure KEM algorithms. This document
	defines conventions for the use of KEM algorithms for the CMS		defines conventions for the use of KEM algorithms for the CMS
	enveloped-data content type and the CMS authenticated-enveloped-data		enveloped-data content type and the CMS authenticated-enveloped-data
	content type.</t>		content type.</t>
	<t>A KEM algorithm is a one-pass (store-and-forward) mechanism for		<t>A KEM algorithm is a one-pass (store-and-forward) mechanism for
	transporting random keying material to a recipient using the recipient's		transporting random keying material to a recipient using the recipient's
	public key. This means that the originator and the recipients do not need		public key. This means that the originator and the recipients do not need
	to be online at the same time. The recipient's private key is needed to		to be online at the same time. The recipient's private key is needed to
	recover the random keying material, which is then treated as a pairwise		recover the random keying material, which is then treated as a pairwise
	shared secret (ss) between the originator and recipient.</t>		shared secret (ss) between the originator and recipient.</t>
	<t>The KEMRecipientInfo structure defined in this document uses the pairwi se		<t>The KEMRecipientInfo structure defined in this document uses the pairwi se
	shared secret as an input to a key derivation function (KDF) to produce a		shared secret as an input to a key derivation function (KDF) to produce a
	pairwise key-encryption key (KEK). Then, the pairwise KEK is used to encrypt a		pairwise key-encryption key (KEK). Then, the pairwise KEK is used to encrypt a
	content-encryption key (CEK) or a content-authenticated-encryption key (CAEK)		content-encryption key (CEK) or a content-authenticated-encryption key (CAEK)
	for that recipient. All of the recipients recieve the same CEK or CAEK.</t>		for that recipient. All of the recipients receive the same CEK or CAEK.</t>
	<t>In this environment, security depends on three things. First, the KEM algorithm		<t>In this environment, security depends on three things. First, the KEM algorithm
	must be secure against adaptive chosen ciphertext attacks. Second, the		must be secure against adaptive chosen ciphertext attacks. Second, the
	key-encryption algorithm must provide confidentiality and integrity protection. Third,		key-encryption algorithm must provide confidentiality and integrity protection. Third,
	the choices of the KDF and the key-encryption algorithm need to provide the same		the choices of the KDF and the key-encryption algorithm need to provide the same
	level of security as the KEM algorithm.</t>		level of security as the KEM algorithm.</t>
	<t>A KEM algorithm provides three functions:</t>		<t>A KEM algorithm provides three functions:</t>
	<ul spacing="normal">		<dl spacing="normal" newline="true">
	<li>		<dt>KeyGen() -&gt; (pk, sk):</dt>
	<t>KeyGen() -&gt; (pk, sk):</t>		<dd>Generate the public key (pk) and a private key (sk).</dd>
	</li>		<dt>Encapsulate(pk) -&gt; (ct, ss):</dt>
	</ul>		<dd>Given the recipient's public key (pk), produce a ciphertext (ct) t
	<ul empty="true">		o be
	<li>		passed to the recipient and shared secret (ss) for the originator.</dd>
	<t>Generate the public key (pk) and a private key (sk).</t>		<dt>Decapsulate(sk, ct) -&gt; ss:</dt>
	</li>		<dd>Given the private key (sk) and the ciphertext (ct), produce the
	</ul>		shared secret (ss) for the recipient.</dd>
	<ul spacing="normal">		</dl>
	<li>
	<t>Encapsulate(pk) -&gt; (ct, ss):</t>
	</li>
	</ul>
	<ul empty="true">
	<li>
	<t>Given the recipient's public key (pk), produce a ciphertext (ct) to
	be
	passed to the recipient and shared secret (ss) for the originator.</t>
	</li>
	</ul>
	<ul spacing="normal">
	<li>
	<t>Decapsulate(sk, ct) -&gt; ss:</t>
	</li>
	</ul>
	<ul empty="true">
	<li>
	<t>Given the private key (sk) and the ciphertext (ct), produce the
	shared secret (ss) for the recipient.</t>
	</li>
	</ul>
	<t>To support a particular KEM algorithm, the CMS originator <bcp14>MUST</ bcp14> implement		<t>To support a particular KEM algorithm, the CMS originator <bcp14>MUST</ bcp14> implement
	the KEM Encapsulate() function.</t>		the KEM Encapsulate() function.</t>
	<t>To support a particular KEM algorithm, the CMS recipient <bcp14>MUST</b cp14> implement the KEM		<t>To support a particular KEM algorithm, the CMS recipient <bcp14>MUST</b cp14> implement the KEM
	KeyGen() function and the KEM Decapsulate() function. The recipient's public ke y		KeyGen() function and the KEM Decapsulate() function. The recipient's public ke y
	is usually carried in a certificate <xref target="RFC5280"/>.</t>		is usually carried in a certificate <xref target="RFC5280"/>.</t>
	<section anchor="terms">		<section anchor="terms">
	<name>Terminology</name>		<name>Terminology</name>
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",		"<bcp14>SHOULD NOT</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	nterpreted as		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and		are to be interpreted as described in BCP&nbsp;14
	only when, they		<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
	appear in all capitals, as shown here.</t>		when, they appear in all capitals, as shown here.</t>
	<?line -18?>
	</section>		</section>
	<section anchor="asn1">		<section anchor="asn1">
	<name>ASN.1</name>		<name>ASN.1</name>
	<t>CMS values are generated using ASN.1 <xref target="X.680"/>, which us es the Basic		<t>CMS values are generated using ASN.1 <xref target="X.680"/>, which us es the Basic
	Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X. 690"/>.</t>		Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X. 690"/>.</t>
	</section>		</section>
	<section anchor="cms-version-numbers">		<section anchor="cms-version-numbers">
	<name>CMS Version Numbers</name>		<name>CMS Version Numbers</name>
	<t>As described in <xref section="1.3" sectionFormat="of" target="RFC565 2"/>, the major data structures		<t>As described in <xref section="1.3" sectionFormat="of" target="RFC565 2"/>, the major data structures
	include a version number as the first item in		include a version number as the first item in
	the data structure. The version number is intended to avoid ASN.1 decode		the data structure. The version number is intended to avoid ASN.1 decode
	errors. Some implementations do not check the version number prior to		errors. Some implementations do not check the version number prior to
	attempting a decode, and then if a decode error occurs, the version		attempting a decode, and then if a decode error occurs, the version
	number is checked as part of the error handling routine. This is a		number is checked as part of the error-handling routine. This is a
	reasonable approach; it places error processing outside of the fast path.		reasonable approach; it places error processing outside of the fast path.
	This approach is also forgiving when an incorrect version number is used		This approach is also forgiving when an incorrect version number is used
	by the originator.</t>		by the originator.</t>
	<t>Whenever the structure is updated, a higher version number will be		<t>Whenever the structure is updated, a higher version number will be
	assigned. However, to ensure maximum interoperability, the higher		assigned. However, to ensure maximum interoperability, the higher
	version number is only used when the new syntax feature is employed. That		version number is only used when the new syntax feature is employed. That
	is, the lowest version number that supports the generated syntax is used.</t>		is, the lowest version number that supports the generated syntax is used.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="kem-processing-overview">		<section anchor="kem-processing-overview">
	<name>KEM Processing Overview</name>		<name>KEM Processing Overview</name>
	<t>KEM algorithms can be used with three CMS content types: the		<t>KEM algorithms can be used with three CMS content types: the
	enveloped-data content type <xref target="RFC5652"/>, the authenticated-data		enveloped-data content type <xref target="RFC5652"/>, the authenticated-data
	content type <xref target="RFC5652"/>, or the authenticated-enveloped-data		content type <xref target="RFC5652"/>, or the authenticated-enveloped-data
	content type <xref target="RFC5083"/>. For simplicity, the terminology associat ed		content type <xref target="RFC5083"/>. For simplicity, the terminology associat ed
	with the enveloped-data content type will be used in this overview.</t>		with the enveloped-data content type will be used in this overview.</t>
	<t>The originator randomly generates the CEK (or the CAEK), and then		<t>The originator randomly generates the CEK (or the CAEK), and then
	all recipients obtain that key as an encrypted object within the KEMRecipientInf o		all recipients obtain that key as an encrypted object within the KEMRecipientInf o
	encryptedKey field explained in <xref target="kemri"/>. All recipients use		encryptedKey field explained in <xref target="kemri"/>. All recipients use
	the originator-generated symmetric key to decrypt the CMS message.</t>		the originator-generated symmetric key to decrypt the CMS message.</t>
	<t>A KEM algorithm and a key-derivation function are used to securely		<t>A KEM algorithm and a key derivation function are used to securely
	establish a pairwise symmetric key-encryption key (KEK), which is used to encryp		establish a pairwise symmetric KEK, which is used to encrypt
	t
	the originator-generated CEK (or the CAEK).</t>		the originator-generated CEK (or the CAEK).</t>
	<t>In advance, each recipient uses the KEM KeyGen() function to create a k ey pair.		<t>In advance, each recipient uses the KEM KeyGen() function to create a k ey pair.
	The recipient will often obtain a certificate <xref target="RFC5280"/> that incl udes the newly		The recipient will often obtain a certificate <xref target="RFC5280"/> that incl udes the newly
	generated public key. Whether the public key is certified or not, the newly		generated public key. Whether the public key is certified or not, the newly
	generated public key is made available to potential originators.</t>		generated public key is made available to potential originators.</t>
	<t>The originator establishes the CEK (or the CAEK) using these steps:</t>		<t>The originator establishes the CEK (or the CAEK) using these steps:</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	<t>The CEK (or the CAEK) is generated at random.</t>		<t>The CEK (or the CAEK) is generated at random.</t>
	</li>		</li>
	<li>		<li>
	<t>For each recipient: </t>		<t>For each recipient: </t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>The recipient's public key is used with the KEM Encapsulate() f unction to obtain a pairwise shared secret (ss) and the ciphertext for the recip ient.</t>		<t>The recipient's public key is used with the KEM Encapsulate() f unction to obtain a pairwise shared secret (ss) and the ciphertext for the recip ient.</t>
	</li>		</li>
	<li>		<li>
	<t>The key-derivation function is used to derive a pairwise symmet ric KEK, from the pairwise ss and other data that is optionally sent in the ukm field.</t>		<t>The key derivation function is used to derive a pairwise symmet ric KEK, from the pairwise ss and other data that is optionally sent in the ukm field.</t>
	</li>		</li>
	<li>		<li>
	<t>The KEK is used to encrypt the CEK for this recipient.</t>		<t>The KEK is used to encrypt the CEK for this recipient.</t>
	</li>		</li>
	</ul>		</ul>
	</li>		</li>
	<li>		<li>
	<t>The CEK (or the CAEK) is used to encrypt the content for all recipi ents.</t>		<t>The CEK (or the CAEK) is used to encrypt the content for all recipi ents.</t>
	</li>		</li>
	</ol>		</ol>
	<t>The recipient obtains the CEK (or the CAEK) using these steps:</t>		<t>The recipient obtains the CEK (or the CAEK) using these steps:</t>
	<ol spacing="normal" type="1"><li>		<ol spacing="normal" type="1"><li>
	<t>The recipient's private key and the ciphertext are used with the KE M Decapsulate() function to obtain a pairwise ss.</t>		<t>The recipient's private key and the ciphertext are used with the KE M Decapsulate() function to obtain a pairwise ss.</t>
	</li>		</li>
	<li>		<li>
	<t>The key-derivation function is used to derive a pairwise symmetric KEK, from the pairwise ss and other data that is optionally sent in the ukm fiel d.</t>		<t>The key derivation function is used to derive a pairwise symmetric KEK, from the pairwise ss and other data that is optionally sent in the ukm fiel d.</t>
	</li>		</li>
	<li>		<li>
	<t>The KEK is used to decrypt the CEK (or the CAEK) .</t>		<t>The KEK is used to decrypt the CEK (or the CAEK).</t>
	</li>		</li>
	<li>		<li>
	<t>The CEK (or the CAEK) is used to decrypt the content.</t>		<t>The CEK (or the CAEK) is used to decrypt the content.</t>
	</li>		</li>
	</ol>		</ol>
	</section>		</section>
	<section anchor="kemri">		<section anchor="kemri">
	<name>KEM Recipient Information</name>		<name>KEM Recipient Information</name>
	<t>This document defines KEMRecipientInfo for use with KEM algorithms.		<t>This document defines KEMRecipientInfo for use with KEM algorithms.
	As specified in Section 6.2.5 of <xref target="RFC5652"/>, recipient information		As specified in <xref target="RFC5652" sectionFormat="of" section="6.2.5"/>,
	for		recipient information for
	additional key management techniques are represented in the		additional key management techniques is represented in the
	OtherRecipientInfo type, and they are each identified by a unique		OtherRecipientInfo type. Each key management technique is identified by a unique
	ASN.1 object identifier.</t>		ASN.1 object identifier.</t>
	<t>The object identifier associated with KEMRecipientInfo is:</t>		<t>The object identifier associated with KEMRecipientInfo is:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)		id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
	rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }		rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 }
	id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 }		id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 }
	]]></artwork>		]]></artwork>
	<t>The KEMRecipientInfo type is:</t>		<t>The KEMRecipientInfo type is:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	skipping to change at line 244 ¶		skipping to change at line 226 ¶
	rid RecipientIdentifier,		rid RecipientIdentifier,
	kem KEMAlgorithmIdentifier,		kem KEMAlgorithmIdentifier,
	kemct OCTET STRING,		kemct OCTET STRING,
	kdf KeyDerivationAlgorithmIdentifier,		kdf KeyDerivationAlgorithmIdentifier,
	kekLength INTEGER (1..65535),		kekLength INTEGER (1..65535),
	ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL,		ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL,
	wrap KeyEncryptionAlgorithmIdentifier,		wrap KeyEncryptionAlgorithmIdentifier,
	encryptedKey EncryptedKey }		encryptedKey EncryptedKey }
	]]></artwork>		]]></artwork>
	<t>The fields of the KEMRecipientInfo type have the following meanings:</t >		<t>The fields of the KEMRecipientInfo type have the following meanings:</t >
	<ul empty="true">		<t indent="3">version is the syntax version number. The version <bcp1
	<li>		4>MUST</bcp14> be 0. The
	<t>version is the syntax version number. The version <bcp14>MUST</bcp		CMSVersion type is described in <xref target="RFC5652" sectionFormat="of" sectio
	14> be 0. The		n="10.2.5"/>.</t>
	CMSVersion type is described in Section 10.2.5 of <xref target="RFC5652"/>.</t>		<t indent="3">rid specifies the recipient's certificate or key that wa
	</li>		s used by
	</ul>
	<ul empty="true">
	<li>
	<t>rid specifies the recipient's certificate or key that was used by
	the originator with the KEM Encapsulate() function. The		the originator with the KEM Encapsulate() function. The
	RecipientIdentifier provides two alternatives for specifying the		RecipientIdentifier provides two alternatives for specifying the
	recipient's certificate <xref target="RFC5280"/>, and thereby the recipient's pu blic		recipient's certificate <xref target="RFC5280"/>, and thereby the recipient's pu blic
	key. The recipient's certificate <bcp14>MUST</bcp14> contain a KEM public key. Therefore,		key. The recipient's certificate <bcp14>MUST</bcp14> contain a KEM public key. Therefore,
	a recipient X.509 version 3 certificate that contains a key usage		a recipient X.509 version 3 certificate that contains a key usage
	extension <bcp14>MUST</bcp14> assert the keyEncipherment bit. The issuerAndSeri alNumber		extension <bcp14>MUST</bcp14> assert the keyEncipherment bit. The issuerAndSeri alNumber
	alternative identifies the recipient's certificate by the issuer's		alternative identifies the recipient's certificate by the issuer's
	distinguished name and the certificate serial number; the		distinguished name and the certificate serial number; the
	subjectKeyIdentifier alternative identifies the recipient's certificate by a key		subjectKeyIdentifier alternative identifies the recipient's certificate by a key
	identifier. When an X.509 certificate is referenced, the key identifier		identifier. When an X.509 certificate is referenced, the key identifier
	matches the X.509 subjectKeyIdentifier extension value. When other		matches the X.509 subjectKeyIdentifier extension value. When other
	certificate formats are referenced, the documents that specify the certificate		certificate formats are referenced, the documents that specify the certificate
	format and their use with the CMS must include details on matching		format and their use with the CMS must include details on matching
	the key identifier to the appropriate certificate field. For recipient		the key identifier to the appropriate certificate field. For recipient
	processing, implementations <bcp14>MUST</bcp14> support both of these alternativ es for		processing, implementations <bcp14>MUST</bcp14> support both of these alternativ es for
	specifying the recipient's certificate. For originator processing,		specifying the recipient's certificate. For originator processing,
	implementations <bcp14>MUST</bcp14> support at least one of these alternatives.< /t>		implementations <bcp14>MUST</bcp14> support at least one of these alternatives.< /t>
	</li>		<t indent="3">kem identifies the KEM algorithm, and any associated par
	</ul>		ameters, used
	<ul empty="true">
	<li>
	<t>kem identifies the KEM algorithm, and any associated parameters, us
	ed
	by the originator. The KEMAlgorithmIdentifier is described in <xref target="kem alg"/>.</t>		by the originator. The KEMAlgorithmIdentifier is described in <xref target="kem alg"/>.</t>
	</li>		<t indent="3">kemct is the ciphertext produced by the KEM Encapsulate(
	</ul>		) function for
	<ul empty="true">
	<li>
	<t>kemct is the ciphertext produced by the KEM Encapsulate() function
	for
	this recipient.</t>		this recipient.</t>
	</li>		<t indent="3">kdf identifies the key derivation function, and any asso
	</ul>		ciated parameters,
	<ul empty="true">
	<li>
	<t>kdf identifies the key-derivation algorithm, and any associated par
	ameters,
	used by the originator to generate the KEK. The		used by the originator to generate the KEK. The
	KeyDerivationAlgorithmIdentifier is described in Section 10.1.6 of <xref target=		KeyDerivationAlgorithmIdentifier is described in <xref target="RFC5652" sectionF
	"RFC5652"/>.</t>		ormat="of" section="10.1.6"/>.</t>
	</li>		<t indent="3">kekLength is the size of the KEK in octets. This value
	</ul>		is one
	<ul empty="true">		of the inputs to the key derivation function. The upper bound on the integer
	<li>
	<t>kekLength is the size of the KEK in octets. This value is one
	of the inputs to the key-derivation function. The upper bound on the integer
	value is provided to make it clear to implementers that support for very		value is provided to make it clear to implementers that support for very
	large integer values is not needed. Implementations <bcp14>MUST</bcp14> confirm that		large integer values is not needed. Implementations <bcp14>MUST</bcp14> confirm that
	the value provided is consistent with the key-encryption algorithm		the value provided is consistent with the key-encryption algorithm
	identified in the wrap field below.</t>		identified in the wrap field below.</t>
	</li>		<t indent="3">ukm is optional user keying material. When the ukm valu
	</ul>		e is provided,
	<ul empty="true">
	<li>
	<t>ukm is optional user keying material. When the ukm value is provid
	ed,
	it is used as part of the info structure described in <xref target="kdf"/> to		it is used as part of the info structure described in <xref target="kdf"/> to
	provide a context input to the key-derivation function. For example, the		provide a context input to the key derivation function. For example, the
	ukm value could include a nonce, application-specific context information,		ukm value could include a nonce, application-specific context information,
	or an identifier for the originator. A KEM algorithm may place		or an identifier for the originator. A KEM algorithm may place
	requirements on the ukm value. Implementations that do not support the		requirements on the ukm value. Implementations that do not support the
	ukm field <bcp14>SHOULD</bcp14> gracefully discontinue processing when the ukm f ield is		ukm field <bcp14>SHOULD</bcp14> gracefully discontinue processing when the ukm f ield is
	present. Note that this requirement expands the original purpose of the		present. Note that this requirement expands the original purpose of the
	ukm described in Section 10.2.6 of <xref target="RFC5652"/>; it is not limited t o being		ukm described in <xref target="RFC5652" sectionFormat="of" section="10.2.6"/>; i t is not limited to being
	used with key agreement algorithms.</t>		used with key agreement algorithms.</t>
	</li>		<t indent="3">wrap identifies a key-encryption algorithm used to encry
	</ul>		pt the
	<ul empty="true">
	<li>
	<t>wrap identifies a key-encryption algorithm used to encrypt the
	CEK. The KeyEncryptionAlgorithmIdentifier		CEK. The KeyEncryptionAlgorithmIdentifier
	is described in Section 10.1.3 of <xref target="RFC5652"/>.</t>		is described in <xref target="RFC5652" sectionFormat="of" section="10.1.3"/>.</t
	</li>		>
	</ul>		<t indent="3">encryptedKey is the result of encrypting the CEK or the
	<ul empty="true">		CAEK (the content-authenticated-encryption key, as discussed in <xref target="RF
	<li>		C5083"/>) with the KEK.
	<t>encryptedKey is the result of encrypting the CEK or the
	content-authenticated-encryption key <xref target="RFC5083"/> (CAEK) with the KE
	K.
	EncryptedKey is an OCTET STRING.</t>		EncryptedKey is an OCTET STRING.</t>
	</li>
	</ul>
	</section>		</section>
	<section anchor="kemalg">		<section anchor="kemalg">
	<name>KEM Algorithm Identifier</name>		<name>KEM Algorithm Identifier</name>
	<t>The KEMAlgorithmIdentifier type identifies a KEM algorithm used to		<t>The KEMAlgorithmIdentifier type identifies a KEM algorithm used to
	establish a pairwise ss. The details of establishment depend on		establish a pairwise ss. The details of establishment depend on
	the KEM algorithm used. A Key derivation algorithm is used to transform		the KEM algorithm used. A key derivation function is used to transform
	the pairwise ss value into a KEK.</t>		the pairwise ss value into a KEK.</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	KEMAlgorithmIdentifier ::= AlgorithmIdentifier{ KEM-ALGORITHM, {...} }		KEMAlgorithmIdentifier ::= AlgorithmIdentifier{ KEM-ALGORITHM, {...} }
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="kdf">		<section anchor="kdf">
	<name>Key Derivation</name>		<name>Key Derivation</name>
	<t>This section describes the conventions of using the KDF to compute the		<t>This section describes the conventions of using the KDF to compute the
	KEK for KEMRecipientInfo. For simplicity, the		KEK for KEMRecipientInfo. For simplicity, the
	terminology used in the HKDF specification <xref target="RFC5869"/> is used here .</t>		terminology used in the HKDF specification <xref target="RFC5869"/> is used here .</t>
	<t>Many KDFs internally employ a one-way hash function. When this is		<t>Many KDFs internally employ a one-way hash function. When this is
	the case, the hash function that is used is indirectly indicated by		the case, the hash function that is used is indirectly indicated by
	the KeyDerivationAlgorithmIdentifier. Other KDFs internally employ an		the KeyDerivationAlgorithmIdentifier. Other KDFs internally employ an
	encryption algorithm. When this is the case, the encryption that is		encryption algorithm. When this is the case, the encryption that is
	used is indirectly indicated by the KeyDerivationAlgorithmIdentifier.</t>		used is indirectly indicated by the KeyDerivationAlgorithmIdentifier.</t>
	<t>The KDF inputs are:</t>		<t>The KDF inputs are as follows:</t>
	<ul empty="true">		<t indent="3">IKM is the input keying material. It is a symmetric secr
	<li>		et input to
	<t>IKM is the input key material. It is a symmetric secret input to		the KDF. The KDF may use a hash function or an encryption algorithm
	the KDF which may use a hash function or an encryption algorithm
	to generate a pseudorandom key. The algorithm used to derive the		to generate a pseudorandom key. The algorithm used to derive the
	IKM is dependent on the algorithm identified in the		IKM is dependent on the algorithm identified in the
	KeyDerivationAlgorithmIdentifier.</t>		KeyDerivationAlgorithmIdentifier.</t>
	</li>		<t indent="3">L is the length of the output keying material in octets.
	</ul>		L is
	<ul empty="true">
	<li>
	<t>L is the length of the output keying material in octets which is
	identified in the kekLength of the KEMRecipientInfo. The		identified in the kekLength of the KEMRecipientInfo. The
	value is dependent on the key-encryption algorithm that is used		value is dependent on the key-encryption algorithm used;
	which is identified in the KeyEncryptionAlgorithmIdentifier.</t>		the key-encryption algorithm is identified in the KeyEncryptionAlgorithmIdentifi
	</li>		er.</t>
	</ul>		<t indent="3">info is contextual input to the KDF. The DER-encoded
	<ul empty="true">
	<li>
	<t>info is contextual input to the KDF. The DER-encoded
	CMSORIforKEMOtherInfo structure is created from elements of the		CMSORIforKEMOtherInfo structure is created from elements of the
	KEMRecipientInfo structure. CMSORIforKEMOtherInfo is defined as:</t>		KEMRecipientInfo structure. CMSORIforKEMOtherInfo is defined as:</t>
	</li>
	</ul>
	<artwork><![CDATA[		<artwork><![CDATA[
	CMSORIforKEMOtherInfo ::= SEQUENCE {		CMSORIforKEMOtherInfo ::= SEQUENCE {
	wrap KeyEncryptionAlgorithmIdentifier,		wrap KeyEncryptionAlgorithmIdentifier,
	kekLength INTEGER (1..65535),		kekLength INTEGER (1..65535),
	ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }		ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
	]]></artwork>		]]></artwork>
	<t>The CMSORIforKEMOtherInfo structure contains:</t>		<t>The CMSORIforKEMOtherInfo structure contains the following:</t>
	<ul empty="true">		<t indent="3">wrap identifies a key-encryption algorithm; the output o
	<li>		f the
	<t>wrap identifies a key-encryption algorithm; the output of the		key derivation function will be used as a key for this algorithm.</t>
	key-derivation function will be used as a key for this algorithm.</t>		<t indent="3">kekLength is the length of the KEK in octets; the
	</li>		output of the key derivation function will be exactly this size.</t>
	</ul>		<t indent="3">ukm is optional user keying material; see <xref target="
	<ul empty="true">		kemri"/>.</t>
	<li>		<t>The KDF output is as follows:</t>
	<t>kekLength is the length of the KEK in octets; the		<t indent="3">OKM is the output keying material with the exact length
	output of the key-derivation function will be exactly this size.</t>		of L octets.
	</li>
	</ul>
	<ul empty="true">
	<li>
	<t>ukm is optional user keying material; see <xref target="kemri"/>.</
	t>
	</li>
	</ul>
	<t>The KDF output is:</t>
	<ul empty="true">
	<li>
	<t>OKM is the output keying material with the exact length of L octets
	.
	The OKM is the KEK that is used to encrypt the CEK or the CAEK.</t>		The OKM is the KEK that is used to encrypt the CEK or the CAEK.</t>
	</li>
	</ul>
	<t>An acceptable KDF <bcp14>MUST</bcp14> accept an IKM, L, and info as inp uts. An acceptable		<t>An acceptable KDF <bcp14>MUST</bcp14> accept an IKM, L, and info as inp uts. An acceptable
	KDF <bcp14>MAY</bcp14> also accept a salt input value, which is carried as a par ameter to		KDF <bcp14>MAY</bcp14> also accept a salt input value, which is carried as a par ameter to
	the KeyDerivationAlgorithmIdentifier if present. All of these		the KeyDerivationAlgorithmIdentifier if present. All of these
	inputs <bcp14>MUST</bcp14> influence the output of the KDF.</t>		inputs <bcp14>MUST</bcp14> influence the output of the KDF.</t>
	</section>		</section>
	<section anchor="asn1-mod">		<section anchor="asn1-mod">
	<name>ASN.1 Modules</name>		<name>ASN.1 Modules</name>
	<t>This section provides two ASN.1 modules <xref target="X.680"/>. The fi rst ASN.1		<t>This section provides two ASN.1 modules <xref target="X.680"/>. The fi rst ASN.1
	module is an extension to the AlgorithmInformation-2009 module in		module is an extension to the AlgorithmInformation-2009 module discussed in
	<xref target="RFC5912"/>, and it defines the KEM-ALGORITHM CLASS. The second		<xref target="RFC5912"/>; it defines the KEM-ALGORITHM CLASS. The second
	ASN.1 module defines the structures needed to use KEM Algorithms		ASN.1 module defines the structures needed to use KEM algorithms
	with CMS <xref target="RFC5652"/>.</t>		with CMS <xref target="RFC5652"/>.</t>
	<t>The first ASN.1 module uses EXPLICIT tagging, and the second		<t>The first ASN.1 module uses EXPLICIT tagging, and the second
	ASN.1 module uses IMPLICIT tagging.</t>		ASN.1 module uses IMPLICIT tagging.</t>
	<t>Both ASN.1 modules follow the conventions established in		<t>Both ASN.1 modules follow the conventions established in
	<xref target="RFC5911"/>, <xref target="RFC5912"/>, and <xref target="RFC6268"/> .</t>		<xref target="RFC5911"/>, <xref target="RFC5912"/>, and <xref target="RFC6268"/> .</t>
	<section anchor="asn1-mod-1">		<section anchor="asn1-mod-1">
	<name>KEMAlgorithmInformation-2023 ASN.1 Module</name>		<name>KEMAlgorithmInformation-2023 ASN.1 Module</name>
	<sourcecode type="asn.1" markers="true"><![CDATA[		<sourcecode type="asn.1" markers="true"><![CDATA[
	KEMAlgorithmInformation-2023		KEMAlgorithmInformation-2023
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-kemAlgorithmInformation-2023(TBD3) }		id-mod-kemAlgorithmInformation-2023(109) }
	DEFINITIONS EXPLICIT TAGS ::=		DEFINITIONS EXPLICIT TAGS ::=
	BEGIN		BEGIN
	-- EXPORTS ALL;		-- EXPORTS ALL;
	IMPORTS		IMPORTS
	ParamOptions, PUBLIC-KEY, SMIME-CAPS		ParamOptions, PUBLIC-KEY, SMIME-CAPS
	FROM AlgorithmInformation-2009		FROM AlgorithmInformation-2009
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-algorithmInformation-02(58) } ;		id-mod-algorithmInformation-02(58) } ;
	-- KEM-ALGORITHM		-- KEM-ALGORITHM
	--		--
	-- Describes the basic properties of a KEM algorithm		-- Describes the basic properties of a KEM algorithm
	--		--
	-- Suggested prefixes for KEM algorithm objects is: kema-		-- Suggested prefix for KEM algorithm objects is: kema-
	--		--
	-- &id - contains the OID identifying the KEM algorithm		-- &id - contains the OID identifying the KEM algorithm
	-- &Value - if present, contains a type definition for the kemct;		-- &Value - if present, contains a type definition for the kemct;
	-- if absent, implies that no ASN.1 encoding is		-- if absent, implies that no ASN.1 encoding is
	-- performed on the kemct value		-- performed on the kemct value
	-- &Params - if present, contains the type for the algorithm		-- &Params - if present, contains the type for the algorithm
	-- parameters; if absent, implies no parameters		-- parameters; if absent, implies no parameters
	-- &paramPresence - parameter presence requirement		-- &paramPresence - parameter presence requirement
	-- &PublicKeySet - specifies which public keys are used with		-- &PublicKeySet - specifies which public keys are used with
	-- this algorithm		-- this algorithm
	skipping to change at line 493 ¶		skipping to change at line 412 ¶
	[PARAMS [TYPE &Params] ARE &paramPresence]		[PARAMS [TYPE &Params] ARE &paramPresence]
	[PUBLIC-KEYS &PublicKeySet]		[PUBLIC-KEYS &PublicKeySet]
	[UKM [TYPE &Ukm] ARE &ukmPresence]		[UKM [TYPE &Ukm] ARE &ukmPresence]
	[SMIME-CAPS &smimeCaps]		[SMIME-CAPS &smimeCaps]
	}		}
	END		END
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	<section anchor="asn1-mod-2">		<section anchor="asn1-mod-2">
	<name>CMS-KEMRecipientInfo ASN.1 Module</name>		<name>CMS-KEMRecipientInfo-2023 ASN.1 Module</name>
	<t>RFC Editor: Please replace "[THISRFC]" with the the number assigned
	to this document.</t>
	<sourcecode type="asn.1" markers="true"><![CDATA[		<sourcecode type="asn.1" markers="true"><![CDATA[
	CMS-KEMRecipientInfo-2023		CMS-KEMRecipientInfo-2023
	{ iso(1) member-body(2) us(840) rsadsi(113549)		{ iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) smime(16) modules(0)		pkcs(1) pkcs-9(9) smime(16) modules(0)
	id-mod-cms-kemri-2023(TBD2) }		id-mod-cms-kemri-2023(77) }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	-- EXPORTS ALL;		-- EXPORTS ALL;
	IMPORTS		IMPORTS
	OTHER-RECIPIENT, CMSVersion, RecipientIdentifier,		OTHER-RECIPIENT, CMSVersion, RecipientIdentifier,
	EncryptedKey, KeyDerivationAlgorithmIdentifier,		EncryptedKey, KeyDerivationAlgorithmIdentifier,
	KeyEncryptionAlgorithmIdentifier, UserKeyingMaterial		KeyEncryptionAlgorithmIdentifier, UserKeyingMaterial
	FROM CryptographicMessageSyntax-2010 -- [RFC6268]		FROM CryptographicMessageSyntax-2010 -- RFC 6268
	{ iso(1) member-body(2) us(840) rsadsi(113549)		{ iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) smime(16) modules(0)		pkcs(1) pkcs-9(9) smime(16) modules(0)
	id-mod-cms-2009(58) }		id-mod-cms-2009(58) }
	KEM-ALGORITHM		KEM-ALGORITHM
	FROM KEMAlgorithmInformation-2023 -- [THISRFC]		FROM KEMAlgorithmInformation-2023 -- RFC 9629
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-kemAlgorithmInformation-2023(TBD3) }		id-mod-kemAlgorithmInformation-2023(109) }
	AlgorithmIdentifier{}		AlgorithmIdentifier{}
	FROM AlgorithmInformation-2009 -- [RFC5912]		FROM AlgorithmInformation-2009 -- RFC 5912
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-algorithmInformation-02(58) } ;		id-mod-algorithmInformation-02(58) } ;
	--		--
	-- OtherRecipientInfo Types (ori-)		-- OtherRecipientInfo Types (ori-)
	--		--
	SupportedOtherRecipInfo OTHER-RECIPIENT ::= { ori-KEM, ... }		SupportedOtherRecipInfo OTHER-RECIPIENT ::= { ori-KEM, ... }
	skipping to change at line 573 ¶		skipping to change at line 490 ¶
	wrap KeyEncryptionAlgorithmIdentifier,		wrap KeyEncryptionAlgorithmIdentifier,
	kekLength INTEGER (1..65535),		kekLength INTEGER (1..65535),
	ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }		ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL }
	END		END
	]]></sourcecode>		]]></sourcecode>
	</section>		</section>
	</section>		</section>
	<section anchor="sec-cons">		<section anchor="sec-cons">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>The Security Considerations of <xref target="RFC5652"/> are applicable to this document.</t>		<t>The security considerations discussed in <xref target="RFC5652"/> are a pplicable to this document.</t>
	<t>To be appropriate for use with this specification, the KEM algorithm <b cp14>MUST</bcp14>		<t>To be appropriate for use with this specification, the KEM algorithm <b cp14>MUST</bcp14>
	explicitly be designed to be secure when the public key is used many		explicitly be designed to be secure when the public key is used many
	times. For example, a KEM algorithm with a single-use public key is not		times. For example, a KEM algorithm with a single-use public key is not
	appropriate because the public key is expected to be carried in a		appropriate, because the public key is expected to be carried in a
	long-lived certificate <xref target="RFC5280"/> and used over and over. Thus, K EM		long-lived certificate <xref target="RFC5280"/> and used over and over. Thus, K EM
	algorithms that offer indistinguishability under adaptive chosen ciphertext		algorithms that offer indistinguishability under adaptive chosen ciphertext
	attack (IND-CCA2) security are appropriate. A common design pattern for		attack (IND-CCA2) security are appropriate. A common design pattern for
	obtaining IND-CCA2 security with public key reuse is to apply the		obtaining IND-CCA2 security with public key reuse is to apply the
	Fujisaki-Okamoto (FO) transform <xref target="FO"/> or a variant of the FO		Fujisaki-Okamoto (FO) transform <xref target="FO"/> or a variant of the FO
	transform <xref target="HHK"/>.</t>		transform <xref target="HHK"/>.</t>
	<t>The KDF <bcp14>SHOULD</bcp14> offer at least the security level of the KEM.</t>		<t>The KDF <bcp14>SHOULD</bcp14> offer at least the security level of the KEM.</t>
	<t>The choice of the key-encryption algorithm and the size of the		<t>The choice of the key-encryption algorithm and the size of the
	KEK <bcp14>SHOULD</bcp14> be made based on the security level		KEK <bcp14>SHOULD</bcp14> be made based on the security level
	provided by the KEM. The key-encryption algorithm and the		provided by the KEM. The key-encryption algorithm and the
	KEK <bcp14>SHOULD</bcp14> at least have the security level of		KEK <bcp14>SHOULD</bcp14> offer at least the security level of
	the KEM.</t>		the KEM.</t>
	<t>KEM algorithms do not provide data origin authentication; therefore, wh en		<t>KEM algorithms do not provide data origin authentication; therefore, wh en
	a KEM algorithm is used with the authenticated-data content type, the		a KEM algorithm is used with the authenticated-data content type, the
	contents are delivered with integrity from an unknown source.</t>		contents are delivered with integrity from an unknown source.</t>
	<t>Implementations <bcp14>MUST</bcp14> protect the KEM private key, the KE K, the CEK (or the		<t>Implementations <bcp14>MUST</bcp14> protect the KEM private key, the KE K, and the CEK (or the
	CAEK). Compromise of the KEM private key may		CAEK). Compromise of the KEM private key may
	result in the disclosure of all contents protected with that KEM private key.		result in the disclosure of all contents protected with that KEM private key.
	However, compromise of the KEK, the CEK, or the CAEK may result in disclosure		However, compromise of the KEK, the CEK, or the CAEK may result in disclosure
	of the encrypted content of a single message.</t>		of the encrypted content of a single message.</t>
	<t>The KEM produces the IKM input value for the KDF. This IKM value <bcp1 4>MUST NOT</bcp14>		<t>The KEM produces the IKM input value for the KDF. This IKM value <bcp1 4>MUST NOT</bcp14>
	be reused for any other purpose. Likewise, any random value used by		be reused for any other purpose. Likewise, any random value used by
	the KEM algorithm to produce the shared secret or its encapsulation <bcp14>MUST NOT</bcp14>		the KEM algorithm to produce the shared secret or its encapsulation <bcp14>MUST NOT</bcp14>
	be reused for any other purpose. That is, the originator <bcp14>MUST</bcp14> ge nerate a		be reused for any other purpose. That is, the originator <bcp14>MUST</bcp14> ge nerate a
	fresh KEM shared secret for each recipient in the KEMRecipientInfo		fresh KEM shared secret for each recipient in the KEMRecipientInfo
	structure, including any random value used by the KEM algorithm to produce		structure, including any random value used by the KEM algorithm to produce
	the KEM shared secret. In addition, the originator <bcp14>MUST</bcp14> discard the KEM shared		the KEM shared secret. In addition, the originator <bcp14>MUST</bcp14> discard the KEM shared
	secret, including any random value used by the KEM algorithm to produce		secret, including any random value used by the KEM algorithm to produce
	the KEM shared secret, after constructing the entry in the KEMRecipientInfo		the KEM shared secret, after constructing the entry in the KEMRecipientInfo
	structure for the corresponding recipient. Similarly, the recipient <bcp14>MUST </bcp14>		structure for the corresponding recipient. Similarly, the recipient <bcp14>MUST </bcp14>
	discard the KEM shared secret, including any random value used by the KEM		discard the KEM shared secret, including any random value used by the KEM
	algorithm to produce the KEM shared secret, after constructing the		algorithm to produce the KEM shared secret, after constructing the
	KEK from the KEMRecipientInfo structure.</t>		KEK from the KEMRecipientInfo structure.</t>
	<t>Implementations <bcp14>MUST</bcp14> randomly generate content-encryptio n keys,		<t>Implementations <bcp14>MUST</bcp14> randomly generate content-encryptio n keys,
	content-authenticated-encryption keys, and message-authentication keys.		content-authenticated-encryption keys, and message-authentication keys.
	Also, the generation of KEM key pairs relies on random numbers. The use		Also, the generation of KEM key pairs relies on random numbers. The use
	of inadequate pseudo-random number generators (PRNGs) to generate these		of inadequate pseudorandom number generators (PRNGs) to generate these
	keys can result in little or no security. An attacker may find it much		keys can result in little or no security. An attacker may find it much
	easier to reproduce the PRNG environment that produced the keys,		easier to reproduce the PRNG environment that produced the keys,
	searching the resulting small set of possibilities, rather than brute		searching the resulting small set of possibilities, rather than brute-force sear
	force searching the whole key space. The generation of quality random		ching the whole key space. The generation of quality random
	numbers is difficult. <xref target="RFC4086"/> offers important guidance in thi s area.</t>		numbers is difficult. <xref target="RFC4086"/> offers important guidance in thi s area.</t>
	<t>If the cipher and key sizes used for the key-encryption and the		<t>If the cipher and key sizes used for the key-encryption algorithm and t
	content-encryption algorithms are different, the effective security is		he
			content-encryption algorithm are different, the effective security is
	determined by the weaker of the two algorithms. If, for example, the		determined by the weaker of the two algorithms. If, for example, the
	content is encrypted with AES-CBC using a 128-bit CEK, and the CEK is		content is encrypted with AES-CBC using a 128-bit CEK and the CEK is
	wrapped with AES-KEYWRAP using a 256-bit KEK, then at most 128 bits of		wrapped with AES-KEYWRAP using a 256-bit KEK, then at most 128 bits of
	protection is provided.</t>		protection is provided.</t>
	<t>If the cipher and key sizes used for the key-encryption and the		<t>If the cipher and key sizes used for the key-encryption algorithm and t
	content-authenticated-encryption algorithms are different, the effective		he
			content-authenticated-encryption algorithm are different, the effective
	security is determined by the weaker of the two algorithms. If, for example,		security is determined by the weaker of the two algorithms. If, for example,
	the content is encrypted with AES-GCM using a 128-bit		the content is encrypted with AES-GCM using a 128-bit
	CAEK, and the CAEK is wrapped with AES-KEYWRAP using a 192-bit KEK, then at		CAEK and the CAEK is wrapped with AES-KEYWRAP using a 192-bit KEK, then at
	most 128 bits of protection is provided.</t>		most 128 bits of protection is provided.</t>
	<t>If the cipher and key sizes used for the key-encryption and the		<t>If the cipher and key sizes used for the key-encryption algorithm and t
	message-authentication algorithms are different, the effective security is		he
			message-authentication algorithm are different, the effective security is
	determined by the weaker of the two algorithms. If, for example, the		determined by the weaker of the two algorithms. If, for example, the
	content is authenticated with HMAC-SHA256 using a 512-bit		content is authenticated with HMAC-SHA256 using a 512-bit
	message-authentication key, and the message-authentication key is wrapped		message-authentication key and the message-authentication key is wrapped
	with AES-KEYWRAP using a 256-bit KEK, then at most 256 bits of		with AES-KEYWRAP using a 256-bit KEK, then at most 256 bits of
	protection is provided.</t>		protection is provided.</t>
	<t>Implementers should be aware that cryptographic algorithms, including K EM		<t>Implementers should be aware that cryptographic algorithms, including K EM
	algorithms, become weaker with time. As new cryptoanalysis techniques are		algorithms, become weaker with time. As new cryptoanalysis techniques are
	developed and computing capabilities advance, the work factor to break a		developed and computing capabilities advance, the work factor to break a
	particular cryptographic algorithm will be reduced. As a result,		particular cryptographic algorithm will be reduced. As a result,
	cryptographic algorithm implementations should be modular, allowing new		cryptographic algorithm implementations should be modular, allowing new
	algorithms to be readily inserted. That is, implementers should be prepared		algorithms to be readily inserted. That is, implementers should be prepared
	for the set of supported algorithms to change over time.</t>		for the set of supported algorithms to change over time.</t>
	</section>		</section>
	<section anchor="iana">		<section anchor="iana">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>For KEMRecipientInfo in <xref target="kemri"/>, IANA has assigned the o		<t>For KEMRecipientInfo as defined in <xref target="kemri"/>, IANA has
	bject identifier (OID)		assigned the following OID in the "SMI Security for
	for (1.2.840.113549.1.9.16.13.3) in the "SMI Security for S/MIME Other Recipient		S/MIME Other Recipient Info Identifiers (1.2.840.113549.1.9.16.13)"
	Info Identifiers" registry (1.2.840.113549.1.9.16.13), and the Description		registry:
	for the new OID has been set to "id-ori-kem".</t>		</t>
	<t>For the ASN.1 Module in <xref target="asn1-mod-1"/>, IANA is requested
	to assign an		<table anchor="iana-table1" align="left">
	object identifier (OID) for the module identifier to replace TBD3. The		<name></name>
	OID for the module should be allocated in the "SMI Security for PKIX		<thead>
	Module Identifier" registry (1.3.6.1.5.5.7.0), and the Description		<tr>
	for the new OID should be set to "id-mod-kemAlgorithmInformation-2023".</t>		<th>Decimal</th>
	<t>For the ASN.1 Module in <xref target="asn1-mod-2"/>, IANA is requested		<th>Description</th>
	to assign an		<th>References</th>
	object identifier (OID) for the module identifier to replace TBD2. The		</tr>
	OID for the module should be allocated in the "SMI Security for S/MIME		</thead>
	Module Identifier" registry (1.2.840.113549.1.9.16.0), and the Description		<tbody>
	for the new OID should be set to "id-mod-cms-kemri-2023".</t>		<tr>
	</section>		<td>3</td>
	<section numbered="false" anchor="acknowledgements">		<td>id-ori-kem</td>
	<name>Acknowledgements</name>		<td>RFC 9629</td>
	<t>Our thanks to Burt Kaliski for his guidance and design review.</t>		</tr>
	<t>Our thanks to Carl Wallace for his careful review of the ASN.1 modules.		</tbody>
	</t>		</table>
	<t>Our thanks to
	Hendrik Brockhaus,		<t>For the ASN.1 module defined in <xref target="asn1-mod-1"/>, IANA has
	Jonathan Hammell,		assigned the following OID in the "SMI Security for PKIX Module
	Mike Jenkins,		Identifier" registry (1.3.6.1.5.5.7.0):
	David von Oheimb,		</t>
	Francois Rousseau, and
	Linda Dunbar		<table anchor="iana-table2" align="left">
	for their careful review and thoughtful comments.</t>		<name></name>
			<thead>
			<tr>
			<th>Decimal</th>
			<th>Description</th>
			<th>References</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>109</td>
			<td>id-mod-kemAlgorithmInformation-2023</td>
			<td>RFC 9629</td>
			</tr>
			</tbody>
			</table>
			<t>For the ASN.1 module defined in <xref target="asn1-mod-2"/>, IANA has
			assigned the following OID in the "SMI Security for S/MIME Module
			Identifier (1.2.840.113549.1.9.16.0)" registry:
			</t>
			<table anchor="iana-table3" align="left">
			<name></name>
			<thead>
			<tr>
			<th>Decimal</th>
			<th>Description</th>
			<th>References</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>77</td>
			<td>id-mod-cms-kemri-2023</td>
			<td>RFC 9629</td>
			</tr>
			</tbody>
			</table>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references anchor="sec-normative-references">		<references anchor="sec-normative-references">
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="RFC5083">
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.50
	<title>Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Da		83.xml"/>
	ta Content Type</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.52
	<author fullname="R. Housley" initials="R." surname="Housley"/>		80.xml"/>
	<date month="November" year="2007"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.56
	<abstract>		52.xml"/>
	<t>This document describes an additional content type for the Cryp		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
	tographic Message Syntax (CMS). The authenticated-enveloped-data content type is		11.xml"/>
	intended for use with authenticated encryption modes. All of the various key ma		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
	nagement techniques that are supported in the CMS enveloped-data content type ar		12.xml"/>
	e also supported by the CMS authenticated-enveloped-data content type. [STANDARD
	S-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5083"/>
	<seriesInfo name="DOI" value="10.17487/RFC5083"/>
	</reference>
	<reference anchor="RFC5280">
	<front>
	<title>Internet X.509 Public Key Infrastructure Certificate and Cert
	ificate Revocation List (CRL) Profile</title>
	<author fullname="D. Cooper" initials="D." surname="Cooper"/>
	<author fullname="S. Santesson" initials="S." surname="Santesson"/>
	<author fullname="S. Farrell" initials="S." surname="Farrell"/>
	<author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
	<author fullname="R. Housley" initials="R." surname="Housley"/>
	<author fullname="W. Polk" initials="W." surname="Polk"/>
	<date month="May" year="2008"/>
	<abstract>
	<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
	icate revocation list (CRL) for use in the Internet. An overview of this approac
	h and model is provided as an introduction. The X.509 v3 certificate format is d
	escribed in detail, with additional information regarding the format and semanti
	cs of Internet name forms. Standard certificate extensions are described and two
	Internet-specific extensions are defined. A set of required certificate extensi
	ons is specified. The X.509 v2 CRL format is described in detail along with stan
	dard and Internet-specific extensions. An algorithm for X.509 certification path
	validation is described. An ASN.1 module and examples are provided in the appen
	dices. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5280"/>
	<seriesInfo name="DOI" value="10.17487/RFC5280"/>
	</reference>
	<reference anchor="RFC5652">
	<front>
	<title>Cryptographic Message Syntax (CMS)</title>
	<author fullname="R. Housley" initials="R." surname="Housley"/>
	<date month="September" year="2009"/>
	<abstract>
	<t>This document describes the Cryptographic Message Syntax (CMS).
	This syntax is used to digitally sign, digest, authenticate, or encrypt arbitra
	ry message content. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="70"/>
	<seriesInfo name="RFC" value="5652"/>
	<seriesInfo name="DOI" value="10.17487/RFC5652"/>
	</reference>
	<reference anchor="RFC5911">
	<front>
	<title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and
	S/MIME</title>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<date month="June" year="2010"/>
	<abstract>
	<t>The Cryptographic Message Syntax (CMS) format, and many associa
	ted formats, are expressed using ASN.1. The current ASN.1 modules conform to the
	1988 version of ASN.1. This document updates those ASN.1 modules to conform to
	the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the f
	ormats; this is simply a change to the syntax. This document is not an Internet
	Standards Track specification; it is published for informational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5911"/>
	<seriesInfo name="DOI" value="10.17487/RFC5911"/>
	</reference>
	<reference anchor="RFC5912">
	<front>
	<title>New ASN.1 Modules for the Public Key Infrastructure Using X.5
	09 (PKIX)</title>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<date month="June" year="2010"/>
	<abstract>
	<t>The Public Key Infrastructure using X.509 (PKIX) certificate fo
	rmat, and many associated formats, are expressed using ASN.1. The current ASN.1
	modules conform to the 1988 version of ASN.1. This document updates those ASN.1
	modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire c
	hanges to any of the formats; this is simply a change to the syntax. This docume
	nt is not an Internet Standards Track specification; it is published for informa
	tional purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5912"/>
	<seriesInfo name="DOI" value="10.17487/RFC5912"/>
	</reference>
	<reference anchor="X.680" target="https://www.itu.int/rec/T-REC-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 (ASN.1 ): Specification 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="2021" month="February"/>		<date year="2021" month="February"/>
	</front>		</front>
	<seriesInfo name="ITU-T Recommendation" value="X.680"/>		<seriesInfo name="ITU-T Recommendation" value="X.680"/>
	<seriesInfo name="ISO/IEC" value="8824-1:2021"/>		<seriesInfo name="ISO/IEC" value="8824-1:2021"/>
	</reference>		</reference>
	<reference anchor="X.690" target="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 Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>		<title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
	<author>		<author>
	<organization>ITU-T</organization>		<organization>ITU-T</organization>
	</author>		</author>
	<date year="2021" month="February"/>		<date year="2021" month="February"/>
	</front>		</front>
	<seriesInfo name="ITU-T Recommendation" value="X.690"/>		<seriesInfo name="ITU-T Recommendation" value="X.690"/>
	<seriesInfo name="ISO/IEC" value="8825-1:2021"/>		<seriesInfo name="ISO/IEC" value="8825-1:2021"/>
	</reference>		</reference>
	<reference anchor="RFC2119">
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit		119.xml"/>
	le>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>		174.xml"/>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized. T
	his document defines these words as they should be interpreted in IETF documents
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l specifications. This document aims to reduce the ambiguity by clarifying that
	only UPPERCASE usage of the key words have the defined special meanings.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	</reference>
	</references>		</references>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references">
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="RFC4086">
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<title>Randomness Requirements for Security</title>		086.xml"/>
	<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	rd"/>		869.xml"/>
	<author fullname="J. Schiller" initials="J." surname="Schiller"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<author fullname="S. Crocker" initials="S." surname="Crocker"/>		268.xml"/>
	<date month="June" year="2005"/>
	<abstract>		<reference anchor="FO" target="https://doi.org/10.1007/s00145-011-9114-1
	<t>Security systems are built on strong cryptographic algorithms t		">
	hat foil pattern analysis attempts. However, the security of these systems is de
	pendent on generating secret quantities for passwords, cryptographic keys, and s
	imilar quantities. The use of pseudo-random processes to generate secret quantit
	ies can result in pseudo-security. A sophisticated attacker may find it easier t
	o reproduce the environment that produced the secret quantities and to search th
	e resulting small set of possibilities than to locate the quantities in the whol
	e of the potential number space.</t>
	<t>Choosing random quantities to foil a resourceful and motivated
	adversary is surprisingly difficult. This document points out many pitfalls in u
	sing poor entropy sources or traditional pseudo-random number generation techniq
	ues for generating such quantities. It recommends the use of truly random hardwa
	re techniques and shows that the existing hardware on many systems can be used f
	or this purpose. It provides suggestions to ameliorate the problem when a hardwa
	re solution is not available, and it gives examples of how large such quantities
	need to be for some applications. This document specifies an Internet Best Curr
	ent Practices for the Internet Community, and requests discussion and suggestion
	s for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="106"/>
	<seriesInfo name="RFC" value="4086"/>
	<seriesInfo name="DOI" value="10.17487/RFC4086"/>
	</reference>
	<reference anchor="RFC5869">
	<front>
	<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)<
	/title>
	<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
	<author fullname="P. Eronen" initials="P." surname="Eronen"/>
	<date month="May" year="2010"/>
	<abstract>
	<t>This document specifies a simple Hashed Message Authentication
	Code (HMAC)-based key derivation function (HKDF), which can be used as a buildin
	g block in various protocols and applications. The key derivation function (KDF)
	is intended to support a wide range of applications and requirements, and is co
	nservative in its use of cryptographic hash functions. This document is not an I
	nternet Standards Track specification; it is published for informational purpose
	s.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5869"/>
	<seriesInfo name="DOI" value="10.17487/RFC5869"/>
	</reference>
	<reference anchor="RFC6268">
	<front>
	<title>Additional New ASN.1 Modules for the Cryptographic Message Sy
	ntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
	<author fullname="J. Schaad" initials="J." surname="Schaad"/>
	<author fullname="S. Turner" initials="S." surname="Turner"/>
	<date month="July" year="2011"/>
	<abstract>
	<t>The Cryptographic Message Syntax (CMS) format, and many associa
	ted formats, are expressed using ASN.1. The current ASN.1 modules conform to the
	1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to co
	nform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative
	version. There are no bits- on-the-wire changes to any of the formats; this is s
	imply a change to the syntax. This document is not an Internet Standards Track s
	pecification; it is published for informational purposes.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6268"/>
	<seriesInfo name="DOI" value="10.17487/RFC6268"/>
	</reference>
	<reference anchor="FO">
	<front>		<front>
	<title>Secure Integration of Asymmetric and Symmetric Encryption Sch emes</title>		<title>Secure Integration of Asymmetric and Symmetric Encryption Sch emes</title>
	<author fullname="Eiichiro Fujisaki" initials="E." surname="Fujisaki ">		<author fullname="Eiichiro Fujisaki" initials="E." surname="Fujisaki ">
	<organization/>		<organization/>
	</author>		</author>
	<author fullname="Tatsuaki Okamoto" initials="T." surname="Okamoto">		<author fullname="Tatsuaki Okamoto" initials="T." surname="Okamoto">
	<organization/>		<organization/>
	</author>		</author>
	<date month="December" year="2011"/>		<date month="December" year="2011"/>
	</front>		</front>
	<seriesInfo name="Journal of Cryptology" value="vol. 26, no. 1, pp. 80
	-101"/>
	<seriesInfo name="DOI" value="10.1007/s00145-011-9114-1"/>
	<refcontent>Springer Science and Business Media LLC</refcontent>		<refcontent>Springer Science and Business Media LLC</refcontent>
			<refcontent>Journal of Cryptology, vol. 26, no. 1, pp. 80-101</refcont
			ent>
			<seriesInfo name="DOI" value="10.1007/s00145-011-9114-1"/>
	</reference>		</reference>
	<reference anchor="HHK">
			<reference anchor="HHK" target="https://doi.org/10.1007/978-3-319-70500-
			2_12">
	<front>		<front>
	<title>A Modular Analysis of the Fujisaki-Okamoto Transformation</ti tle>		<title>A Modular Analysis of the Fujisaki-Okamoto Transformation</ti tle>
	<author fullname="Dennis Hofheinz" initials="D." surname="Hofheinz">		<author fullname="Dennis Hofheinz" initials="D." surname="Hofheinz">
	<organization/>		<organization/>
	</author>		</author>
	<author fullname="Kathrin Hövelmanns" initials="K." surname="Hövelma nns">		<author fullname="Kathrin Hövelmanns" initials="K." surname="Hövelma nns">
	<organization/>		<organization/>
	</author>		</author>
	<author fullname="Eike Kiltz" initials="E." surname="Kiltz">		<author fullname="Eike Kiltz" initials="E." surname="Kiltz">
	<organization/>		<organization/>
	</author>		</author>
	<date year="2017"/>		<date month="November" year="2017"/>
	</front>		</front>
	<seriesInfo name="Theory of Cryptography" value="pp. 341-371"/>
	<seriesInfo name="DOI" value="10.1007/978-3-319-70500-2_12"/>
	<seriesInfo name="ISBN" value="[&quot;9783319704999&quot;, &quot;97833
	19705002&quot;]"/>
	<refcontent>Springer International Publishing</refcontent>		<refcontent>Springer International Publishing</refcontent>
			<refcontent>Theory of Cryptography, TCC 2017, Lecture Notes in Compute
			r Science, vol. 10677, pp. 341-371</refcontent>
			<refcontent>Print ISBN 9783319704999, Online ISBN 9783319705002</refco
			ntent>
			<seriesInfo name="DOI" value="10.1007/978-3-319-70500-2_12"/>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<?line 685?>		<section numbered="false" anchor="acknowledgements">
			<name>Acknowledgements</name>
			<t>Our thanks to <contact fullname="Burt Kaliski"/> for his guidance and d
			esign review.</t>
			<t>Our thanks to <contact fullname="Carl Wallace"/> for his careful review
			of the ASN.1 modules.</t>
			<t>Our thanks to
			<contact fullname="Hendrik Brockhaus"/>,
			<contact fullname="Jonathan Hammell"/>,
			<contact fullname="Mike Jenkins"/>,
			<contact fullname="David von Oheimb"/>,
			<contact fullname="Francois Rousseau"/>, and
			<contact fullname="Linda Dunbar"/>
			for their careful reviews and thoughtful comments.</t>
			</section>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA+09TXMbR3Z3VOE/dKiqmNxgIIISZYra9S5EQiLMzyUp2yqX
	a6sx0wDGHMzA0wNSXEZbe8k55xxSlUOqcs8tuaQqfyW7+R157/X3YEBR8q7L
	h3jXFmamP16/9/p9dyuKonZLVjxPfsezIhe7rCoXot1K5yX9lNXW5ubzza12
	KyninM+gQVLycRWlohpHGZ/NZRTPZHQlZmUabe60WzGvdpmsknbrZrLLjvrH
	Zxfs66K8SvMJe10Wizk0KXIpcrmQu+wznO6zdmsxT3gl4MX2s22YbJ7utluM
	VUUMTW6F/AyfZFFWpRhL/9XtLHhTpVUGIH72RuJ0h+KWDfKYz+Ui41Va5OxY
	xFOep3LG1g8Hxxusn02KMq2mM8nSnFVTwfbK23lVTEo+n6YxtJeSTwS7uM0r
	/o6t7x1fbMA0fDQqxfUug0cG45yLOJ2nIq+G+bgAdC5Gs1RKmO/ydg7QDAeX
	r6BPKfguW7sQ8QJmvF1rt65u4FteiTIXVbSPWAUsAxZg6dB8UU2LEn5GuM7x
	IssU9s8XUrKDYiEzcYtfihKw/FU6STNmhu6wo6M9/GbADD/jlxj+3GUHMHVS
	5B32VZ9eFou8KuH9mwt8FDOeZrtsqub6zTUOIkXcjYvZElRfFtMcqMsdSIOc
	uMdNdpzmueDzIktlhx2frJ7wexirCwS4/Y1QYzTNiA+M7e6yP//rv/3pP/7h
	T//1z//zxz/+7z/955//8d/VJy7jNN1ll8WsGC9mKTu9WowKC90+LGZPlFUH
	CBB3fVyZLw7wVzwtx/zd/Viq9DzdAuf5O9wdv5ngJwU8bChgjXIGXHitgD9/
	tfd0c+eZ+b298+y5+f1s69kO/X51CvCcDru9Tfj/5ueP5eZm7+l2tNnrRc97
	vadRDxsdHByGrZ5/vhM9iZ70nkefb25vbkZbv+ttIQR5ff7tzZ0n9vfWzqb9
	DVvQ/oaJvN/q/TfdZ7o1bFFeTgTs+GlVzeXu48c3NzfdtFp007x6XIr48WV0
	PtiLqIfuoLboF+qJsaFBDGzPCrZnXmTF5JZFkWnQH8mq5HFlNuFJUanWp7lg
	6/2Lk25vY9c0vpjDXhynsWpRjNmIS9jHue6jecPsLXyIFEcML99El+oN7UG2
	tbnVi1Dw4SspylRIpKGdiTow2PrFbCbyhIbfZd5CocnF6ePhYG+X7exsAbV2
	cUiNv+c/If4QQ0zkcZGgUCwXGcrZJUS9JEQNTLNzbMbWXw7ONzpmpD2eFzl0
	yZaa7UEzBkoEto+s4P0ilVORLDXbh2Y/BQmeN5Jg25IApEkUwZZXjIXPlw8S
	/Uwu5nPQQpJdgWqBzrnER1w5iHN4xSelEAALvLKapYs0YkBLfH0reAnyL3ZT
	iVKyKb8WbCQE8Kckutw+TH25STqgv+Jsgchut35Y8LxazCKJEl+ghgrBuZym
	koE+XxCkiRinOVAHtPI1PMM8kgFLgTIFnCykQOYIh2CjW9KV8DhJc14VJdG+
	NGpQgjhEhsNFgiaDT4mgB1KYME8FjZbg0CYAShqyArqGTrM0STKBT49QX5ZF
	sogJHXePUnx8rwjYNBZC+UDS3t1p0ff+ffcjOEIA0rJiLpIIZuRmcawCzd9u
	eWMShsjAABQg9yOqYfdBxwcMAZIahtDcx0ZFNV3mQLaKAYEa7ZYAI28EundK
	QGBTIG3iEYr5dMI2jk6WfdutD/Avexj7tlv38C/7KPYFk6mZf9lq9jVfgRSA
	mNXYfzDNyKS13Yh9+uGkDEDmDAzsaM7BgFuXsGlEBONHAMwNL5MNNrObW+0+
	Q1sS2tCymCHZ8AmkPQhDEMNAPe62HawWvyLA9t1nEozpBRA+xs4GeTMBY0ND
	XjXt42AAxDSqT5YLAUIOZhxBhzwDlDPdXYJBBmppJmj4YHI2L9NrgJYYDibG
	QYjr2i1oVVwLRYjm5XXYDWy7KfZD1AO3C8Q9mHaw6jlYZTephB0ip2BaJ6Af
	4lJUgFm5ASBWN8iN9wkpu8nrBjw4LyUIGGQ9xVqJ8g0C+SK1cFkFBsKYQ7/5
	olJUQgQkgrCBW2G8yJUMWz/cf7WBTeYk1wCpQDA9KHaK9PbEtjgGbJzDDYVo
	MNx9EGAhh4irpX1tuXNprD0YiyFiDNtHdS6vte9Dh3ZL7R+gvkMmmBlZhlut
	xjz4U4BwsHwCU+KMOBJRYKhRCxsqLYscsdthUrsqgLE5KHbJ0LaZgmTDtvkE
	hcCrtJSVQkCw0dqtGbgMyKRafPAJT3N4wxM+R+uXxdMCvE8w7lF2VeIdfKoq
	Hl/hqOAjFXlCw5JC9zHg9jLNAPS6ThMSk2P4E3DGMwQZmQzUkpjQAqAVGGXY
	X+29MukoxQpQpDEwkUYZcIHdeyvnxd2jWYWmNkhttzLAMaHfYo7LZdw0CiY9
	mNQINowpyQv9BUrx1yJf32DRF2x9fgW0udqgT18weC9K3NzEhVbIYDNlDPJg
	+69Dz64a1KkFQY1x7BjpLu3YQKm8Lsrqk3TcpvHJCUPRjhoJ3EpSb4dgLAKv
	QXAYzeCEhoZ4XziIJWABpwCopVyCt75kS9YahA54YrZ7gKmJrMLaASgFQT/E
	AFYZUrVj1ZYn/o7fXFyydDbPhFKchj98amxYBviUyRx+w7kMK7Zblp2sADTo
	wSF9LHuQNKgVywjgWaPIW/Asu2UxL8FJIHkNHAHIVh6O0MYd+LjauHv0iF2K
	cpZqZ+nuEWicmXxvVALS7qYoQfCs4ULWOupPdnJKv88Hv30zPB/s4++Lg/7R
	kf3R0i0uDk7fHO27X67n3unx8eBkX3WGtyx41Vo77r+FL4iUtdOzy+HpSf9o
	bVn/AK8oDidRU86BZ0gxgjEk4zIdKRy83Dv773/pPYXV/w0sf6vXew5GpHrY
	6X3+FB5uSIvgbKDSb/UjUOO2xedzMPUIkyDYgSxpxTMw00CuyGlxkzPgZdFt
	tX7xLWLmu132y1E87z39Qr/ABQcvDc6Cl4Sz5TdLnRUSG141TGOxGbyvYTqE
	t/82eDZ4917+8tdk8ES9nV9/0dIMRH41/kbOv+bZAmQo0mWixWKi7THlf9/d
	kQ///r2xaqwJQY53u9XkedvN8WG3Wk3w3GNwBOsrsM5xk50sZiP4SfIf2Mhn
	kru7C6WgWK/7BFWIdVnUvp7x70F2kG1sDSOJ8Sw011HyXus5cprDKJ4x6meW
	VgJM31zJmnAMvatrvVNJHJ0rK5Hx6yJNNAbBNykSkJSiLIuSlHUB9oSVMVxZ
	/tpajaciviJAahOAeEaxCgYoaH0xm5N5zfXgHYNwMN3G9i2jGVkRg2qVHX/Q
	dsuBTTMq6xQFpVHsqi8Y9klGhnyxgBmFMcTRK0BTmMsiB/cM0DkHrcDj6QtA
	HZtnHE0ENQS8hwfiKBhDov7XU4w5miO8mna1G2wGoeEzWaAmmaTX2BV3uLJM
	46IEiVo1EAANyHZryccnvvoa+gtjtjtDGXuRyw22E2fTdALSoT7yTQqCBHUy
	qOR0AmY1IOGguMHROspelTjUjL9LZ4uZEmzgYZV8lGYU1cYp1dDt1jLUJMDI
	9qU1YuNc3DCpnPUxuA4aUCB6VtzS9JdgxKICUWNnAIxcQggZujbug+3cBteD
	a5ypjUeK7MwR6xTGu07FDX6s+aExEGIkNNDwimkbzIuSkEMpd5WNcJ+r6oUa
	1GpCS37ZSw17aFPj4U4u8wITaI7DABL3YhpbWlWehgWaF3GKo7ZbtFTaG/es
	R3OLQo7Rf4XGpfXdPOtG+ZDAA4Y8iljob6wbfx/dF7fHgRNhDs9ZKUYVp6mA
	4hRMISdOm+IARjH6HncMwq+zRcvJH9sawx/jVGQJE+9gIxs/8u6OUmWEtH44
	/QLdyHDPRT6vzWaiKrX5C/vFj9Ugx8xUeKrRyFfWODoWTT4oai3jNSqvKbv1
	I0bO2w6haPRNPa+95ones7glKhnfkCfXPI9BMAuUZ36oQzgHZ9mohEljihZo
	zxvh7yqWcWMQixVj4DlD+ZVGo+IJrfOkES6IJbeGIMwCcrKaajHpeS2oJ9QM
	yE4lqqrOh0bDTjOOqvaapxlpCfQBi0r5nB5CZdO+sGRctSFc2AjpW4m58ml6
	XRU5XWoO4DgwMQhAG4+m3uqSIAhpRaOpMP9qM96yixUOqz0TXL4lmOPMZQeq
	wfNq9qkcdKu2iMfN9Fk0bwrYAB02LotZGJmRUtnYxBIk6xQ/gcih3UPOi0Se
	1HJlcTVTwqMG3ooQj6GrWl0qa8t7cg8pm4YyghiHC0WkZTC3ixQlPom3VgUK
	G+hmRVTAH83+4gr+kIZFf7Z01nSqETmQ80sIpo5PH0DgptC+M1isFgvyiXeP
	lLJaTrCYoPtS8BR5BqPuRKda6J6cD5Uh0F66cT2edbe622jPBkaJY7LUA4qi
	4zxJUoVR4pgZz0H1qVAD5kDTH4w3VgpwjhHlxowAHXuK9AnBRpvDWga31JOk
	mIrsEbhgEHO2oKFhIeSSaIPANiqdAK5/8Swgi5sQhFTtjT/84Q+449MkArSx
	05dfDvYu2XB/cHI5fDUcnLPd3V+xO2hcrPcwZ4A2ajQqktv1Ldxt6ztPN3WK
	tZQ8kel6r/dk++nzDTa/iiV2wT+j5+vwRs7SmVjvPdtgvSfsvRI0alos51k9
	tYKMuhCwK8LoZMaFi1pqgyNeDH77ZnCyN2B3Cm5jf4NNo93XDoi/CBjpht8C
	/wiKqOsMbwnuoRvSYlunrHEZMKet8mlqAFQ63bscXLKLy/PhyWvzIRmjWbFv
	RcR9Y1wdiXwCJB2eXA5eA57We93us+3tJ9smdY7b/NvN79jgm7Oj4d7wkr2R
	ojykbMexyeWYqIPuclPyOUIwsCbWaggCm3PgP4QkIknjQs6NBKNUHnmVRQYO
	EeVjBM8x6q5DnYY+Ki1jfKDQa6o59xQRAmN+U72nkIkJTWg2CYMSNiSx2SAY
	ugoOJL0RJnIpVOwbciCSyGZGWXzDtUgc3dbt0YfYHmYBDTznRdJvCuBWLOyi
	ehuVcPQyoySEVgHrWZ1WIJVCe+PLxhOlKRoipP6QhH6U+Uol4upqOUGYAWAU
	wE9+PvGb7vbmc0vEJ8GYhEw9ptRW9gL9D3Ac3oFycXTHCHxZmcwGoJW0Osnq
	UVpp0FMpF6Ls58kF7QYVr0IHzWLRydL7ia0xpQbE9GcSxM6weswZGF4/qbah
	4t8XOii/IDEOO8kj86fBxHWw2qkKchIoGKPw7HcgE24MVAHfR6WjlJFse7db
	oA1jY9OrARqhdcSgEKWZlUwU8Oi9OZWGNVoznNzofZ001rxcxyFlBmEMg9/U
	MwWsl4q5MxM8TASwT0bpPVoOVa8sL9akbyiuBYYiQhtAThaUCkJYErRbLmLW
	WQoTEmcG9RRKKgK49Z0b1OTcQ2UNgCdPPACA8vdBADjLBIbxilw0Q6KFHmq0
	GtPVcjHk6ud+xAXjkcD1MJbsrAzuMW16NinLJfFMQQyY08pipUe1RvDMdp3i
	SsyuvMep0yVHS87LF6SLa2uume8PXn67pWV/vTQAOGzipzPBBjei/kNmwH3K
	q9d91qy8nNFg1Gj6e+E08yGOU8SVqGzBC21fFegEoHRLKjCQZn+scGo0bYHV
	ANhRsaBsj+5eiQmFU83gWoeRxzDjVwLD0HGGmSB4YVkYa378uCgpONATIOAy
	rGc0A5u0CFZ+6BISirsOm/YCJdLLGQ2spICCyoKUUo2PBHGuojeVrWVqTJd7
	wtaY/sqqUlG5kQDzRlMD7TPPScNNUtarUYzkNG7bEspwj1fW46qlAdJ6YUm4
	m5IxxpgKklmU2tfR0HeVqyG5n8IUd3nHEbG6fMEBGReLLGEuY5MXFFIDcZrp
	AtBIG1KxN631uGBhVDzjS+SGRDlj9ajjjN+qHAZaOz8s0lIoHVLUsNjAEcRd
	OpdjmMyuShFQZwAnJUyAdeG3DDQ9gp/mimtMBP7GJ5vqm2JZlPILYfKTwhg0
	Wv5YWDF2y7EAxVtrBsZTOS+k2a4KptXma10CUGpH74gsnaWV2m0jQdrPBTlW
	1pMqniVW9sQiX1030hDjARPcSLgPehmUYl8t4Z40S7jAKUmNfQRyn/aEgVOr
	VF0VRIA9qBTJL4tUZUm+9Y6lRYPa/MC/vp/nxT7skpkn1Cn0gSrO82+bhL9y
	X3wyhHtA435VOF1qGlhLaOwCtjrQghVQrMhdvUY4uNp3YXVZUHZoqE8Fhbip
	1Uh+0ErLspwq1Q51ZZbz2ZvWjZ57w/s7bB/1j16fng8vD4477K7b7b73/NBH
	BKtTqIhokH42wiQ1axl+kyZgZWs7AUWu0BHrpjDYX8xASupSmkMdCa07uM1p
	KsCGl6dy6SbBDnBwGdTJK7bbeYaFFAa1VAiB8B+j3QF9VAq7VNE+lW3UtZ83
	IBCnHFjAE9xaqVAyWJeGcSl0ttNva2OJCkacJUkxhQuz4E/aJ9at/ZDVAjNT
	GGwlwLnNZQUcVYOYhQB7PTS0WqKtBpc9CFq7C4Ek2ugBP0VHJIaHxwYUpS1V
	SNDo7WGlqm9d+FYnCYxq1RiDoVXqCvUWOi68RgClBZttDd+AhA0uxSIpXFmr
	is8uS2QdYyY21KtQG54i64oNvc1ct2c+bJxqYXxk8JMpo1NbJcWi0ugKyoqt
	7WlTeU22lDNhVwSUjAFtLaWlpa3UWD6rt1s2obgMxId0l15/qgKsxrpZ0CI9
	uwporwXx/uA8orMyODE4rCDHQJbA0mi31OqDcURdlEzJAJEZC2dsRNGq2mKY
	rnl0wpMqO+ZB8JRO4DR2aYqifmwM8YGRzI+NZtYikB9CqAko7X6sjfPC52eD
	/VVJnqC2gJvolU2ehfWyDb5aVmN7z1vTgaMAkJXJJgMH2O0kFml2dAQ/wi15
	AcJMeFUFvqDUUKQGnadOTq7Y+a40A0HyFnpkvFE1ujcSLj/QTA15SS8npcoT
	gHJxLOYVZbMRVBUppHcoY0EWdthRRxdTA4twqcU+mjt+b9hj2L3/VlU6mSGY
	5JkR8CR/vLIEUyWqzxHo4IDTAx/098fM+Q6u7B2rN7RqUtWv+RjmzVWBb8ia
	JG+UNaQSScdFQqV8d4+4zHvRrEiWLaIgvKy6zUw3U1yohZgqvtMFiqqRNoFd
	OFBLPrdA5/BFeOabmX65OYT0vLdlYtKpywBqye9sPrZ31L+40JBIKqg3+TI9
	pN/V1RS6wyGkfAPLXOqqIYwgNh3U8hZsJqEKESuiKj6ZUCDQhH4bAaM+w+Ow
	D03yEkOEIdJVgmTJPHX1FkmAux7ibgmR9AIP/Lq6zcDgDoiy9SRgF49bot57
	rSmAq/Nub8lwr42jhLlNIzq9GhXlhOfp76np+pMN8MGT9Wcb2kAUFbQ2isAc
	NVjf9s4uSXyaX6Xv1j/HYRG29c0NpzuYfokZxpXQrV++3IepdUpyf/BqeDJE
	dXLh6HnZf32Beg8bvBy8HtJ58ijCBqfnlxesf3T0Al8BMfFZAXCGe/2UpKns
	sLM3L2Gs6HDwtsMujofHg2ivf6Zbvjo/PV69Ncxyfhz+PhGDGn+8CbjNrfXt
	HUAce6FQBwgJ96Z6aT7tBz6WOik9p5rLKlVHU2rebND9YjGZALNjgLWEDf1O
	57lCD1XlwdFT2MUgMY9CCP42TVjk0kgIxulw3+DTRtwbgIC+X5FdGXnyuONn
	pMgzJ1GTmgCz1sazuHphRgn+waLfkRqInEShA1F5UT9FjSZxwwCAOqSGSJyF
	i4Fx0kAWbmJDuQpw7EWgG3iXFh7OaIPbL5rAB8hdCwsBvTqjqWPEoFOCc/PS
	C4I5wClpCPrxApynyEu+KtXqcooyrNdpBDw0tewcb8DmifyVWFw0WT+2G5hK
	3nrqaWEv9khOF6of+vTm8LgROIoS2sGpUGKPz2WdV3WVh45VIGBTrREuHqNE
	aRw75nNV0pzqEhVboNINNsdARXN39SPtHvhPVEpeU7hUl+Hm8io20sR0cZ/P
	+ud9UKOXb88G7FzyQzE7sxzC+ucDa296XayoBPULwolg+Hv9g4pF3rvGgNMV
	wzgpC6PQ/HSELI0PbkdlmpwtMar6x65nn718i0uqT6oVxTJSyBIxHhHKGv+f
	5fqWNydDcKK0p6PFi2se1meYXbzqc7jFAtWDGq3/5ujSsLgZ0N9dPs6XxsY9
	wlZD5u8F9qCpHYOzGp3M2NjwPfsaMMsu3p5c9r8xWPXQBwhW7779qn/0ZqAx
	+J1+p9nuW6K7xt53xCghrmx7j+cC3JgGyGd6NECIHspbu2nnrcYtlD5qvhmc
	7Gsn9W6XyWJRxnTsI5rx8gqY8VfqjqL37lhNtOTWrzLLtqgX3mgwSNKqKHfZ
	GeZ5qSwNEyNs7dvLg+EFNPhuzTlf+K89TaPOSlCAKTgD1l0y+Joga7L2movG
	avVixuC4r2xMW8KeeaKNE3cjlDHnthrNOWtqf5I5d3p5MDjH61GGZ0Ngwk5Q
	Mba6KMxPDHQeWuT1wShKQxDEIIWMyeAqCX2ThLpIAnDU26TVfqt9ge+ctfdp
	RPt4wtWIh1auMiX18utGpF3Xvd4KLcoweMOiPtFu/ml8D+zQlOF4H6x/tf9s
	KIru3s9o8Q90HPQGbCiVxUvNJNYZp9GGaYt/Xqg0rUhcH2pf26a6ihS7A+90
	WLfbNaJBv2vuYRkxhGbJODDlq0FB68+9jjbA+fKhIofk/6+g/ekraF0wBS2z
	BtPb5+HV6dLVEmUpZ2pne7/EHI0RdJ9DHp4i+BgE/YVJ9Cmml73AkO1hFVCC
	uTayae8egUSMsDTIJutXNQ0rFcj70lUw+ljVsol1Scfs/dLD4IiDitn7SeKG
	S0koIIyFsSrxnN3ikOA1kmmnD/Lr60pssUrD2agZzzG7C9JG1it+6mUHBBtn
	mCfPRITQhuPlBd7M5S1qJGKOzZanBqjBybVw+ncstFtZkU+iLL2GF6uOzmGY
	k8Cn637ofMy1rhBfyI66FsK/rAoDLsV4jIH23Kvd1ceA2SJPcJiVt7nQwW4e
	X7H14cl+tLfXB3nubkUpA1JS7QTeHqcKDoAceI4ala4qR1SniNCvN2O5oQjD
	HqZKgehLKcKAPHWrMkGvFt+nkl+l0ekVnxXwbf3V6YarxQBMvToFJNElPNcc
	oMptkuDVqb4FSjc8ODisJXh0CZTClq0h1eFtBaa9GUYzpe2vLqDxU1SNmVgb
	L3f1iarCQs89Eupw4ohLF/UKZ7dVbX4ZqDuGdd+0wVR2gfaMwtIqbZFMt+G4
	tS4nMyV2dD5L1XT5554BDkri6Yp42pBYFr90nVd4HG35uHVwnrkT1DapuE8i
	cOOUZhR3aRDlknkOrH6V41UbSjCqI7FNlZP6kiErd7yzdEYYHXZsMm7dFFqp
	g7agMYoZjDBLpVeAGgyCBRFYwkfFWzrxjrV2WUEn9jFOjHeEmLVpcBx2eFUf
	EdZij/7HDdM7cDt+8pAqMxwcDgZbEOsOaxvsUxRbycHgiPSlXSeVKKuAHtVg
	uKShjcGa+gAgOzZRH809J+3WSKjtn6gjk/mtPgKoCwWh61F6JbDaqkNfdWGI
	GiY4jRJymXctGLF7cMQVZkorvDgruGLvI2C6VFnbTr0WmsZwxSzt1hhQrg7z
	hRCMl876spXn4m2ez7/pbxUuGjSoQ4VDVACNuqfQnAtsXhQyDC/dfUNqAACO
	RvhrQQY0H2NsHS0UwoJJawi8SPgBKLNsSHd2yHmRq5tcvdvXLtJZmvEy0xs+
	vIiJzsA0LJx9/Lo9VV3nzgevW1fomdOz99TIrJR4S5c92AvswjpRrPh/SD2p
	VNlYLR+iUB1QAzy8mslCoVfPmqqbc3Hh5pIBrB6mxAt80nhUkTxT6EmXPEAn
	YMtE/LBA0FWxWBQ0N1MUMOL62fnJa7lRP6MgVYWLukbECUUwkqpMqMsFrILU
	VRNkGMHgKEbHqcrjzxbxFExTLvVBGzww64iKU/t38ylpbo91aNMB0SwFL+kE
	j1fpi09yhsoBfU5YNUgemZrkRwcwVKlLEvAilHKhTxDFqNj9wW6mRaYUkZzz
	2NwcFBIBUEnmocKiuZiHShSTdDzGe8twn5Bhihdvo82FZpPEVFlRVmh3gZ2Z
	4G0T9r4RvLNdMaHSLsrKtJetok2k7QCXXAwNGmPGNLCnZ5mQNZCO6cyVvhBC
	wFNMFq41cjDnmAhVreo25Y3gSFKt/9TRQ//q4XFHyengbIBRjnTxotGYpK37
	g4to7+WeLrHlrLe1E42ATUgV2/tQ6YR6u4Ue5NzveTh4+/V5/8z23tp+Rr2N
	RkceZLMCbDgYF4//STLa3C2J/oGKvyzmV27/B9KBtIQhBPvRdNClvvfS4fXe
	cZ0OymrzKNFXlwV8kBK951tLlMDaoJAU7K9JiRXS9WeyDwL+UHg8OO7vRRcH
	feBii8ft3paiw2pd4aizuo1HM13a9HHbB0F60Pbxj2zJKR0EwnDGDd0gSGd4
	gzuum29krvnoHYwW4OVrGufKzFcXAPclXbulRuU5z24l+sTBpQxIPn3zE6FK
	Ve/jRGFu3Nz9Q+Qtyis25rE+rDcCyXyl7sq1l1KuWIktswTLBJWWApJrFYUG
	wop+9RObDn2UP+Hgu3BzRj7HC76CK7fVjDxJqd4dj0DbK8fI6E6bKTMH/auM
	UrOdtOqUJrwe3uzNMP4/ESq4QjTQF6X3T/rLgbIUKEJBslcN5yOC66k6aoQp
	FklKE6iaNl1ssX463NeXAq/3ulvdnaebXRUs7/a68O+zbu9J98mGsXPXLo6H
	Lj6HvVSthD6OcO7O76r4vp1IrgE+J6lEm3nlRO56L13dRDLIIRN5EyuMcF3q
	wnIVDF9zAfu1rkEQdggyu4Qgr+bOYEkfGlPVUBj/IYzRGYoV+LLC0lRZBoed
	TXYYc1FdVUSPQNf6eNsZ2FDJrZVIPjscftNu6XU4pIY4fdIFHHa34X+fdzcf
	ikoHhofLD6XZHozkrZ8CyVvmqMKPxbIp+/kAnpt498fjO8y6r5kC4xiDSJlI
	1P04kkLtyjoWya/W8mKNBMLpQtnhVyRUXi5K0DpgUcurlBaG1rA1j9XfFEDY
	L4W9jy8cYQ+cUfY1oAxRbEYAHxSPaupeRlcHZbXLQ7VbByJPyvSKvSyL+GrK
	F+hufFmAX49+wwGfzUSWwavj9EqwL0V+BeIWHvc5qEF2jX9RzFSksxG8egXe
	QVwAIOfFQoKPseiov7rjCHwhzvYX+YiXFuFpWYdXkadYTKYVvlV/7Yi+FAv/
	oooReFft1v8BfXD0GVNrAAA=
	</rfc>		</rfc>
End of changes. 78 change blocks.
	659 lines changed or deleted		269 lines changed or added
This html diff was produced by rfcdiff 1.48.