<?xml version='1.0' encoding='utf-8'?> encoding='UTF-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.2 (Ruby 2.6.10) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-cms-sha3-hash-04" number="9688" obsoletes="" updates="" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 --> version="3" xml:lang="en">

  <front>
    <title abbrev="Using SHA3 with the CMS">Use of the SHA3 One-way One-Way Hash Functions in the Cryptographic Message Syntax (CMS)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-sha3-hash-04"/> name="RFC" value="9688"/>
    <author initials="R." surname="Housley" fullname="Russ Housley">
      <organization abbrev="Vigil Security">Vigil Security, LLC</organization>
      <address>
        <postal>
          <city>Herndon</city>
          <region>VA</region>
          <country>United States of America</country>
        </postal>
        <email>housley@vigilsec.com</email>
      </address>
    </author>
    <date year="2024" month="May" day="16"/>
    <area>Security</area>
    <keyword>Internet-Draft</keyword> month="November"/>

    <area>SEC</area>
    <workgroup>lamps</workgroup>

<keyword>example</keyword>

    <abstract>
      <?line 119?>
<t>This document describes the conventions for using the one-way hash functions
in the SHA3 family with the Cryptographic Message Syntax (CMS).  The SHA3
family can be used as a message digest algorithm, as part of a signature
algorithm, as part of a message authentication code, or as part of a key
derivation function.</t> Key
Derivation Function (KDF).</t>
    </abstract>
  </front>
  <middle>
    <?line 127?>
<section anchor="intro">
      <name>Introduction</name>
      <t>The Cryptographic Message Syntax (CMS) <xref target="RFC5652"/> is used to digitally sign,
digest, authenticate, or encrypt arbitrary message contents.  This
specification describes the use of the four one-way hash functions in the
SHA3 family (SHA3-224, SHA3-256, SHA3-384, and SHA3-512) <xref target="SHA3"/> with the
CMS.  In addition, this specification describes the use of these four
one-way hash functions with the RSASSA PKCS#1 version 1.5 signature
algorithm <xref target="RFC8017"/> and the Elliptic Curve Digital Signature Algorithm
(ECDSA) <xref target="DSS"/> with the CMS signed-data content type.</t>
      <t>This document should not be confused with RFC 8702 <xref target="RFC8702"/>, which defines
conventions for using the the SHAKE family of SHA3-based extensible output
functions with the CMS.</t>
      <section anchor="asn1">
        <name>ASN.1</name>
        <t>CMS values are generated using with ASN.1 <xref target="X.680"/>, using the Basic
Encoding Rules (BER) and the Distinguished Encoding Rules (DER) <xref target="X.690"/>.</t>
      </section>
      <section anchor="terminology">
        <name>Terminology</name>
        <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
<?line -6?>
        </t>
      </section>
    </section>
    <section anchor="sha3oids">
      <name>Message Digest Algorithms</name>
      <t>One-way hash functions are also referred to as message digest algorithms.
This section specifies the conventions employed by CMS implementations
that support SHA3-224, SHA3-256, SHA3-384, and SHA3-512 <xref target="SHA3"/>.</t>
<t>Digest algorithm identifiers are located in the SignedData digestAlgorithms
field, the SignerInfo digestAlgorithm field, the DigestedData digestAlgorithm
field, and the AuthenticatedData digestAlgorithm field.</t> <t>Digest values
are located in the DigestedData digest field and the Message Digest
authenticated attribute.  In addition, digest values are input to signature
algorithms.</t>
      <t>SHA3-224, SHA3-256, SHA3-384, and SHA3-512 produce output values with
224, 256, 384, and 512 bits, respectively.  The object identifiers for
      these four one-way hash functions are as follows:</t>
      <sourcecode type="asn.1"><![CDATA[
   hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
       us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 }

   id-sha3-224 OBJECT IDENTIFIER ::= { hashAlgs 7 }

   id-sha3-256 OBJECT IDENTIFIER ::= { hashAlgs 8 }

   id-sha3-384 OBJECT IDENTIFIER ::= { hashAlgs 9 }

   id-sha3-512 OBJECT IDENTIFIER ::= { hashAlgs 10 }
]]></sourcecode>
      <t>When using the id-sha3-224, id-sha3-s256, id-sha3-384, or id-sha3-512
algorithm identifiers, the parameters field MUST <bcp14>MUST</bcp14> be absent; absent, not NULL
but absent.</t>
    </section>
    <section anchor="signature-algorithms">
      <name>Signature Algorithms</name>
      <t>This section specifies the conventions employed by CMS implementations
that support the four SHA3 one-way hash functions with the RSASSA PKCS#1
version 1.5 v1.5 signature algorithm <xref target="RFC8017"/> and the Elliptic Curve Digital
Signature Algorithm (ECDSA) ECDSA <xref target="DSS"/> with the CMS signed-data content type.</t>
      <t>Signature algorithm identifiers are located in the SignerInfo
signatureAlgorithm field of SignedData.  Also, signature algorithm
identifiers are located in the SignerInfo signatureAlgorithm field
of countersignature attributes.</t>
      <t>Signature values are located in the SignerInfo signature field of
SignedData.  Also, signature values are located in the SignerInfo
signature field of countersignature attributes.</t>
      <section anchor="rsassa-pkcs1-v15-with-sha3">
        <name>RSASSA PKCS#1 v1.5 with SHA3</name>
        <t>The RSASSA PKCS#1 v1.5 is defined in <xref target="RFC8017"/>.  When RSASSA PKCS#1 v1.5 is
used in conjunction with one of the SHA3 one-way hash functions, the
object identifiers are:</t>
        <sourcecode type="asn.1"><![CDATA[
   OID ::= OBJECT IDENTIFIER

   sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
       us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 }

   id-rsassa-pkcs1-v1-5-with-sha3-224 OID ::= { sigAlgs 13 }

   id-rsassa-pkcs1-v1-5-with-sha3-256 OID ::= { sigAlgs 14 }

   id-rsassa-pkcs1-v1-5-with-sha3-384 OID ::= { sigAlgs 15 }

   id-rsassa-pkcs1-v1-5-with-sha3-512 OID ::= { sigAlgs 16 }
]]></sourcecode>
        <t>The algorithm identifier for RSASSA PKCS#1 v1.5 subject public keys
in certificates is specified in <xref target="RFC3279"/>, and it is repeated here for
convenience:</t>
        <sourcecode type="asn.1"><![CDATA[
   rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
]]></sourcecode>
        <t>When the rsaEncryption, id-rsassa-pkcs1-v1-5-with-sha3-224,
id-rsassa-pkcs1-v1-5-with-sha3-256,
id-rsassa-pkcs1-v1-5-with-sha3-384, and
id-rsassa-pkcs1-v1-5-with-sha3-512 algorithm identifier is identifiers are used,
the AlgorithmIdentifier parameters field MUST <bcp14>MUST</bcp14> contain NULL.</t>
        <t>When the rsaEncryption algorithm identifier is used, the RSA public key,
which is composed of a modulus and a public exponent, MUST <bcp14>MUST</bcp14> be encoded
using the RSAPublicKey type as specified in <xref target="RFC3279"/>.  The output of
this encoding is carried in the certificate subject public key.  The
definition of RSAPublicKey is repeated here for convenience:</t>
        <sourcecode type="asn.1"><![CDATA[
   RSAPublicKey ::= SEQUENCE {
      modulus INTEGER, -- n
      publicExponent INTEGER } -- e
]]></sourcecode>
        <t>When signing, the RSASSA PKCS#1 v1.5 signature algorithm generates a
single value, and that value. That value is used directly as the signature value.</t>
      </section>
      <section anchor="ecdsa-with-sha3">
        <name>ECDSA with SHA3</name>
        <t>The Elliptic Curve Digital Signature Algorithm (ECDSA) ECDSA is defined in
