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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!ENTITY RFC2046 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"> nbsp    "&#160;">
 <!ENTITY RFC2985 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2985.xml"> zwsp   "&#8203;">
 <!ENTITY RFC2986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"> nbhy   "&#8209;">
 <!ENTITY RFC3739 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3739.xml">
<!ENTITY RFC4108 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4108.xml">
<!ENTITY RFC5274 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5274.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5652 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml">
<!ENTITY RFC5911 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml">
<!ENTITY RFC5912 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml">
<!ENTITY RFC5913 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5913.xml">
<!ENTITY RFC5915 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5915.xml">
<!ENTITY RFC5916 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5916.xml">
<!ENTITY RFC5917 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5917.xml">
<!ENTITY RFC5958 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml">
<!ENTITY RFC5959 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5959.xml">
<!ENTITY RFC6010 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6010.xml">
<!ENTITY RFC6031 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6031.xml">
<!ENTITY RFC6032 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6032.xml">
<!ENTITY RFC6033 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6033.xml">
<!ENTITY RFC6160 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6160.xml">
<!ENTITY RFC6161 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6161.xml">
<!ENTITY RFC6162 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6162.xml">
<!ENTITY RFC6268 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml">
<!ENTITY RFC6402 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6402.xml">
<!ENTITY RFC7030 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml">
<!ENTITY RFC7191 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7191.xml">
<!ENTITY RFC7192 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7192.xml">
<!ENTITY RFC7292 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7292.xml">
<!ENTITY RFC7906 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7906.xml">
<!ENTITY RFC8295 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8295.xml">
<!ENTITY RFC8603 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8603.xml">
<!ENTITY RFC8755 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8755.xml">
<!ENTITY RFC8756 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8756.xml">
<!ENTITY I-D.cooley-cnsa-dtls-tls-profile SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.cooley-cnsa-dtls-tls-profile.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> wj     "&#8288;">
]>

<rfc submissionType="IETF" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-turner-sodp-profile-08" number="9152" submissionType="independent" category="info" ipr="trust200902"> ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <!-- Generated by id2xml 1.5.0 on 2021-01-19T23:07:54Z -->
	<?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="The SODP (Secure Object Delivery Protoco">The SODP (Secure abbrev="SODP Server Interfaces">Secure Object Delivery Protocol)
    Protocol (SODP) Server Interfaces: NSA's
    Profile for Delivery of Certificates, CRLs, Certificate Revocation Lists (CRLs),
    and Symmetric Keys to Clients</title> Clients
</title>
    <seriesInfo name="RFC" value="9152"/>
    <author initials="M." surname="Jenkins" fullname="Michael Jenkins">
      <organization abbrev="NSA">National Security Agency</organization>
	<address><email>mjjenki@cyber.nsa.gov</email>
      <address>
        <email>mjjenki@cyber.nsa.gov</email>
      </address>
    </author>
    <author initials="S." surname="Turner" fullname="Sean Turner">
      <organization>sn3rd</organization>
	<address><email>sean@sn3rd.com</email>
      <address>
        <email>sean@sn3rd.com</email>
      </address>
    </author>
    <date year="2021" month="January"/>
	<abstract><t> year="2022" month="April"/>
