<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" docName="draft-cooley-cnsa-dtls-tls-profile-07" indexInclude="true" ipr="trust200902" number="9151" prepTime="2022-04-25T16:59:35" scripts="Common,Latin" sortRefs="true" submissionType="independent" symRefs="true" tocDepth="2" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-cooley-cnsa-dtls-tls-profile-07" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9151" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="CNSA Suite Profile for (D)TLS">Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3</title>
    <seriesInfo name="RFC" value="9151" stream="independent"/>
    <author fullname="Dorothy Cooley" initials="D." surname="Cooley">
      <organization abbrev="NSA" showOnFrontPage="true">National Security Agency</organization>
      <address>
        <email>decoole@nsa.gov</email>
      </address>
    </author>
    <date month="04" year="2022"/>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines a base profile for TLS protocol versions 1.2
      and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the
      US Commercial National Security Algorithm (CNSA) Suite.
      </t>
      <t indent="0" pn="section-abstract-2">The profile applies to the capabilities, configuration, and operation
      of all components of US National Security Systems that use TLS or DTLS.
      It is also appropriate for all other US Government systems that process
      high-value information.
</t>
      <t indent="0" pn="section-abstract-3">The profile is made publicly available here for use by developers and
      operators of these and any other system deployments.
</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see Section 2 of RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9151" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cnsa">CNSA</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cnsa-suites">CNSA Suites</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cnsa-dtls-key-establishment">CNSA (D)TLS Key Establishment Algorithms</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cnsa-tls-authentication">CNSA TLS Authentication</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cnsa-compliance-and-interop">CNSA Compliance and Interoperability Requirements</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acceptable-elliptic-curve-c">Acceptable Elliptic Curve Cryptography (ECC) Curves</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acceptable-rsa-schemes-para">Acceptable RSA Schemes, Parameters, and Checks</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acceptable-finite-field-gro">Acceptable Finite Field Groups</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-certificates">Certificates</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtls-12-requirements">(D)TLS 1.2 Requirements</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-extended_master_secret-">The "extended_master_secret" Extension</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-signature_algorithms-ex">The "signature_algorithms" Extension</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-signature_algorithms_ce">The "signature_algorithms_cert" Extension</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-certificaterequest-mess">The CertificateRequest Message</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-certificateverify-messa">The CertificateVerify Message</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.6">
                <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-signature-in-the-server">The Signature in the ServerKeyExchange Message</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.7">
                <t indent="0" pn="section-toc.1-1.6.2.7.1"><xref derivedContent="6.7" format="counter" sectionFormat="of" target="section-6.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-certificate-status">Certificate Status</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dtls-13-requirements">(D)TLS 1.3 Requirements</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-signature_algorithms-ext">The "signature_algorithms" Extension</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-signature_algorithms_cer">The "signature_algorithms_cert" Extension</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-early_data-extension">The "early_data" Extension</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-resumption">Resumption</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-certificate-status-2">Certificate Status</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">This document specifies a profile of TLS version 1.2 <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/> and TLS version 1.3 <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> as well as DTLS version 1.2 <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/> and DTLS version 1.3 <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/> for use by applications that support the National Security Agency's (NSA) Commercial National Security Algorithm (CNSA) Suite <xref target="CNSA" format="default" sectionFormat="of" derivedContent="CNSA"/>.  The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems <xref target="SP80059" format="default" sectionFormat="of" derivedContent="SP80059"/>. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments.
</t>
      <t indent="0" pn="section-1-2">This document does not define any new cipher suites; instead, it defines a CNSA-compliant profile of TLS and DTLS, and the cipher suites defined in <xref target="RFC5288" format="default" sectionFormat="of" derivedContent="RFC5288"/>, <xref target="RFC5289" format="default" sectionFormat="of" derivedContent="RFC5289"/>, and <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>.  This profile uses only algorithms in the CNSA Suite.
</t>
      <t indent="0" pn="section-1-3">The reader is assumed to have familiarity with the TLS 1.2 and 1.3 as well as the DTLS 1.2 and 1.3 protocol specifications: <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/>, <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>,  <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>, and <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/>, respectively.  All <bcp14>MUST</bcp14>-level requirements from the protocol documents apply throughout this profile; they are generally not repeated.  This profile contains changes that elevate some <bcp14>SHOULD</bcp14>-level options to <bcp14>MUST</bcp14>-level; this profile also contains changes that elevate some <bcp14>MAY</bcp14>-level options to <bcp14>SHOULD</bcp14>-level or <bcp14>MUST</bcp14>-level.  All options that are not mentioned in this profile remain at their original requirement level.
</t>
    </section>
    <section anchor="cnsa" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-cnsa">CNSA</name>
      <t indent="0" pn="section-2-1">The National Security Agency (NSA) profiles commercial cryptographic
      algorithms and protocols as part of its mission to support secure,
      interoperable communications for US National Security Systems. To this
      end, it publishes guidance both to assist with the US Government
      transition to new algorithms and to provide vendors -- and the Internet
      community in general -- with information concerning their proper use and
      configuration.
</t>
      <t indent="0" pn="section-2-2">Recently, cryptographic transition plans have become overshadowed by the prospect of the development of a cryptographically relevant quantum computer.  The NSA has established the CNSA Suite to provide vendors and IT users near-term flexibility in meeting their Information Assurance (IA) interoperability requirements. The purpose behind this flexibility is to avoid having vendors and customers make two major transitions in a relatively short timeframe, as we anticipate a need to shift to quantum-resistant cryptography in the near future.
</t>
      <t indent="0" pn="section-2-3">The NSA is authoring a set of RFCs, including this one, to provide
      updated guidance concerning the use of certain commonly available
      commercial algorithms in IETF protocols.  These RFCs can be used in
      conjunction with other RFCs and cryptographic guidance (e.g., NIST
      Special Publications) to properly protect Internet traffic and
      data-at-rest for US National Security Systems.