<xref target="DSS"/>.  When the ECDSA is used in conjunction with one of the SHA3
one-way hash functions, the object identifiers are:</t>
        <sourcecode type="asn.1"><![CDATA[
   sigAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
       us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 3 }

   id-ecdsa-with-sha3-224 OBJECT IDENTIFIER ::= { sigAlgs 9 }

   id-ecdsa-with-sha3-256 OBJECT IDENTIFIER ::= { sigAlgs 10 }

   id-ecdsa-with-sha3-384 OBJECT IDENTIFIER ::= { sigAlgs 11 }

   id-ecdsa-with-sha3-512 OBJECT IDENTIFIER ::= { sigAlgs 12 }
   ]]></sourcecode>
        <t>When using
<t> When the id-sha3-224, id-sha3-s256, id-sha3-384, or id-sha3-512 algorithm
identifier is used, the parameters field <bcp14>MUST</bcp14> be absent, not NULL but absent.</t>
<t> When the id-ecdsa-with-sha3-224, id-ecdsa-with-sha3-256,
id-ecdsa-with-sha3-384, id-
ecdsa-with-sha3-384, and id-ecdsa-with-sha3-512 algorithm identifiers, identifiers are
used, the parameters field MUST <bcp14>MUST</bcp14> be absent; absent, not NULL but absent.</t>
<t>The conventions for
ECDSA public keys is are as specified in <xref target="RFC5480"/>.  The
ECParameters associated with the ECDSA public key in the signers certificate SHALL
<bcp14>SHALL</bcp14> apply to the verification of the signature.</t> <t>When
signing, the ECDSA algorithm generates two values.  These values are commonly
referred to as r and s.  To easily transfer these two values as one signature,
they MUST <bcp14>MUST</bcp14> be ASN.1 encoded using the ECDSA-Sig-Value defined in
<xref target="RFC3279"/> and target="RFC3279"/>, which is repeated here for convenience:</t>
<sourcecode type="asn.1"><![CDATA[ ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s
INTEGER } ]]></sourcecode>
      </section>
    </section>
    <section anchor="message-authentication-codes-using-hmac-and-sha3">
      <name>Message Authentication Codes using Using HMAC and SHA3</name>
      <t>This section specifies the conventions employed by CMS implementations
that support the HMAC Hashed Message Authentication Code (HMAC) <xref target="RFC2104"/> with SHA3 message authentication code (MAC).</t>
      <t>MAC algorithm identifiers are located in the AuthenticatedData
macAlgorithm field.</t>
      <t>MAC values are located in the AuthenticatedData mac field.</t>
      <t>When HMAC is used in conjunction with one of the SHA3
one-way hash functions, the object identifiers are:</t>
      <sourcecode type="asn.1"><![CDATA[
   hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
       us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 }

   id-hmacWithSHA3-224 OBJECT IDENTIFIER ::= { hashAlgs 13 }

   id-hmacWithSHA3-256 OBJECT IDENTIFIER ::= { hashAlgs 14 }

   id-hmacWithSHA3-384 OBJECT IDENTIFIER ::= { hashAlgs 15 }

   id-hmacWithSHA3-512 OBJECT IDENTIFIER ::= { hashAlgs 16 }
]]></sourcecode>
      <t>When the id-hmacWithSHA3-224, id-hmacWithSHA3-256,
id-hmacWithSHA3-384, and id-hmacWithSHA3-512 algorithm
identifier is
identifiers are used, the parameters field MUST <bcp14>MUST</bcp14> be absent; absent,
not NULL but absent.</t>
    </section>
    <section anchor="key-derivation-functions">
      <name>Key Derivation Functions</name>
      <t>The CMS KEMRecipientInfo structure <xref target="I-D.ietf-lamps-cms-kemri"/> target="RFC9629"/> is one place where
algorithm identifiers for key-derivation functions are needed.</t>
      <section anchor="hkdf-with-sha3">
        <name>HKDF with SHA3</name>
        <t>This section assigns four algorithm identifiers that can be employed by CMS
implementations that support the HMAC-based Extract-and-Expand Key Derivation
Function (HKDF) <xref target="RFC5869"/> with the SHA3 family of hash functions.</t>
        <t>When HKDF is used in conjunction with one of the SHA3
one-way hash functions, the object identifiers are:</t>
        <sourcecode type="asn.1"><![CDATA[
   id-alg OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3 }

   id-alg-hkdf-with-sha3-224 OBJECT IDENTIFIER ::= { id-alg TBD1 32 }

   id-alg-hkdf-with-sha3-256 OBJECT IDENTIFIER ::= { id-alg TBD2 33 }

   id-alg-hkdf-with-sha3-384 OBJECT IDENTIFIER ::= { id-alg TBD3 34 }

   id-alg-hkdf-with-sha3-512 OBJECT IDENTIFIER ::= { id-alg TBD4 35 }
]]></sourcecode>
<t>When id-alg-hkdf-with-sha3-224, id-alg-hkdf-with-sha3-256,
id-alg-hkdf-with-sha3-384, or id-alg-hkdf-with-sha3-512 is used in
an algorithm identifier, the parameters field MUST <bcp14>MUST</bcp14> be absent; absent,
not NULL but absent.</t>
      </section>
      <section anchor="kmac128-kdf-and-kmac256-kdf">
        <name>KMAC128-KDF and KMAC256-KDF</name>
        <t>This section specifies the conventions employed by CMS implementations
that employ either the KMAC128 or KMAC256 as a key derivation function KDFs as
defined in Section 4.4 of <xref target="NIST.SP.800-108r1-upd1"/>.</t>
        <t>KMAC128 and KMAC256 are specified in <xref target="NIST.SP.800-185"/>. The use of KMAC128
and KMAC256 as a key derivation function KDFs are defined as:</t>
        <ul empty="true">
          <li>
            <t>KMAC128-KDF as follows:</t>
            <t indent="3">KMAC128-KDF is KMAC128(K, X, L, S).</t>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <t>KMAC256-KDF
            <t indent="3">KMAC256-KDF is KMAC256(K, X, L, S).</t>
          </li>
        </ul>
        <t>The parameters to the KMAC128 and KMAC256 functions are:</t>
        <ul empty="true">
          <li>
<dl>
              <dt>K</dt>
              <dd>
                <t>the
                <t>The input key-derivation key.  The length of K MUST <bcp14>MUST</bcp14> be less than 2^2040.</t> 2<sup>2040</sup>.</t>
              </dd>
            </dl>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <dl>
              <dt>X</dt>
              <dd>
                <t>the
                <t>The context, which contains the ASN.1 DER encoding of CMSORIforKEMOtherInfo when the KDF is used with <xref target="I-D.ietf-lamps-cms-kemri"/>.</t> target="RFC9629"/>.</t>
              </dd>
            </dl>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <dl>
              <dt>L</dt>
              <dd>
                <t>the
                <t>The output length, length in bits.  L MUST <bcp14>MUST</bcp14> be greater than or equal to 0, 0 and L MUST <bcp14>MUST</bcp14> be less than 2^2040.</t> 2<sup>2040</sup>.</t>
              </dd>
            </dl>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <dl>
              <dt>S</dt>
              <dd>
                <t>the
                <t>The optional customization label, such as "KDF" (0x4B4446).  The length of S MUST <bcp14>MUST</bcp14> be less than 2^2040.</t> 2<sup>2040</sup>.</t>
              </dd>
            </dl>
          </li>
        </ul>
        <t>The K parameter is known to all authorized parties; it is often the output