<keyword>CNSA</keyword>
<keyword>NSS</keyword>
    <abstract>
      <t>
   This document specifies protocol interfaces profiled by the US NSA
   (United United States National Security Agency) Agency (NSA) for NSS (National National Security
   System) System (NSS) servers that provide public key certificates, CRLs
   (Certificate Certificate Revocation Lists), Lists (CRLs), and symmetric keys to NSS clients.
   Servers that support these interfaces are referred to as SODP (Secure Secure
   Object Delivery Protocol) Protocol (SODP) servers. The intended audience for this
   profile comprises developers of client devices that will obtain key
   management services from NSA-operated SODP servers.  Interfaces
   supported by SODP servers include: EST (Enrollment include Enrollment over Secure
   Transport)
   Transport (EST) and its extensions as well as CMC (Certificate Certificate Management
   over CMS (Cryptographic Message Syntax)).</t> (CMC).</t>
      <t>
   This profile applies to the capabilities, configuration, and operation of
   all components of US National Security Systems (SP 800-59). It is also
   appropriate for 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>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   This document specifies protocol interfaces profiled by the US NSA
   (United United States National Security Agency) Agency (NSA) for NSS (National National Security
   System)
   System (NSS) servers that provide public key certificates, CRLs
   (Certificate Certificate Revocation Lists), Lists (CRLs), and symmetric keys to NSS clients.
   Servers that support these interfaces are referred to as SODP (Secure Secure
   Object Delivery Protocol) Protocol (SODP) servers.  The purpose of this document is
   to indicate options from, and requirements additional in addition to, the base
   specifications listed in <xref target="sect-1.1"/> target="sect-1.1" format="default"/> that are necessary for client
   interoperability with NSA-operated SODP servers.  Clients are always
   devices,
   devices and need not implement all of the interfaces specified
   herein; clients are free to choose which interfaces to implement
   based on their operational requirements.  Interfaces supported by
   SODP servers include:</t>

	<t><list>
	<t><list style="symbols"><t>EST (Enrollment
          <ul spacing="normal">
            <li>Enrollment over Secure Transport) Transport (EST) <xref target="RFC7030"/> target="RFC7030" format="default"/> and its
       extensions <xref target="RFC8295"/>, and</t>

	<t>CMC (Certificate target="RFC8295" format="default"/>, and</li>
            <li>Certificate Management over CMS (Cryptographic Message
       Syntax)) (CMC) <xref target="RFC5274" format="default"/> <xref target="RFC5274"/><xref target="RFC6402"/> target="RFC6402" format="default"/> for both Simple PKI (Public Public Key
       Infrastructure)
       Infrastructure (PKI) requests and responses (i.e., PKCS#10 requests
       and PKCS#7 responses) and Full PKI requests and responses.</t>

	</list>
	</t>

	</list>
	</t> responses.</li>

      </ul>
      <t>
   This profile applies to the capabilities, configuration, and operation of
   all components of US National Security Systems <xref target="SP-800-59"/>. target="SP-800-59" format="default"/>. It is also
   appropriate for 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>
   This profile conforms to the existing requirements of the NSA's
   Commercial National Security Algorithms. Algorithms (CNSAs).  As operational needs evolve
   over time, this profile will be updated to incorporate new commercial
   algorithms and protocols as they are developed and approved for use.</t>
      <section title="Documents anchor="sect-1.1" numbered="true" toc="default">
        <name>Documents to be Familiar With" anchor="sect-1.1"> With</name>
        <t>Familiarity with the follow specifications is assumed:

	  <list style="symbols">

	  <t>EST <xref target="RFC7030"/>
        </t>
        <ul spacing="normal">
          <li>EST and EST extensions extensions: <xref
	  target="RFC8295"/>;</t>

	  <t>PKI-related specifications target="RFC7030" format="default"/> and <xref target="RFC8295" format="default"/></li>
          <li>PKI-related specifications: <xref target="RFC2986" format="default"/>, <xref target="RFC2986"/>, target="RFC3739" format="default"/>, <xref
	  target="RFC3739"/>, target="RFC5274" format="default"/>, <xref target="RFC5274"/>, target="RFC5280" format="default"/>, <xref
	  target="RFC5280"/>, target="RFC5912" format="default"/>, <xref target="RFC5912"/>, target="RFC5913" format="default"/>, <xref
	  target="RFC5913"/>, target="RFC5916" format="default"/>, <xref target="RFC5916"/>, target="RFC5917" format="default"/>, <xref
	  target="RFC5917"/>,<xref target="RFC6010"/>, target="RFC6010" format="default"/>, and <xref
	  target="RFC6402"/>;</t>

	  <t>Key-format-related specifications target="RFC6402" format="default"/></li>
          <li>Key-format-related specifications: <xref target="RFC5915"/>, target="RFC5915" format="default"/>, <xref
	  target="RFC5958"/>, target="RFC5958" format="default"/>, <xref target="RFC5959"/>, target="RFC5959" format="default"/>, <xref
	  target="RFC6031"/>, target="RFC6031" format="default"/>, <xref target="RFC6032"/>, target="RFC6032" format="default"/>, <xref
	  target="RFC6160"/>, target="RFC6160" format="default"/>, <xref target="RFC6161"/>, target="RFC6161" format="default"/>, <xref
	  target="RFC6162"/>, target="RFC6162" format="default"/>, <xref target="RFC7191"/>, target="RFC7191" format="default"/>, <xref
	  target="RFC7192"/>, target="RFC7192" format="default"/>, <xref target="RFC7292"/>, target="RFC7292" format="default"/>, and <xref
	  target="RFC7906"/>;</t>

	  <t>CMS-related target="RFC7906" format="default"/></li>
          <li>CMS-related (Cryptographic Message Syntax) RFCs documents: <xref
	  target="RFC5652"/>, target="RFC5652" format="default"/> and <xref target="RFC6268"/>, and;</t>

	  <t>CNSA-related (Commercial National Security Algorithm) drafts target="RFC6268" format="default"/></li>
          <li>CNSA-related documents: <xref target="RFC8603"/>, target="RFC8603" format="default"/>, <xref target="RFC8755"/>, target="RFC8755" format="default"/>, <xref
	  target="RFC8756"/>, target="RFC8756" format="default"/>, and <xref
	  target="I-D.cooley-cnsa-dtls-tls-profile"/>.</t>

	</list>
	</t> target="RFC9151" format="default"/></li>
        </ul>
        <t>
   The requirements from RFCs apply throughout this profile and are
   generally not repeated here.  This document is purposely written
   without using the requirements language described in <xref target="RFC2119"/> language.</t> target="RFC2119" format="default"/> and <xref target="RFC8174"/>.</t>
      </section>
      <section title="Document Organization" anchor="sect-1.2"> anchor="sect-1.2" numbered="true" toc="default">
        <name>Document Organization</name>
        <t> The document is organized as follows:

	  <list style="symbols">

	    <t>The

        </t>
        <ul spacing="normal">
          <li>The remainder of this section describes the operational
	    environment used by clients to retrieve secure objects.</t>

	    <t><xref target="sect-2"/> objects.</li>
          <li>
            <xref target="sect-2" format="default"/> specifies the ASN.1 (Abstract Abstract Syntax Notation one) One (ASN.1) version used.</t>

	    <t><xref target="sect-3"/> used.</li>
          <li>
            <xref target="sect-3" format="default"/> specifies SODP's EST interface.</t>

	    <t><xref target="sect-4"/> interface.</li>

          <li>
            <xref target="sect-4" format="default"/> specifies SODP's CMC interfaces; one
	    section each for Simple PKI requests/responses interfaces.
          </li>

          <li>Sections <xref target="sect-5" format="counter"/>-<xref target="sect-7" format="counter"/> specify Trust Anchor (TA), Certification Authority (CA), and Full PKI
	    requests/responses.</t>

	    <t>Sections 5-9 respectively End-Entity (EE) certificates, respectively.
	  </li>
          <li>Sections <xref target="sect-8" format="counter"/> and <xref target="sect-9" format="counter"/> specify TA, CA, Relying Party Applications and EE certificates
	    as well as CRL.</t>

	  </list>
	</t> CRL Profile, respectively.</li>
        </ul>
      </section>
      <section title="Environment" anchor="sect-1.3"><t>
   The environment is Client-Server-based from which clients anchor="sect-1.3" numbered="true" toc="default">
        <name>Environment</name>

        <t>
   Clients obtain
   secure "objects" or "packages". "packages" from the client-server-based environment.  Objects/packages vary based on the
   SOA (Source
   Source of Authority) Authority (SOA), but all objects are "secured" minimally
   through the use of one or more digital signatures and zero or more
   layers of encryption, as profiled in this document.  An SOA is the
   authority for the creation of objects that the client will recognize
   as valid.  An SOA can delegate its authority to other actors;
   delegation occurs through the issuance of certificates.  An object or
   package is the generic term for certificates, certificate status
   information, and keys (both asymmetric and symmetric).  All of the
   objects except for the certificates and certificate status
   information are directly encapsulated in and protected by CMS content
   types.  CMS content types that provide security are referred to as
   CMS-protecting
   "CMS-protecting content types. types".  All others are simply referred to as
   CMS
   "CMS content types. types".  All secured objects are distributed either as CMS
   packages or as part of a CMS package.</t>
        <t>
   In the following example depicted in Figure 1, <xref target="ure-operating-environment-key-and-pki-sources-of-authority"/>, there are two SOAs:
   one for symmetric keys, as depicted by the KTA (Key Key Trust Anchor), Anchor (KTA),
   and one for public key certificates, as depicted by the PKI TA (Trust
   Anchor). Trust
   Anchor (TA).  The KTA is responsible for the creation and distribution of
   symmetric keys.  The KTA delegates the creation and distribution
   responsibilities to separate entities through the issuance of
   certificates to a KSA (Key Key Source Authority) Authority (KSA) and a KDA (Key Key
   Distribution Authority). Authority (KDA).  The KSA generates the keys, digitally signs
   the keys, and encrypts the key for the end client using CMS content
   types for each step.  The KDA distributes the KSA-generated and -
   protected KSA-protected key to the client; the key may also be signed by the KDA.
   The resulting CMS package is provided to the client through the EST
   extension's /symmetrickey service.  The PKI TA is responsible for the
   creation, distribution, and management of public key certificates.
   The PKI TA delegates these responsibilities to CAs (Certification
   Authorities) Certification
   Authorities (CAs), and CAs CAs, in turn turn, are responsible for creating,
   distributing, and managing EEs (End-Entities) certificates; End-Entity (EE) certificates. CAs
   distribute PKI-related information through the /cacerts, /crls,
   /eecerts, /fullcmc, /simpleenroll, /simplereenroll, and /csrattrs EST
   and EST extension services.</t>
        <figure title="- Operating anchor="ure-operating-environment-key-and-pki-sources-of-authority">
          <name>Operating Environment (Key and PKI Sources of Authority)" anchor="ure-operating-environment-key-and-pki-sources-of-authority"><artwork><![CDATA[ Authority)</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   +-----+                            +--------+
   | KTA |                            | PKI TA |
   +-----+                            +--------+
      |                                   |
      | Signs                             | Signs
      |                                   |
      +-------------+                     V
      |             |                   +----+
      V             V                   | CA |
   +-----+       +-----+                +----+
   | KSA |       | KDA |                   |
   +-----+       +-----+                   | Signs
      |           |                        |
      | Signs &   | Optionally             +---------------+
      | Encrypts  | Signs                  |               |
      |           |                        V               V
      |           |                +-------------+ +-------------+
      |           V                | Certificate | | Certificate |
  +---|-------------+              +-------------+ | Revocation  |
  |   V             | CMS Content                  | List        |
  | +-------------+ | Types                        +-------------+
  | | Key Package | |
  | +-------------+ |
  +-----------------+
]]></artwork>
        </figure>
        <t>
   For clients that support the CMC interface and not the EST interface,
   the environment includes only the PKI TAs.</t>
      </section>
    </section>
    <section title="Abstract anchor="sect-2" numbered="true" toc="default">
      <name>Abstract Syntax Notation One" anchor="sect-2"><t> One</name>
      <t>
   Implementations of this specification use the '02/'08 2002/2008
   ASN.1 (Abstract
   Syntax Notation One) version; '02/'08 2002/2008 ASN.1 modules can be found in
   <xref target="RFC5911"/>, target="RFC5911" format="default"/>, <xref target="RFC5912"/>, target="RFC5912" format="default"/>, and <xref target="RFC6268"/> target="RFC6268" format="default"/> (use RFC 6268 <xref target="RFC6268"/> for the CMS syntax) syntax), while other specifications already include the '02/'08 2002/2008 ASN.1 along
   with the '88 1988 ASN.1.  See Section 1.1 of <xref target="RFC6268"/> target="RFC6268" sectionFormat="of" section="1.1" /> for a discussion
   about the differences between the '02 2002 and '08 2008 ASN.1 versions.</t>
    </section>
    <section title="EST Interface" anchor="sect-3"><t> anchor="sect-3" numbered="true" toc="default">
      <name>EST Interface</name>

      <t>
   Client options for EST <xref target="RFC7030"/> target="RFC7030" format="default"/> and EST extensions <xref target="RFC8295"/> client options target="RFC8295" format="default"/> are
   specified in this section.</t>
      <section title="Hypertext anchor="sect-3.1" numbered="true" toc="default">
        <name>Hypertext Transfer Protocol Layer" anchor="sect-3.1"><t> Layer</name>
        <t>
   Clients that receive redirection responses (3xx status codes) will
   terminate the connection (<xref target="RFC7030"/>, Section 3.2.1).</t> target="RFC7030" sectionFormat="comma" section="3.2.1"/>).</t>
        <t>
   Per Section 2.2 of <xref target="RFC8295"/>, target="RFC8295" sectionFormat="of" section="2.2"/>, clients indicate the format
   ("application/xml" or "application/json") of the PAL information
   (<xref target="RFC8295"/>, Section 2.1.1) target="RFC8295" sectionFormat="comma" section="2.1.1"/>) via the HTTP Accept header.</t>
      </section>
      <section title="Transport anchor="sect-3.2" numbered="true" toc="default">
        <name>Transport Layer Security" anchor="sect-3.2"><t> Security</name>
        <t>
   TLS implementations are configured as specified in
   <xref target="I-D.cooley-cnsa-dtls-tls-profile"/>; target="RFC9151" format="default"/>; the notable exception is that only EC-based
   algorithms are used.</t>
      </section>
      <section title="Eligibility" anchor="sect-3.3"><t> anchor="sect-3.3" numbered="true" toc="default">
        <name>Eligibility</name>

        <t>
 At the EST interface, servers enroll only enroll clients that they have
 established a prior established relationship with, established with independently of
 the EST service. To accomplish this, client owners/operators
   interact in person with the human acting as the RA (Registration
   Authority) Registration
   Authority (RA) to ensure the information included in the transmitted
   certificate request, which is sometimes called a CSR (Certificate Certificate
   Signing Request), Request (CSR), is associated with a client.  The mechanism by
   which the owner/operator interact interacts with the RA as well as
   the information provided is beyond the scope of this document.  The
   information exchanged by the owner/operator might be something as
   simple as the subject name included in the to-be sent CSR to be sent or a copy
   of the certificate that will be used to verify the certificate
   request, which is provided out-of-band.</t> out of band.</t>
      </section>
      <section title="Authentication" anchor="sect-3.4"><t> anchor="sect-3.4" numbered="true" toc="default">
        <name>Authentication</name>
        <t>
   Mutual authentication occurs via "Certificate TLS Authentication"
   (<xref target="RFC7030"/>, Section 2.1). target="RFC7030" sectionFormat="comma" section="2.2.1"/>).  Clients provide their certificate to
   servers in the TLS Certificate message, which is sent in response to
   the server's TLS Certificate Request message.  Both servers and
   clients reject all attempts to authenticate based on certificates
   that cannot be validated back to an installed TA.</t>
      </section>
      <section title="Authorization" anchor="sect-3.5"><t> anchor="sect-3.5" numbered="true" toc="default">
        <name>Authorization</name>
        <t>
   Clients always use an explicit TA database (<xref target="RFC7030"/>, <xref target="sect-3.6.1"/>). target="RFC7030" sectionFormat="comma" section="3.6.1"/>).  At a minimum, clients support two TAs; TAs: one for the PKI and
   one for symmetric keys.</t>
        <t>
   Clients check that the server's certificate includes the id-kp-cmcRA
   EKU (Extended
   Extended Key Usage) Usage (EKU) value (<xref target="RFC6402"/>, Section 2.10).</t> target="RFC6402" sectionFormat="comma" section="2.10"/>).</t>

        <t>
   Clients that support processing of the CMS Content Constraints extension
   <xref target="RFC6010"/> target="RFC6010" format="default"/> ensure returned CMS content is from an SOA or is from an
   entity authorized by an SOA for that CMS content; see Section 6.0 <xref target="sect-7.1"/> for
   SOA certificates.</t>
      </section>
      <section title="EST anchor="sect-3.6" numbered="true" toc="default">
        <name>EST and EST Extensions" anchor="sect-3.6"><t> Extensions</name>
        <t>
   This section profiles SODP's interfaces for EST <xref target="RFC7030"/> target="RFC7030" format="default"/> and EST Extensions extensions
   <xref target="RFC8295"/> interfaces.</t> target="RFC8295" format="default"/>.</t>
        <section title="/pal" anchor="sect-3.6.1"><t> anchor="sect-3.6.1" numbered="true" toc="default">
          <name>/pal</name>
          <t>
   The PAL (Package Package Availability List) List (PAL) is limited to 32 entries, where
   the 32nd PAL entry links to an additional PAL (i.e., is PAL Package
   Type 0001).</t>
          <t>
   The PAL is XML <xref target="XML"/>.</t> target="XML" format="default"/>.</t>
        </section>
        <section title="/cacerts" anchor="sect-3.6.2"><t> anchor="sect-3.6.2" numbered="true" toc="default">
          <name>/cacerts</name>
          <t>
   The CA certificates located in the explicit TA database are
   distributed to the client when it is registered.  This TA
   distribution mechanism is out-of-scope.</t> out of scope.</t>
          <t>
   CA certificates provided through this service are as specified in
   Sections 5 <xref target="sect-5" format="counter"/> and 6 <xref target="sect-6" format="counter"/> of this document.</t>
        </section>
        <section title="/simpleenroll" anchor="sect-3.6.3"><t> anchor="sect-3.6.3" numbered="true" toc="default">

          <name>/simpleenroll</name>
          <t>
   CSRs follow the specifications in Section 4.2 of <xref target="RFC8756"/>, target="RFC8756" sectionFormat="of" section="4.2"/>,
   except that the CMC-specific Change Subject Name ChangeSubjectName and
   the POP Link Witness V2 attributes do not apply.  Second, only  Only
   EC-based algorithms are used.</t>
          <t>
   Client certificates provided through this service are as specified in
   Section 7
   <xref target="sect-7"/> of this document.</t>
          <t>
   The HTTP content-type content type of "text/plain" (<xref target="RFC2046"/>, <xref target="sect-4.1"/>) target="RFC2046" sectionFormat="comma" section="4.1"/>) is
   used to return human readable human-readable errors.</t>
        </section>
        <section title="/simplereenroll" anchor="sect-3.6.4"><t> anchor="sect-3.6.4" numbered="true" toc="default">
          <name>/simplereenroll</name>
          <t>
   There are no additional requirements for requests beyond those
   specified in Sections 3.4 <xref target="sect-3.4" format="counter"/> and 3.6.3 <xref target="sect-3.6.3" format="counter"/> of this document.</t>
          <t>
   The HTTP content-type content type of "text/plain" (<xref target="RFC2046"/>, <xref target="sect-4.1"/>) target="RFC2046" sectionFormat="comma" section="4.1"/>) is
   used to return human readable human-readable errors.</t>
        </section>
        <section title="/fullcmc" anchor="sect-3.6.5"><t> anchor="sect-3.6.5" numbered="true" toc="default">
          <name>/fullcmc</name>
          <t>
   Requests are as specified in <xref target="RFC8756"/> target="RFC8756" format="default"/> with the notable
   exception that only EC-based algorithms are used.</t>
          <t>
   Additional attributes for returned CMS packages can be found in
   <xref target="RFC7906"/>.</t> target="RFC7906" format="default"/>.</t>
          <t>
   Certificates provided through this service are as specified in
   Section 7
   <xref target="sect-7"/> of this document.</t>
        </section>
        <section title="/serverkeygen" anchor="sect-3.6.6"><t> anchor="sect-3.6.6" numbered="true" toc="default">
          <name>/serverkeygen</name>

          <t>
   PKCS#12 <xref target="RFC7292"/>, target="RFC7292" format="default"/> -- sometimes referred to as "PFX" (Personal
   inFormation eXchange), "P12", and "PKCS#12" files, are
   Information Exchange) or "P12" -- is used to
   provide server-generated asymmetric private keys and the associated
   certificate to clients.  This interface is a one-way interface as the
   RA requests these from the server.</t>
          <t>
   PFXs <xref target="RFC7292"/> target="RFC7292" format="default"/> are exchanged using both password privacy mode and
   integrity password mode.  The PRF algorithm for PBKDF2 (the KDF for
   PBES2 and PBMAC1) is HMAC-SHA-384 HMAC-SHA-384, and the PBES2 encryption scheme is
   AES-256.</t>
          <t>
   The HTTP content-type content type of "text/plain" (<xref target="RFC2046"/>, <xref target="sect-4.1"/>) target="RFC2046" sectionFormat="comma" section="4.1"/>) is
   used to return human readable human-readable errors.</t>
          <t>
   /serverkeygen/return is not supported at this time.</t>
        </section>
        <section title="/csrattrs" anchor="sect-3.6.7"><t> anchor="sect-3.6.7" numbered="true" toc="default">
          <name>/csrattrs</name>

          <t>
 Clients use this service to retrieve partially filled PKIRequests: PKIRequests
 with no public key or proof-of-possession signature,
 i.e., their values are set to zero length length, either a zero length BIT
 STRING or OCTET STRING. The pKCS7PDU attribute, defined in
   <xref target="RFC2985"/>, target="RFC2985" format="default"/>, includes the partially filled PKIRequest as the only
   element in the CsrAttrs sequence.  Even though the CsrAttrs syntax is
   defined as a set, there is only ever exactly one instance of values
   present.</t>
        </section>
        <section title="/crls" anchor="sect-3.6.8"><t> anchor="sect-3.6.8" numbered="true" toc="default">
          <name>/crls</name>
          <t>
   CRLs provided through this service are as specified in Section 9 <xref target="sect-9"/> of
   this document.</t>
        </section>
        <section title="/symmetrickeys" anchor="sect-3.6.9"><t> anchor="sect-3.6.9" numbered="true" toc="default">
          <name>/symmetrickeys</name>

          <t>
   Clients that claim to support SODP-interoperation SODP interoperation will be able to process
   the following messages from a an SODP server: additional </t>

