<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5912 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml">
<!ENTITY RFC5958 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC9629 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9629.xml">
<!ENTITY I-D.celi-wiggers-tls-authkem SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.celi-wiggers-tls-authkem.xml">
<!ENTITY I-D.longa-cfrg-frodokem SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.longa-cfrg-frodokem.xml">
<!ENTITY RFC7468 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7468.xml">
]>
<rfc submissionType="IETF" docName="draft-smyslov-lamps-frodokem-certificates-00" category="std" ipr="trust200902">
	<!-- Generated by id2xml 1.5.2 on 2026-01-23T09:02:11Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc text-list-symbols="*o+-"?>
	<?rfc toc="yes"?>
	<front>
	<title abbrev="Algorithm Identifiers for FrodoKEM"> Internet X.509 Public Key Infrastructure - Algorithm Identifiers for FrodoKEM</title>

    <author fullname="Valery Smyslov" initials="V."  surname="Smyslov">
     <organization> ELVIS-PLUS </organization>
     <address>
     <postal>
          <country>Russian Federation</country>
        </postal>   
       <email> svan@elvis.ru </email>
     </address>
   </author>

   <date />
	<workgroup>LAMPS</workgroup>
	<abstract><t>
   FrodoKEM is an unstructured lattice-based Key Encapsulation Mechanism (KEM). Compared to ML-KEM, 
   FrodoKEM is considered as having more conservative design.  This document
   specifies the conventions for using FrodoKEM in X.509 Public Key
   Infrastructure.  The conventions for the subject public keys and
   private keys are also specified.</t>
	</abstract>
	</front>

	<middle>
	<section title="Introduction" anchor="sect-1">
    <t>FrodoKEM <xref target="I-D.longa-cfrg-frodokem" /> is an unstructured lattice-based Key Encapsulation Mechanism (KEM).
    At the time of writing this document, FrodoKEM is being standardized in ISO (International Organization for Standardization)
    as a quantum-resistant key-encapsulation mechanism.
    </t>

    <t> This document specifies the use of FrodoFEM in Public Key Infrastructure X.509 (PKIX)
    certificates <xref target="RFC5280"/> at two security levels: FrodoKEM-976 and FrodoKEM-1344, 
    using object identifiers assigned by ISO.  The private key format is also specified.</t>

	<section title="Applicability Statement" anchor="sect-1.1">
    <t>FrodoKEM certificates are used in protocols where the public key is
    used to generate and encapsulate a shared secret used to derive a
    symmetric key used to encrypt a payload, like in CMS.  To be used in TLS, FrodoKEM certificates
    could only be used as end-entity identity certificates and would
    require significant updates to the protocol; see, for example,
    <xref target="I-D.celi-wiggers-tls-authkem" />.
    </t>
	</section>

	</section>

	<section title="Conventions and Definitions" anchor="sect-2"><t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in
    BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
    capitals, as shown here.</t>

	</section>

	<section title="Algorithm Identifiers" anchor="sect-3">
        <t>The AlgorithmIdentifier type is defined in [RFC5912] as follows:
        </t>

	<figure><artwork><![CDATA[
 AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
   SEQUENCE {
     algorithm   ALGORITHM-TYPE.&id({AlgorithmSet}),
     parameters  ALGORITHM-TYPE.
                   &Params({AlgorithmSet}{@algorithm}) OPTIONAL
   }
]]></artwork>
	</figure>
	<aside><t>NOTE: The above syntax is from <xref target="RFC5912"/> and is compatible with
      the 2021 ASN.1 syntax <xref target="X680" />.  See <xref target="RFC5280"/> for the 1988 ASN.1
      syntax.</t>
	</aside>

	<t>
   The fields in AlgorithmIdentifier have the following meanings:</t>

	<t><list style="symbols"><t>algorithm identifies the cryptographic algorithm with an object
      identifier.</t>

	<t>parameters, which are optional, are the associated parameters for
      the algorithm identifier in the algorithm field.</t>

	</list>
	</t>

	<t>
   The AlgorithmIdentifier for a FrodoKEM public key <bcp14>MUST</bcp14> use one of the
   object identifiers (OID) from ISO listed below,
   based on the security level.  The parameters field of the
   AlgorithmIdentifier for the FrodoKEM public key <bcp14>MUST</bcp14> be absent.</t>

	<figure><artwork><![CDATA[
  frodokem OBJECT IDENTIFIER ::= { iso(1) standard(0) 
  encryption-algorithms(18033) part2(2) 
  key-encapsulation-mechanism(2) 7 }

  id-kem-frodokem976-shake OBJECT IDENTIFIER ::= { frodokem 1 }

  id-kem-frodokem1344-shake OBJECT IDENTIFIER ::= { frodokem 2 }

  id-kem-efrodokem976-shake OBJECT IDENTIFIER ::= { frodokem 3 }

  id-kem-efrodokem1344-shake OBJECT IDENTIFIER ::= { frodokem 4 }

  id-kem-frodokem976-aes OBJECT IDENTIFIER ::= { frodokem 5 }

  id-kem-frodokem1344-aes OBJECT IDENTIFIER ::= { frodokem 6 }

  id-kem-efrodokem976-aes OBJECT IDENTIFIER ::= { frodokem 7 }

  id-kem-efrodokem1344-aes OBJECT IDENTIFIER ::= { frodokem 8 }
]]></artwork>
	</figure>
	</section>

	<section title="Subject Public Key Fields" anchor="sect-4"><t>
   In the X.509 certificate, the subjectPublicKeyInfo field has the
   SubjectPublicKeyInfo type, which has the following ASN.1 syntax:</t>

	<figure><artwork><![CDATA[
  SubjectPublicKeyInfo {PUBLIC-KEY: IOSet} ::= SEQUENCE {
      algorithm        AlgorithmIdentifier {PUBLIC-KEY, {IOSet}},
      subjectPublicKey BIT STRING
  }


]]></artwork>
	</figure>
	<t>The fields in SubjectPublicKeyInfo have the following meaning:
    <list style="symbols">
        <t>algorithm is the algorithm identifier and parameters for the public key (see above).</t>
        <t>subjectPublicKey contains the byte stream of the public key.</t>
	</list>
	</t>

	<t>
   For each FrodoKEM security level, see <xref target="table1" />, we define a PUBLIC-KEY
   ASN.1 type as follows.</t>

	<figure><artwork><![CDATA[
pk-frodokem976-shake PUBLIC-KEY ::= {
  IDENTIFIER id-kem-frodokem976-shake
  -- KEY no ASN.1 wrapping; 15632 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY frodokem976-shake-PrivateKey -- defined in Section 6
  }

pk-frodokem1344-shake PUBLIC-KEY ::= {
  IDENTIFIER id-kem-frodokem1344-shake
  -- KEY no ASN.1 wrapping; 21520 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY frodokem1344-shake-PrivateKey -- defined in Section 6
  }

pk-efrodokem976-shake PUBLIC-KEY ::= {
  IDENTIFIER id-kem-efrodokem976-shake
  -- KEY no ASN.1 wrapping; 15632 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY efrodokem976-shake-PrivateKey -- defined in Section 6
  }

pk-efrodokem1344-shake PUBLIC-KEY ::= {
  IDENTIFIER id-kem-efrodokem1344-shake
  -- KEY no ASN.1 wrapping; 21520 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY efrodokem1344-shake-PrivateKey -- defined in Section 6
  }

pk-frodokem976-aes PUBLIC-KEY ::= {
  IDENTIFIER id-kem-frodokem976-aes
  -- KEY no ASN.1 wrapping; 15632 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY frodokem976-aes-PrivateKey -- defined in Section 6
  }

pk-frodokem1344-aes PUBLIC-KEY ::= {
  IDENTIFIER id-kem-frodokem1344-aes
  -- KEY no ASN.1 wrapping; 21520 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY frodokem1344-aes-PrivateKey -- defined in Section 6
  }

pk-efrodokem976-aes PUBLIC-KEY ::= {
  IDENTIFIER id-kem-efrodokem976-aes
  -- KEY no ASN.1 wrapping; 15632 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY efrodokem976-aes-PrivateKey -- defined in Section 6
  }

pk-efrodokem1344-aes PUBLIC-KEY ::= {
  IDENTIFIER id-kem-efrodokem1344-aes
  -- KEY no ASN.1 wrapping; 21520 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY efrodokem1344-aes-PrivateKey -- defined in Section 6
  }

frodokem976-shake-PublicKey ::= OCTET STRING (SIZE (15632))

frodokem1344-shake-PublicKey ::= OCTET STRING (SIZE (21520))

efrodokem976-shake-PublicKey ::= OCTET STRING (SIZE (15632))

efrodokem1344-shake-PublicKey ::= OCTET STRING (SIZE (21520))

frodokem976-aes-PublicKey ::= OCTET STRING (SIZE (15632))

frodokem1344-aes-PublicKey ::= OCTET STRING (SIZE (21520))

efrodokem976-aes-PublicKey ::= OCTET STRING (SIZE (15632))

efrodokem1344-aes-PublicKey ::= OCTET STRING (SIZE (21520))
  ]]></artwork>
    </figure>
    <t>


   When a FrodoKEM public key appears outside of a SubjectPublicKeyInfo
   type in an environment that uses ASN.1 encoding, it can be encoded as
   an OCTET STRING by using the frodokem976-shake-PublicKey, frodokem1344-shake-PublicKey, efrodokem976-shake-PublicKey,
   efrodokem1344-shake-PublicKey, frodokem976-aes-PublicKey, frodokem1344-aes-PublicKey, efrodokem976-aes-PublicKey, and efrodokem1344-aes-PublicKey
   types corresponding to the correct key size.</t>

	<t>
   <xref target="RFC5958"/> describes the Asymmetric Key Package's OneAsymmetricKey
   type for encoding asymmetric keypairs.  When a FrodoKEM private key or
   keypair is encoded as a OneAsymmetricKey, it follows the description
   in <xref target="sect-6"/>.</t>