</t>
    </section>
    <section anchor="terms" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-3-1">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 in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here.
</t>
      <t indent="0" pn="section-3-2">"ECDSA" and "ECDH" refer to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Diffie Hellman (ECDH), respectively. ECDSA and ECDH are used with the NIST P-384 curve (which is based on a 384-bit prime modulus) and the SHA-384 hash function.  Similarly, "RSA" and "DH" refer to Rivest-Shamir-Adleman (RSA) and Finite Field Diffie-Hellman (DH), respectively. RSA and DH are used with a 3072-bit or 4096-bit modulus.  When RSA is used for digital signature, it is used with the SHA-384 hash function.
</t>
      <t indent="0" pn="section-3-3">Henceforth, this document refers to TLS versions 1.2 and 1.3 and DTLS versions 1.2 and 1.3 collectively as "(D)TLS".
</t>
    </section>
    <section anchor="cnsa-suite" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-cnsa-suites">CNSA Suites</name>
      <t indent="0" pn="section-4-1"><xref target="CNSA" format="default" sectionFormat="of" derivedContent="CNSA"/> approves the use of both Finite Field and elliptic curve versions of the DH key agreement algorithm as well as RSA-based key establishment. <xref target="CNSA" format="default" sectionFormat="of" derivedContent="CNSA"/> also approves certain versions of the RSA and elliptic curve digital signature algorithms. The approved encryption techniques include the Advanced Encryption Standard (AES) used with a 256-bit key in an Authenticated Encryption with Associated Data (AEAD) mode.
</t>
      <t indent="0" pn="section-4-2">In particular, CNSA includes the following:

</t>
      <dl newline="true" indent="3" spacing="normal" pn="section-4-3">
        <dt pn="section-4-3.1">Encryption:
</dt>
        <dd pn="section-4-3.2">AES <xref target="AES" format="default" sectionFormat="of" derivedContent="AES"/> (with key size 256 bits),
operating in Galois/Counter Mode (GCM) <xref target="GCM" format="default" sectionFormat="of" derivedContent="GCM"/>
        </dd>
        <dt pn="section-4-3.3">Digital Signature:
</dt>
        <dd pn="section-4-3.4">
          <t indent="0" pn="section-4-3.4.1">ECDSA <xref target="DSS" format="default" sectionFormat="of" derivedContent="DSS"/> (using the NIST P-384
elliptic curve)</t>
          <t indent="0" pn="section-4-3.4.2">RSA <xref target="DSS" format="default" sectionFormat="of" derivedContent="DSS"/> (with a modulus of
            3072 bits or 4096 bits)</t>
        </dd>
        <dt pn="section-4-3.5">Key Establishment (includes key agreement and key transport):
</dt>
        <dd pn="section-4-3.6">
          <t indent="0" pn="section-4-3.6.1">ECDH <xref target="PWKE-A" format="default" sectionFormat="of" derivedContent="PWKE-A"/> (using the NIST P-384
  elliptic curve)</t>
          <t indent="0" pn="section-4-3.6.2">DH <xref target="PWKE-A" format="default" sectionFormat="of" derivedContent="PWKE-A"/> (with a prime
            modulus of 3072 or 4096 bits)</t>
          <t indent="0" pn="section-4-3.6.3">RSA <xref target="PWKE-B" format="default" sectionFormat="of" derivedContent="PWKE-B"/> (with a modulus of
            3072 or 4096 bits, but only in (D)TLS 1.2)</t>
        </dd>
      </dl>
      <t indent="0" pn="section-4-4"><xref target="CNSA" format="default" sectionFormat="of" derivedContent="CNSA"/> also approves the use of SHA-384 <xref target="SHS" format="default" sectionFormat="of" derivedContent="SHS"/> as the hash algorithm for mask generation, signature generation, Pseudorandom Function (PRF) in TLS 1.2 and HMAC-based Key Derivation Function (HKDF) in TLS 1.3.
</t>
      <section anchor="tls-ke" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-cnsa-dtls-key-establishment">CNSA (D)TLS Key Establishment Algorithms</name>
        <t indent="0" pn="section-4.1-1">The following combination of algorithms and key sizes are used in CNSA (D)TLS:


</t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-4.1-2">
          <li pn="section-4.1-2.1">AES with 256-bit key, operating in GCM mode</li>
          <li pn="section-4.1-2.2">ECDH <xref target="PWKE-A" format="default" sectionFormat="of" derivedContent="PWKE-A"/> using the
          Ephemeral Unified Model Scheme with cofactor set to 1 (see Section
          6.1.2.2 in <xref target="PWKE-A" format="default" sectionFormat="of" derivedContent="PWKE-A"/>)</li>
          <li pn="section-4.1-2.3">TLS PRF/HKDF with SHA-384 <xref target="SHS" format="default" sectionFormat="of" derivedContent="SHS"/></li>
        </ul>
        <t indent="0" pn="section-4.1-3">Or

</t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-4.1-4">
          <li pn="section-4.1-4.1">AES with 256-bit key, operating in GCM mode</li>
          <li pn="section-4.1-4.2">RSA key transport using 3072-bit or 4096-bit modulus <xref target="PWKE-B" format="default" sectionFormat="of" derivedContent="PWKE-B"/><xref target="RFC8017" format="default" sectionFormat="of" derivedContent="RFC8017"/></li>
          <li pn="section-4.1-4.3">TLS PRF/HKDF with SHA-384 <xref target="SHS" format="default" sectionFormat="of" derivedContent="SHS"/></li>
        </ul>
        <t indent="0" pn="section-4.1-5">Or