of a KEM Decap() operation.  The X parameter is assembled from data that
is transmitted by the originator.  The L parameter is determined by the
size of the output keying material.  The S parameter is optional, and if
it is provided by the originator, it is passed in the parameters field of
the KDF algorithm identifier.</t>
        <t>When KMAC128-KDF or KMAC256-KDF is used, the object identifiers are:</t>
        <sourcecode type="asn.1"><![CDATA[
   hashAlgs OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
       us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 }

   id-kmac128 OBJECT IDENTIFIER ::= { hashAlgs 21 }

   id-kmac256 OBJECT IDENTIFIER ::= { hashAlgs 22 }
]]></sourcecode>
        <t>When the id-kmac128 or id-kmac256 is used as part of an algorithm identifier, the
parameters field MUST <bcp14>MUST</bcp14> be absent when there is no customization label S. (S).  If any
value is provided for S, then the parameters field MUST <bcp14>MUST</bcp14> be present and
contain the value of S, encoded as Customization.</t>
        <sourcecode type="asn.1"><![CDATA[
   Customization ::= OCTET STRING
]]></sourcecode>
      </section>
      <section anchor="kdf2-and-kdf3-with-sha3">
        <name>KDF2 and KDF3 with SHA3</name>
        <t>This section specifies the conventions employed by CMS implementations
that employ either the KDF2 or KDF3 functions defined in <xref target="ANS-X9.44"/>. target="ANS-X9.44-2007"/>.
The CMS KEMRecipientInfo structure <xref target="I-D.ietf-lamps-cms-kemri"/> target="RFC9629"/> is one
place where algorithm identifiers for key-derivation functions are needed.</t>
        <t>The key-derivation function algorithm identifier is an object identifier
and optional parameters.  When KDF2 and KDF3 are used, they are identified by
the id-kdf-kdf2 and id-kdf-kdf3 object identifiers, respectively.  The
key-derivation function algorithm identifier parameters carry a message
digest algorithm identifier, which indicates the hash function that
is being employed.  To support SHA3, the key-derivation function
algorithm identifier parameters contain an algorithm identifier from
<xref target="sha3oids"/>.</t>
        <sourcecode type="asn.1"><![CDATA[
   x9-44 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
       tc68(133) country(16) x9(840) x9Standards(9) x9-44(44) }

   x9-44-components OBJECT IDENTIFIER ::= { x9-44 components(1) }

   id-kdf-kdf2 OBJECT IDENTIFIER ::= { x9-44-components kdf2(1) }

   id-kdf-kdf3 OBJECT IDENTIFIER ::= { x9-44-components kdf3(2) }
]]></sourcecode>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Implementations must protect the signer's private key.  Compromise of the
signer's private key permits masquerade.</t>
      <t>Implementations must protect the key-derivation key.  Compromise of the
key-derivation key permits others to derive the derived keying material,
which would result in loss of confidentiality, integrity, or authentication,
depending on the use of the derived keying material.</t>
      <t>When more than two parties share the same message-authentication key,
data origin authentication is not assured.  Any party that knows the
message-authentication key can compute a valid MAC, therefore MAC; therefore, the content
could originate from any one of the parties.</t>
      <t>Implementations
<!-- [rfced] Should "k value" use the uppercase form "K value" per the
parameters to the KMAC functions defined in Section 5.2?

Original:
   Implementations must randomly generate message-authentication keys
   and one-time values, such as the k value when generating a ECDSA signature.

Perhaps:
   Implementations must randomly generate message-authentication keys and
   one-time values, such as the K value when generating an ECDSA signature.
-->
      <t>  Implementations must randomly generate message-authentication keys
  and one-time values, such as the a per-message secret number (called the
  k value) when generating a ECDSA signature.
In addition, the generation of public/private key pairs relies on a
random numbers.  The use of inadequate pseudo-random pseudorandom number generators
(PRNGs) to generate cryptographic values can result in little or no
security.  Instead of brute force brute-force searching the whole key space, an
attacker may find it much easier to reproduce the PRNG environment that
produced the keys, keys and then search the resulting small set of
possibilities.  The generation of quality random numbers is
difficult.  RFC 4086  <xref target="RFC4086"/> offers important guidance in this area,
and Appendix 3 of FIPS Pub PUB 186-4 <xref target="DSS"/> provides some PRNG techniques.</t>
      <t>Implementers should be aware that cryptographic algorithms become weaker
with time.  As new cryptanalysis techniques are developed and computing
performance improves, the work factor to break a particular cryptographic
algorithm will reduce.  Therefore, cryptographic algorithm
implementations should be modular modular, allowing new algorithms to be readily
inserted.  That is, implementers should be prepared to regularly update
the set of algorithms in their implementations.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is asked to assign has assigned one object identifier for the ASN.1 module in <xref target="asn1mod"/>
in the "SMI Security for S/MIME Module Identifiers (1.2.840.113549.1.9.16.0)"
registry <xref target="IANA-MOD"/>:</t>
      <sourcecode type="asn1"><![CDATA[
   id-mod-sha3-oids-2023 OBJECT IDENTIFIER ::= {
      iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) mod(0) TBD0 78 }
]]></sourcecode>
      <t>IANA is asked to assign has assigned four object identifiers for the HKDF using SHA3 algorithm
identifiers in the "SMI Security for S/MIME Algorithms (1.2.840.113549.1.9.16.3)"
registry <xref target="IANA-ALG"/>:</t>
      <sourcecode type="asn1"><![CDATA[
   id-alg-hkdf-with-sha3-224 OBJECT IDENTIFIER ::= { id-alg TBD1 32 }

   id-alg-hkdf-with-sha3-256 OBJECT IDENTIFIER ::= { id-alg TBD2 33 }

   id-alg-hkdf-with-sha3-384 OBJECT IDENTIFIER ::= { id-alg TBD3 34 }

   id-alg-hkdf-with-sha3-512 OBJECT IDENTIFIER ::= { id-alg TBD4 35 }
]]></sourcecode>
    </section>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Thanks to
Daniel Van Geest and
Sean Turner
for their careful review and thoughtful comments.</t>
      <t>Thanks to Sara Kerman, Quynh Dang, and David Cooper