<ul>
<li>additional encryption and origin
   authentication (<xref target="RFC8295"/>, <xref target="sect-5"/>); server-provided target="RFC8295" sectionFormat="comma" section="5"/>); and
   </li>
<li>server-provided Symmetric Key
   Content Type <xref target="RFC6032"/> target="RFC6032" format="default"/> encapsulated in an Encrypted Key Content Type using
   the EnvelopedData choice <xref target="RFC6033"/> target="RFC6033" format="default"/> with a an SOA certificate that includes the
   CMS Content Constraints extension (see <xref target="sect-7.1"/>).</t> target="sect-7.1" format="default"/>).</li>
</ul>

          <t>
   Client-supported algorithms to decrypt the server-returned symmetric
   key are as follows:

	<list style="hanging" hangIndent="6">

	<t hangText="Message Digest:">
          </t>

          <ul>
            <li>Message Digest: See Section 5 of <xref
	target="RFC8755"/>.</t>

	<t hangText="Digital target="RFC8755" sectionFormat="of" section="4"/>.</li>
            <li>Digital Signature Algorithm:"> Algorithm: See Section 6.1 of <xref
	target="RFC8755"/>.</t>

	<t hangText="Key Agreement:"> target="RFC8755" sectionFormat="of" section="5"/>.</li>
            <li>Key Agreement: See Section 7.1 of <xref
	target="RFC8755"/>.</t>

        <t hangText="Key Wrap:"> target="RFC8755" sectionFormat="of" section="6.1"/>.</li>
            <li>Key Wrap: AES-256 Key Wrap with Padding <xref
        target="RFC6033"/> target="RFC6033"
            format="default"/> is used. AES-128 Key Wrap with Padding is not
        used.</t>

	<t hangText="Content Encryption:">
            used.</li>
            <li>Content Encryption: AES-256 Key Wrap with Padding <xref
	target="RFC6033"/>
            target="RFC6033" format="default"/> is used. AES-128 Key Wrap with
            Padding is not
	used.</t>

	</list>
	</t> used.</li>
          </ul>
          <t>
   /symmetrickeys/return is not used at this time.</t>
        </section>
        <section title="/eecerts, anchor="sect-3.6.10" numbered="true" toc="default">
          <name>/eecerts, /firmware, /tamp" anchor="sect-3.6.10"><t> /tamp</name>
          <t>
   /eecerts, /firmware, and /tamp are not used at this time.</t>
        </section>
      </section>
    </section>
    <section title="CMC Interface" anchor="sect-4"><t> anchor="sect-4" numbered="true" toc="default">
      <name>CMC Interface</name>
      <t>
   Client options for CMC <xref target="RFC5274"/><xref target="RFC6402"/> clients options target="RFC5274" format="default"/> <xref target="RFC6402" format="default"/> are specified in this section.</t>
      <section title="RFC anchor="sect-4.1" numbered="true" toc="default">
        <name>RFC 5273 Transport Protocols" anchor="sect-4.1"><t> Protocols</name>

        <t>
   Clients use only use the HTTPS-based transport; the transport. The TLS implementation
   and configuration is are as specified in <xref target="I-D.cooley-cnsa-dtls-tls-profile"/>; target="RFC9151" format="default"/>, with the
   notable exceptions are exception that only EC-based algorithms are used.</t>
        <t>
   Clients that receive HTTP redirection responses (3xx status codes)
   will terminate the connection (<xref target="RFC7030"/>, Section 3.2.1).</t> target="RFC7030" sectionFormat="comma" section="3.2.1"/>).</t>
      </section>
      <section title="Eligibility" anchor="sect-4.2"><t> anchor="sect-4.2" numbered="true" toc="default">
        <name>Eligibility</name>
        <t>
 At the CMC interface, servers enroll only enroll clients that they have
 established a prior established relationship with, established with independently of
 the EST service. To accomplish this, client owners/operators
   interact in person with the human acting as the RA (Registration
   Authority) Registration
   Authority (RA) to ensure the information included in the transmitted
   certificate request, which is sometimes called a CSR (Certificate Certificate
   Signing Request), Request (CSR), is associated with a client.  The mechanism by
   which the owner/operator interact interacts with the RA as well as the
   information provided is beyond the scope of this document.  The
   information exchanged by the owner/operator might be something as
   simple as the subject name included in the to-be sent CSR to be sent or a copy
   of the certificate that will be used to verify the certificate
   request, which is provided out-of-band.</t> out of band.</t>
      </section>
      <section title="Authentication" anchor="sect-4.3"><t> anchor="sect-4.3" numbered="true" toc="default">
        <name>Authentication</name>

        <t>
   Mutual authentication occurs via client and server signing of CMC
   protocol elements, as required by <xref target="RFC8756"/>. target="RFC8756" format="default"/>. All such
   signatures must be are validated against an installed TA; any that fail
   validation are rejected.</t>
      </section>
      <section title="Authorization" anchor="sect-4.4"><t> anchor="sect-4.4" numbered="true" toc="default">
        <name>Authorization</name>
        <t>
   Clients support the simultaneous presence of as many TAs as are
   required for all of the functions of the client, and only these TAs.</t>
        <t>
   Clients check that the server's certificate includes the id-kp-cmcRA
   EKU (Extended
   Extended Key Usage) Usage (EKU) value <xref target="RFC6402"/>, Section 2.10.</t> (<xref target="RFC6402" sectionFormat="comma" section="2.10"/>).</t>
        <t>
   Clients that support processing of the CMS Content Constraints extension
   <xref target="RFC6010"/> target="RFC6010" format="default"/> ensure returned CMS content is from an SOA or is from an
   entity authorized by an SOA for that CMS content; see Section 6.0 <xref target="sect-7.1"/> for
   SOA certificates</t> certificates.</t>

      </section>
      <section title="Full anchor="sect-4.5" numbered="true" toc="default">
        <name>Full PKI Requests/Responses" anchor="sect-4.5"><t> Requests/Responses</name>
        <t>
   Requests are as specified in <xref target="RFC8756"/> target="RFC8756" format="default"/> with the notable
   exception that only EC-based algorithms are used.</t>

        <t>
   Additional attributes for returned CMC CMS packages can be found in
   <xref target="RFC7906"/>.</t> target="RFC7906" format="default"/>.</t>
        <t>
   Certificates provided through this service are as specified in
   Section 7 <xref target="sect-7"/> of this document.</t>
      </section>
    </section>
    <section title="Trust anchor="sect-5" numbered="true" toc="default">
      <name>Trust Anchor Profile" anchor="sect-5"><t> Profile</name>
      <t>
   Clients are free to store the TA in the format of their choosing;
   however, servers provide TA information in the form of self-signed CA
   certificates.  This section documents requirements for self-signed
   certificates in addition to those specified in <xref target="RFC8603"/>, target="RFC8603" format="default"/>, which in
   turn specifies requirements in addition to those in <xref target="RFC5280"/>.</t> target="RFC5280" format="default"/>.</t>
      <t>
   Only EC-based algorithms are used.</t>
      <t>
   Issuer and subject names are composed of only the following naming
   attributes: country name, domain component, organization name,
   organizational unit name, common name, state or province name,
   distinguished name qualifier, and serial number.</t>
      <t>
   In the Subject Key Identifier extension, the keyIdentifier is the 64
   low-order bits of the subject's subjectPublicKey field.</t>
      <t>
   In the Key Usage extension, the nonRepudiation bit is never set.</t>
    </section>
    <section title="Non-Self-Signed anchor="sect-6" numbered="true" toc="default">
      <name>Non-Self-Signed Certification Authority Certificate Profile" anchor="sect-6"><t> Profile</name>
      <t>
   This section documents requirements for non-self signed non-self-signed CA
   certificates in addition to those specified in <xref target="RFC8603"/>, target="RFC8603" format="default"/>, which in
   turn specifies requirements in addition to those in <xref target="RFC5280"/>.</t> target="RFC5280" format="default"/>.</t>
      <t>
   Only EC-based algorithms are used.</t>
      <t>
   Subject names are composed of only the following naming attributes:
   country name, domain component, organization name, organizational
   unit name, common name, state or province name, distinguished name
   qualifier, and serial number.</t>
      <t>
   In the Authority Key Identifier extension, the keyIdentifier choice
   is always used.  The keyIdentifier is the 64 low-order bits of the
   issuer's subjectPublicKey field.</t>
      <t>
   In the Subject Key Identifier extension, the keyIdentifier is the 64
   low-order bits of the subject's subjectPublicKey field.</t>
      <t>
   In the Key Usage extension, the nonRepudiation bit is never set.</t>
      <t>
   The Certificate Policies extension is always included included, and
   policyQualifiers are never used.</t>
      <t>Non-self-signed CA certificates can also include the following:</t>

	<t><list style="hanging" hangIndent="6">

	  <t hangText="Name Constraints:">
      <dl newline="false" spacing="normal" indent="3">
        <dt>Name Constraints:</dt>
        <dd> permittedSubtrees constraints are
	  included
	  included, and excludedSubstree constraints are not.  Of the
	  GeneralName choices, issuers support the following: rfc822Name,
	  dNSName, uniformResourceIdentifier, and iPAddress (both IPv4 and
	  IPv6) as well as hardwareModuleName, which is defined in <xref
	  target="RFC4108"/>. target="RFC4108" format="default"/>.  Note that rfc822Name, dNSName, and
	  uniformResourceIdentifier are defined as IA5 strings strings, and the
	  character sets allowed is are not uniform amongst these three name
	  forms.</t>

	  <t hangText="CRL
	  forms.</dd>
        <dt>CRL Distribution Points:"> Points:</dt>
        <dd> A distributionPoint is
	  always the fullName choice; the choice. The uniformResourceIdentifier
	  GeneralName choice is always included included, but others can also be used as
	  long as the first element in the sequence of CRLDistributionPoints
	  is the uniformResourceIdentifier choice; the choice. The reasons and CRLIssuer cRLIssuer
	  fields are never populated.  This extension is never marked
	  critical.</t>

	  <t hangText="Authority as
	  critical.</dd>
        <dt>Authority Information Access:"> Access:</dt>
        <dd> Only one instance of
	  AccessDescription is included.  accessMethod is id-caIssuers id-caIssuers, and
	  accessLocation's GeneralName is always the uniformResourceIdentifier
	  choice.</t>

	  <t hangText="Extended
	  choice.</dd>
        <dt>Extended Key Usage:"> Usage:</dt>
        <dd> EST servers and RAs include the
	  id-kp-cmcRA EKU EKU, and the CAs include the id-kp-cmcCA, which are both
	  specified in <xref target="RFC6402"/>.</t>

	</list>
	</t> target="RFC6402" format="default"/>.</dd>
      </dl>

      <t>
   Issuers include the Authority Clearance Constraints extension <xref target="RFC5913"/> target="RFC5913" format="default"/> in
   non-self-signed CA certificates that are issued to non-SOAs; values for the
   CP (Certificate Policy) OID (Object IDentifier)
   Certificate Policy (CP) Object Identifier (OID) and the supported classList
   values are found in the Issuer's issuer's CP.  Criticality is determined by the
   issuer
   issuer, and a securityCategories is never included.  Only one instance of
   Clearance is generated in the AuthorityClearanceConstraints sequence.</t>
      <t>
   Issuers include a critical CMS Content Constraints extension
   <xref target="RFC6010"/> target="RFC6010" format="default"/> in CA certificates used to issue SOA certificates;
   this is necessary to enable enforcement of scope of the SOA
   authority.  The content types included depend on the packages the
   SOA sources, sources but include key packages (i.e., Encrypted Key Packages,
   Symmetric Key Packages, and Asymmetric Key Packages).</t>
    </section>
    <section title="End-Entity anchor="sect-7" numbered="true" toc="default">
      <name>End-Entity Certificate Profile" anchor="sect-7"><t> Profile</name>
      <t>
   This section documents requirements for EE signature and key
   establishment certificates in addition to those listed in <xref target="RFC8603"/>, target="RFC8603" format="default"/>,
   which in turn specifies requirements in addition to those in
   <xref target="RFC5280"/>.</t> target="RFC5280" format="default"/>.</t>
      <t>
   Only EC-based algorithms are used.</t>
      <t>
   Subject names are composed of the following naming attributes:
   country name, domain component, organization name, organizational
   unit name, common name, state or province name, distinguished name
   qualifier, and serial number.</t>
      <t>
   In the Authority Key Identifier extension, the keyIdentifier choice
   is always used.  The keyIdentifier is the 64 low-order bits of the
   issuer's subjectPublicKey field.</t>
      <t>
   In the Subject Key Identifier extension, the keyIdentifier is the 64
   low-order bits of the subject's subjectPublicKey field.</t>
      <t>
   In the Key Usage extension, signature certificates only assert
   digitalSignature
   digitalSignature, and key establishment certificates only assert
   keyAgreement.</t>
      <t>
   The Certificate Policies extension is always included included, and
   policyQualifiers are never used.</t>
      <t>
   When included, the non-critical CRL Distribution Point extension's
   distributionPoint is always identified by the fullName choice; the choice. The
   uniformResourceIdentifier GeneralName choice is always included included, but
   others can also be used as long as the first element in the sequence
   of distribution points is the URI choice and it is an HTTP/HTTPS
   scheme; the
   scheme. The reasons and cRLIssuer fields are never populated.</t>
      <t>
   The following subsections provide additional requirements for the
   different types of EE certificates.</t>
      <section title="Source anchor="sect-7.1" numbered="true" toc="default">
        <name>Source of Authority Certificate Profile" anchor="sect-7.1"><t> Profile</name>
        <t>