</t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-4.1-6">
          <li pn="section-4.1-6.1">AES with 256-bit key, operating in GCM mode</li>
          <li pn="section-4.1-6.2">DH using dhEphem with domain parameters specified below in <xref target="ff-groups" format="default" sectionFormat="of" derivedContent="Section 5.3"/> (see Section 6.1.2.1 in <xref target="PWKE-A" format="default" sectionFormat="of" derivedContent="PWKE-A"/>)</li>
          <li pn="section-4.1-6.3">TLS PRF/HKDF with SHA-384 <xref target="SHS" format="default" sectionFormat="of" derivedContent="SHS"/></li>
        </ul>
        <t indent="0" pn="section-4.1-7">The specific CNSA-compliant cipher suites are listed in <xref target="compliance" format="default" sectionFormat="of" derivedContent="Section 5"/>.
</t>
      </section>
      <section anchor="tls-auth" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-cnsa-tls-authentication">CNSA TLS Authentication</name>
        <t indent="0" pn="section-4.2-1">For server and/or client authentication, CNSA (D)TLS <bcp14>MUST</bcp14> generate and verify either ECDSA signatures or RSA signatures.
</t>
        <t indent="0" pn="section-4.2-2">In all cases, the client <bcp14>MUST</bcp14> authenticate the
        server.  The server <bcp14>MAY</bcp14> also authenticate the client, as
        needed by the specific application.
</t>
        <t indent="0" pn="section-4.2-3">The public keys used to verify these signatures <bcp14>MUST</bcp14>
        be contained in a certificate (see <xref target="certs" format="default" sectionFormat="of" derivedContent="Section 5.4"/> for more
        information).</t>
      </section>
    </section>
    <section anchor="compliance" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-cnsa-compliance-and-interop">CNSA Compliance and Interoperability Requirements</name>
      <t indent="0" pn="section-5-1">CNSA (D)TLS <bcp14>MUST NOT</bcp14> use TLS versions prior to (D)TLS
      1.2 in a CNSA-compliant system.  CNSA (D)TLS servers and clients
      <bcp14>MUST</bcp14> implement and use either (D)TLS version 1.2 <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/> <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/> or (D)TLS version 1.3 <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/>.
</t>
      <section anchor="ecc-curves" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-acceptable-elliptic-curve-c">Acceptable Elliptic Curve Cryptography (ECC) Curves</name>
        <t indent="0" pn="section-5.1-1">The elliptic curves used in the CNSA Suite appear in the literature
        under two different names <xref target="DSS" format="default" sectionFormat="of" derivedContent="DSS"/> <xref target="SECG" format="default" sectionFormat="of" derivedContent="SECG"/>.  For the sake of clarity, both names
        are listed below:
</t>
        <table anchor="elliptic_curve_table" align="center" pn="table-1">
          <name slugifiedName="name-elliptic-curves-in-cnsa-sui">Elliptic Curves in CNSA Suite</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Curve</th>
              <th align="left" colspan="1" rowspan="1">NIST name</th>
              <th align="left" colspan="1" rowspan="1">SECG name</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">P-384</td>
              <td align="left" colspan="1" rowspan="1">nistp384</td>
              <td align="left" colspan="1" rowspan="1">secp384r1</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-5.1-3"><xref target="RFC8422" format="default" sectionFormat="of" derivedContent="RFC8422"/> defines a variety of elliptic curves.  CNSA (D)TLS connections <bcp14>MUST</bcp14> use secp384r1 (also called nistp384), and the uncompressed form <bcp14>MUST</bcp14> be used, as required by <xref target="RFC8422" format="default" sectionFormat="of" derivedContent="RFC8422"/> and <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>.
</t>
        <t indent="0" pn="section-5.1-4">Key pairs <bcp14>MUST</bcp14> be generated following Section 5.6.1.2 of <xref target="PWKE-A" format="default" sectionFormat="of" derivedContent="PWKE-A"/>.
</t>
      </section>
      <section anchor="rsa-schemes" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-acceptable-rsa-schemes-para">Acceptable RSA Schemes, Parameters, and Checks</name>
        <t indent="0" pn="section-5.2-1"><xref target="CNSA" format="default" sectionFormat="of" derivedContent="CNSA"/> specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile. 
</t>
        <dl newline="true" indent="3" spacing="normal" pn="section-5.2-2">
          <dt pn="section-5.2-2.1">For (D)TLS 1.2:
</dt>
          <dd pn="section-5.2-2.2">
            <t indent="0" pn="section-5.2-2.2.1">For certificate signatures, RSASSA-PKCS1-v1_5 <xref target="RFC8017" format="default" sectionFormat="of" derivedContent="RFC8017"/> <bcp14>MUST</bcp14> be supported, and RSASSA-PSS <xref target="DSS" format="default" sectionFormat="of" derivedContent="DSS"/> <bcp14>SHOULD</bcp14> be supported.</t>
            <t indent="0" pn="section-5.2-2.2.2">For signatures in TLS handshake messages, RSASSA-PKCS1-v1_5 <xref target="RFC8017" format="default" sectionFormat="of" derivedContent="RFC8017"/> <bcp14>MUST</bcp14> be supported, and RSASSA-PSS <xref target="DSS" format="default" sectionFormat="of" derivedContent="DSS"/> <bcp14>SHOULD</bcp14> be supported.</t>
            <t indent="0" pn="section-5.2-2.2.3">For key transport, RSAES-PKCS1-v1_5 <xref target="RFC8017" format="default" sectionFormat="of" derivedContent="RFC8017"/> <bcp14>MUST</bcp14> be supported.</t>
          </dd>
          <dt pn="section-5.2-2.3">For (D)TLS 1.3:
</dt>
          <dd pn="section-5.2-2.4">
            <t indent="0" pn="section-5.2-2.4.1">For certificate signatures, RSASSA-PKCS1-v1_5 <xref target="RFC8017" format="default" sectionFormat="of" derivedContent="RFC8017"/> <bcp14>MUST</bcp14> be supported, and RSASSA-PSS <xref target="DSS" format="default" sectionFormat="of" derivedContent="DSS"/> <bcp14>SHOULD</bcp14> be supported.</t>
            <t indent="0" pn="section-5.2-2.4.2">For signatures in TLS handshake messages, RSASSA-PSS <xref target="DSS" format="default" sectionFormat="of" derivedContent="DSS"/> <bcp14>MUST</bcp14> be
              supported.</t>
            <t indent="0" pn="section-5.2-2.4.3">For key transport, TLS 1.3 does not support RSA key
              transport.</t>
          </dd>
          <dt pn="section-5.2-2.5">For all versions of (D)TLS:
</dt>
          <dd pn="section-5.2-2.6">
            <t indent="0" pn="section-5.2-2.6.1">RSA exponent e <bcp14>MUST</bcp14> satisfy
  2<sup>16</sup>&lt;e&lt;2<sup>256</sup> and be odd per <xref target="DSS" format="default" sectionFormat="of" derivedContent="DSS"/>.</t>
            <t indent="0" pn="section-5.2-2.6.2">If RSASSA-PSS is supported (using rsa_pss_rsae_sha384 for example), then
   the implementation <bcp14>MUST</bcp14> assert rsaEncryption as the public
   key algorithm, the hash algorithm (used for both mask generation and
   signature generation) <bcp14>MUST</bcp14> be SHA-384, the mask generation
   function 1 (MGF1) from <xref target="RFC8017" format="default" sectionFormat="of" derivedContent="RFC8017"/>
              <bcp14>MUST</bcp14> be used, and the salt length <bcp14>MUST</bcp14> be 48
   octets.</t>
          </dd>
        </dl>
      </section>
      <section anchor="ff-groups" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-acceptable-finite-field-gro">Acceptable Finite Field Groups</name>
        <t indent="0" pn="section-5.3-1"><xref target="CNSA" format="default" sectionFormat="of" derivedContent="CNSA"/> specifies a minimum modulus size of 3072 bits; however, only two modulus sizes (3072 bits and 4096 bits) are supported by this profile. 
</t>
        <t indent="0" pn="section-5.3-2">Ephemeral key pairs <bcp14>MUST</bcp14> be generated following Section 5.6.1.1.1 of <xref target="PWKE-A" format="default" sectionFormat="of" derivedContent="PWKE-A"/> using the approved safe prime groups specified in <xref target="RFC7919" format="default" sectionFormat="of" derivedContent="RFC7919"/> for DH ephemeral key agreement.  The named groups are:	

</t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-5.3-3">
          <li pn="section-5.3-3.1">ffdhe3072 (ID=257)</li>
          <li pn="section-5.3-3.2">ffdhe4096 (ID=258)</li>
        </ul>
      </section>
      <section anchor="certs" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-certificates">Certificates</name>
        <t indent="0" pn="section-5.4-1">Certificates used to establish a CNSA (D)TLS connection <bcp14>MUST</bcp14> be signed with ECDSA or RSA and <bcp14>MUST</bcp14> be compliant with the CNSA Suite Certificate and Certificate Revocation List (CRL) Profile <xref target="RFC8603" format="default" sectionFormat="of" derivedContent="RFC8603"/>.