for getting the object identifiers assigned for KMAC128 and KMAC256.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="ANS-X9.44"> anchor="ANS-X9.44-2007" target="https://webstore.ansi.org/standards/ascx9/ansix9442007r2017">
          <front>
            <title>Public Key Cryptography for the Financial Services Industry -- Key Establishment Using Integer Factorization Cryptography</title>
            <author>
              <organization>American National Standards Institute</organization>
            </author>
            <date year="2007"/> year="2017"/>
          </front>
          <seriesInfo name="American National Standard" value="X9.44"/> name="ANSI" value="X9.44-2007 (R2017)"/>
        </reference>

        <reference anchor="NIST.SP.800-108r1-upd1" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf">
          <front>
            <title>Recommendation for key derivation using pseudorandom functions</title>
            <author> Key Derivation Using Pseudorandom Functions</title>
            <author fullname="Lily Chen">
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date year="2024" month="February" day="02"/>
          </front>
          <seriesInfo name="NIST SP" value="800-108r1-upd1"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-108r1-upd1"/>
        </reference>

        <reference anchor="NIST.SP.800-185" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf">
          <front>
            <title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash</title>
            <author>
            <author fullname="John Kelsey">
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date year="2016" month="December"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-185"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-185"/>
        </reference>
        <reference anchor="RFC2104">
          <front>
            <title>HMAC: Keyed-Hashing for Message Authentication</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
            <author fullname="M. Bellare" initials="M." surname="Bellare"/>
            <author fullname="R. Canetti" initials="R." surname="Canetti"/>
            <date month="February" year="1997"/>
            <abstract>
              <t>This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2104"/>
          <seriesInfo name="DOI" value="10.17487/RFC2104"/>
        </reference>
        <reference anchor="RFC3279">
          <front>
            <title>Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="L. Bassham" initials="L." surname="Bassham"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <date month="April" year="2002"/>
            <abstract>
              <t>This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3279"/>
          <seriesInfo name="DOI" value="10.17487/RFC3279"/>
        </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="RFC5480">
          <front>
            <title>Elliptic Curve Cryptography Subject Public Key Information</title>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <author fullname="D. Brown" initials="D." surname="Brown"/>
            <author fullname="K. Yiu" initials="K." surname="Yiu"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="T. Polk" initials="T." surname="Polk"/>
            <date month="March" year="2009"/>
            <abstract>
              <t>This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module fullname="Shu-jen Chang">
              <organization>National Institute of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate Standards and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5480"/>
          <seriesInfo name="DOI" value="10.17487/RFC5480"/>
        </reference>
        <reference anchor="RFC5869">
          <front>
            <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
            <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/> Technology</organization>
            </author>
            <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 fullname="Ray Perlner">
              <organization>National Institute 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="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>
        <reference anchor="RFC8017">
          <front>
            <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
            <author fullname="K. Moriarty" initials="K." role="editor" surname="Moriarty"/>
            <author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
            <author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
            <author fullname="A. Rusch" initials="A." surname="Rusch"/> Technology</organization>
            </author>
            <date month="November" year="2016"/>
            <abstract>
              <t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t>
              <t>This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.</t>
              <t>This document also obsoletes RFC 3447.</t>
            </abstract> year="2016" month="December"/>
          </front>
          <seriesInfo name="RFC" value="8017"/> name="NIST SP" value="800-185"/>
          <seriesInfo name="DOI" value="10.17487/RFC8017"/> value="10.6028/NIST.SP.800-185"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3279.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.5480.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.5912.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>

        <reference anchor="SHA3" target="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf">
          <front>
            <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date year="2015" month="August"/>
          </front>
          <seriesInfo name="FIPS PUB" name="NIST FIPS" value="202"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
        </reference>

        <reference anchor="DSS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf">
          <front>
            <title>Digital Signature Standard (DSS)</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date year="2023" month="February" day="03"/>
          </front>
          <seriesInfo name="FIPS PUB" value="186-5"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
        </reference>

        <reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680"> target="https://www.itu.int/rec/T-REC-X.680-202102-I/en">
          <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-202102-I/en">
          <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>

        <reference anchor="IANA-ALG" target="https://www.iana.org/assignments/smi-numbers/">
          <front>
            <title>SMI Security for for S/MIME Algorithms (1.2.840.113549.1.9.16.3)</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>

        <reference anchor="IANA-MOD" target="https://www.iana.org/assignments/smi-numbers/">
          <front>
            <title>SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="I-D.ietf-lamps-cms-kemri">
          <front>
            <title>Using Key Encapsulation Mechanism (KEM) Algorithms in the Cryptographic Message Syntax (CMS)</title>
            <author fullname="Russ Housley" initials="R." surname="Housley">
              <organization>Vigil Security, LLC</organization>
            </author>
            <author fullname="John Gray" initials="J." surname="Gray">
              <organization>Entrust</organization>
            </author>
            <author fullname="Tomofumi Okubo" initials="T." surname="Okubo">
              <organization>DigiCert, Inc.</organization>
            </author>
            <date day="6" month="February" year="2024"/>
            <abstract>
              <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>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-cms-kemri-08"/>
        </reference>
        <reference anchor="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="RFC8702">
          <front>
            <title>Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)</title>
            <author fullname="P. Kampanakis" initials="P." surname="Kampanakis"/>
            <author fullname="Q. Dang" initials="Q." surname="Dang"/>
            <date month="January" year="2020"/>
            <abstract>
              <t>This document updates the "Cryptographic Message Syntax (CMS) Algorithms" (RFC 3370) and describes the conventions for using the SHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme (RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA). The conventions for the associated signer public keys in CMS are also described.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8702"/>
          <seriesInfo name="DOI" value="10.17487/RFC8702"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9629.xml"/>

	<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.8702.xml"/>

      </references>
    </references>
    <?line 522?>

<section numbered="false" numbered="true" anchor="asn1mod">
      <name>Appendix.  ASN.1 Module</name>
      <name>ASN.1 Module </name>
      <t>This section contains the ASN.1 module for the algorithm identifiers using the SHA3