This section specifies the format for SOA certificates, i.e., certificates
issued to those entities that are authorized to create, digitally sign,
encrypt, and distribute key packages; these certificates are issued by non-PKI
TAs.</t>
        <t>
   The Subject Alternative Name extension is always included.  The
   following choices are supported supported: rfc822Name, dnsName, dNSName, ediPartyName,
   uniformResourceIdentifier, or ipAddress iPAddress (both IPv4 and IPv6).  This
   extension is never critical.</t>
        <t>
   A critical CMS Content Constraints extension <xref target="RFC6010"/> target="RFC6010" format="default"/> is included in
   SOA signature certificates.  The content types included depend on the
   packages the SOA sources (e.g., Encrypted Key Packages, Symmetric Key
   Packages, and Asymmetric Key Packages).</t>
      </section>
      <section title="Client anchor="sect-7.2" numbered="true" toc="default">
        <name>Client Certificate Profile" anchor="sect-7.2"><t> Profile</name>
        <t>
   This section specifies the format for certificates issued to clients.</t>
        <t>
   A non-critical Subject Directory Attributes extension is always
   included with the following attributes:

	<list style="symbols">

	  <t>Device

        </t>
        <ul spacing="normal">
          <li>Device Owner <xref target="RFC5916"/></t>

	  <t>Clearance target="RFC5916" format="default"/></li>
          <li>Clearance Sponsor <xref target="RFC5917"/></t>

	  <t>Clearance <xref target="RFC5913"/></t>

	</list>
	</t> target="RFC5917" format="default"/></li>
          <li>Clearance <xref target="RFC5913" format="default"/></li>
        </ul>
        <t>
   The following extensions are also included at the discretion of the
   CA:

	<list style="symbols">

	  <t>The

        </t>

        <ul spacing="normal">
          <li> The Authority Information Access extension with only one instance of the
