<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?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" submissionType="IETF" obsoletes="" updates="5652" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.19.3 -->version="3" xml:lang="en"> <front> <title abbrev="CMS KEMRecipientInfo">Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-lamps-cms-kemri-08"/>name="RFC" value="9629"/> <author fullname="Russ Housley"> <organization abbrev="Vigil Security">Vigil Security, LLC</organization> <address> <postal><city>Herndon, VA</city> <country>US</country><city>Herndon</city> <region>VA</region> <country>United States of America</country> </postal> <email>housley@vigilsec.com</email> </address> </author> <author fullname="John Gray"> <organization>Entrust</organization> <address> <postal><city>Minneapolis, MN</city> <country>US</country><city>Minneapolis</city> <region>MN</region> <country>United States of America</country> </postal> <email>john.gray@entrust.com</email> </address> </author> <author fullname="大久保 智史" asciiFullname="Tomofumi Okubo"><organization abbrev="DigiCert">DigiCert, Inc.</organization><organization>Penguin Securities Pte. Ltd.</organization> <address> <postal><city>Fairfax, VA</city> <country>US</country><country>Singapore</country> </postal> <email>tomofumi.okubo+ietf@gmail.com</email> </address> </author> <date year="2024"month="February" day="06"/> <area>Security</area> <workgroup>LAMPS Working Group</workgroup> <keyword>Internet-Draft</keyword>month="August"/> <area>SEC</area> <workgroup>lamps</workgroup> <keyword>kemri</keyword> <keyword>KEMRecipientInfo</keyword> <abstract><?line 82?><t>The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms by the originator and recipients to encrypt and decrypt CMS content. This document updates RFC 5652.</t> </abstract> </front> <middle><?line 91?><section anchor="intro"> <name>Introduction</name> <t>This document updatesthe The Cryptographic Message Syntax (CMS)"<xref target="RFC5652" format="title"/>" <xreftarget="RFC5652"/>.</t>target="RFC5652" format="default"/>.</t> <t>TheCryptographic Message Syntax (CMS)CMS 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 establish the key used to encrypt and decrypt the content. In recent years, cryptographers have been specifying Key Encapsulation Mechanism (KEM) algorithms, including quantum-secure KEM algorithms. This document defines conventions for the use of KEM algorithms for the CMS enveloped-data content type and the CMS authenticated-enveloped-data content type.</t> <t>A KEM algorithm is a one-pass (store-and-forward) mechanism for transporting random keying material to a recipient using the recipient's 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 recover the random keying material, which is then treated as a pairwise shared secret (ss) between the originator and recipient.</t> <t>The KEMRecipientInfo structure defined in this document uses the pairwise 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 content-encryption key (CEK) or a content-authenticated-encryption key (CAEK) for that recipient. All of the recipientsrecievereceive the same CEK or CAEK.</t> <t>In this environment, security depends on three things. First, the KEM algorithm must be secure against adaptive chosen ciphertext attacks. Second, the 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 level of security as the KEM algorithm.</t> <t>A KEM algorithm provides three functions:</t><ul spacing="normal"> <li> <t>KeyGen()<dl spacing="normal" newline="true"> <dt>KeyGen() -> (pk,sk):</t> </li> </ul> <ul empty="true"> <li> <t>Generatesk):</dt> <dd>Generate the public key (pk) and a private key(sk).</t> </li> </ul> <ul spacing="normal"> <li> <t>Encapsulate(pk)(sk).</dd> <dt>Encapsulate(pk) -> (ct,ss):</t> </li> </ul> <ul empty="true"> <li> <t>Givenss):</dt> <dd>Given the recipient's public key (pk), produce a ciphertext (ct) to be passed to the recipient and shared secret (ss) for theoriginator.</t> </li> </ul> <ul spacing="normal"> <li> <t>Decapsulate(sk,originator.</dd> <dt>Decapsulate(sk, ct) ->ss:</t> </li> </ul> <ul empty="true"> <li> <t>Givenss:</dt> <dd>Given the private key (sk) and the ciphertext (ct), produce the shared secret (ss) for therecipient.</t> </li> </ul>recipient.</dd> </dl> <t>To support a particular KEM algorithm, the CMS originator <bcp14>MUST</bcp14> implement the KEM Encapsulate() function.</t> <t>To support a particular KEM algorithm, the CMS recipient <bcp14>MUST</bcp14> implement the KEM KeyGen() function and the KEM Decapsulate() function. The recipient's public key is usually carried in a certificate <xref target="RFC5280"/>.</t> <section anchor="terms"> <name>Terminology</name> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t><?line -18?></section> <section anchor="asn1"> <name>ASN.1</name> <t>CMS values are generated using ASN.1 <xref target="X.680"/>, which uses the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X.690"/>.</t> </section> <section anchor="cms-version-numbers"> <name>CMS Version Numbers</name> <t>As described in <xref section="1.3" sectionFormat="of" target="RFC5652"/>, the major data structures include a version number as the first item in the data structure. The version number is intended to avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and then if a decode error occurs, the version number is checked as part of theerror handlingerror-handling routine. This is a reasonable approach; it places error processing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the originator.</t> <t>Whenever the structure is updated, a higher version number will be assigned. However, to ensure maximum interoperability, the higher 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> </section> </section> <section anchor="kem-processing-overview"> <name>KEM Processing Overview</name> <t>KEM algorithms can be used with three CMS content types: the enveloped-data content type <xref target="RFC5652"/>, the authenticated-data content type <xref target="RFC5652"/>, or the authenticated-enveloped-data content type <xref target="RFC5083"/>. For simplicity, the terminology associated 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 all recipients obtain that key as an encrypted object within the KEMRecipientInfo encryptedKey field explained in <xref target="kemri"/>. All recipients use the originator-generated symmetric key to decrypt the CMS message.</t> <t>A KEM algorithm and akey-derivationkey derivation function are used to securely establish a pairwise symmetrickey-encryption key (KEK),KEK, which is used to encrypt the originator-generated CEK (or the CAEK).</t> <t>In advance, each recipient uses the KEM KeyGen() function to create a key pair. The recipient will often obtain a certificate <xref target="RFC5280"/> that includes 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> <t>The originator establishes the CEK (or the CAEK) using these steps:</t> <ol spacing="normal" type="1"><li> <t>The CEK (or the CAEK) is generated at random.</t> </li> <li> <t>For each recipient: </t> <ul spacing="normal"> <li> <t>The recipient's public key is used with the KEM Encapsulate() function to obtain a pairwise shared secret (ss) and the ciphertext for the recipient.</t> </li> <li> <t>Thekey-derivationkey derivation function is used to derive a pairwise symmetric KEK, from the pairwise ss and other data that is optionally sent in the ukm field.</t> </li> <li> <t>The KEK is used to encrypt the CEK for this recipient.</t> </li> </ul> </li> <li> <t>The CEK (or the CAEK) is used to encrypt the content for all recipients.</t> </li> </ol> <t>The recipient obtains the CEK (or the CAEK) using these steps:</t> <ol spacing="normal" type="1"><li> <t>The recipient's private key and the ciphertext are used with the KEM Decapsulate() function to obtain a pairwise ss.</t> </li> <li> <t>Thekey-derivationkey derivation function is used to derive a pairwise symmetric KEK, from the pairwise ss and other data that is optionally sent in the ukm field.</t> </li> <li> <t>The KEK is used to decrypt the CEK (or theCAEK) .</t>CAEK).</t> </li> <li> <t>The CEK (or the CAEK) is used to decrypt the content.</t> </li> </ol> </section> <section anchor="kemri"> <name>KEM Recipient Information</name> <t>This document defines KEMRecipientInfo for use with KEM algorithms. As specified inSection 6.2.5 of<xreftarget="RFC5652"/>,target="RFC5652" sectionFormat="of" section="6.2.5"/>, recipient information for additional key management techniquesareis represented in the OtherRecipientInfotype, and they are eachtype. Each key management technique is identified by a unique ASN.1 object identifier.</t> <t>The object identifier associated with KEMRecipientInfo is:</t> <artwork><![CDATA[ id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 } id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 } ]]></artwork> <t>The KEMRecipientInfo type is:</t> <artwork><![CDATA[ KEMRecipientInfo ::= SEQUENCE { version CMSVersion, -- always set to 0 rid RecipientIdentifier, kem KEMAlgorithmIdentifier, kemct OCTET STRING, kdf KeyDerivationAlgorithmIdentifier, kekLength INTEGER (1..65535), ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL, wrap KeyEncryptionAlgorithmIdentifier, encryptedKey EncryptedKey } ]]></artwork> <t>The fields of the KEMRecipientInfo type have the following meanings:</t><ul empty="true"> <li> <t>version<t indent="3">version is the syntax version number. The version <bcp14>MUST</bcp14> be 0. The CMSVersion type is described inSection 10.2.5 of<xreftarget="RFC5652"/>.</t> </li> </ul> <ul empty="true"> <li> <t>ridtarget="RFC5652" sectionFormat="of" section="10.2.5"/>.</t> <t indent="3">rid specifies the recipient's certificate or key that was used by the originator with the KEM Encapsulate() function. The RecipientIdentifier provides two alternatives for specifying the recipient's certificate <xref target="RFC5280"/>, and thereby the recipient's public 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 extension <bcp14>MUST</bcp14> assert the keyEncipherment bit. The issuerAndSerialNumber alternative identifies the recipient's certificate by the issuer's distinguished name and the certificate serial number; the subjectKeyIdentifier alternative identifies the recipient's certificate by a key identifier. When an X.509 certificate is referenced, the key identifier matches the X.509 subjectKeyIdentifier extension value. When other certificate formats are referenced, the documents that specify the certificate format and their use with the CMS must include details on matching the key identifier to the appropriate certificate field. For recipient processing, implementations <bcp14>MUST</bcp14> support both of these alternatives for specifying the recipient's certificate. For originator processing, implementations <bcp14>MUST</bcp14> support at least one of these alternatives.</t></li> </ul> <ul empty="true"> <li> <t>kem<t indent="3">kem identifies the KEM algorithm, and any associated parameters, used by the originator. The KEMAlgorithmIdentifier is described in <xref target="kemalg"/>.</t></li> </ul> <ul empty="true"> <li> <t>kemct<t indent="3">kemct is the ciphertext produced by the KEM Encapsulate() function for this recipient.</t></li> </ul> <ul empty="true"> <li> <t>kdf<t indent="3">kdf identifies thekey-derivation algorithm,key derivation function, and any associated parameters, used by the originator to generate the KEK. The KeyDerivationAlgorithmIdentifier is described inSection 10.1.6 of<xreftarget="RFC5652"/>.</t> </li> </ul> <ul empty="true"> <li> <t>kekLengthtarget="RFC5652" sectionFormat="of" section="10.1.6"/>.</t> <t indent="3">kekLength is the size of the KEK in octets. This value is one of the inputs to thekey-derivationkey derivation function. The upper bound on the integer 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 the value provided is consistent with the key-encryption algorithm identified in the wrap field below.</t></li> </ul> <ul empty="true"> <li> <t>ukm<t indent="3">ukm is optional user keying material. When the ukm value is provided, it is used as part of the info structure described in <xref target="kdf"/> to provide a context input to thekey-derivationkey derivation function. For example, the ukm value could include a nonce, application-specific context information, or an identifier for the originator. A KEM algorithm may place requirements on the ukm value. Implementations that do not support the ukm field <bcp14>SHOULD</bcp14> gracefully discontinue processing when the ukm field is present. Note that this requirement expands the original purpose of the ukm described inSection 10.2.6 of<xreftarget="RFC5652"/>;target="RFC5652" sectionFormat="of" section="10.2.6"/>; it is not limited to being used with key agreement algorithms.</t></li> </ul> <ul empty="true"> <li> <t>wrap<t indent="3">wrap identifies a key-encryption algorithm used to encrypt the CEK. The KeyEncryptionAlgorithmIdentifier is described inSection 10.1.3 of<xreftarget="RFC5652"/>.</t> </li> </ul> <ul empty="true"> <li> <t>encryptedKeytarget="RFC5652" sectionFormat="of" section="10.1.3"/>.</t> <t indent="3">encryptedKey is the result of encrypting the CEK or the CAEK (the content-authenticated-encryptionkeykey, as discussed in <xreftarget="RFC5083"/> (CAEK)target="RFC5083"/>) with the KEK. EncryptedKey is an OCTET STRING.</t></li> </ul></section> <section anchor="kemalg"> <name>KEM Algorithm Identifier</name> <t>The KEMAlgorithmIdentifier type identifies a KEM algorithm used to establish a pairwise ss. The details of establishment depend on the KEM algorithm used. AKeykey derivationalgorithmfunction is used to transform the pairwise ss value into a KEK.</t> <artwork><![CDATA[ KEMAlgorithmIdentifier ::= AlgorithmIdentifier{ KEM-ALGORITHM, {...} } ]]></artwork> </section> <section anchor="kdf"> <name>Key Derivation</name> <t>This section describes the conventions of using the KDF to compute the KEK for KEMRecipientInfo. For simplicity, the 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 the case, the hash function that is used is indirectly indicated by the KeyDerivationAlgorithmIdentifier. Other KDFs internally employ an encryption algorithm. When this is the case, the encryption that is used is indirectly indicated by the KeyDerivationAlgorithmIdentifier.</t> <t>The KDF inputsare:</t> <ul empty="true"> <li> <t>IKMare as follows:</t> <t indent="3">IKM is the inputkeykeying material. It is a symmetric secret input to the KDF. The KDFwhichmay use a hash function or an encryption algorithm to generate a pseudorandom key. The algorithm used to derive the IKM is dependent on the algorithm identified in the KeyDerivationAlgorithmIdentifier.</t></li> </ul> <ul empty="true"> <li> <t>L<t indent="3">L is the length of the output keying material inoctets whichoctets. L is identified in the kekLength of the KEMRecipientInfo. The value is dependent on the key-encryption algorithmthat is used whichused; the key-encryption algorithm is identified in the KeyEncryptionAlgorithmIdentifier.</t></li> </ul> <ul empty="true"> <li> <t>info<t indent="3">info is contextual input to the KDF. The DER-encoded CMSORIforKEMOtherInfo structure is created from elements of the KEMRecipientInfo structure. CMSORIforKEMOtherInfo is defined as:</t></li> </ul><artwork><![CDATA[ CMSORIforKEMOtherInfo ::= SEQUENCE { wrap KeyEncryptionAlgorithmIdentifier, kekLength INTEGER (1..65535), ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } ]]></artwork> <t>The CMSORIforKEMOtherInfo structurecontains:</t> <ul empty="true"> <li> <t>wrapcontains the following:</t> <t indent="3">wrap identifies a key-encryption algorithm; the output of thekey-derivationkey derivation function will be used as a key for this algorithm.</t></li> </ul> <ul empty="true"> <li> <t>kekLength<t indent="3">kekLength is the length of the KEK in octets; the output of thekey-derivationkey derivation function will be exactly this size.</t></li> </ul> <ul empty="true"> <li> <t>ukm<t indent="3">ukm is optional user keying material; see <xref target="kemri"/>.</t></li> </ul><t>The KDF outputis:</t> <ul empty="true"> <li> <t>OKMis as follows:</t> <t indent="3">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></li> </ul><t>An acceptable KDF <bcp14>MUST</bcp14> accept an IKM, L, and info as inputs. An acceptable KDF <bcp14>MAY</bcp14> also accept a salt input value, which is carried as a parameter to the KeyDerivationAlgorithmIdentifier if present. All of these inputs <bcp14>MUST</bcp14> influence the output of the KDF.</t> </section> <section anchor="asn1-mod"> <name>ASN.1 Modules</name> <t>This section provides two ASN.1 modules <xref target="X.680"/>. The first ASN.1 module is an extension to the AlgorithmInformation-2009 module discussed in <xreftarget="RFC5912"/>, andtarget="RFC5912"/>; it defines the KEM-ALGORITHM CLASS. The second ASN.1 module defines the structures needed to use KEMAlgorithmsalgorithms with CMS <xref target="RFC5652"/>.</t> <t>The first ASN.1 module uses EXPLICIT tagging, and the second ASN.1 module uses IMPLICIT tagging.</t> <t>Both ASN.1 modules follow the conventions established in <xref target="RFC5911"/>, <xref target="RFC5912"/>, and <xref target="RFC6268"/>.</t> <section anchor="asn1-mod-1"> <name>KEMAlgorithmInformation-2023 ASN.1 Module</name> <sourcecode type="asn.1" markers="true"><![CDATA[ KEMAlgorithmInformation-2023 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)id-mod-kemAlgorithmInformation-2023(TBD3)id-mod-kemAlgorithmInformation-2023(109) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL; IMPORTS ParamOptions, PUBLIC-KEY, SMIME-CAPS FROM AlgorithmInformation-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } ; -- KEM-ALGORITHM -- -- Describes the basic properties of a KEM algorithm -- -- Suggestedprefixesprefix for KEM algorithm objects is: kema- -- -- &id - contains the OID identifying the KEM algorithm -- &Value - if present, contains a type definition for the kemct; -- if absent, implies that no ASN.1 encoding is -- performed on the kemct value -- &Params - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- ¶mPresence - parameter presence requirement -- &PublicKeySet - specifies which public keys are used with -- this algorithm -- &Ukm - if absent, type for user keying material -- &ukmPresence - specifies the requirements to define the UKM -- field -- &smimeCaps - contains the object describing how the S/MIME -- capabilities are presented. -- -- Example: -- kema-kem-rsa KEM-ALGORITHM ::= { -- IDENTIFIER id-kem-rsa -- PARAMS TYPE RsaKemParameters ARE optional -- PUBLIC-KEYS { pk-rsa | pk-rsa-kem } -- UKM ARE optional -- SMIME-CAPS { TYPE GenericHybridParameters -- IDENTIFIED BY id-rsa-kem } -- } KEM-ALGORITHM ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Value OPTIONAL, &Params OPTIONAL, ¶mPresence ParamOptions DEFAULT absent, &PublicKeySet PUBLIC-KEY OPTIONAL, &Ukm OPTIONAL, &ukmPresence ParamOptions DEFAULT absent, &smimeCaps SMIME-CAPS OPTIONAL } WITH SYNTAX { IDENTIFIER &id [VALUE &Value] [PARAMS [TYPE &Params] ARE ¶mPresence] [PUBLIC-KEYS &PublicKeySet] [UKM [TYPE &Ukm] ARE &ukmPresence] [SMIME-CAPS &smimeCaps] } END ]]></sourcecode> </section> <section anchor="asn1-mod-2"><name>CMS-KEMRecipientInfo<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[ CMS-KEMRecipientInfo-2023 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)id-mod-cms-kemri-2023(TBD2)id-mod-cms-kemri-2023(77) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS ALL; IMPORTS OTHER-RECIPIENT, CMSVersion, RecipientIdentifier, EncryptedKey, KeyDerivationAlgorithmIdentifier, KeyEncryptionAlgorithmIdentifier, UserKeyingMaterial FROM CryptographicMessageSyntax-2010 --[RFC6268]RFC 6268 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } KEM-ALGORITHM FROM KEMAlgorithmInformation-2023 --[THISRFC]RFC 9629 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)id-mod-kemAlgorithmInformation-2023(TBD3)id-mod-kemAlgorithmInformation-2023(109) } AlgorithmIdentifier{} FROM AlgorithmInformation-2009 --[RFC5912]RFC 5912 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } ; -- -- OtherRecipientInfo Types (ori-) -- SupportedOtherRecipInfo OTHER-RECIPIENT ::= { ori-KEM, ... } ori-KEM OTHER-RECIPIENT ::= { KEMRecipientInfo IDENTIFIED BY id-ori-kem } id-ori OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 13 } id-ori-kem OBJECT IDENTIFIER ::= { id-ori 3 } -- -- KEMRecipientInfo -- KEMRecipientInfo ::= SEQUENCE { version CMSVersion, -- always set to 0 rid RecipientIdentifier, kem KEMAlgorithmIdentifier, kemct OCTET STRING, kdf KeyDerivationAlgorithmIdentifier, kekLength INTEGER (1..65535), ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL, wrap KeyEncryptionAlgorithmIdentifier, encryptedKey EncryptedKey } KEMAlgSet KEM-ALGORITHM ::= { ... } KEMAlgorithmIdentifier ::= AlgorithmIdentifier{ KEM-ALGORITHM, {KEMAlgSet} } -- -- CMSORIforKEMOtherInfo -- CMSORIforKEMOtherInfo ::= SEQUENCE { wrap KeyEncryptionAlgorithmIdentifier, kekLength INTEGER (1..65535), ukm [0] EXPLICIT UserKeyingMaterial OPTIONAL } END ]]></sourcecode> </section> </section> <section anchor="sec-cons"> <name>Security Considerations</name> <t>TheSecurity Considerations ofsecurity considerations discussed in <xref target="RFC5652"/> are applicable to this document.</t> <t>To be appropriate for use with this specification, the KEM algorithm <bcp14>MUST</bcp14> 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 notappropriateappropriate, because the public key is expected to be carried in a long-lived certificate <xref target="RFC5280"/> and used over and over. Thus, KEM algorithms that offer indistinguishability under adaptive chosen ciphertext attack (IND-CCA2) security are appropriate. A common design pattern for 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 transform <xref target="HHK"/>.</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 KEK <bcp14>SHOULD</bcp14> be made based on the security level provided by the KEM. The key-encryption algorithm and the KEK <bcp14>SHOULD</bcp14> offer at leasthavethe security level of the KEM.</t> <t>KEM algorithms do not provide data origin authentication; therefore, when a KEM algorithm is used with the authenticated-data content type, the contents are delivered with integrity from an unknown source.</t> <t>Implementations <bcp14>MUST</bcp14> protect the KEM private key, the KEK, and the CEK (or the CAEK). Compromise of the KEM private key may 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 of the encrypted content of a single message.</t> <t>The KEM produces the IKM input value for the KDF. This IKM value <bcp14>MUST NOT</bcp14> 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> be reused for any other purpose. That is, the originator <bcp14>MUST</bcp14> generate a fresh KEM shared secret for each recipient in the KEMRecipientInfo 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 secret, including any random value used by the KEM algorithm to produce the KEM shared secret, after constructing the entry in the KEMRecipientInfo structure for the corresponding recipient. Similarly, the recipient <bcp14>MUST</bcp14> discard the KEM shared secret, including any random value used by the KEM algorithm to produce the KEM shared secret, after constructing the KEK from the KEMRecipientInfo structure.</t> <t>Implementations <bcp14>MUST</bcp14> randomly generate content-encryption keys, content-authenticated-encryption keys, and message-authentication keys. Also, the generation of KEM key pairs relies on random numbers. The use of inadequatepseudo-randompseudorandom number generators (PRNGs) to generate these keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather thanbrute forcebrute-force searching the whole key space. The generation of quality random numbers is difficult. <xref target="RFC4086"/> offers important guidance in this area.</t> <t>If the cipher and key sizes used for the key-encryption algorithm and the content-encryptionalgorithmsalgorithm are different, the effective security is determined by the weaker of the two algorithms. If, for example, the content is encrypted with AES-CBC using a 128-bitCEK,CEK and the CEK is wrapped with AES-KEYWRAP using a 256-bit KEK, then at most 128 bits of protection is provided.</t> <t>If the cipher and key sizes used for the key-encryption algorithm and the content-authenticated-encryptionalgorithmsalgorithm are different, the effective security is determined by the weaker of the two algorithms. If, for example, the content is encrypted with AES-GCM using a 128-bitCAEK,CAEK and the CAEK is wrapped with AES-KEYWRAP using a 192-bit KEK, then at most 128 bits of protection is provided.</t> <t>If the cipher and key sizes used for the key-encryption algorithm and the message-authenticationalgorithmsalgorithm are different, the effective security is determined by the weaker of the two algorithms. If, for example, the content is authenticated with HMAC-SHA256 using a 512-bit message-authenticationkey,key and the message-authentication key is wrapped with AES-KEYWRAP using a 256-bit KEK, then at most 256 bits of protection is provided.</t> <t>Implementers should be aware that cryptographic algorithms, including KEM algorithms, become weaker with time. As new cryptoanalysis techniques are developed and computing capabilities advance, the work factor to break a particular cryptographic algorithm will be reduced. As a result, cryptographic algorithm implementations should be modular, allowing new algorithms to be readily inserted. That is, implementers should be prepared for the set of supported algorithms to change over time.</t> </section> <section anchor="iana"> <name>IANA Considerations</name> <t>For KEMRecipientInfo as defined in <xref target="kemri"/>, IANA has assigned theobject identifier (OID) for (1.2.840.113549.1.9.16.13.3)following OID in the "SMI Security for S/MIME Other Recipient InfoIdentifiers" registry (1.2.840.113549.1.9.16.13), and the Description for the new OID has been set to "id-ori-kem".</t>Identifiers (1.2.840.113549.1.9.16.13)" registry: </t> <table anchor="iana-table1" align="left"> <name></name> <thead> <tr> <th>Decimal</th> <th>Description</th> <th>References</th> </tr> </thead> <tbody> <tr> <td>3</td> <td>id-ori-kem</td> <td>RFC 9629</td> </tr> </tbody> </table> <t>For the ASN.1Modulemodule defined in <xref target="asn1-mod-1"/>, IANAis requested to assign an object identifier (OID) forhas assigned themodule identifier to replace TBD3. Thefollowing OIDfor the module should be allocatedin the "SMI Security for PKIX Module Identifier" registry(1.3.6.1.5.5.7.0), and the Description for the new OID should be set to "id-mod-kemAlgorithmInformation-2023".</t>(1.3.6.1.5.5.7.0): </t> <table anchor="iana-table2" align="left"> <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.1Modulemodule defined in <xref target="asn1-mod-2"/>, IANAis requested to assign an object identifier (OID) forhas assigned themodule identifier to replace TBD2. Thefollowing OIDfor the module should be allocatedin the "SMI Security for S/MIME ModuleIdentifier" registry (1.2.840.113549.1.9.16.0), and the Description for the new OID should be set to "id-mod-cms-kemri-2023".</t> </section> <section numbered="false" anchor="acknowledgements"> <name>Acknowledgements</name> <t>Our thanks to Burt Kaliski for his guidance and design review.</t> <t>Our thanks to Carl Wallace for his careful review of the ASN.1 modules.</t> <t>Our thanks to Hendrik Brockhaus, Jonathan Hammell, Mike Jenkins, David von Oheimb, Francois Rousseau, and Linda Dunbar for their careful review and thoughtful comments.</t>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> </middle> <back> <references> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC5083"> <front> <title>Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type</title> <author fullname="R. Housley" initials="R." surname="Housley"/> <date month="November" year="2007"/> <abstract> <t>This document describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. [STANDARDS-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 Certificate 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 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [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 arbitrary 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 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 changes to any of the formats; 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.509 (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 format, 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 changes to any of the formats; 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="5912"/> <seriesInfo name="DOI" value="10.17487/RFC5912"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5083.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/> <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680"> <front> <title>Information technology--- Abstract Syntax Notation One (ASN.1): Specification of basic notation</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-T Recommendation" value="X.680"/> <seriesInfo name="ISO/IEC" value="8824-1:2021"/> </reference> <reference anchor="X.690"target="https://www.itu.int/rec/T-REC-X.680">target="https://www.itu.int/rec/T-REC-X.690"> <front> <title>Information technology--- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <author> <organization>ITU-T</organization> </author> <date year="2021" month="February"/> </front> <seriesInfo name="ITU-T Recommendation" value="X.690"/> <seriesInfo name="ISO/IEC" value="8825-1:2021"/> </reference><reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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</title> <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 protocol 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/> <referenceanchor="RFC4086"> <front> <title>Randomness Requirements for Security</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> <author fullname="J. Schiller" initials="J." surname="Schiller"/> <author fullname="S. Crocker" initials="S." surname="Crocker"/> <date month="June" year="2005"/> <abstract> <t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole 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 using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware 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 Current Practices for the Internet Community, and requests discussion and suggestions 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 building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</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 Syntax (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 associated 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 conform 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 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="6268"/> <seriesInfo name="DOI" value="10.17487/RFC6268"/> </reference> <reference anchor="FO">anchor="FO" target="https://doi.org/10.1007/s00145-011-9114-1"> <front> <title>Secure Integration of Asymmetric and Symmetric Encryption Schemes</title> <author fullname="Eiichiro Fujisaki" initials="E." surname="Fujisaki"> <organization/> </author> <author fullname="Tatsuaki Okamoto" initials="T." surname="Okamoto"> <organization/> </author> <date month="December" year="2011"/> </front><seriesInfo name="Journal<refcontent>Springer Science and Business Media LLC</refcontent> <refcontent>Journal ofCryptology" value="vol.Cryptology, vol. 26, no. 1, pp.80-101"/>80-101</refcontent> <seriesInfo name="DOI" value="10.1007/s00145-011-9114-1"/><refcontent>Springer Science and Business Media LLC</refcontent></reference> <referenceanchor="HHK">anchor="HHK" target="https://doi.org/10.1007/978-3-319-70500-2_12"> <front> <title>A Modular Analysis of the Fujisaki-Okamoto Transformation</title> <author fullname="Dennis Hofheinz" initials="D." surname="Hofheinz"> <organization/> </author> <author fullname="Kathrin Hövelmanns" initials="K." surname="Hövelmanns"> <organization/> </author> <author fullname="Eike Kiltz" initials="E." surname="Kiltz"> <organization/> </author> <date month="November" year="2017"/> </front><seriesInfo name="Theory<refcontent>Springer International Publishing</refcontent> <refcontent>Theory ofCryptography" value="pp. 341-371"/>Cryptography, TCC 2017, Lecture Notes in Computer Science, vol. 10677, pp. 341-371</refcontent> <refcontent>Print ISBN 9783319704999, Online ISBN 9783319705002</refcontent> <seriesInfo name="DOI" value="10.1007/978-3-319-70500-2_12"/><seriesInfo name="ISBN" value="["9783319704999", "9783319705002"]"/> <refcontent>Springer International Publishing</refcontent></reference> </references> </references><?line 685?><section numbered="false" anchor="acknowledgements"> <name>Acknowledgements</name> <t>Our thanks to <contact fullname="Burt Kaliski"/> for his guidance and design 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><!-- ##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>