family of hash functions <xref target="SHA3"/>.  This module imports types from other ASN.1
modules that are defined in <xref target="RFC5912"/>.</t>
      <sourcecode type="asn.1" markers="true"><![CDATA[
   SHA3-OIDs-2023
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) modules(0) id-mod-sha3-oids-2023(TBD0) id-mod-sha3-oids-2023(78) }

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   EXPORTS ALL;

   IMPORTS

     AlgorithmIdentifier{}, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM,
     KEY-DERIVATION, MAC-ALGORITHM
     FROM AlgorithmInformation-2009  -- [RFC5912]
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-algorithmInformation-02(58) }

    mda-sha1, pk-rsa, pk-ec, ECDSA-Sig-Value
    FROM PKIXAlgs-2009  -- [RFC5912]
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-pkix1-algorithms2008-02(56) }

    mda-sha224, mda-sha256, mda-sha384, mda-sha512
    FROM PKIX1-PSS-OAEP-Algorithms-2009  -- [RFC5912]
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-pkix1-rsa-pkalgs-02(54) } ;

   --
   -- Alias
   --

   OID ::= OBJECT IDENTIFIER

   --
   -- Object Identifier Arcs
   --

   nistAlgorithm OID ::= { joint-iso-itu-t(2) country(16)
       us(840) organization(1) gov(101) csor(3) 4 }

   hashAlgs OID ::= { nistAlgorithm 2 }

   sigAlgs OID ::= { nistAlgorithm 3 }

   x9-44 OID ::= { iso(1) identified-organization(3) tc68(133)
       country(16) x9(840) x9Standards(9) x9-44(44) }

   x9-44-components OID ::= { x9-44 components(1) }

   id-alg OID ::= { iso(1) member-body(2) us(840)
       rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 3 }

   --
   -- Message Digest Algorithms
   --

   id-sha3-224 OID ::= { hashAlgs 7 }

   id-sha3-256 OID ::= { hashAlgs 8 }

   id-sha3-384 OID ::= { hashAlgs 9 }

   id-sha3-512 OID ::= { hashAlgs 10 }

   mda-sha3-224 DIGEST-ALGORITHM ::= {
       IDENTIFIER id-sha3-224
       PARAMS ARE absent }

   mda-sha3-256 DIGEST-ALGORITHM ::= {
       IDENTIFIER id-sha3-256
       PARAMS ARE absent }

   mda-sha3-384 DIGEST-ALGORITHM ::= {
       IDENTIFIER id-sha3-384
       PARAMS ARE absent }

   mda-sha3-512 DIGEST-ALGORITHM ::= {
       IDENTIFIER id-sha3-512
       PARAMS ARE absent }

   HashAlgorithm ::= AlgorithmIdentifier{ DIGEST-ALGORITHM,
                         { HashAlgorithms } }

   HashAlgorithms DIGEST-ALGORITHM ::=  {
       mda-sha3-224 |
       mda-sha3-256 |
       mda-sha3-384 |
       mda-sha3-512,
       ... }

   --
   -- Signature Algorithms
   --

   id-rsassa-pkcs1-v1-5-with-sha3-224 OID ::= { sigAlgs 13 }

   id-rsassa-pkcs1-v1-5-with-sha3-256 OID ::= { sigAlgs 14 }

   id-rsassa-pkcs1-v1-5-with-sha3-384 OID ::= { sigAlgs 15 }

   id-rsassa-pkcs1-v1-5-with-sha3-512 OID ::= { sigAlgs 16 }

   id-ecdsa-with-sha3-224 OID ::= { sigAlgs 9 }

   id-ecdsa-with-sha3-256 OID ::= { sigAlgs 10 }

   id-ecdsa-with-sha3-384 OID ::= { sigAlgs 11 }

   id-ecdsa-with-sha3-512 OID ::= { sigAlgs 12 }

   sa-rsaWithSHA3-224 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-224
       PARAMS TYPE NULL ARE required
       HASHES { mda-sha3-224 }
       PUBLIC-KEYS { pk-rsa }
       SMIME-CAPS {IDENTIFIED BY
           id-rsassa-pkcs1-v1-5-with-sha3-224 } }

   sa-rsaWithSHA3-256 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-256
       PARAMS TYPE NULL ARE required
       HASHES { mda-sha3-256 }
       PUBLIC-KEYS { pk-rsa }
       SMIME-CAPS {IDENTIFIED BY
           id-rsassa-pkcs1-v1-5-with-sha3-256 } }

   sa-rsaWithSHA3-384 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-384
       PARAMS TYPE NULL ARE required
       HASHES { mda-sha3-384 }
       PUBLIC-KEYS { pk-rsa }
       SMIME-CAPS {IDENTIFIED BY
           id-rsassa-pkcs1-v1-5-with-sha3-384 } }

   sa-rsaWithSHA3-512 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-rsassa-pkcs1-v1-5-with-sha3-512
       PARAMS TYPE NULL ARE required
       HASHES { mda-sha3-512 }
       PUBLIC-KEYS { pk-rsa }
       SMIME-CAPS {IDENTIFIED BY
           id-rsassa-pkcs1-v1-5-with-sha3-512 } }

   sa-ecdsaWithSHA3-224 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-ecdsa-with-sha3-224
       VALUE ECDSA-Sig-Value
       PARAMS ARE absent
       HASHES { mda-sha3-224 }
       PUBLIC-KEYS { pk-ec }
       SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-224 } }

   sa-ecdsaWithSHA3-256 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-ecdsa-with-sha3-256
       VALUE ECDSA-Sig-Value
       PARAMS ARE absent
       HASHES { mda-sha3-256 }
       PUBLIC-KEYS { pk-ec }
       SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-256 } }

   sa-ecdsaWithSHA3-384 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-ecdsa-with-sha3-384
       VALUE ECDSA-Sig-Value
       PARAMS ARE absent
       HASHES { mda-sha3-384 }
       PUBLIC-KEYS { pk-ec }
       SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-384 } }

   sa-ecdsaWithSHA3-512 SIGNATURE-ALGORITHM ::= {
       IDENTIFIER id-ecdsa-with-sha3-512
       VALUE ECDSA-Sig-Value
       PARAMS ARE absent
       HASHES { mda-sha3-512 }
       PUBLIC-KEYS { pk-ec }
       SMIME-CAPS {IDENTIFIED BY id-ecdsa-with-sha3-512 } }

   SignatureAlg ::= AlgorithmIdentifier{ SIGNATURE-ALGORITHM,
                         { SignatureAlgs } }

   SignatureAlgs SIGNATURE-ALGORITHM ::= {
       sa-rsaWithSHA3-224 |
       sa-rsaWithSHA3-256 |
       sa-rsaWithSHA3-384 |
       sa-rsaWithSHA3-512 |
       sa-ecdsaWithSHA3-224 |
       sa-ecdsaWithSHA3-256 |
       sa-ecdsaWithSHA3-384 |
       sa-ecdsaWithSHA3-512,
       ... }

   --
   -- Message Authentication Codes
   --

   id-hmacWithSHA3-224 OID ::= { hashAlgs 13 }

   id-hmacWithSHA3-256 OID ::= { hashAlgs 14 }

   id-hmacWithSHA3-384 OID ::= { hashAlgs 15 }

   id-hmacWithSHA3-512 OID ::= { hashAlgs 16 }

   maca-hmacWithSHA3-224 MAC-ALGORITHM ::= {
       IDENTIFIER id-hmacWithSHA3-224
       PARAMS ARE absent
       IS-KEYED-MAC TRUE
       SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-224 } }

   maca-hmacWithSHA3-256 MAC-ALGORITHM ::= {
       IDENTIFIER id-hmacWithSHA3-256
       PARAMS ARE absent
       IS-KEYED-MAC TRUE
       SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-256 } }

   maca-hmacWithSHA3-384 MAC-ALGORITHM ::= {
       IDENTIFIER id-hmacWithSHA3-384
       PARAMS ARE absent
       IS-KEYED-MAC TRUE
       SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-384 } }

   maca-hmacWithSHA3-512 MAC-ALGORITHM ::= {
       IDENTIFIER id-hmacWithSHA3-512
       PARAMS ARE absent
       IS-KEYED-MAC TRUE
       SMIME-CAPS {IDENTIFIED BY id-hmacWithSHA3-512 } }

   MACAlgorithm ::= AlgorithmIdentifier{ MAC-ALGORITHM,
                       { MACAlgorithms } }

   MACAlgorithms MAC-ALGORITHM ::= {
       maca-hmacWithSHA3-224 |
       maca-hmacWithSHA3-256 |
       maca-hmacWithSHA3-384 |
       maca-hmacWithSHA3-512,
       ... }

   --
   -- Key Derivation Algorithms
   --

   id-alg-hkdf-with-sha3-224 OID ::= { id-alg TBD1 32 }

   id-alg-hkdf-with-sha3-256 OID ::= { id-alg TBD2 33 }

   id-alg-hkdf-with-sha3-384 OID ::= { id-alg TBD3 34 }

   id-alg-hkdf-with-sha3-512 OID ::= { id-alg TBD4 35 }

   id-kmac128 OID ::= { hashAlgs 21 }

   id-kmac256  OID ::= { hashAlgs 22 }

   id-kdf-kdf2 OID ::= { x9-44-components kdf2(1) }

   id-kdf-kdf3 OID ::= { x9-44-components kdf3(2) }

   kda-hkdf-with-sha3-224 KEY-DERIVATION ::= {
       IDENTIFIER id-alg-hkdf-with-sha3-224
       PARAMS ARE absent
       -- No S/MIME caps defined -- }

   kda-hkdf-with-sha3-256 KEY-DERIVATION ::= {
       IDENTIFIER id-alg-hkdf-with-sha3-256
       PARAMS ARE absent
       -- No S/MIME caps defined -- }

   kda-hkdf-with-sha3-384 KEY-DERIVATION ::= {
       IDENTIFIER id-alg-hkdf-with-sha3-384
       PARAMS ARE absent
       -- No S/MIME caps defined -- }

   kda-hkdf-with-sha3-512 KEY-DERIVATION ::= {
       IDENTIFIER id-alg-hkdf-with-sha3-512
       PARAMS ARE absent
       -- No S/MIME caps defined -- }

   kda-kmac128 KEY-DERIVATION ::= {
       IDENTIFIER id-kmac128
       PARAMS TYPE Customization ARE optional
       -- PARAMS are absent when Customization is ''H --
       -- No S/MIME caps defined -- }

   kda-kmac256 KEY-DERIVATION ::= {
       IDENTIFIER id-kmac256
       PARAMS TYPE Customization ARE optional
       -- PARAMS are absent when Customization is ''H --
       -- No S/MIME caps defined -- }

   kda-kdf2 KEY-DERIVATION ::= {
       IDENTIFIER id-kdf-kdf2
       PARAMS TYPE KDF2-HashFunction ARE required
       -- No S/MIME caps defined -- }

   kda-kdf3 KEY-DERIVATION ::= {
       IDENTIFIER id-kdf-kdf3
       PARAMS TYPE KDF3-HashFunction ARE required
       -- No S/MIME caps defined -- }

   Customization ::= OCTET STRING

   KDF2-HashFunction ::= AlgorithmIdentifier { DIGEST-ALGORITHM,
                             { KDF2-HashFunctions } }

   KDF2-HashFunctions DIGEST-ALGORITHM ::= {
      X9-HashFunctions,
      ... }

   KDF3-HashFunction ::= AlgorithmIdentifier { DIGEST-ALGORITHM,
                             { KDF3-HashFunctions } }

   KDF3-HashFunctions DIGEST-ALGORITHM ::= {
      X9-HashFunctions,
      ... }

   X9-HashFunctions DIGEST-ALGORITHM ::= {
       mda-sha1 |
       mda-sha224 |
       mda-sha256 |
       mda-sha384 |
       mda-sha512 |
       mda-sha3-224 |
       mda-sha3-256 |
       mda-sha3-384 |
       mda-sha3-512,
       ... }

   KeyDerivationFunction ::=  AlgorithmIdentifier{ KEY-DERIVATION,
                                  { KeyDevAlgs } }

   KeyDevAlgs KEY-DERIVATION ::= {
       kda-hkdf-with-sha3-224 |
       kda-hkdf-with-sha3-256 |
       kda-hkdf-with-sha3-384 |
       kda-hkdf-with-sha3-512 |
       kda-kmac128 |
       kda-kmac256 |
       kda-kdf2 |
       kda-kdf3,
       ... }

   END
]]></sourcecode>
    </section>
    <section numbered="false" anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Thanks to <contact fullname="Daniel Van Geest"/> and <contact
      fullname="Sean Turner"/> for their careful review and thoughtful
      comments.</t>
      <t>Thanks to <contact fullname="Sara Kerman"/>, <contact fullname="Quynh
      Dang"/>, and <contact fullname="David Cooper"/> for getting the object
      identifiers assigned for KMAC128 and KMAC256.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIADRZRmYAA+1d6XLjSHL+X09RVv8QFUFQvKSWNJ5dUyS7xdW5IjXbExtr