AccessDescription included. accessMethod id-caIssuers is id-caIssuers, and the accessLocation's
accessLocation’s GeneralName using is always the uniformResourceIdentifier choice.</t>

	  <t>A
choice.
</li>
          <li>A non-critical Subject Alternative Name extension that includes
	  the hardwareModuleName form <xref target="RFC4108"/>, target="RFC4108" format="default"/>, rfc822Name, or
	  uniformResourceIdentifier.</t>

	  <t>A
	  uniformResourceIdentifier.</li>
          <li>A critical Subject Alternative Name extension that includes: includes
	  dNSName, rfc822Name, ediPartyName, uniformResourceIdentifier, or
	  ipAddress
	  iPAddress (both IPv4 and IPv6).</t>

	</list>
	</t> IPv6).</li>
        </ul>
      </section>
    </section>
    <section title="Relying anchor="sect-8" numbered="true" toc="default">
      <name>Relying Party Applications" anchor="sect-8"><t> Applications</name>
      <t>
   This section documents requirements for RPs (Relying Parties) Relying Parties (RPs) in
   addition to those listed in <xref target="RFC8603"/>, target="RFC8603" format="default"/>, which in turn specifies
   requirements in addition to those in <xref target="RFC5280"/>.</t> target="RFC5280" format="default"/>.</t>
      <t>
   Only EC-based algorithms are used.</t>
      <t>
   RPs support the Authority Key Identifier and the Subject Key
   Identifier extensions.</t>
      <t>
   RPs should support the following extensions: CRL Distribution Points,
   Authority Information Access, Subject Directory Attribute,  Authority
   Clearance Constraints, and CMS Content Constraints extensions.</t> Constraints.</t>
      <t>
   Within the Subject Directory Attribute extension, RPs should support
   the Clearance Sponsor, Clearance, and Device Owner attributes.</t>
      <t>
   RPs support the id-kp-cmcRA and id-kp-cmcCA EKUs.</t>
      <t>
   Failure to support extensions in this section might limit the
   suitability of a device for certain applications.</t>
    </section>
    <section title="CRL Profile" anchor="sect-9"><t> anchor="sect-9" numbered="true" toc="default">
      <name>CRL Profile</name>
      <t>
   This section documents requirements for CRLs in addition to those
   listed in <xref target="RFC8603"/>, target="RFC8603" format="default"/>, which in turn specifies requirements in addition
   to those in <xref target="RFC5280"/>.</t> target="RFC5280" format="default"/>.</t>
      <t>
   Only EC-based algorithms are used.</t>
      <t>
   Two types of CRLs are produced: complete base CRLs and partitioned
   base CRLs.</t>
      <t>
   crlEntryExtensions are never included included, and the reasons and cRLIssuer
   fields are never populated.</t>
      <t>All CRLs include the following CRL extensions:

	<list style="symbols">

	  <t>The

      </t>
      <ul spacing="normal">
        <li>The Authority Key Identifier extension: The keyIdentifier is the
	  64 low-order bits of the issuer's subjectPublicKey field.</t>

	  <t>As field.</li>
        <li>As per <xref target="RFC5280"/>, target="RFC5280" format="default"/>, the CRL Number extension.</t>

	 </list></t> extension.</li>
      </ul>

      <t>
   The only other extension included in partitioned base CRLs is the
   Issuing Distribution Point extension.  The distributionPoint is
   always identified by the fullName choice; the
   uniformResourceIdenifier choice. The
   uniformResourceIdentifier GeneralName choice is always included included, but
   others can also be used as long as the first element in the sequence
   of distribution points is the uniformResourceIdenifier uniformResourceIdentifier choice and the
   scheme is an HTTP/HTTPS scheme; all scheme. All other fields are omitted.</t>
    </section>
    <section title="IANA Considerations" anchor="sect-10"><t>
   None.</t> anchor="sect-10" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   This document has no IANA actions.</t>
    </section>
    <section title="Security Considerations" anchor="sect-11"><t> anchor="sect-11" numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>
   This entire document is about security.  This document profiles the
   use of many protocols and services: EST, CMC, and PKCS#10/#7/#12 as
   well as certificates, CRLs, and their extensions <xref target="RFC5280"/>. target="RFC5280" format="default"/>.
 These have been referred to cited throughout this document document, and those the
 specifications identified by those citations should be consulted
 for security considerations related to implemented protocol protocols
 and services.</t>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC2046;
	&RFC2985;
	&RFC2986;
	&RFC3739;
	&RFC4108;
	&RFC5274;
	&RFC5280;
	&RFC5652;
	&RFC5911;
	&RFC5912;
	&RFC5913;
	&RFC5915;
	&RFC5916;
	&RFC5917;
	&RFC5958;
	&RFC5959;
	&RFC6010;
	&RFC6031;
	&RFC6032;
	&RFC6033;
	&RFC6160;
	&RFC6161;
	&RFC6162;
	&RFC6268;
	&RFC6402;
	&RFC7030;
	&RFC7191;
	&RFC7192;
	&RFC7292;
	&RFC7906;
	&RFC8295;
	&RFC8603;
	&RFC8755;
	&RFC8756;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2985.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3739.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4108.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5274.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5911.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5913.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5915.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5916.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5917.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5958.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5959.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6010.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6031.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6032.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6033.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6160.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6161.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6162.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6268.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6402.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7191.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7192.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7292.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7906.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8295.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8603.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8755.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8756.xml"/>

        <reference anchor="XML" target="https://www.w3.org/TR/2008/REC-xml-20081126/"><front> target="https://www.w3.org/TR/2008/REC-xml-20081126/">
          <front>
            <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
            <author initials="T." surname="Bray" fullname="T. fullname="Tim Bray">
	</author>
            <author initials="J." surname="Paoli" fullname="J. fullname="Jean Paoli">
	</author>
            <author initials="M." initials="C.M." surname="Sperberg-McQueen" fullname="M. fullname="C.M. Sperberg-McQueen">
	</author>
            <author initials="E." surname="Maler" fullname="E. fullname="Eve Maler">
	</author>
            <author initials="F." surname="Yergeau" fullname="F. fullname="François Yergeau">
	</author>
            <date month="November" year="2008"/>
          </front>
         <seriesInfo name="World" value="Wide name="World Wide Web Consortium Recommendation REC-xml-20081126"/> Recommendation" value="REC-xml-20081126"/>
        </reference>

        <reference anchor="SP-800-59" target="https://csrc.nist.gov/publications/detail/sp/800-59/final"><front> target="https://csrc.nist.gov/publications/detail/sp/800-59/final">
          <front>
            <title>Guideline for Identifying an Information System as a National Security System</title>
            <author>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <date month="August" year="2003"/>
          </front>
          <seriesInfo name="SP" name="DOI" value="10.6028/NIST.SP.800-59"/>
          <seriesInfo name="NIST Special Publication" value="800-59"/>
        </reference>
	&I-D.cooley-cnsa-dtls-tls-profile;

<reference anchor='RFC9151' target="https://www.rfc-editor.org/info/rfc9151">
<front>
<title>Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3</title>

<author initials='D.' surname='Cooley' fullname='Dorothy Cooley'>
    <organization />
</author>

<date month='April' year='2022' />
</front>
<seriesInfo name="RFC" value="9151"/>
<seriesInfo name="DOI" value="10.17487/RFC9151"/>
</reference>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
	<references title="Informative References">
	&RFC2119;
    </references>
  </back>

</rfc>