<!--	<t>
   When the FrodoKEM private key appears outside of an Asymmetric Key
   Package in an environment that uses ASN.1 encoding, it can be encoded
   using one of the ML-KEM-PrivateKey CHOICE formats defined in
   <xref target="sect-6"/>.  The seed format is RECOMMENDED as it efficiently stores
   both the private and public key.</t> -->

<!--	<t>
   Appendix C.2 contains examples for ML-KEM public keys encoded using
   the textual encoding defined in <xref target="RFC7468"/>.</t> -->

	</section>

	<section title="Key Usage Bits" anchor="sect-5"><t>
   The intended application for the key is indicated in the keyUsage
   certificate extension; see Section 4.2.1.3 of <xref target="RFC5280"/>.  If the
   keyUsage extension is present in certificates, then keyEncipherement
   <bcp14>MUST</bcp14> be the only key usage set for certificates that indicate 
   id-kem-frodokem976-shake, id-kem-frodokem1344-shake, id-kem-efrodokem976-shake, id-kem-efrodokem1344-shake, 
   id-kem-frodokem976-aes, id-kem-frodokem1344-aes, id-kem-efrodokem976-aes, id-kem-efrodokem1344-aes in SubjectPublicKeyInfo.</t>

	</section>

	<section title="Private Key Format" anchor="sect-6">

	<t>"Asymmetric Key Packages" <xref target="RFC5958"/> describes how to encode a private
   key in a structure that both identifies which algorithm the private
   key is for and allows for the public key and additional attributes
   about the key to be included as well.  For illustration, the ASN.1
   structure OneAsymmetricKey is replicated below.</t>

	<figure><artwork><![CDATA[
  OneAsymmetricKey ::= SEQUENCE {
    version                  Version,
    privateKeyAlgorithm      SEQUENCE {
    algorithm                PUBLIC-KEY.&id({PublicKeySet}),
    parameters               PUBLIC-KEY.&Params({PublicKeySet}
                               {@privateKeyAlgorithm.algorithm})
                                  OPTIONAL}
    privateKey               OCTET STRING (CONTAINING
                               PUBLIC-KEY.&PrivateKey({PublicKeySet}
                                 {@privateKeyAlgorithm.algorithm})),
    attributes           [0] Attributes OPTIONAL,
    ...,
    [[2: publicKey       [1] BIT STRING (CONTAINING
                               PUBLIC-KEY.&Params({PublicKeySet}
                                 {@privateKeyAlgorithm.algorithm})
                                 OPTIONAL ]],
    ...
  }

  ...

  PrivateKey ::= OCTET STRING
                     -- Content varies based on type of key. The
                     -- algorithm identifier dictates the format of
                     -- the key.
]]></artwork>
	</figure>

	<t> For FrodoKEM private keys, the privateKey field in OneAsymmetricKey
   contains the OCTET STRING representation of the FrodoKEM private key.</t>

	<t>The privateKeyAlgorithm field uses the AlgorithmIdentifier structure
   with the appropriate OID as defined in <xref target="sect-3"/>.</t>

	<t>The publicKey field contains the byte stream of the public key.  If
   present, the publicKey field will hold the encoded public key as
   defined in <xref target="sect-4"/>.</t>

<!--	<t>
   Appendix C.1 contains examples for ML-KEM private keys encoded using
   the textual encoding defined in <xref target="RFC7468"/>.</t> -->

	</section>

<!--
	<section title="Private Key Consistency Testing" anchor="sect-8"><t>
   When receiving a private key that contains both the seed and the
   expandedKey, the recipient SHOULD perform a seed consistency check to
   ensure that the sender properly generated the private key.
   Recipients that do not perform this seed consistency check avoid
   keygen and compare operations, but are unable to ensure that the seed
   and expandedKey match.</t>

	<t>
   If the check is done and the seed and the expandedKey are not
   consistent, the recipient MUST reject the private key as malformed.</t>

	<t>
   When receiving a private key that contains an expandedKey, [FIPS203]
   stipulates in section 7.3 that before use, a "hash check" MUST be
   performed.  That section stipulates two other checks on the type and
   length of the expandedKey which are ensured by this standard.</t>

	<t>
   The seed consistency check consists of regenerating the expanded form
   from the seed via ML-KEM.KeyGen_internal(d,z) (algorithm 16) using
   the first 32 octets as _d_ and the remaining 32 octets as _z_ and
   ensuring it is bytewise equal to the value presented in the private
   key.</t>

	<t>Appendix C.4 includes some examples of inconsistent seeds and
   expanded private keys.</t> 

	</section>
-->

	<section title="Security Considerations" anchor="sect-9"><t>
   The Security Considerations section of <xref target="RFC5280"/> applies to this
   specification as well.</t>

	<t>
   Protection of the private-key information, i.e., the seed, is vital
   to public-key cryptography.  Disclosure of the private-key material
   to another entity can lead to masquerades.</t>

	<t>
   The generation of private keys relies on random numbers.  The use of
   inadequate pseudo-random number generators (PRNGs) to generate these
   values 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 than brute
   force searching the whole key space.  The generation of quality
   random numbers is difficult.</t>

<!--	<t>Many protocols only rely on the IND-CCA security of a KEM.  Some
   (implicitly) require further binding properties, formalized in
   <xref target="CDM23"/>.  The private key format influences these binding properties.
   Per <xref target="KEMMY24"/>, ML-KEM is LEAK-BIND-K-PK-secure and LEAK-BIND-K-CT-
   secure when using the expanded private key format, but not MAL-BIND-
   K-CT nor MAL-BIND-K-PK.  Using the 64-byte seed format provides a
   step up in binding security, additionally providing MAL-BIND-K-CT
   security, but still not MAL-BIND-K-PK.</t>
-->

   <t>
    For more detailed FrodoKEM specific security considerations refer to
    <xref target="I-D.longa-cfrg-frodokem" />.
   </t>
	</section>

	<section title="IANA Considerations" anchor="sect-10"><t>
   For the ASN.1 Module in Appendix A, IANA is requested to assign an
   object identifier (OID) for the module identifier (TBD) with a
   Description of "id-mod-frodokem-kem-2026".  The OID for the module
   should be allocated in the "SMI Security for PKIX Module Identifier"
   registry (1.3.6.1.5.5.7.0).</t>

	</section>

	</middle>

	<back>
	<references title="Normative References">
	&I-D.longa-cfrg-frodokem;
	&RFC2119;
	&RFC5280;
	&RFC5912;
	&RFC5958;
	&RFC8174;
	&RFC9629;
    <reference anchor="X680" 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>
	</references>

	<references title="Informative References">
<!--	<reference anchor="CDM23" target="https://eprint.iacr.org/2023/1933.pdf"><front>
	<title>Keeping Up with the KEMs: Stronger Security Notions for KEMs and automated analysis of KEM-based protocols</title>
	<author initials="C." surname="Cremers" fullname="C. Cremers">
	</author>
	<author initials="A." surname="Dax" fullname="A. Dax">
	</author>
	<author initials="N." surname="Medinger" fullname="N. Medinger">
	</author>
	<date year="2023"/>
	</front>
	</reference> -->
	&I-D.celi-wiggers-tls-authkem;
<!--	<reference anchor="KEMMY24" target="https://eprint.iacr.org/2024/523.pdf"><front>
	<title>Unbindable Kemmy Schmidt: ML-KEM is neither MAL-BIND-K-CT nor MAL-BIND-K-PK</title>
	<author initials="S." surname="Schmieg" fullname="S. Schmieg">
	</author>
	<date year="2024"/>
	</front>
	</reference> -->
	</references> 

	<section title="ASN.1 Module" anchor="sect-a"><t>
   This appendix includes the ASN.1 module <xref target="X680" /> for FrodoKEM.  Note
   that as per <xref target="RFC5280"/>, certificates use the Distinguished Encoding
   Rules; see [X690].  This module imports objects from <xref target="RFC5912"/> and
   <xref target="RFC9629"/>.</t>

	<figure><artwork><![CDATA[
<CODE BEGINS>
X509-FRODOKEM-2026
{ iso(1) identified-organization(3) dod(6)
  internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-frodokem-kem-2026(TBD) }

DEFINITIONS IMPLICIT TAGS ::= BEGIN

EXPORTS ALL;

IMPORTS

 PUBLIC-KEY
   FROM AlgorithmInformation-2009  -- [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) }

 KEM-ALGORITHM
   FROM KEMAlgorithmInformation-2023  -- [RFC 9629]
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-kemAlgorithmInformation-2023(109) };

--
-- FrodoKEM Identifiers
--

frodokem OBJECT IDENTIFIER ::= { iso(1) standard(0) 
encryption-algorithms(18033) part2(2) 
key-encapsulation-mechanism(2) 7 }

id-kem-frodokem976-shake OBJECT IDENTIFIER ::= { frodokem 1 }

id-kem-frodokem1344-shake OBJECT IDENTIFIER ::= { frodokem 2 }

id-kem-efrodokem976-shake OBJECT IDENTIFIER ::= { frodokem 3 }

id-kem-efrodokem1344-shake OBJECT IDENTIFIER ::= { frodokem 4 }

id-kem-frodokem976-aes OBJECT IDENTIFIER ::= { frodokem 5 }

id-kem-frodokem1344-aes OBJECT IDENTIFIER ::= { frodokem 6 }

id-kem-efrodokem976-aes OBJECT IDENTIFIER ::= { frodokem 7 }

id-kem-efrodokem1344-aes OBJECT IDENTIFIER ::= { frodokem 8 }

--
-- Public Key Algorithms
--

PublicKeys PUBLIC-KEY ::= {
  -- This expands PublicKeys from [RFC 5912]
  pk-frodokem976-shake |
  pk-frodokem1344-shake |
  pk-efrodokem976-shake |
  pk-efrodokem1344-shake |
  pk-frodokem976-aes |
  pk-frodokem1344-aes |
  pk-efrodokem976-aes |
  pk-efrodokem1344-aes,
  ...
  }

--
-- FrodoKEM Public Keys
--

pk-frodokem976-shake PUBLIC-KEY ::= {
  IDENTIFIER id-kem-frodokem976-shake
  -- KEY no ASN.1 wrapping; 15632 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY frodokem976-shake-PrivateKey -- defined in Section 6
  }

pk-frodokem1344-shake PUBLIC-KEY ::= {
  IDENTIFIER id-kem-frodokem1344-shake
  -- KEY no ASN.1 wrapping; 21520 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY frodokem1344-shake-PrivateKey -- defined in Section 6
  }

pk-efrodokem976-shake PUBLIC-KEY ::= {
  IDENTIFIER id-kem-efrodokem976-shake
  -- KEY no ASN.1 wrapping; 15632 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY efrodokem976-shake-PrivateKey -- defined in Section 6
  }

pk-efrodokem1344-shake PUBLIC-KEY ::= {
  IDENTIFIER id-kem-efrodokem1344-shake
  -- KEY no ASN.1 wrapping; 21520 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY efrodokem1344-shake-PrivateKey -- defined in Section 6
  }

pk-frodokem976-aes PUBLIC-KEY ::= {
  IDENTIFIER id-kem-frodokem976-aes
  -- KEY no ASN.1 wrapping; 15632 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY frodokem976-aes-PrivateKey -- defined in Section 6
  }

pk-frodokem1344-aes PUBLIC-KEY ::= {
  IDENTIFIER id-kem-frodokem1344-aes
  -- KEY no ASN.1 wrapping; 21520 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY frodokem1344-aes-PrivateKey -- defined in Section 6
  }

pk-efrodokem976-aes PUBLIC-KEY ::= {
  IDENTIFIER id-kem-efrodokem976-aes
  -- KEY no ASN.1 wrapping; 15632 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY efrodokem976-aes-PrivateKey -- defined in Section 6
  }

pk-efrodokem1344-aes PUBLIC-KEY ::= {
  IDENTIFIER id-kem-efrodokem1344-aes
  -- KEY no ASN.1 wrapping; 21520 octets --
  PARAMS ARE absent
  CERT-KEY-USAGE { keyEncipherment }
  PRIVATE-KEY efrodokem1344-aes-PrivateKey -- defined in Section 6
  }

frodokem976-shake-PublicKey ::= OCTET STRING (SIZE (15632))

frodokem1344-shake-PublicKey ::= OCTET STRING (SIZE (21520))

efrodokem976-shake-PublicKey ::= OCTET STRING (SIZE (15632))

efrodokem1344-shake-PublicKey ::= OCTET STRING (SIZE (21520))

frodokem976-aes-PublicKey ::= OCTET STRING (SIZE (15632))

frodokem1344-aes-PublicKey ::= OCTET STRING (SIZE (21520))

efrodokem976-aes-PublicKey ::= OCTET STRING (SIZE (15632))

efrodokem1344-aes-PublicKey ::= OCTET STRING (SIZE (21520))

END
<CODE ENDS>
]]></artwork>
	</figure>
	</section>

	<section title="Parameter Set Security and Sizes" anchor="sect-b">
    <t> Instead of defining the strength of a quantum algorithm in a
   traditional manner using the imprecise notion of bits of security,
   NIST has defined security levels by picking a reference scheme, which
   NIST expects to offer notable levels of resistance to both quantum
   and classical attack.  To wit, a KEM algorithm that achieves NIST PQC
   security must require computational resources to break IND-CCA
   security comparable or greater than that required for key search on
   AES-128, AES-192, and AES-256 for Levels 1, 3, and 5, respectively.
   Levels 2 and 4 use collision search for SHA-256 and SHA-384 as
   reference.</t>