B0QUJaxAgIMCpeZqtM/iZ/GTObMOnAWQUqvH47A7pqNJoI7MrMwvj6riWJZF
eGT7zn/YXuCzIxqFS0bcRSg+8ajdbB4228QJpr49h9dOaM8iy2XRzPLs+YJb
0zm3+L3dse5tfm81u2RqR0eURw5ZuEeE0iiYHtHtFePb8IUHYRSyGU89Wc3T
DyI38mCW7RvOaDCj0T2j45Neh176zHqyV/QEJqGflv40cgOfU9cXTfrhahEF
d6G9uHen9Jxxbt9Bx5Uf2V9prX8+3tkm9u1tyB7F0K5/J0d9cqN7OcD5eJvw
5e3c5RwGnqwWQMRoOPlE7JDZR3RrzKbL0I1WW+ThCd74EQt9FlkDlAZx7Aia
t5vtrtXcs1r7hNjL6D4Ij4hFpdSul5zTk2DJPbYCpoPw7oj+5N65HtUD1+nZ
WR9eaTKzb+HFFP45oicwrxP48D1kd0ApNOzhy2DpRyG8v/HdiDl0HAFJHCXY
m7PQndrQhs1t1zui95KKf3vECTibNqbBnBDXnwXh3I7cR4aLNupd9Kze2Wf8
DDQpbqj4I4jHBuK7WrCt8fkoppbCWOLvePd8dD6kPe8ugOf3c05rrUa7cdBt
Nlqtzl73sNFqwN/9RmdnS45mh3cM1Oc+ihb8aHf36emp4dq+3YBJd21Ymzt/
zvyI7/K5a/nL+S0L+a6m9/xy8A30KlrPA2fpMTpyYBp35rKwjOTmt5JsDRo5
M3pg81DYzPWnfrd5sK8+HnxstvEj8dNL1LsYW18OG91uKc9q6X16YaO12B6q
he/YocNBgzlIYhmxtFD+oHpfLW89sKNTtkpblhQTWssn17f9qYsDsvDRnTIc
zwGwCFcU4EQOgr2HgCwwFL9HCVBpeGg7dyDWT/Y0Aq34h6AtM48YQNtU86P4
yoEVxlFLNYvl3B1RIRdodzEaTxrjq8ZBs2m1mgdhy1ounNaRcd38R2+xvOUN
3+VR4y543MUP+GR3vGDIrJSKmIzvmkduLJxZRsuuGVgXMO9ILlGADyAXB0h/
lI+WQigLzpZOEAL9wZzONLxtFVbWkisbsxwvI5p6srrwL52w6b0feMFdVp6I
UW34r0SqyBdVDNMUx0c0y2lJ98Hl6Ii2mo39ZvugREb5ZTnYe/f1ONgrLATA
vdWhA5Q7wGPsQI7oFN6cDuv09LzXr9PJcuEx4WNQhFd2aHse8/DB91iL1r7V
euNCHOytlbhoAvDRbjW7Ckk67Y+H6uPe/l5bf+weNPXHg/24wWFLNzhotj7i
R/SZxcWqXKtPo6uxJAs/NUD/8kuzLZcmMd4rFs6XkWDWOrY5LFe8IMOvEdrS
rcesyyVMECUruf091mfPah6UrM8W8kOvbo63QLuArS0KLwbj8WuVOSeg1sG+
VdDe7QH46ggRDpyJHS1DFtNPazDnzvdgvt0RQNHZhH9B9VZaI7cyKpmwho2+
NPalwpU4z2jZcP1oN2TT3Yl1PexbooPJUY101AJAGsVsJD6odws+CfyMDgUv
AqlXGE7SWm980WjtaIaErc2UlaGUbm0OTtBXXcokPJrcWJOs4Frl8Cpa06xX
OKIJf9BifLk7GvbBzA8AqltHOJ6U2eFvJDOUCmX+NHDQM4UQDQFMFqRzLKQz
1M2usRmtHQ+vd+pqoL7tBz708Aqt+tBKqN4ArACeLyFCADPPNxtAs+8s9kOT
2Pe02IllWRCQSx0iZHLvcgqJ0FJEMw7j09C9BUIxJJoG/iNGjJiUoJeXbh3f
BCpzwfQoce1EZS4iDZnZc9dbpbKRtelMg9KJ6k1UbwyFbhlMDJK0wbLpXPVz
3DvGI2rrILyOrxd2GOEy2pRrTCFlLfRAuAzIo1ICWCxWh9VItYTYhqRiG81t
Q0py7jqOxwj5gDFgCHG2eEmfP7j49QUFvAnv9PlZ+a+XFworIjiOAuQTQRJE
gSzVieS7niZb0gu6jZNQO7x1YWkhaNUcwipGGKsL8bqc8IzWZ1d8mWSos2AZ
lqyzylBJep1r+MVqt7t1Kj/t7atPnQN4hoYhvu212sgsfgZOtXYQkEEDzZja
juPiJHV4DHLYjFguySUl5MY6eD3ujcc9enXaH39o0UdIWnDUVmPPpDBySTBM
AEKRfhxh6HnuAsRO+8vwkdGiD4vTQlIb9gfjHjIL3izFK+blYj7mWGC1tl4g
GkGC3shbJIfU1nMQsdEQoOlMqIYYDMijmEcpSuHTy0udPoGO3YOoZq7POCm3
YWWpp0O9hOhEcYluRXzCMCzhLoQlNBBhCTEIFJcNdP+DBFiCy0gfbW8JK2SD
MO6Yz0Ibc3c5rYTh52eB40hrQo2AXmKC3lj264FVDn0IQ0uqJhB1uSoMEIaI
ecpTgEHC1vnNeLJVl//Si0vx+Xr455vR9XCAn0EUZ2fxB6JajE8ub84Gyaek
Z//y/Hx4MZCd4SnNPCJb572ft6QdbF1eTUaXF72zLWlI6eVGqYHZw1K7WI5Z
hCwS0Ee06jvY57h/9V//2eoCu/8iYuHWIeiX/HLQ+thFZQN0kLMFPqKw+ApC
XBF7sWB2iKMArADALlCBuUBH0LUnn96zENTwX//ogf5Qa/+PfyCIbhq0BhJ4
U9WP5w9YKQtchwPaXZotENmCWQIashkLQ4ltMGMZnPOGNAPOJJwqGDD4JTZf
eMEKBrxdCcNy4TtDUcocikT3NhjRcrEIAM83x6gYokCRBjniqBvXUSRnXjAV
Sq7dn7DtAZq25CsRFoFOnlNPmoUYueSb0VQrObl5OD2aNpBeyikYO8iBE5ZS
pprjwTCt7BxPphQilk56bmpHESgrROZ5UHcKE7s+pjxRQGIIzqgBecWaLYT/
1XilJ0GwImIA0Tfuhj3AV4Lqhwz1C2tQ3koFIcHt3+FJZqUBPUnia8pco9B0
bOx5wRM/IuSf//wnPPAborqAjWE1OL08/tOwP6GjwfBiMvo0Gl7To6Mf6TP9
ewB2b7k8sCD6taIaOEtVBq219ndUXAewWTvoNncwarR9VW2qtXYoJGG1VhM+
THkQ1jo7FDOyePVr3R3apmCkMILryPo2yKWUlpjYj/lOe/vrOx3kOoHc13c6
zHXCNVrbqdWEXiBmQv4CKpjyKSkm6/EXLrQgRZUIn1ITEqOhS2uEqNCeAySj
OghrEN4D0BoCamj6g/DTFzfgL0D51UN0RaYAgZPvgnFx7Cais1dFRMQYEdG3
RETEwDB9a0Q0NpCyCQYLcE1wJQeDIt6JoRrsvgcOqm7im2w8GS2bjMBkwpBR
wvEEGiV5hslyVDZNFDNDKpnZZFBSHHQN0RBj5WJqVB2xriKNE0GXoQWGPCJA
FVSk1AooF0Zs7ENE6Otilub/XemynAzUPLOzZlZ7YcPEAO0glTxSX44GAmcK
6CPwCcTxPwrjnQQnQ26DI7YWD1Pesh5b1p6FEkmhu2LkOSa6tWlvhPli7+5m
vQXeF3vvbdZbAH+x975GetQrExiIHMegPHwpV30hd4EgDxDViikLI5legm0k
6WZKLbG6jJkKwp0bYZuQQQCN9oOBsogKJFa7kIIX1Ah4HMrMXFToStQFFAXX
fc5wI826DZwVaExeS2Aoh7s1uWG3Q1Fs2An/tVr4qZVxg2gLmdnrG2hLnazX
ibVtdIS1rh2usXENVf2jTmKdT+1cml0wegwb1gx9b6NMAtWzaX+Y0pE6kck0
NJkG80WA8COrR7ihupSlZlt3YF8XgDt+VI+jAlFwZA5JQhIYX+574E4iujeR
d5VonY5FZTgLCC9yxbiKiVTZYegmUJ5SZ4PGy+GIAF5XlzwzBJm0m1Zod6Yz
qvIYEujhRX9In5X2akGNLibDz8PrOrUs6qt3krKhkppuQl+wDUtpMvoe4Lde
DFiUbRvCA115gCUiKHxPeUCdLNkqPYhrbY4bgrQgVbZl/JXznNLXifgl7942
LwnFAVDG/REVDmnXJyfRdG3g7UrKXlJem3m735E/Y1MHACPnw0rI0mQfVnSv
yFVit9Is71+VtsT9W+X9qzKYuH+7PIExiKNewqcAZgP9ynmZaTMnO+RVyQ7N
JDsTw86B1OmU80X9NiIf7ttq5CPD/lVCAziSYOoKbIoTh/y4GghFMhFykgZE
Ucej9mIBRh4FohnkO5n9n4zhN0zwIyc04Uz0FKggWxLPdcyNp63QfcxFJS5X
AAvF2oguAWU2xzpsFNo+h1aqsg0DEx29c2H7MYmypBevS2qXKy65RkKMQLQF
gGT9JDAvH3pLbyMoeVVwkx/X6AGAxRj99SNOE7SXip8UGHvZDZk+8MIVLyfn
vX5c8fl+2bOYRggGTxnoPFXkFRW7RrQG3XZAaQSRm+aphZIdmdvTYr0OxyzP
4Ip1Pxgk7iuUWPD02/qU30WtiypYvgeJ/AVe6GriBlWllE/K9t6k+pXOkjK9
NyqDpbOkTO/N6mH7hUTAIIG6iTHhQvL0xv6jQIqpQpKNp9f5EGL2IR/ESbtB
susaH4lRG6pgx6fD82uw+QVAUyRLIlG4nIqI6/m57CCi3F1FZV949pThxkhm
zy9X8EWfYhk2f6UZ+owB0MrQ8OR08CkbGabASZ6Y5LIuZ55MoJDa7s4hFskh
FjUiltq2G34VG/sWLJkFoTWuXFaURIuS1pBmvfN8sH+Yrsilt3YBFrIoEIMK
8vzbggpoIcjv+yXShzV4wufunCEGpeNSmNa6f3BmG4amitDJ8aBVPUYFmiRj
tCvHqMKUZIxqXqqQJRmjm0GWUqnUy5kVCGPmQRfiS6hLFI3Y5lT+2yDngzgu
2WofWKjWwnDgO5CM39832pCNKAP6ZZinp0YJqFnleZfcwVptM3JHOI7ixoqs
bqOL9vb8bD6lKnYz9UwpBgWY5ULx3KlLDMknyZkLNQjJDFJJb5iEnTZui/2B
pKUNolVfa6d1+qVOz+p0jMGUbKYWQTeDr7lmk+y6q/DexGoGwSUd5Ej6SLER
mQP8uGxCPebfIaQB87FGeRAOIhr7tP3v7Wa3KQj+osYTmxhfI30gQ1WopMbI
SH0AFhZXc2Bg0JfL6xG4HXBtl6gawq09aSeeRlsBr1VuTpBypkhRFSTJQh0X
GDc+gbGzmJW7EOP+UHKD54l+WdoeCrIp3f9ZNdNjPdNCnc2cLnkUzPVJeM++
ZV4dfBYIAvRkC1jZorXm1+5xt9vd3ymIeFw1GzY9TZYbZfLg48kFTKk8T52s
c/8BYsJTXGClP6jSbTCLlCzVkRZRzANpg3+c2osaRJkLTOfweJck6Ut2HnDk
4Fo8GHkWBnMqNqvQogm8E2nb3I0iafxiltC9cyFVC0I13Fl2OAc/zIVRyB6E
A9naZapVAxVE/Zjj8ri2p0/JZUfSclex2oxIhhdh8Og6JoLqSiQLZCnOJArY
KYqOUvVMiKsjgbQtJxBmpTT2f23m8ABBL4LI2rC7nXL02GmjPKHdNsXqek7p
D/Vg2vbT5xgrHCFZ4whjYAlFFdQPTDZLxbE8nGhF4oJprFXiipGYrER99IyL
kIkpcVdAl+pFAUYMiQZfj+sWwF4/TUgjpx2Zl3KPrj8ZTuh4cj26+KzKCR9Q
ZdsS+QefOqWR+fs7cpwWTQBnTZxNpuQS33JCmH6fdIak0pmSDGPzdEadlDO1
LN1CQa+RN24RHsQeIVEOXenOLhGSECPFSp4N0kPhKhBtHBAZwt+2zkrV944B
XExHe8irOEtpNO61rJKTwyR/Zi1jf2rfyHfU3iLSnsl6YrdxyxDdtbbJQmD6
vJoEzhKijZlrhmhlbCVAIdwYeX6OT/C95K3t66HVrcguZL6VrJOVAdtOjMXR
dP+g1up0MkANg0uE/noY397A/EvMWesCEEtAFd8tsQOHO0XlfkESmzRE2hJM
1npT2Ts9DbY2DdF51RAddE9xmTO+ntkHswO5hQpOyCiX5M8B5hBpI9TppKa9
jfCLasBUbNqHyWAR3fgwNDE1pAsMNICguc1/WcKsDta3185pjIaLMxabxfMF
iIwiIhcN5LFjR11Zy4U2erv1SRx5BtNdehEiphdwLs+i+DOparYnbhfjGdk7
edEYwC1blK1DgrRgvoyt/fzp9hIKdDwzD/AcLkadWNZXUSQFKwklAxzsSwOB
lSsGi31jERnKaCtfLBa+NsJQErAdDb7nr8QUK1nYwVhWAAYpn0BUilDN8PKT
jW7UBWeLl/2EP58Fik51kAp8LkpUR39MRq/g09MVGsVlmVrIe5zeKt7yqOBf
bIyLak/kzvU+SBL+C81Svl8EIWpIXAlbbbGktmFytwLiY+Vq00bu/uxmlN12
Q9zK9nDVENqJuoWqriqrGFrpA4jEwXQHOssrq1amtZ4uCDmpXV1ffOY7qM6x
GKaZyx2qSo/rk1JgyArwHH0IK0+4QgBxNJZHzBZnCm5DXEpYOPDinNnh9F5v
Aj7dB55kiy/Ax2OET+wosqcPQNvcXkGoJc+mzFG8uIeEoQgetdbnYXEUJBxC
rEc3DMTVbel/VAtHGzuPDxP7igp5ikJwggTxOWZYnInjCAuwS/fWBe5cveuV
WxtMIhHssuLHo1yOO5u5Uxi1IW5jUrwaLkuR+AnimmA2E03n6AltIPhu6Tq2
P2XxoXn8FYO6iDF6C2HpX2kHJ5WX+Ja3FC/ndePThipqBTMO5koe4qqY+8sy
q/U4rbp2gcHykzR6LM9mVjo5pQzNpjjmE7NhTYgsooLio22DsbMn2dOGKGjF
MVOMp1V1EYhOIPGUZ6ulVYOsCUCouNUmeEbIfWSqVvoUhA90Ju6ai9sCIIgH
PIeCFgwytcMsqako4cmF5QPYgUWXCybBol7GW6H2nAhGHO2wsZ7tBU+oG8ho
SijyGgOQ5rjeirg+Z2EkAxyUpQusuGaJQ7IAnMgt0pDd4SQAO8sFXooTQaBU
v/RcMp1ww3yULrYS8GcSiu4WH4qM/kFvxiLkSEDMB5LxjwTIus1c/pyCiOUh
UGrB95cXfflt8x9hKP3hCPwVBvwlDPHbA3/VPwPxtyRN1qVwmFjWRzF2s/B6
a1lkouIwY318TWFcn9YxlMdh/hr0mxwP4iPYZXKVZ+aNp+rlFgbWCpbJr5iY
D9+uk/FmP8oRyxYSK/WbIC8vRen+f8U/XfH/QHtTDE085twJC+Pk+UghOnN+
3PKDLXHb0fYf0PbJANIA5tGfwBF+ZiJRgpBgzODrZBmCjyBq5cFoIbNisyXi
0qOLGCI8ULC8u4/wqbzfGvFGanQ6hhSHnjJExzr983Ll31OY8E66r4ENQA8W
j8U8Mc0di6L46qqhBMXl4XOhSYaisbrqeQsuV8hBeZuGvlesLPv5gwYDs2RS
ZQdDMViBirYHcw6fGAgp25xLbi7J+54xWglHysWhQy4DQBGbq6t7spXaW0xX
6+ODOYetdjE9FFvBl6OBRB8JFSXbcBvvv8WnRNI4g8Qh1hhRr4YIpPO0wfDT
6GKEN+zGdHR+dTbqjyZ00vs8Rt3GBsfDz6ML0XT45eryejKmvbOzH8QDaI8P
8KOkwnAC9fmlTgejz8PxBIHj8no0OTmv0/Ho80VvcnM9TD2UQ5wOf7YGw+vR
Tz2kqY5hetJGNvl0fXmemiq5zG7hL1VRPBD5V7UEf9PS2SD5pg7gM4jPVb/s
lIA5SlfBZ20PF2oKluXyOcdviwf3a+2jFjUIPemkpG+bSG22a3sHehHo3LFx
kVp1GA5PAYt/2bSePzREYv6vTkdfsCZazvM3svwWjhXD2KCVsM2BxAPB8H6e
YbH7qT/jTSP1Wexvqs976gdSYrZb1tV4bF32hldW4sF+v3IIxYluG9cKZYB1
Ggr2g43lLy4AzT3Ptbl6suY+RabfpYTn1IHvXjhND5Qp1qfuCLzznoA+v5Ps
RcQzZSnQjjo+QlvSrpMuZqVarV/KuHammXiXElpMQGXRTBy2yNNqxvX4vN8r
j1dklr/0mnFKAzJ3F2Paqm8rFpsZ7ycWmxlvJBabxUeItbkL6vJuIhOLp6Ou
FEv67VXvuncOrul6qPdr8hMAX6+fYG9/4wlQIq+eADptPAHK8tUTaPCsmOBE
rooyPBzQ5MaLTjzxc/k/z9kxOQCeYSpu5iZhJ6McvxafwooWn+IyFJ+CGGJ6
G41GwZCMF04zNvR/7uJY1QWDQo91VwqKU6y7RFDsse7aQLFH7GxsFELmQKsh
AK2ypTWrnzOxyc9XQ3lmCo0tZL8sXUhtdKOT3vhkOAY6M/r9Eo9xcwxBuAVx
MLaR4WDydoyJu9XvXcHLmMQBPf6Zps1xA319KZENrNZ7yqYAoK+Wzd7+N8vm
NaLB6cyiQbV8R9EUof+1okGCfkPRiOnMokH7e0fRFJ3Wa0WzJ2z/NxONmC4R
jYCnb4EbA+jqhj/1zm6GxrSQGlz8WzGHTTeBnBL3UC6J14OLwZu8uyQqEebt
ksgiSVYSb8ASg5d8b0lUA8qbJZEDjqwk3gAdBu//3pKoxo83SyKNE+PUb1+U
R93lhTLTn+fMqDLuLm2cJ4KvXwdDIPVr2bt0dG7wpGXvUETpd0UsrXibm7No
c+VvixmCEpEx4TZdu8vmC8UrVIY0uPLSlKF95TUpQ/vKi1GG9jruh7Z2kYNM
KbbKQPM91xrgaIzWNRxYeO9ucn0z3Mi6CgS+lJMPAn0j+RUlgPckP+UtiuTj
+r6N/KoCwzuSn4b4Ivmobm8jv6p88Y7kp3EZRtmgGpJhpxSRnzOjceMcvEo0
ZkP8teJ1pihiVKSK1+vKJLlrhmW1krKt4KQy+prNX0OvDbZ7Db022OA19Eph
bny4vQidpuPsxnYp0pMjltnq8oaHKis7qWOU2OkBghrDamQ32qos0ryca+0S
9OUi0EcNpvYiOdYNb8pJA8F9G2kbAPbbSEO9+ibSNgHjt5GGyvtNpG0CtBuS
pq1kc3pUD1POn72+gDTpE/IpqlQH8WOSqcsa2b4up9vbJ8mPnL+Gndcpperx
O2UHAecVvCiMMjGDFxIsLOnHd6RNxZnN6eq8nq5OCV2dd6Frzd0ZbFKUQUnI
QF+1g4J/nouDJxGE4VXl3tCXw2xrPbfy8nLEzvfkpFPOSf7VN3KSb7Fm10yf
vShsG5m2nYybToYtp0wa+303sqj4Hy0lYVlm/czRa+6QTfXq6SXEOR7jskI8
rXxUZbklAcivVe/TIilxxVXvM+JPO6XCw8JMAiDzTzoGoQ8vBuKs3/MR5cEy
nDK8kGfN7fCBhfzHbfyf6G2/kP8GlEDSHl1vAAA=

-->
</rfc>