<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" docName="draft-turner-sodp-profile-08" indexInclude="true" ipr="trust200902" number="9152" prepTime="2022-04-26T15:14:07" scripts="Common,Latin" sortRefs="true" submissionType="independent" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-turner-sodp-profile-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9152" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="SODP Server Interfaces">Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients</title>
    <seriesInfo name="RFC" value="9152" stream="independent"/>
    <author initials="M." surname="Jenkins" fullname="Michael Jenkins">
      <organization abbrev="NSA" showOnFrontPage="true">National Security Agency</organization>
      <address>
        <email>mjjenki@cyber.nsa.gov</email>
      </address>
    </author>
    <author initials="S." surname="Turner" fullname="Sean Turner">
      <organization showOnFrontPage="true">sn3rd</organization>
      <address>
        <email>sean@sn3rd.com</email>
      </address>
    </author>
    <date month="04" year="2022"/>
    <keyword>CNSA</keyword>
    <keyword>NSS</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
   This document specifies protocol interfaces profiled by the United States National Security Agency (NSA) for National Security System (NSS) servers that provide public key certificates, Certificate Revocation Lists (CRLs), and symmetric keys to NSS clients.
   Servers that support these interfaces are referred to as Secure
   Object Delivery 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 Enrollment over Secure
   Transport (EST) and its extensions as well as Certificate Management
   over CMS (CMC).</t>
      <t indent="0" pn="section-abstract-2">
   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>
    <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/rfc9152" 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" 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>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-documents-to-be-familiar-wi">Documents to be Familiar With</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.2">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.2.1"><xref derivedContent="1.2" format="counter" sectionFormat="of" target="section-1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-document-organization">Document Organization</xref></t>
              </li>
              <li pn="section-toc.1-1.1.2.3">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.3.1"><xref derivedContent="1.3" format="counter" sectionFormat="of" target="section-1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-environment">Environment</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" 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-abstract-syntax-notation-on">Abstract Syntax Notation One</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" 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-est-interface">EST Interface</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hypertext-transfer-protocol">Hypertext Transfer Protocol Layer</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transport-layer-security">Transport Layer Security</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eligibility">Eligibility</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authentication">Authentication</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization">Authorization</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-est-and-est-extensions">EST and EST Extensions</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.6.2">
                  <li pn="section-toc.1-1.3.2.6.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.1.1"><xref derivedContent="3.6.1" format="counter" sectionFormat="of" target="section-3.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-pal">/pal</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.2.1"><xref derivedContent="3.6.2" format="counter" sectionFormat="of" target="section-3.6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cacerts">/cacerts</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.3.1"><xref derivedContent="3.6.3" format="counter" sectionFormat="of" target="section-3.6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-simpleenroll">/simpleenroll</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.4">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.4.1"><xref derivedContent="3.6.4" format="counter" sectionFormat="of" target="section-3.6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-simplereenroll">/simplereenroll</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.5">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.5.1"><xref derivedContent="3.6.5" format="counter" sectionFormat="of" target="section-3.6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fullcmc">/fullcmc</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.6">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.6.1"><xref derivedContent="3.6.6" format="counter" sectionFormat="of" target="section-3.6.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-serverkeygen">/serverkeygen</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.7">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.7.1"><xref derivedContent="3.6.7" format="counter" sectionFormat="of" target="section-3.6.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-csrattrs">/csrattrs</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.8">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.8.1"><xref derivedContent="3.6.8" format="counter" sectionFormat="of" target="section-3.6.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-crls">/crls</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.9">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.9.1"><xref derivedContent="3.6.9" format="counter" sectionFormat="of" target="section-3.6.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-symmetrickeys">/symmetrickeys</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.10">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.10.1"><xref derivedContent="3.6.10" format="counter" sectionFormat="of" target="section-3.6.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-eecerts-firmware-tamp">/eecerts, /firmware, /tamp</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </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-cmc-interface">CMC Interface</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-rfc-5273-transport-protocol">RFC 5273 Transport Protocols</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-eligibility-2">Eligibility</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authentication-2">Authentication</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-authorization-2">Authorization</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.5">
                <t indent="0" pn="section-toc.1-1.4.2.5.1"><xref derivedContent="4.5" format="counter" sectionFormat="of" target="section-4.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-full-pki-requests-responses">Full PKI Requests/Responses</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-trust-anchor-profile">Trust Anchor Profile</xref></t>
          </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-non-self-signed-certificati">Non-Self-Signed Certification Authority Certificate Profile</xref></t>
          </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-end-entity-certificate-prof">End-Entity Certificate Profile</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-source-of-authority-certifi">Source of Authority Certificate Profile</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-client-certificate-profile">Client Certificate Profile</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-relying-party-applications">Relying Party Applications</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-crl-profile">CRL Profile</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-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <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.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t indent="0" pn="section-toc.1-1.12.2.1.1"><xref derivedContent="12.1" format="counter" sectionFormat="of" target="section-12.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t indent="0" pn="section-toc.1-1.12.2.2.1"><xref derivedContent="12.2" format="counter" sectionFormat="of" target="section-12.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sect-1" 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 protocol interfaces profiled by the United States National Security Agency (NSA) for National Security
   System (NSS) servers that provide public key certificates, Certificate Revocation Lists (CRLs), and symmetric keys to NSS clients.
   Servers that support these interfaces are referred to as Secure
   Object Delivery Protocol (SODP) servers.  The purpose of this document is
   to indicate options from, and requirements in addition to, the base
   specifications listed in <xref target="sect-1.1" format="default" sectionFormat="of" derivedContent="Section 1.1"/> that are necessary for client
   interoperability with NSA-operated SODP servers.  Clients are always
   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>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-2">
        <li pn="section-1-2.1">Enrollment over Secure Transport (EST) <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/> and its
       extensions <xref target="RFC8295" format="default" sectionFormat="of" derivedContent="RFC8295"/>, and</li>
        <li pn="section-1-2.2">Certificate Management over CMS (CMC) <xref target="RFC5274" format="default" sectionFormat="of" derivedContent="RFC5274"/> <xref target="RFC6402" format="default" sectionFormat="of" derivedContent="RFC6402"/> for both Simple Public Key
       Infrastructure (PKI) requests and responses (i.e., PKCS#10 requests
       and PKCS#7 responses) and Full PKI requests and responses.</li>
      </ul>
      <t indent="0" pn="section-1-3">
   This profile applies to the capabilities, configuration, and operation of
   all components of US National Security Systems <xref target="SP-800-59" format="default" sectionFormat="of" derivedContent="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>
      <t indent="0" pn="section-1-4">
   This profile conforms to the existing requirements of the NSA's
   Commercial National Security 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 anchor="sect-1.1" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-documents-to-be-familiar-wi">Documents to be Familiar With</name>
        <t indent="0" pn="section-1.1-1">Familiarity with the follow specifications is assumed:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.1-2">
          <li pn="section-1.1-2.1">EST and EST extensions: <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/> and <xref target="RFC8295" format="default" sectionFormat="of" derivedContent="RFC8295"/></li>
          <li pn="section-1.1-2.2">PKI-related specifications: <xref target="RFC2986" format="default" sectionFormat="of" derivedContent="RFC2986"/>, <xref target="RFC3739" format="default" sectionFormat="of" derivedContent="RFC3739"/>, <xref target="RFC5274" format="default" sectionFormat="of" derivedContent="RFC5274"/>, <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>, <xref target="RFC5912" format="default" sectionFormat="of" derivedContent="RFC5912"/>, <xref target="RFC5913" format="default" sectionFormat="of" derivedContent="RFC5913"/>, <xref target="RFC5916" format="default" sectionFormat="of" derivedContent="RFC5916"/>, <xref target="RFC5917" format="default" sectionFormat="of" derivedContent="RFC5917"/>, <xref target="RFC6010" format="default" sectionFormat="of" derivedContent="RFC6010"/>, and <xref target="RFC6402" format="default" sectionFormat="of" derivedContent="RFC6402"/></li>
          <li pn="section-1.1-2.3">Key-format-related specifications: <xref target="RFC5915" format="default" sectionFormat="of" derivedContent="RFC5915"/>, <xref target="RFC5958" format="default" sectionFormat="of" derivedContent="RFC5958"/>, <xref target="RFC5959" format="default" sectionFormat="of" derivedContent="RFC5959"/>, <xref target="RFC6031" format="default" sectionFormat="of" derivedContent="RFC6031"/>, <xref target="RFC6032" format="default" sectionFormat="of" derivedContent="RFC6032"/>, <xref target="RFC6160" format="default" sectionFormat="of" derivedContent="RFC6160"/>, <xref target="RFC6161" format="default" sectionFormat="of" derivedContent="RFC6161"/>, <xref target="RFC6162" format="default" sectionFormat="of" derivedContent="RFC6162"/>, <xref target="RFC7191" format="default" sectionFormat="of" derivedContent="RFC7191"/>, <xref target="RFC7192" format="default" sectionFormat="of" derivedContent="RFC7192"/>, <xref target="RFC7292" format="default" sectionFormat="of" derivedContent="RFC7292"/>, and <xref target="RFC7906" format="default" sectionFormat="of" derivedContent="RFC7906"/></li>
          <li pn="section-1.1-2.4">CMS-related (Cryptographic Message Syntax) documents: <xref target="RFC5652" format="default" sectionFormat="of" derivedContent="RFC5652"/> and <xref target="RFC6268" format="default" sectionFormat="of" derivedContent="RFC6268"/></li>
          <li pn="section-1.1-2.5">CNSA-related documents: <xref target="RFC8603" format="default" sectionFormat="of" derivedContent="RFC8603"/>, <xref target="RFC8755" format="default" sectionFormat="of" derivedContent="RFC8755"/>, <xref target="RFC8756" format="default" sectionFormat="of" derivedContent="RFC8756"/>, and <xref target="RFC9151" format="default" sectionFormat="of" derivedContent="RFC9151"/></li>
        </ul>
        <t indent="0" pn="section-1.1-3">
   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" format="default" sectionFormat="of" derivedContent="RFC2119"/> and <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>.</t>
      </section>
      <section anchor="sect-1.2" numbered="true" toc="include" removeInRFC="false" pn="section-1.2">
        <name slugifiedName="name-document-organization">Document Organization</name>
        <t indent="0" pn="section-1.2-1"> The document is organized as follows:

        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.2-2">
          <li pn="section-1.2-2.1">The remainder of this section describes the operational
	    environment used by clients to retrieve secure objects.</li>
          <li pn="section-1.2-2.2">
            <xref target="sect-2" format="default" sectionFormat="of" derivedContent="Section 2"/> specifies the Abstract Syntax Notation One (ASN.1) version used.</li>
          <li pn="section-1.2-2.3">
            <xref target="sect-3" format="default" sectionFormat="of" derivedContent="Section 3"/> specifies SODP's EST interface.</li>
          <li pn="section-1.2-2.4">
            <xref target="sect-4" format="default" sectionFormat="of" derivedContent="Section 4"/> specifies SODP's CMC interfaces.
          </li>
          <li pn="section-1.2-2.5">Sections <xref target="sect-5" format="counter" sectionFormat="of" derivedContent="5"/>-<xref target="sect-7" format="counter" sectionFormat="of" derivedContent="7"/> specify Trust Anchor (TA), Certification Authority (CA), and End-Entity (EE) certificates, respectively.
	  </li>
          <li pn="section-1.2-2.6">Sections <xref target="sect-8" format="counter" sectionFormat="of" derivedContent="8"/> and <xref target="sect-9" format="counter" sectionFormat="of" derivedContent="9"/> specify Relying Party Applications and CRL Profile, respectively.</li>
        </ul>
      </section>
      <section anchor="sect-1.3" numbered="true" toc="include" removeInRFC="false" pn="section-1.3">
        <name slugifiedName="name-environment">Environment</name>
        <t indent="0" pn="section-1.3-1">
   Clients obtain
   secure "objects" or "packages" from the client-server-based environment.  Objects/packages vary based on the
   Source of 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 content types".  All others are simply referred to as
   "CMS content types".  All secured objects are distributed either as CMS
   packages or as part of a CMS package.</t>
        <t indent="0" pn="section-1.3-2">
   In the example depicted in <xref target="ure-operating-environment-key-and-pki-sources-of-authority" format="default" sectionFormat="of" derivedContent="Figure 1"/>, there are two SOAs:
   one for symmetric keys, as depicted by the Key Trust Anchor (KTA),
   and one for public key certificates, as depicted by the PKI 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 Key Source Authority (KSA) and a Key
   Distribution 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 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 Certification
   Authorities (CAs), and CAs, in turn, are responsible for creating,
   distributing, and managing 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 anchor="ure-operating-environment-key-and-pki-sources-of-authority" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-operating-environment-key-a">Operating Environment (Key and PKI Sources of Authority)</name>
          <artwork name="" type="" align="left" alt="" pn="section-1.3-3.1">
   +-----+                            +--------+
   | KTA |                            | PKI TA |
   +-----+                            +--------+
      |                                   |
      | Signs                             | Signs
      |                                   |
      +-------------+                     V
      |             |                   +----+
      V             V                   | CA |
   +-----+       +-----+                +----+
   | KSA |       | KDA |                   |
   +-----+       +-----+                   | Signs
      |           |                        |
      | Signs &amp;   | Optionally             +---------------+
      | Encrypts  | Signs                  |               |
      |           |                        V               V
      |           |                +-------------+ +-------------+
      |           V                | Certificate | | Certificate |
  +---|-------------+              +-------------+ | Revocation  |
  |   V             | CMS Content                  | List        |
  | +-------------+ | Types                        +-------------+
  | | Key Package | |
  | +-------------+ |
  +-----------------+
</artwork>
        </figure>
        <t indent="0" pn="section-1.3-4">
   For clients that support the CMC interface and not the EST interface,
   the environment includes only the PKI TAs.</t>
      </section>
    </section>
    <section anchor="sect-2" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-abstract-syntax-notation-on">Abstract Syntax Notation One</name>
      <t indent="0" pn="section-2-1">
   Implementations of this specification use the 2002/2008
   ASN.1 version; 2002/2008 ASN.1 modules can be found in
   <xref target="RFC5911" format="default" sectionFormat="of" derivedContent="RFC5911"/>, <xref target="RFC5912" format="default" sectionFormat="of" derivedContent="RFC5912"/>, and <xref target="RFC6268" format="default" sectionFormat="of" derivedContent="RFC6268"/> (use <xref target="RFC6268" format="default" sectionFormat="of" derivedContent="RFC6268"/> for the CMS syntax), while other specifications already include the 2002/2008 ASN.1 along
   with the 1988 ASN.1.  See <xref target="RFC6268" sectionFormat="of" section="1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6268#section-1.1" derivedContent="RFC6268"/> for a discussion
   about the differences between the 2002 and 2008 ASN.1 versions.</t>
    </section>
    <section anchor="sect-3" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-est-interface">EST Interface</name>
      <t indent="0" pn="section-3-1">
   Client options for EST <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/> and EST extensions <xref target="RFC8295" format="default" sectionFormat="of" derivedContent="RFC8295"/> are
   specified in this section.</t>
      <section anchor="sect-3.1" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-hypertext-transfer-protocol">Hypertext Transfer Protocol Layer</name>
        <t indent="0" pn="section-3.1-1">
   Clients that receive redirection responses (3xx status codes) will
   terminate the connection (<xref target="RFC7030" sectionFormat="comma" section="3.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-3.2.1" derivedContent="RFC7030"/>).</t>
        <t indent="0" pn="section-3.1-2">
   Per <xref target="RFC8295" sectionFormat="of" section="2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8295#section-2.2" derivedContent="RFC8295"/>, clients indicate the format
   ("application/xml" or "application/json") of the PAL information
   (<xref target="RFC8295" sectionFormat="comma" section="2.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8295#section-2.1.1" derivedContent="RFC8295"/>) via the HTTP Accept header.</t>
      </section>
      <section anchor="sect-3.2" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-transport-layer-security">Transport Layer Security</name>
        <t indent="0" pn="section-3.2-1">
   TLS implementations are configured as specified in
   <xref target="RFC9151" format="default" sectionFormat="of" derivedContent="RFC9151"/>; the notable exception is that only EC-based
   algorithms are used.</t>
      </section>
      <section anchor="sect-3.3" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-eligibility">Eligibility</name>
        <t indent="0" pn="section-3.3-1">
 At the EST interface, servers only enroll clients that they have 
 established a prior relationship with independently of
 the EST service. To accomplish this, client owners/operators
   interact in person with the human acting as the Registration
   Authority (RA) to ensure the information included in the transmitted
   certificate request, which is sometimes called a Certificate
   Signing Request (CSR), is associated with a client.  The mechanism by
   which the owner/operator 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 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>
      </section>
      <section anchor="sect-3.4" numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-authentication">Authentication</name>
        <t indent="0" pn="section-3.4-1">
   Mutual authentication occurs via "Certificate TLS Authentication"
   (<xref target="RFC7030" sectionFormat="comma" section="2.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-2.2.1" derivedContent="RFC7030"/>).  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 anchor="sect-3.5" numbered="true" toc="include" removeInRFC="false" pn="section-3.5">
        <name slugifiedName="name-authorization">Authorization</name>
        <t indent="0" pn="section-3.5-1">
   Clients always use an explicit TA database (<xref target="RFC7030" sectionFormat="comma" section="3.6.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-3.6.1" derivedContent="RFC7030"/>).  At a minimum, clients support two TAs: one for the PKI and
   one for symmetric keys.</t>
        <t indent="0" pn="section-3.5-2">
   Clients check that the server's certificate includes the id-kp-cmcRA
   Extended Key Usage (EKU) value (<xref target="RFC6402" sectionFormat="comma" section="2.10" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6402#section-2.10" derivedContent="RFC6402"/>).</t>
        <t indent="0" pn="section-3.5-3">
   Clients that support processing of the CMS Content Constraints extension
   <xref target="RFC6010" format="default" sectionFormat="of" derivedContent="RFC6010"/> ensure returned CMS content is from an SOA or an
   entity authorized by an SOA for that CMS content; see <xref target="sect-7.1" format="default" sectionFormat="of" derivedContent="Section 7.1"/> for
   SOA certificates.</t>
      </section>
      <section anchor="sect-3.6" numbered="true" toc="include" removeInRFC="false" pn="section-3.6">
        <name slugifiedName="name-est-and-est-extensions">EST and EST Extensions</name>
        <t indent="0" pn="section-3.6-1">
   This section profiles SODP's interfaces for EST <xref target="RFC7030" format="default" sectionFormat="of" derivedContent="RFC7030"/> and EST extensions
   <xref target="RFC8295" format="default" sectionFormat="of" derivedContent="RFC8295"/>.</t>
        <section anchor="sect-3.6.1" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.1">
          <name slugifiedName="name-pal">/pal</name>
          <t indent="0" pn="section-3.6.1-1">
   The Package Availability List (PAL) is limited to 32 entries, where
   the 32nd PAL entry links to an additional PAL (i.e., PAL Package
   Type 0001).</t>
          <t indent="0" pn="section-3.6.1-2">
   The PAL is XML <xref target="XML" format="default" sectionFormat="of" derivedContent="XML"/>.</t>
        </section>
        <section anchor="sect-3.6.2" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.2">
          <name slugifiedName="name-cacerts">/cacerts</name>
          <t indent="0" pn="section-3.6.2-1">
   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>
          <t indent="0" pn="section-3.6.2-2">
   CA certificates provided through this service are as specified in
   Sections <xref target="sect-5" format="counter" sectionFormat="of" derivedContent="5"/> and <xref target="sect-6" format="counter" sectionFormat="of" derivedContent="6"/> of this document.</t>
        </section>
        <section anchor="sect-3.6.3" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.3">
          <name slugifiedName="name-simpleenroll">/simpleenroll</name>
          <t indent="0" pn="section-3.6.3-1">
   CSRs follow the specifications in <xref target="RFC8756" sectionFormat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8756#section-4.2" derivedContent="RFC8756"/>,
   except that the CMC-specific ChangeSubjectName and
   the POP Link Witness V2 attributes do not apply.  Only
   EC-based algorithms are used.</t>
          <t indent="0" pn="section-3.6.3-2">
   Client certificates provided through this service are as specified in
   <xref target="sect-7" format="default" sectionFormat="of" derivedContent="Section 7"/> of this document.</t>
          <t indent="0" pn="section-3.6.3-3">
   The HTTP content type of "text/plain" (<xref target="RFC2046" sectionFormat="comma" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2046#section-4.1" derivedContent="RFC2046"/>) is
   used to return human-readable errors.</t>
        </section>
        <section anchor="sect-3.6.4" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.4">
          <name slugifiedName="name-simplereenroll">/simplereenroll</name>
          <t indent="0" pn="section-3.6.4-1">
   There are no additional requirements for requests beyond those
   specified in Sections <xref target="sect-3.4" format="counter" sectionFormat="of" derivedContent="3.4"/> and <xref target="sect-3.6.3" format="counter" sectionFormat="of" derivedContent="3.6.3"/> of this document.</t>
          <t indent="0" pn="section-3.6.4-2">
   The HTTP content type of "text/plain" (<xref target="RFC2046" sectionFormat="comma" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2046#section-4.1" derivedContent="RFC2046"/>) is
   used to return human-readable errors.</t>
        </section>
        <section anchor="sect-3.6.5" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.5">
          <name slugifiedName="name-fullcmc">/fullcmc</name>
          <t indent="0" pn="section-3.6.5-1">
   Requests are as specified in <xref target="RFC8756" format="default" sectionFormat="of" derivedContent="RFC8756"/> with the notable
   exception that only EC-based algorithms are used.</t>
          <t indent="0" pn="section-3.6.5-2">
   Additional attributes for returned CMS packages can be found in
   <xref target="RFC7906" format="default" sectionFormat="of" derivedContent="RFC7906"/>.</t>
          <t indent="0" pn="section-3.6.5-3">
   Certificates provided through this service are as specified in
   <xref target="sect-7" format="default" sectionFormat="of" derivedContent="Section 7"/> of this document.</t>
        </section>
        <section anchor="sect-3.6.6" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.6">
          <name slugifiedName="name-serverkeygen">/serverkeygen</name>
          <t indent="0" pn="section-3.6.6-1">
   PKCS#12 <xref target="RFC7292" format="default" sectionFormat="of" derivedContent="RFC7292"/> -- sometimes referred to as "PFX" (Personal
   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 indent="0" pn="section-3.6.6-2">
   PFXs <xref target="RFC7292" format="default" sectionFormat="of" derivedContent="RFC7292"/> 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, and the PBES2 encryption scheme is
   AES-256.</t>
          <t indent="0" pn="section-3.6.6-3">
   The HTTP content type of "text/plain" (<xref target="RFC2046" sectionFormat="comma" section="4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2046#section-4.1" derivedContent="RFC2046"/>) is
   used to return human-readable errors.</t>
          <t indent="0" pn="section-3.6.6-4">
   /serverkeygen/return is not supported at this time.</t>
        </section>
        <section anchor="sect-3.6.7" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.7">
          <name slugifiedName="name-csrattrs">/csrattrs</name>
          <t indent="0" pn="section-3.6.7-1">
 Clients use this service to retrieve partially filled PKIRequests
 with no public key or proof-of-possession signature,
 i.e., their values are set to zero length, either a zero length BIT
 STRING or OCTET STRING. The pKCS7PDU attribute, defined in
   <xref target="RFC2985" format="default" sectionFormat="of" derivedContent="RFC2985"/>, 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 anchor="sect-3.6.8" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.8">
          <name slugifiedName="name-crls">/crls</name>
          <t indent="0" pn="section-3.6.8-1">
   CRLs provided through this service are as specified in <xref target="sect-9" format="default" sectionFormat="of" derivedContent="Section 9"/> of
   this document.</t>
        </section>
        <section anchor="sect-3.6.9" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.9">
          <name slugifiedName="name-symmetrickeys">/symmetrickeys</name>
          <t indent="0" pn="section-3.6.9-1">
   Clients that claim to support SODP interoperation will be able to process
   the following messages from an SODP server: </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.6.9-2">
            <li pn="section-3.6.9-2.1">additional encryption and origin
   authentication (<xref target="RFC8295" sectionFormat="comma" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8295#section-5" derivedContent="RFC8295"/>); and
   </li>
            <li pn="section-3.6.9-2.2">server-provided Symmetric Key
   Content Type <xref target="RFC6032" format="default" sectionFormat="of" derivedContent="RFC6032"/> encapsulated in an Encrypted Key Content Type using
   the EnvelopedData choice <xref target="RFC6033" format="default" sectionFormat="of" derivedContent="RFC6033"/> with an SOA certificate that includes the
   CMS Content Constraints extension (see <xref target="sect-7.1" format="default" sectionFormat="of" derivedContent="Section 7.1"/>).</li>
          </ul>
          <t indent="0" pn="section-3.6.9-3">
   Client-supported algorithms to decrypt the server-returned symmetric
   key are as follows:
          </t>
          <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-3.6.9-4">
            <li pn="section-3.6.9-4.1">Message Digest: See <xref target="RFC8755" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8755#section-4" derivedContent="RFC8755"/>.</li>
            <li pn="section-3.6.9-4.2">Digital Signature Algorithm: See <xref target="RFC8755" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8755#section-5" derivedContent="RFC8755"/>.</li>
            <li pn="section-3.6.9-4.3">Key Agreement: See <xref target="RFC8755" sectionFormat="of" section="6.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8755#section-6.1" derivedContent="RFC8755"/>.</li>
            <li pn="section-3.6.9-4.4">Key Wrap: AES-256 Key Wrap with Padding <xref target="RFC6033" format="default" sectionFormat="of" derivedContent="RFC6033"/> is used. AES-128 Key Wrap with Padding is not
            used.</li>
            <li pn="section-3.6.9-4.5">Content Encryption: AES-256 Key Wrap with Padding <xref target="RFC6033" format="default" sectionFormat="of" derivedContent="RFC6033"/> is used. AES-128 Key Wrap with
            Padding is not used.</li>
          </ul>
          <t indent="0" pn="section-3.6.9-5">
   /symmetrickeys/return is not used at this time.</t>
        </section>
        <section anchor="sect-3.6.10" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.10">
          <name slugifiedName="name-eecerts-firmware-tamp">/eecerts, /firmware, /tamp</name>
          <t indent="0" pn="section-3.6.10-1">
   /eecerts, /firmware, and /tamp are not used at this time.</t>
        </section>
      </section>
    </section>
    <section anchor="sect-4" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-cmc-interface">CMC Interface</name>
      <t indent="0" pn="section-4-1">
   Client options for CMC <xref target="RFC5274" format="default" sectionFormat="of" derivedContent="RFC5274"/> <xref target="RFC6402" format="default" sectionFormat="of" derivedContent="RFC6402"/> are specified in this section.</t>
      <section anchor="sect-4.1" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-rfc-5273-transport-protocol">RFC 5273 Transport Protocols</name>
        <t indent="0" pn="section-4.1-1">
   Clients only use the HTTPS-based transport. The TLS implementation
   and configuration are as specified in <xref target="RFC9151" format="default" sectionFormat="of" derivedContent="RFC9151"/>, with the
   notable exception that only EC-based algorithms are used.</t>
        <t indent="0" pn="section-4.1-2">
   Clients that receive HTTP redirection responses (3xx status codes)
   will terminate the connection (<xref target="RFC7030" sectionFormat="comma" section="3.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7030#section-3.2.1" derivedContent="RFC7030"/>).</t>
      </section>
      <section anchor="sect-4.2" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-eligibility-2">Eligibility</name>
        <t indent="0" pn="section-4.2-1">
 At the CMC interface, servers only enroll clients that they have
 established a prior relationship with independently of
 the EST service. To accomplish this, client owners/operators
   interact in person with the human acting as the Registration
   Authority (RA) to ensure the information included in the transmitted
   certificate request, which is sometimes called a Certificate
   Signing Request (CSR), is associated with a client.  The mechanism by
   which the owner/operator 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 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>
      </section>
      <section anchor="sect-4.3" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-authentication-2">Authentication</name>
        <t indent="0" pn="section-4.3-1">
   Mutual authentication occurs via client and server signing of CMC
   protocol elements, as required by <xref target="RFC8756" format="default" sectionFormat="of" derivedContent="RFC8756"/>. All such
   signatures are validated against an installed TA; any that fail
   validation are rejected.</t>
      </section>
      <section anchor="sect-4.4" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-authorization-2">Authorization</name>
        <t indent="0" pn="section-4.4-1">
   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 indent="0" pn="section-4.4-2">
   Clients check that the server's certificate includes the id-kp-cmcRA
   Extended Key Usage (EKU) value (<xref target="RFC6402" sectionFormat="comma" section="2.10" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6402#section-2.10" derivedContent="RFC6402"/>).</t>
        <t indent="0" pn="section-4.4-3">
   Clients that support processing of the CMS Content Constraints extension
   <xref target="RFC6010" format="default" sectionFormat="of" derivedContent="RFC6010"/> ensure returned CMS content is from an SOA or an
   entity authorized by an SOA for that CMS content; see <xref target="sect-7.1" format="default" sectionFormat="of" derivedContent="Section 7.1"/> for
   SOA certificates.</t>
      </section>
      <section anchor="sect-4.5" numbered="true" toc="include" removeInRFC="false" pn="section-4.5">
        <name slugifiedName="name-full-pki-requests-responses">Full PKI Requests/Responses</name>
        <t indent="0" pn="section-4.5-1">
   Requests are as specified in <xref target="RFC8756" format="default" sectionFormat="of" derivedContent="RFC8756"/> with the notable
   exception that only EC-based algorithms are used.</t>
        <t indent="0" pn="section-4.5-2">
   Additional attributes for returned CMS packages can be found in
   <xref target="RFC7906" format="default" sectionFormat="of" derivedContent="RFC7906"/>.</t>
        <t indent="0" pn="section-4.5-3">
   Certificates provided through this service are as specified in <xref target="sect-7" format="default" sectionFormat="of" derivedContent="Section 7"/> of this document.</t>
      </section>
    </section>
    <section anchor="sect-5" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-trust-anchor-profile">Trust Anchor Profile</name>
      <t indent="0" pn="section-5-1">
   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" format="default" sectionFormat="of" derivedContent="RFC8603"/>, which in
   turn specifies requirements in addition to those in <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.</t>
      <t indent="0" pn="section-5-2">
   Only EC-based algorithms are used.</t>
      <t indent="0" pn="section-5-3">
   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 indent="0" pn="section-5-4">
   In the Subject Key Identifier extension, the keyIdentifier is the 64
   low-order bits of the subject's subjectPublicKey field.</t>
      <t indent="0" pn="section-5-5">
   In the Key Usage extension, the nonRepudiation bit is never set.</t>
    </section>
    <section anchor="sect-6" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-non-self-signed-certificati">Non-Self-Signed Certification Authority Certificate Profile</name>
      <t indent="0" pn="section-6-1">
   This section documents requirements for non-self-signed CA
   certificates in addition to those specified in <xref target="RFC8603" format="default" sectionFormat="of" derivedContent="RFC8603"/>, which in
   turn specifies requirements in addition to those in <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.</t>
      <t indent="0" pn="section-6-2">
   Only EC-based algorithms are used.</t>
      <t indent="0" pn="section-6-3">
   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 indent="0" pn="section-6-4">
   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 indent="0" pn="section-6-5">
   In the Subject Key Identifier extension, the keyIdentifier is the 64
   low-order bits of the subject's subjectPublicKey field.</t>
      <t indent="0" pn="section-6-6">
   In the Key Usage extension, the nonRepudiation bit is never set.</t>
      <t indent="0" pn="section-6-7">
   The Certificate Policies extension is always included, and
   policyQualifiers are never used.</t>
      <t indent="0" pn="section-6-8">Non-self-signed CA certificates can also include the following:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-6-9">
        <dt pn="section-6-9.1">Name Constraints:</dt>
        <dd pn="section-6-9.2"> permittedSubtrees constraints are
	  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" format="default" sectionFormat="of" derivedContent="RFC4108"/>.  Note that rfc822Name, dNSName, and
	  uniformResourceIdentifier are defined as IA5 strings, and the
	  character sets allowed are not uniform amongst these three name
	  forms.</dd>
        <dt pn="section-6-9.3">CRL Distribution Points:</dt>
        <dd pn="section-6-9.4"> A distributionPoint is
	  always the fullName choice. The uniformResourceIdentifier
	  GeneralName choice is always included, but others can also be used as
	  long as the first element in the sequence of CRLDistributionPoints
	  is the uniformResourceIdentifier choice. The reasons and cRLIssuer
	  fields are never populated.  This extension is never marked as
	  critical.</dd>
        <dt pn="section-6-9.5">Authority Information Access:</dt>
        <dd pn="section-6-9.6"> Only one instance of
	  AccessDescription is included.  accessMethod is id-caIssuers, and
	  accessLocation's GeneralName is always the uniformResourceIdentifier
	  choice.</dd>
        <dt pn="section-6-9.7">Extended Key Usage:</dt>
        <dd pn="section-6-9.8"> EST servers and RAs include the
	  id-kp-cmcRA EKU, and the CAs include the id-kp-cmcCA, which are both
	  specified in <xref target="RFC6402" format="default" sectionFormat="of" derivedContent="RFC6402"/>.</dd>
      </dl>
      <t indent="0" pn="section-6-10">
   Issuers include the Authority Clearance Constraints extension <xref target="RFC5913" format="default" sectionFormat="of" derivedContent="RFC5913"/> in
   non-self-signed CA certificates that are issued to non-SOAs; values for the
   Certificate Policy (CP) Object Identifier (OID) and the supported classList
   values are found in the issuer's CP.  Criticality is determined by the
   issuer, and a securityCategories is never included.  Only one instance of
   Clearance is generated in the AuthorityClearanceConstraints sequence.</t>
      <t indent="0" pn="section-6-11">
   Issuers include a critical CMS Content Constraints extension
   <xref target="RFC6010" format="default" sectionFormat="of" derivedContent="RFC6010"/> 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 but include key packages (i.e., Encrypted Key Packages,
   Symmetric Key Packages, and Asymmetric Key Packages).</t>
    </section>
    <section anchor="sect-7" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-end-entity-certificate-prof">End-Entity Certificate Profile</name>
      <t indent="0" pn="section-7-1">
   This section documents requirements for EE signature and key
   establishment certificates in addition to those listed in <xref target="RFC8603" format="default" sectionFormat="of" derivedContent="RFC8603"/>,
   which in turn specifies requirements in addition to those in
   <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.</t>
      <t indent="0" pn="section-7-2">
   Only EC-based algorithms are used.</t>
      <t indent="0" pn="section-7-3">
   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 indent="0" pn="section-7-4">
   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 indent="0" pn="section-7-5">
   In the Subject Key Identifier extension, the keyIdentifier is the 64
   low-order bits of the subject's subjectPublicKey field.</t>
      <t indent="0" pn="section-7-6">
   In the Key Usage extension, signature certificates only assert
   digitalSignature, and key establishment certificates only assert
   keyAgreement.</t>
      <t indent="0" pn="section-7-7">
   The Certificate Policies extension is always included, and
   policyQualifiers are never used.</t>
      <t indent="0" pn="section-7-8">
   When included, the non-critical CRL Distribution Point extension's
   distributionPoint is always identified by the fullName choice. The
   uniformResourceIdentifier GeneralName choice is always 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 reasons and cRLIssuer fields are never populated.</t>
      <t indent="0" pn="section-7-9">
   The following subsections provide additional requirements for the
   different types of EE certificates.</t>
      <section anchor="sect-7.1" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-source-of-authority-certifi">Source of Authority Certificate Profile</name>
        <t indent="0" pn="section-7.1-1">
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 packages; these certificates are issued by non-PKI
TAs.</t>
        <t indent="0" pn="section-7.1-2">
   The Subject Alternative Name extension is always included.  The
   following choices are supported: rfc822Name, dNSName, ediPartyName,
   uniformResourceIdentifier, or iPAddress (both IPv4 and IPv6).  This
   extension is never critical.</t>
        <t indent="0" pn="section-7.1-3">
   A critical CMS Content Constraints extension <xref target="RFC6010" format="default" sectionFormat="of" derivedContent="RFC6010"/> 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 anchor="sect-7.2" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-client-certificate-profile">Client Certificate Profile</name>
        <t indent="0" pn="section-7.2-1">
   This section specifies the format for certificates issued to clients.</t>
        <t indent="0" pn="section-7.2-2">
   A non-critical Subject Directory Attributes extension is always
   included with the following attributes:

        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.2-3">
          <li pn="section-7.2-3.1">Device Owner <xref target="RFC5916" format="default" sectionFormat="of" derivedContent="RFC5916"/></li>
          <li pn="section-7.2-3.2">Clearance Sponsor <xref target="RFC5917" format="default" sectionFormat="of" derivedContent="RFC5917"/></li>
          <li pn="section-7.2-3.3">Clearance <xref target="RFC5913" format="default" sectionFormat="of" derivedContent="RFC5913"/></li>
        </ul>
        <t indent="0" pn="section-7.2-4">
   The following extensions are also included at the discretion of the
   CA:

        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.2-5">
          <li pn="section-7.2-5.1"> The Authority Information Access extension with only one instance of
AccessDescription included. accessMethod is id-caIssuers, and
accessLocation's GeneralName is always the uniformResourceIdentifier
choice.
</li>
          <li pn="section-7.2-5.2">A non-critical Subject Alternative Name extension that includes
	  the hardwareModuleName form <xref target="RFC4108" format="default" sectionFormat="of" derivedContent="RFC4108"/>, rfc822Name, or
	  uniformResourceIdentifier.</li>
          <li pn="section-7.2-5.3">A critical Subject Alternative Name extension that includes
	  dNSName, rfc822Name, ediPartyName, uniformResourceIdentifier, or
	  iPAddress (both IPv4 and IPv6).</li>
        </ul>
      </section>
    </section>
    <section anchor="sect-8" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-relying-party-applications">Relying Party Applications</name>
      <t indent="0" pn="section-8-1">
   This section documents requirements for Relying Parties (RPs) in
   addition to those listed in <xref target="RFC8603" format="default" sectionFormat="of" derivedContent="RFC8603"/>, which in turn specifies
   requirements in addition to those in <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.</t>
      <t indent="0" pn="section-8-2">
   Only EC-based algorithms are used.</t>
      <t indent="0" pn="section-8-3">
   RPs support the Authority Key Identifier and the Subject Key
   Identifier extensions.</t>
      <t indent="0" pn="section-8-4">
   RPs should support the following extensions: CRL Distribution Points,
   Authority Information Access, Subject Directory Attribute,  Authority
   Clearance Constraints, and CMS Content Constraints.</t>
      <t indent="0" pn="section-8-5">
   Within the Subject Directory Attribute extension, RPs should support
   the Clearance Sponsor, Clearance, and Device Owner attributes.</t>
      <t indent="0" pn="section-8-6">
   RPs support the id-kp-cmcRA and id-kp-cmcCA EKUs.</t>
      <t indent="0" pn="section-8-7">
   Failure to support extensions in this section might limit the
   suitability of a device for certain applications.</t>
    </section>
    <section anchor="sect-9" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-crl-profile">CRL Profile</name>
      <t indent="0" pn="section-9-1">
   This section documents requirements for CRLs in addition to those
   listed in <xref target="RFC8603" format="default" sectionFormat="of" derivedContent="RFC8603"/>, which in turn specifies requirements in addition
   to those in <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>.</t>
      <t indent="0" pn="section-9-2">
   Only EC-based algorithms are used.</t>
      <t indent="0" pn="section-9-3">
   Two types of CRLs are produced: complete base CRLs and partitioned
   base CRLs.</t>
      <t indent="0" pn="section-9-4">
   crlEntryExtensions are never included, and the reasons and cRLIssuer
   fields are never populated.</t>
      <t indent="0" pn="section-9-5">All CRLs include the following CRL extensions:

      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-9-6">
        <li pn="section-9-6.1">The Authority Key Identifier extension: The keyIdentifier is the
	  64 low-order bits of the issuer's subjectPublicKey field.</li>
        <li pn="section-9-6.2">As per <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>, the CRL Number extension.</li>
      </ul>
      <t indent="0" pn="section-9-7">
   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
   uniformResourceIdentifier GeneralName choice is always included, but
   others can also be used as long as the first element in the sequence
   of distribution points is the uniformResourceIdentifier choice and the
   scheme is an HTTP/HTTPS scheme. All other fields are omitted.</t>
    </section>
    <section anchor="sect-10" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-10-1">
   This document has no IANA actions.</t>
    </section>
    <section anchor="sect-11" numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-11-1">
   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" format="default" sectionFormat="of" derivedContent="RFC5280"/>.  
 These have been cited throughout this document, and the
 specifications identified by those citations should be consulted
 for security considerations related to implemented protocols
 and services.</t>
    </section>
  </middle>
  <back>
    <references pn="section-12">
      <name slugifiedName="name-references">References</name>
      <references pn="section-12.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2046" target="https://www.rfc-editor.org/info/rfc2046" quoteTitle="true" derivedAnchor="RFC2046">
          <front>
            <title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
            <author initials="N." surname="Freed" fullname="N. Freed">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Borenstein" fullname="N. Borenstein">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1996" month="November"/>
            <abstract>
              <t indent="0">This second document defines the general structure of the MIME media typing system and defines an initial set of media types.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2046"/>
          <seriesInfo name="DOI" value="10.17487/RFC2046"/>
        </reference>
        <reference anchor="RFC2985" target="https://www.rfc-editor.org/info/rfc2985" quoteTitle="true" derivedAnchor="RFC2985">
          <front>
            <title>PKCS #9: Selected Object Classes and Attribute Types Version 2.0</title>
            <author initials="M." surname="Nystrom" fullname="M. Nystrom">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Kaliski" fullname="B. Kaliski">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2000" month="November"/>
            <abstract>
              <t indent="0">This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document, except for the security considerations section, is taken directly from that specification.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2985"/>
          <seriesInfo name="DOI" value="10.17487/RFC2985"/>
        </reference>
        <reference anchor="RFC2986" target="https://www.rfc-editor.org/info/rfc2986" quoteTitle="true" derivedAnchor="RFC2986">
          <front>
            <title>PKCS #10: Certification Request Syntax Specification Version 1.7</title>
            <author initials="M." surname="Nystrom" fullname="M. Nystrom">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Kaliski" fullname="B. Kaliski">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2000" month="November"/>
            <abstract>
              <t indent="0">This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process.  The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2986"/>
          <seriesInfo name="DOI" value="10.17487/RFC2986"/>
        </reference>
        <reference anchor="RFC3739" target="https://www.rfc-editor.org/info/rfc3739" quoteTitle="true" derivedAnchor="RFC3739">
          <front>
            <title>Internet X.509 Public Key Infrastructure: Qualified Certificates Profile</title>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Nystrom" fullname="M. Nystrom">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Polk" fullname="T. Polk">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="March"/>
            <abstract>
              <t indent="0">This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons.  The profile defines specific conventions for certificates that are qualified within a defined legal framework, named Qualified Certificates.  However, the profile does not define any legal requirements for such Qualified Certificates.  The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements.  The profile is however not limited to Qualified Certificates and further profiling may facilitate specific local needs. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3739"/>
          <seriesInfo name="DOI" value="10.17487/RFC3739"/>
        </reference>
        <reference anchor="RFC4108" target="https://www.rfc-editor.org/info/rfc4108" quoteTitle="true" derivedAnchor="RFC4108">
          <front>
            <title>Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages</title>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2005" month="August"/>
            <abstract>
              <t indent="0">This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components.  CMS is specified in RFC 3852.  A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package.  A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package.  Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4108"/>
          <seriesInfo name="DOI" value="10.17487/RFC4108"/>
        </reference>
        <reference anchor="RFC5274" target="https://www.rfc-editor.org/info/rfc5274" quoteTitle="true" derivedAnchor="RFC5274">
          <front>
            <title>Certificate Management Messages over CMS (CMC): Compliance Requirements</title>
            <author initials="J." surname="Schaad" fullname="J. Schaad">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Myers" fullname="M. Myers">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="June"/>
            <abstract>
              <t indent="0">This document provides a set of compliance statements about the CMC (Certificate Management over CMS) enrollment protocol.  The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents.  This document provides the information needed to make a compliant version of CMC.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5274"/>
          <seriesInfo name="DOI" value="10.17487/RFC5274"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author initials="D." surname="Cooper" fullname="D. Cooper">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Santesson" fullname="S. Santesson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Farrell" fullname="S. Farrell">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Boeyen" fullname="S. Boeyen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Polk" fullname="W. Polk">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2008" month="May"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC5652" target="https://www.rfc-editor.org/info/rfc5652" quoteTitle="true" derivedAnchor="RFC5652">
          <front>
            <title>Cryptographic Message Syntax (CMS)</title>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="September"/>
            <abstract>
              <t indent="0">This document describes the Cryptographic Message Syntax (CMS).  This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="70"/>
          <seriesInfo name="RFC" value="5652"/>
          <seriesInfo name="DOI" value="10.17487/RFC5652"/>
        </reference>
        <reference anchor="RFC5911" target="https://www.rfc-editor.org/info/rfc5911" quoteTitle="true" derivedAnchor="RFC5911">
          <front>
            <title>New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME</title>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Schaad" fullname="J. Schaad">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t indent="0">The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates those ASN.1 modules to conform to the 2002 version of ASN.1.  There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet Standards Track  specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5911"/>
          <seriesInfo name="DOI" value="10.17487/RFC5911"/>
        </reference>
        <reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5912" quoteTitle="true" derivedAnchor="RFC5912">
          <front>
            <title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Schaad" fullname="J. Schaad">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t indent="0">The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet  Standards Track specification; it is published for informational  purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5912"/>
          <seriesInfo name="DOI" value="10.17487/RFC5912"/>
        </reference>
        <reference anchor="RFC5913" target="https://www.rfc-editor.org/info/rfc5913" quoteTitle="true" derivedAnchor="RFC5913">
          <front>
            <title>Clearance Attribute and Authority Clearance Constraints Certificate Extension</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Chokhani" fullname="S. Chokhani">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t indent="0">This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates.  The Clearance attribute is used to indicate the clearance held by the subject.  The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate.  The Authority Clearance Constraints certificate extension values in a Trust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5913"/>
          <seriesInfo name="DOI" value="10.17487/RFC5913"/>
        </reference>
        <reference anchor="RFC5915" target="https://www.rfc-editor.org/info/rfc5915" quoteTitle="true" derivedAnchor="RFC5915">
          <front>
            <title>Elliptic Curve Private Key Structure</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Brown" fullname="D. Brown">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t indent="0">This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information.  The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5915"/>
          <seriesInfo name="DOI" value="10.17487/RFC5915"/>
        </reference>
        <reference anchor="RFC5916" target="https://www.rfc-editor.org/info/rfc5916" quoteTitle="true" derivedAnchor="RFC5916">
          <front>
            <title>Device Owner Attribute</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t indent="0">This document defines the Device Owner attribute.  It indicates the entity (e.g., company, organization, department, agency) that owns the device.  This attribute may be included in public key certificates and attribute certificates.  This document is not  an Internet Standards Track specification; it is published for  informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5916"/>
          <seriesInfo name="DOI" value="10.17487/RFC5916"/>
        </reference>
        <reference anchor="RFC5917" target="https://www.rfc-editor.org/info/rfc5917" quoteTitle="true" derivedAnchor="RFC5917">
          <front>
            <title>Clearance Sponsor Attribute</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t indent="0">This document defines the clearance sponsor attribute.  It indicates the entity that sponsored (i.e., granted) the clearance.  This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5917"/>
          <seriesInfo name="DOI" value="10.17487/RFC5917"/>
        </reference>
        <reference anchor="RFC5958" target="https://www.rfc-editor.org/info/rfc5958" quoteTitle="true" derivedAnchor="RFC5958">
          <front>
            <title>Asymmetric Key Packages</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="August"/>
            <abstract>
              <t indent="0">This document defines the syntax for private-key information and a content type for it.  Private-key information includes a private key for a specified public-key algorithm and a set of attributes.  The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type.  This document obsoletes RFC 5208.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5958"/>
          <seriesInfo name="DOI" value="10.17487/RFC5958"/>
        </reference>
        <reference anchor="RFC5959" target="https://www.rfc-editor.org/info/rfc5959" quoteTitle="true" derivedAnchor="RFC5959">
          <front>
            <title>Algorithms for Asymmetric Key Package Content Type</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="August"/>
            <abstract>
              <t indent="0">This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958.  It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData, EnvelopedData, EncryptedData, AuthenticatedData, and AuthEnvelopedData.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5959"/>
          <seriesInfo name="DOI" value="10.17487/RFC5959"/>
        </reference>
        <reference anchor="RFC6010" target="https://www.rfc-editor.org/info/rfc6010" quoteTitle="true" derivedAnchor="RFC6010">
          <front>
            <title>Cryptographic Message Syntax (CMS) Content Constraints Extension</title>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Ashmore" fullname="S. Ashmore">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Wallace" fullname="C. Wallace">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="September"/>
            <abstract>
              <t indent="0">This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints extension. This extension is used to determine whether a public key is appropriate to use in the processing of a protected content.  In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content.  The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate.  If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6010"/>
          <seriesInfo name="DOI" value="10.17487/RFC6010"/>
        </reference>
        <reference anchor="RFC6031" target="https://www.rfc-editor.org/info/rfc6031" quoteTitle="true" derivedAnchor="RFC6031">
          <front>
            <title>Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="December"/>
            <abstract>
              <t indent="0">This document defines the symmetric key format content type.  It is transport independent.  The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6031"/>
          <seriesInfo name="DOI" value="10.17487/RFC6031"/>
        </reference>
        <reference anchor="RFC6032" target="https://www.rfc-editor.org/info/rfc6032" quoteTitle="true" derivedAnchor="RFC6032">
          <front>
            <title>Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="December"/>
            <abstract>
              <t indent="0">This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package.  It is transport independent.  CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type.  It is designed to be used with the CMS Content Constraints (CCC) extension, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6032"/>
          <seriesInfo name="DOI" value="10.17487/RFC6032"/>
        </reference>
        <reference anchor="RFC6033" target="https://www.rfc-editor.org/info/rfc6033" quoteTitle="true" derivedAnchor="RFC6033">
          <front>
            <title>Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="December"/>
            <abstract>
              <t indent="0">This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type.  Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, and AuthEnvelopedData.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6033"/>
          <seriesInfo name="DOI" value="10.17487/RFC6033"/>
        </reference>
        <reference anchor="RFC6160" target="https://www.rfc-editor.org/info/rfc6160" quoteTitle="true" derivedAnchor="RFC6160">
          <front>
            <title>Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="April"/>
            <abstract>
              <t indent="0">This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type.  Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6160"/>
          <seriesInfo name="DOI" value="10.17487/RFC6160"/>
        </reference>
        <reference anchor="RFC6161" target="https://www.rfc-editor.org/info/rfc6161" quoteTitle="true" derivedAnchor="RFC6161">
          <front>
            <title>Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="April"/>
            <abstract>
              <t indent="0">This document describes the conventions for using several Elliptic Curve cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type.  Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData.  This document extends RFC 6033. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6161"/>
          <seriesInfo name="DOI" value="10.17487/RFC6161"/>
        </reference>
        <reference anchor="RFC6162" target="https://www.rfc-editor.org/info/rfc6162" quoteTitle="true" derivedAnchor="RFC6162">
          <front>
            <title>Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="April"/>
            <abstract>
              <t indent="0">This document describes conventions for using Elliptic Curve cryptographic algorithms with SignedData and EnvelopedData to protect the AsymmetricKeyPackage content type.  Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman (ECDH) with EnvelopedData and Elliptic Curve Digital Signature Algorithm (ECDSA) with SignedData.  This document extends RFC 5959. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6162"/>
          <seriesInfo name="DOI" value="10.17487/RFC6162"/>
        </reference>
        <reference anchor="RFC6268" target="https://www.rfc-editor.org/info/rfc6268" quoteTitle="true" derivedAnchor="RFC6268">
          <front>
            <title>Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)</title>
            <author initials="J." surname="Schaad" fullname="J. Schaad">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="July"/>
            <abstract>
              <t indent="0">The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version.  There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet Standards Track  specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6268"/>
          <seriesInfo name="DOI" value="10.17487/RFC6268"/>
        </reference>
        <reference anchor="RFC6402" target="https://www.rfc-editor.org/info/rfc6402" quoteTitle="true" derivedAnchor="RFC6402">
          <front>
            <title>Certificate Management over CMS (CMC) Updates</title>
            <author initials="J." surname="Schaad" fullname="J. Schaad">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="November"/>
            <abstract>
              <t indent="0">This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS).  This document updates RFC 5272, RFC 5273, and RFC 5274.</t>
              <t indent="0">The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6402"/>
          <seriesInfo name="DOI" value="10.17487/RFC6402"/>
        </reference>
        <reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc7030" quoteTitle="true" derivedAnchor="RFC7030">
          <front>
            <title>Enrollment over Secure Transport</title>
            <author initials="M." surname="Pritikin" fullname="M. Pritikin" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Yee" fullname="P. Yee" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Harkins" fullname="D. Harkins" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="October"/>
            <abstract>
              <t indent="0">This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport.  This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates.  It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7030"/>
          <seriesInfo name="DOI" value="10.17487/RFC7030"/>
        </reference>
        <reference anchor="RFC7191" target="https://www.rfc-editor.org/info/rfc7191" quoteTitle="true" derivedAnchor="RFC7191">
          <front>
            <title>Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types</title>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="April"/>
            <abstract>
              <t indent="0">This document defines the syntax for two Cryptographic Message Syntax (CMS) content types: one for key package receipts and another for key package errors.  The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages.  The key package error content type is used to indicate an error occurred during the processing of a key package.  CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7191"/>
          <seriesInfo name="DOI" value="10.17487/RFC7191"/>
        </reference>
        <reference anchor="RFC7192" target="https://www.rfc-editor.org/info/rfc7192" quoteTitle="true" derivedAnchor="RFC7192">
          <front>
            <title>Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="April"/>
            <abstract>
              <t indent="0">This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types.  Specifically, it includes conventions necessary to implement SignedData, EnvelopedData, EncryptedData, and AuthEnvelopedData.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7192"/>
          <seriesInfo name="DOI" value="10.17487/RFC7192"/>
        </reference>
        <reference anchor="RFC7292" target="https://www.rfc-editor.org/info/rfc7292" quoteTitle="true" derivedAnchor="RFC7292">
          <front>
            <title>PKCS #12: Personal Information Exchange Syntax v1.1</title>
            <author initials="K." surname="Moriarty" fullname="K. Moriarty" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Nystrom" fullname="M. Nystrom">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Parkinson" fullname="S. Parkinson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Rusch" fullname="A. Rusch">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Scott" fullname="M. Scott">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="July"/>
            <abstract>
              <t indent="0">PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions.  Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information.  This standard supports direct transfer of personal information under several privacy and integrity modes.</t>
              <t indent="0">This document represents a republication of PKCS #12 v1.1 from RSA Laboratories' Public Key Cryptography Standard (PKCS) series.  By publishing this RFC, change control is transferred to the IETF.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7292"/>
          <seriesInfo name="DOI" value="10.17487/RFC7292"/>
        </reference>
        <reference anchor="RFC7906" target="https://www.rfc-editor.org/info/rfc7906" quoteTitle="true" derivedAnchor="RFC7906">
          <front>
            <title>NSA's Cryptographic Message Syntax (CMS) Key Management Attributes</title>
            <author initials="P." surname="Timmel" fullname="P. Timmel">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Housley" fullname="R. Housley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="June"/>
            <abstract>
              <t indent="0">This document defines key management attributes used by the National Security Agency (NSA).  The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages.  Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7906"/>
          <seriesInfo name="DOI" value="10.17487/RFC7906"/>
        </reference>
        <reference anchor="RFC8295" target="https://www.rfc-editor.org/info/rfc8295" quoteTitle="true" derivedAnchor="RFC8295">
          <front>
            <title>EST (Enrollment over Secure Transport) Extensions</title>
            <author initials="S." surname="Turner" fullname="S. Turner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="January"/>
            <abstract>
              <t indent="0">The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll).  This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them.  This document extends the EST server path components to provide these additional services.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8295"/>
          <seriesInfo name="DOI" value="10.17487/RFC8295"/>
        </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="RFC8755" target="https://www.rfc-editor.org/info/rfc8755" quoteTitle="true" derivedAnchor="RFC8755">
          <front>
            <title>Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions</title>
            <author initials="M." surname="Jenkins" fullname="M. Jenkins">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="March"/>
            <abstract>
              <t indent="0">The United States Government has published the National Security Agency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using the United States National Security Agency's CNSA Suite algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. 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="8755"/>
          <seriesInfo name="DOI" value="10.17487/RFC8755"/>
        </reference>
        <reference anchor="RFC8756" target="https://www.rfc-editor.org/info/rfc8756" quoteTitle="true" derivedAnchor="RFC8756">
          <front>
            <title>Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS</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="2020" month="March"/>
            <abstract>
              <t indent="0">This document specifies a profile of the Certificate Management over CMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm (CNSA) Suite published by the United States Government. </t>
              <t indent="0">The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS.  It is also appropriate for all other US Government systems that process high-value information. </t>
              <t indent="0">The profile is made publicly available here for use by developers and operators of these and any other system deployments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8756"/>
          <seriesInfo name="DOI" value="10.17487/RFC8756"/>
        </reference>
        <reference anchor="RFC9151" target="https://www.rfc-editor.org/info/rfc9151" quoteTitle="true" derivedAnchor="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 showOnFrontPage="true"/>
            </author>
            <date month="April" year="2022"/>
          </front>
          <seriesInfo name="RFC" value="9151"/>
          <seriesInfo name="DOI" value="10.17487/RFC9151"/>
        </reference>
        <reference anchor="SP-800-59" target="https://csrc.nist.gov/publications/detail/sp/800-59/final" quoteTitle="true" derivedAnchor="SP-800-59">
          <front>
            <title>Guideline for Identifying an Information System as a National Security System</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <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>
        <reference anchor="XML" target="https://www.w3.org/TR/2008/REC-xml-20081126/" quoteTitle="true" derivedAnchor="XML">
          <front>
            <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
            <author initials="T." surname="Bray" fullname="Tim Bray">
	</author>
            <author initials="J." surname="Paoli" fullname="Jean Paoli">
	</author>
            <author initials="C.M." surname="Sperberg-McQueen" fullname="C.M. Sperberg-McQueen">
	</author>
            <author initials="E." surname="Maler" fullname="Eve Maler">
	</author>
            <author initials="F." surname="Yergeau" fullname="François Yergeau">
	</author>
            <date month="November" year="2008"/>
          </front>
          <seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-20081126"/>
        </reference>
      </references>
      <references pn="section-12.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <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="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>
      </references>
    </references>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="M." surname="Jenkins" fullname="Michael Jenkins">
        <organization abbrev="NSA" showOnFrontPage="true">National Security Agency</organization>
        <address>
          <email>mjjenki@cyber.nsa.gov</email>
        </address>
      </author>
      <author initials="S." surname="Turner" fullname="Sean Turner">
        <organization showOnFrontPage="true">sn3rd</organization>
        <address>
          <email>sean@sn3rd.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