<table title="Mapping between NIST Security Level, FrodoKEM parameter set, and sizes in bytes" anchor="table1">
  <thead>
    <tr>
        <th>Level</th>
        <th>Parameter Set</th>
        <th>Public Key pk</th>
        <th>Secret Key sk</th>
        <th>Ciphertext ct</th>
        <th>Shared Secret ss</th>
    </tr>
  </thead>
  <tbody>
    <tr>
        <th>3</th>
        <th>FrodoKEM-976</th>
        <th>15,632</th>
        <th>31,296</th>
        <th>15,792</th>
        <th>24</th>
    </tr>
    <tr>
        <th>3</th>
        <th>eFrodoKEM-976</th>
        <th>15,632</th>
        <th>31,296</th>
        <th>15,744</th>
        <th>24</th>
    </tr>
    <tr>
        <th>5</th>
        <th>FrodoKEM-1344</th>
        <th>21,520</th>
        <th>43,088</th>
        <th>21,696</th>
        <th>32</th>
    </tr>
    <tr>
        <th>5</th>
        <th>eFrodoKEM-1344</th>
        <th>21,520</th>
        <th>43,088</th>
        <th>21,632</th>
        <th>32</th>
    </tr>
  </tbody>
</table>

	</section>

	<section title="Acknowledgments" numbered="no" anchor="acknowledgments">
        <t> Most of the text was impudently stolen from draft-ietf-lamps-kyber-certificates.
        </t>
	</section>

	</back>

	</rfc>
	