</t>
      </section>
    </section>
    <section anchor="tls12-reqts" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-dtls-12-requirements">(D)TLS 1.2 Requirements</name>
      <t indent="0" pn="section-6-1">Although TLS 1.2 has technically been obsoleted by the IETF in favor of TLS 1.3, many implementations and deployments of TLS 1.2 will continue to exist.  For the cases where TLS 1.2 continues to be used, implementations <bcp14>MUST</bcp14> use <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/> and <bcp14>SHOULD</bcp14> implement the updates specified in <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/> (outlined in Section <xref sectionFormat="bare" section="1.3" target="RFC8446" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-1.3" derivedContent="RFC8446"/> of that document).
</t>
      <t indent="0" pn="section-6-2">The CNSA (D)TLS 1.2 client <bcp14>MUST</bcp14> offer at least one of these cipher suites:

</t>
      <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6-3">
        <li pn="section-6-3.1">TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5289" format="default" sectionFormat="of" derivedContent="RFC5289"/> <xref target="RFC8422" format="default" sectionFormat="of" derivedContent="RFC8422"/></li>
        <li pn="section-6-3.2">TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5289" format="default" sectionFormat="of" derivedContent="RFC5289"/> <xref target="RFC8422" format="default" sectionFormat="of" derivedContent="RFC8422"/></li>
        <li pn="section-6-3.3">TLS_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5288" format="default" sectionFormat="of" derivedContent="RFC5288"/></li>
        <li pn="section-6-3.4">TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 <xref target="RFC5288" format="default" sectionFormat="of" derivedContent="RFC5288"/> <xref target="RFC7919" format="default" sectionFormat="of" derivedContent="RFC7919"/></li>
      </ul>
      <t indent="0" pn="section-6-4">The CNSA cipher suites listed above <bcp14>MUST</bcp14> be the first
      (most preferred) cipher suites in the ClientHello message.
</t>
      <t indent="0" pn="section-6-5">A CNSA (D)TLS client that offers interoperability with servers that are not CNSA compliant <bcp14>MAY</bcp14> offer additional cipher suites, but any additional cipher suites <bcp14>MUST</bcp14> appear after the CNSA cipher suites in the ClientHello message.
</t>
      <t indent="0" pn="section-6-6">A CNSA (D)TLS server <bcp14>MUST</bcp14> accept one of the CNSA
      Suites above if they are offered in the ClientHello message before
      accepting a non-CNSA-compliant suite.
</t>
      <t indent="0" pn="section-6-7">If interoperability is not desired with non-CNSA-compliant clients or
      servers, then the session <bcp14>MUST</bcp14> fail if no CNSA Suites are
      offered or accepted.
</t>
      <section anchor="ext-master-secret" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-the-extended_master_secret-">The "extended_master_secret" Extension</name>
        <t indent="0" pn="section-6.1-1">A CNSA (D)TLS client <bcp14>SHOULD</bcp14> include and a CNSA
        (D)TLS server <bcp14>SHOULD</bcp14> accept the
        "extended_master_secret" extension as specified in <xref target="RFC7627" format="default" sectionFormat="of" derivedContent="RFC7627"/>. See <xref target="RFC7627" sectionFormat="of" section="1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7627#section-1" derivedContent="RFC7627"/> for security
        concerns when this extension is not used.
</t>
      </section>
      <section anchor="tls12-sig-algs" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-the-signature_algorithms-ex">The "signature_algorithms" Extension</name>
        <t indent="0" pn="section-6.2-1">A CNSA (D)TLS client <bcp14>MUST</bcp14> include and a CNSA (D)TLS server <bcp14>MUST</bcp14> also accept the "signature_algorithms" extension. The CNSA (D)TLS client <bcp14>MUST</bcp14> offer and the 
  CNSA (D)TLS server <bcp14>MUST</bcp14> also accept at least one of the following values in the "signature_algorithms" extensions as specified in <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>:

        </t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.2-2">
          <li pn="section-6.2-2.1">ecdsa_secp384r1_sha384</li>
          <li pn="section-6.2-2.2">rsa_pkcs1_sha384</li>
        </ul>
        <t indent="0" pn="section-6.2-3">And, if supported, the client <bcp14>SHOULD</bcp14> offer and/or the server <bcp14>SHOULD</bcp14> also accept:

        </t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.2-4">
          <li pn="section-6.2-4.1">rsa_pss_pss_sha384</li>
          <li pn="section-6.2-4.2">rsa_pss_rsae_sha384</li>
        </ul>
        <t indent="0" pn="section-6.2-5">Following the guidance in <xref target="RFC8603" format="default" sectionFormat="of" derivedContent="RFC8603"/>, CNSA (D)TLS servers <bcp14>MUST</bcp14> only accept ECDSA or RSA for signatures on ServerKeyExchange messages and for certification path validation.
</t>
        <t indent="0" pn="section-6.2-6">Other client offerings <bcp14>MAY</bcp14> be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA and to indicate the signature algorithms that are acceptable for ServerKeyExchange messages and for certification path validation in non-compliant CNSA (D)TLS connections. These offerings <bcp14>MUST NOT</bcp14> be accepted by a CNSA-compliant (D)TLS server.
</t>
      </section>
      <section anchor="tls12-sig-algs-cert-ext" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-the-signature_algorithms_ce">The "signature_algorithms_cert" Extension</name>
        <t indent="0" pn="section-6.3-1">A CNSA (D)TLS client <bcp14>MAY</bcp14> include the
        "signature_algorithms_cert" extension.  CNSA (D)TLS servers
        <bcp14>MUST</bcp14> process the "signature_algorithms_cert" extension
        if it is offered per <xref target="RFC8446" sectionFormat="of" section="4.2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-4.2.3" derivedContent="RFC8446"/>.
</t>
        <t indent="0" pn="section-6.3-2">Both CNSA (D)TLS clients and servers <bcp14>MUST</bcp14> use one of the following values for certificate path validation:

        </t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3-3">
          <li pn="section-6.3-3.1">ecdsa_secp384r1_sha384</li>
          <li pn="section-6.3-3.2">rsa_pkcs1_sha384</li>
        </ul>
        <t indent="0" pn="section-6.3-4">And, if supported, <bcp14>SHOULD</bcp14> offer/accept:

        </t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.3-5">
          <li pn="section-6.3-5.1">rsa_pss_pss_sha384</li>
          <li pn="section-6.3-5.2">rsa_pss_rsae_sha384</li>
        </ul>
      </section>
      <section anchor="tls12-cert-request" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-the-certificaterequest-mess">The CertificateRequest Message</name>
        <t indent="0" pn="section-6.4-1">When a CNSA (D)TLS server is configured to authenticate the client, the server <bcp14>MUST</bcp14> include the following values in its CertificateRequest.supported_signature_algorithms <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/> offer:

        </t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.4-2">
          <li pn="section-6.4-2.1">ecdsa_secp384r1_sha384</li>
          <li pn="section-6.4-2.2">rsa_pkcs1_sha384</li>
        </ul>
        <t indent="0" pn="section-6.4-3">And, if supported as specified in <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>, <bcp14>SHOULD</bcp14> offer/accept:

        </t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.4-4">
          <li pn="section-6.4-4.1">rsa_pss_pss_sha384</li>
          <li pn="section-6.4-4.2">rsa_pss_rsae_sha384</li>
        </ul>
      </section>
      <section anchor="tls12-cert-verify" numbered="true" toc="include" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-the-certificateverify-messa">The CertificateVerify Message</name>
        <t indent="0" pn="section-6.5-1">A CNSA (D)TLS client <bcp14>MUST</bcp14> use ECDSA or RSA when sending the CertificateVerify message.  CNSA (D)TLS servers <bcp14>MUST</bcp14> only accept ECDSA or RSA in the CertificateVerify message.	
</t>
      </section>
      <section anchor="tls12-ske-message" numbered="true" toc="include" removeInRFC="false" pn="section-6.6">
        <name slugifiedName="name-the-signature-in-the-server">The Signature in the ServerKeyExchange Message</name>
        <t indent="0" pn="section-6.6-1">A CNSA (D)TLS server <bcp14>MUST</bcp14> sign the ServerKeyExchange message using ECDSA or RSA.
</t>
      </section>
      <section anchor="tls12-cert-status" numbered="true" toc="include" removeInRFC="false" pn="section-6.7">
        <name slugifiedName="name-certificate-status">Certificate Status</name>
        <t indent="0" pn="section-6.7-1">Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS
        server or client <bcp14>MUST</bcp14> provide certificate revocation
        status information via a Certificate Revocation List (CRL)
        distribution point or using the Online Certificate Status Protocol
        (OCSP).  A CNSA client <bcp14>SHOULD</bcp14> request it according to
        <xref target="RFC8446" format="default" sectionFormat="of" section="4.4.2.1" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-4.4.2.1" derivedContent="RFC8446"/>.  If OCSP is supported, the (D)TLS server
        <bcp14>SHOULD</bcp14> provide OCSP responses in the
        CertificateStatus message.
</t>
      </section>
    </section>
    <section anchor="tls13-reqts" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-dtls-13-requirements">(D)TLS 1.3 Requirements</name>
      <t indent="0" pn="section-7-1">The CNSA (D)TLS client <bcp14>MUST</bcp14> offer the following cipher
      suite in the ClientHello:

</t>
      <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-7-2">
        <li pn="section-7-2.1">TLS_AES_256_GCM_SHA384</li>
      </ul>
      <t indent="0" pn="section-7-3">The CNSA (D)TLS client <bcp14>MUST</bcp14> include at least one of
      the following values in the "supported_groups" extension:

</t>
      <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-7-4">
        <li pn="section-7-4.1">ECDHE:  secp384r1</li>
        <li pn="section-7-4.2">DHE: ffdhe3072</li>
        <li pn="section-7-4.3">DHE: ffdhe4096</li>
      </ul>
      <t indent="0" pn="section-7-5">The CNSA cipher suite <bcp14>MUST</bcp14> be the first (most
      preferred) cipher suite in the ClientHello message and in the
      extensions.
</t>
      <t indent="0" pn="section-7-6">A CNSA (D)TLS client that offers interoperability with servers that are 
not CNSA compliant <bcp14>MAY</bcp14> offer additional cipher suites, but any additional 
cipher suites <bcp14>MUST</bcp14> appear after the CNSA-compliant cipher suites in the 
ClientHello message.
</t>
      <t indent="0" pn="section-7-7">A CNSA (D)TLS server <bcp14>MUST</bcp14> accept one of the CNSA algorithms listed above if they are offered in the ClientHello message.
</t>
      <t indent="0" pn="section-7-8">If interoperability is not desired with non-CNSA-compliant clients or servers, then the session <bcp14>MUST</bcp14> fail if no CNSA Suites are offered or accepted.
</t>
      <section anchor="tls13-sig-algs" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-the-signature_algorithms-ext">The "signature_algorithms" Extension</name>
        <t indent="0" pn="section-7.1-1">A CNSA (D)TLS client <bcp14>MUST</bcp14> include the "signature_algorithms" extension. The CNSA (D)TLS client <bcp14>MUST</bcp14> offer at least one of the following values in the "signature_algorithms" extension:

        </t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-7.1-2">
          <li pn="section-7.1-2.1">ecdsa_secp384r1_sha384</li>
          <li pn="section-7.1-2.2">rsa_pss_pss_sha384</li>
          <li pn="section-7.1-2.3">rsa_pss_rsae_sha384</li>
        </ul>
        <t indent="0" pn="section-7.1-3">Clients that allow negotiating TLS 1.2 <bcp14>MAY</bcp14> offer rsa_pkcs1_sha384 for use with TLS 1.2.  Other offerings <bcp14>MAY</bcp14> be included to indicate the acceptable signature algorithms in cipher suites that are offered for interoperability with servers not compliant with CNSA in non-compliant CNSA (D)TLS connections.  These offerings <bcp14>MUST NOT</bcp14> be accepted by a CNSA-compliant (D)TLS server.
</t>
      </section>
      <section anchor="tls13-sig-algs-cert" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-the-signature_algorithms_cer">The "signature_algorithms_cert" Extension</name>
        <t indent="0" pn="section-7.2-1">A CNSA (D)TLS client <bcp14>SHOULD</bcp14> include the "signature_algorithms_cert" extension. And, if offered, the CNSA (D)TLS client <bcp14>MUST</bcp14> offer at least one of the following values in the "signature_algorithms_cert" extension:

</t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-7.2-2">
          <li pn="section-7.2-2.1">ecdsa_secp384r1_sha384</li>
          <li pn="section-7.2-2.2">rsa_pkcs1_sha384</li>
        </ul>
        <t indent="0" pn="section-7.2-3">And, if supported, <bcp14>SHOULD</bcp14> offer:
</t>
        <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-7.2-4">
          <li pn="section-7.2-4.1">rsa_pss_pss_sha384</li>
          <li pn="section-7.2-4.2">rsa_pss_rsae_sha384</li>
        </ul>
        <t indent="0" pn="section-7.2-5">Following the guidance in <xref target="RFC8603" format="default" sectionFormat="of" derivedContent="RFC8603"/>, CNSA (D)TLS servers <bcp14>MUST</bcp14> only accept ECDSA or RSA for certificate path validation.
</t>
        <t indent="0" pn="section-7.2-6">Other offerings <bcp14>MAY</bcp14> be included to indicate the signature algorithms that are acceptable for certification path validation in non-compliant CNSA (D)TLS connections. These offerings <bcp14>MUST NOT</bcp14> be accepted by a CNSA-compliant (D)TLS server.
</t>
      </section>
      <section anchor="tls13-early-data" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-the-early_data-extension">The "early_data" Extension</name>
        <t indent="0" pn="section-7.3-1">A CNSA (D)TLS client or server <bcp14>MUST NOT</bcp14> include the
        "early_data" extension.  See <xref target="RFC8446" format="default" sectionFormat="of" section="2.3" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-2.3" derivedContent="RFC8446"/> for security concerns.
</t>
      </section>
      <section anchor="tls13-resumption" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-resumption">Resumption</name>
        <t indent="0" pn="section-7.4-1">A CNSA (D)TLS server <bcp14>MAY</bcp14> send a CNSA (D)TLS client a
        NewSessionTicket message to enable resumption. A CNSA (D)TLS client
        <bcp14>MUST</bcp14> request "psk_dhe_ke" via the
        "psk_key_exchange_modes" ClientHello extension to resume a session. A
        CNSA (D)TLS client <bcp14>MUST</bcp14> offer Ephemeral Elliptic Curve
        Diffie-Hellman (ECDHE) with SHA-384 and/or Ephemeral Diffie-Hellman (DHE) with SHA-384 in the
        "supported_groups" and/or "key_share" extensions.
</t>
      </section>
      <section anchor="tls13-cert-stat" numbered="true" toc="include" removeInRFC="false" pn="section-7.5">
        <name slugifiedName="name-certificate-status-2">Certificate Status</name>
        <t indent="0" pn="section-7.5-1">Certificate Authorities (CAs) providing certificates to a CNSA (D)TLS server or client <bcp14>MUST</bcp14> provide certificate revocation status information via a Certificate Revocation List (CRL) distribution point or using the Online Certificate Status Protocol (OCSP).  A CNSA client <bcp14>SHOULD</bcp14> request it according to <xref target="RFC8446" format="default" sectionFormat="of" section="4.4.2.1" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-4.4.2.1" derivedContent="RFC8446"/>.  If OCSP is supported, the (D)TLS server <bcp14>SHOULD</bcp14> provide OCSP responses in the "CertificateEntry".
</t>
      </section>
    </section>
    <section anchor="sec-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">Most of the security considerations for this document are described
      in <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/>, <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>, <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>, and <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/>.  In addition, the security
      considerations for Elliptic Curve Cryptography (ECC) related to TLS are
      described in <xref target="RFC8422" format="default" sectionFormat="of" derivedContent="RFC8422"/>, <xref target="RFC5288" format="default" sectionFormat="of" derivedContent="RFC5288"/>, and <xref target="RFC5289" format="default" sectionFormat="of" derivedContent="RFC5289"/>. Readers should consult those documents.
</t>
      <t indent="0" pn="section-8-2">In order to meet the goal of a consistent security level for the entire cipher suite, CNSA (D)TLS implementations <bcp14>MUST</bcp14> only use the elliptic curves, RSA schemes, and Finite Fields defined in <xref target="ecc-curves" format="default" sectionFormat="of" derivedContent="Section 5.1"/>, <xref target="rsa-schemes" format="default" sectionFormat="of" derivedContent="Section 5.2"/>, and <xref target="ff-groups" format="default" sectionFormat="of" derivedContent="Section 5.3"/>, respectively.  If this is not the case, then security may be weaker than is required.
</t>
      <t indent="0" pn="section-8-3">As noted in TLS version 1.3 <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>, TLS does not provide inherent replay protections for early data.  For this reason, this profile forbids the use of early data.
</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="AES" target="https://nvlpubs.nist.gov/nistpubs/fips/NIST.FIPS.197.pdf" quoteTitle="true" derivedAnchor="AES">
          <front>
            <title>Announcing the ADVANCED ENCRYPTION STANDARD (AES)</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <date month="November" year="2001"/>
          </front>
          <seriesInfo name="FIPS" value="197"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.197"/>
        </reference>
        <reference anchor="CNSA" target="https://www.cnss.gov/CNSS/issuances/Policies.cfm" quoteTitle="true" derivedAnchor="CNSA">
          <front>
            <title>Use of Public Standards for Secure Information Sharing</title>
            <author>
              <organization showOnFrontPage="true">Committee for National Security Systems</organization>
            </author>
            <date month="October" year="2016"/>
          </front>
          <seriesInfo name="CNSSP" value="15"/>
        </reference>
        <reference anchor="DSS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf" quoteTitle="true" derivedAnchor="DSS">
          <front>
            <title>Digital Signature Standard (DSS)</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <date month="July" year="2013"/>
          </front>
          <seriesInfo name="FIPS PUB" value="186-4"/>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-4"/>
        </reference>
        <reference anchor="GCM" target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf" quoteTitle="true" derivedAnchor="GCM">
          <front>
            <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title>
            <author fullname="Morris Dworkin" initials="M" surname="Dworkin"/>
            <date month="November" year="2007"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-38D"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
        </reference>
        <reference anchor="PWKE-A" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf" quoteTitle="true" derivedAnchor="PWKE-A">
          <front>
            <title>Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography</title>
            <author fullname="Elaine Barker" initials="E" surname="Barker"/>
            <author fullname="Lily Chen" initials="L" surname="Chen"/>
            <author fullname="Allen Roginsky" initials="A" surname="Roginsky"/>
            <author fullname="Apostol Vassilev" initials="A" surname="Vassilev"/>
            <author fullname="Richard Davis" initials="R" surname="Davis"/>
            <date month="April" year="2018"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-56A Revision 3"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
        </reference>
        <reference anchor="PWKE-B" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf" quoteTitle="true" derivedAnchor="PWKE-B">
          <front>
            <title>Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography</title>
            <author fullname="Elaine Barker" initials="E" surname="Barker"/>
            <author fullname="Lily Chen" initials="L" surname="Chen"/>
            <author fullname="Allen Roginsky" initials="A" surname="Roginsky"/>
            <author fullname="Apostol Vassilev" initials="A" surname="Vassilev"/>
            <author fullname="Richard Davis" initials="R" surname="Davis"/>
            <author fullname="Scott Simon" initials="S" surname="Simon"/>
            <date month="March" year="2019"/>
          </front>
          <seriesInfo name="NIST Special Publication" value="800-56B Revision 2"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Br2"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">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="RFC5246" target="https://www.rfc-editor.org/info/rfc5246" quoteTitle="true" derivedAnchor="RFC5246">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
            <author initials="T." surname="Dierks" fullname="T. Dierks">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="August"/>
            <abstract>
              <t indent="0">This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5246"/>
          <seriesInfo name="DOI" value="10.17487/RFC5246"/>
        </reference>
        <reference anchor="RFC5288" target="https://www.rfc-editor.org/info/rfc5288" quoteTitle="true" derivedAnchor="RFC5288">
          <front>
            <title>AES Galois Counter Mode (GCM) Cipher Suites for TLS</title>
            <author initials="J." surname="Salowey" fullname="J. Salowey">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Choudhury" fullname="A. Choudhury">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="McGrew" fullname="D. McGrew">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="August"/>
            <abstract>
              <t indent="0">This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation.  GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations.  This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and Diffie-Hellman-based key exchange mechanisms.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5288"/>
          <seriesInfo name="DOI" value="10.17487/RFC5288"/>
        </reference>
        <reference anchor="RFC5289" target="https://www.rfc-editor.org/info/rfc5289" quoteTitle="true" derivedAnchor="RFC5289">
          <front>
            <title>TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="August"/>
            <abstract>
              <t indent="0">RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS).  However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm.  This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms.  Eight use Hashed Message Authentication Code (HMAC) with SHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM).   This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5289"/>
          <seriesInfo name="DOI" value="10.17487/RFC5289"/>
        </reference>
        <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" quoteTitle="true" derivedAnchor="RFC6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Modadugu" fullname="N. Modadugu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="January"/>
            <abstract>
              <t indent="0">This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to work with TLS version 1.2.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6347"/>
          <seriesInfo name="DOI" value="10.17487/RFC6347"/>
        </reference>
        <reference anchor="RFC7627" target="https://www.rfc-editor.org/info/rfc7627" quoteTitle="true" derivedAnchor="RFC7627">
          <front>
            <title>Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension</title>
            <author initials="K." surname="Bhargavan" fullname="K. Bhargavan" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Delignat-Lavaud" fullname="A. Delignat-Lavaud">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Pironti" fullname="A. Pironti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Langley" fullname="A. Langley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Ray" fullname="M. Ray">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="September"/>
            <abstract>
              <t indent="0">The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate.  Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same.  Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server.  This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7627"/>
          <seriesInfo name="DOI" value="10.17487/RFC7627"/>
        </reference>
        <reference anchor="RFC7919" target="https://www.rfc-editor.org/info/rfc7919" quoteTitle="true" derivedAnchor="RFC7919">
          <front>
            <title>Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)</title>
            <author initials="D." surname="Gillmor" fullname="D. Gillmor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t indent="0">Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept.  This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.</t>
              <t indent="0">This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography (ECC) extensions (RFC 4492).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7919"/>
          <seriesInfo name="DOI" value="10.17487/RFC7919"/>
        </reference>
        <reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8017" quoteTitle="true" derivedAnchor="RFC8017">
          <front>
            <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
            <author initials="K." surname="Moriarty" fullname="K. Moriarty" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Kaliski" fullname="B. Kaliski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Jonsson" fullname="J. Jonsson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Rusch" fullname="A. Rusch">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="November"/>
            <abstract>
              <t indent="0">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 indent="0">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 indent="0">This document also obsoletes RFC 3447.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8017"/>
          <seriesInfo name="DOI" value="10.17487/RFC8017"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">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>
        <reference anchor="RFC8422" target="https://www.rfc-editor.org/info/rfc8422" quoteTitle="true" derivedAnchor="RFC8422">
          <front>
            <title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier</title>
            <author initials="Y." surname="Nir" fullname="Y. Nir">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Josefsson" fullname="S. Josefsson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Pegourie-Gonnard" fullname="M. Pegourie-Gonnard">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="August"/>
            <abstract>
              <t indent="0">This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol.  In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.</t>
              <t indent="0">This document obsoletes RFC 4492.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8422"/>
          <seriesInfo name="DOI" value="10.17487/RFC8422"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="August"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8603" target="https://www.rfc-editor.org/info/rfc8603" quoteTitle="true" derivedAnchor="RFC8603">
          <front>
            <title>Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile</title>
            <author initials="M." surname="Jenkins" fullname="M. Jenkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Zieglar" fullname="L. Zieglar">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="May"/>
            <abstract>
              <t indent="0">This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Commercial National Security Algorithm (CNSA) Suite.  The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ such X.509 certificates.  US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information.  It is made publicly available for use by developers and operators of these and any other system deployments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8603"/>
          <seriesInfo name="DOI" value="10.17487/RFC8603"/>
        </reference>
        <reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9147" quoteTitle="true" derivedAnchor="RFC9147">
          <front>
            <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Modadugu" fullname="N. Modadugu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2022" month="April"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t>
              <t indent="0">This document obsoletes RFC 6347.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9147"/>
          <seriesInfo name="DOI" value="10.17487/RFC9147"/>
        </reference>
        <reference anchor="SHS" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf" quoteTitle="true" derivedAnchor="SHS">
          <front>
            <title>Secure Hash Standard (SHS)</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date month="August" year="2015"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
          <seriesInfo name="FIPS PUB" value="180-4"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="SECG" target="https://www.secg.org/sec2-v2.pdf" quoteTitle="true" derivedAnchor="SECG">
          <front>
            <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
            <author fullname="Daniel Brown" initials="D." surname="Brown"/>
            <date month="February" year="2010"/>
          </front>
          <seriesInfo name="Version" value="2.0"/>
        </reference>
        <reference anchor="SP80059" target="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-59.pdf" quoteTitle="true" derivedAnchor="SP80059">
          <front>
            <title>Guideline for Identifying an Information System as a National Security System</title>
            <author fullname="William Barker" initials="W" surname="Barker"/>
            <date month="August" year="2003"/>
          </front>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-59"/>
          <seriesInfo name="NIST Special Publication" value="800-59"/>
        </reference>
      </references>
    </references>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Dorothy Cooley" initials="D." surname="Cooley">
        <organization abbrev="NSA" showOnFrontPage="true">National Security Agency</organization>
        <address>
          <email>decoole@nsa.gov</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
