<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-lamps-rfc6712bis-10" number="9811" category="std" consensus="true" submissionType="IETF" xml:lang="en" updates="" obsoletes="6712, 9480" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true" prepTime="2025-07-29T10:48:22" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6712bis-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9811" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="HTTP Transfer for CMP">Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)</title>
    <seriesInfo name="RFC" value="9811" stream="IETF"/>
    <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
      <organization abbrev="Siemens" showOnFrontPage="true">Siemens</organization>
      <address>
        <postal>
          <street>Werner-von-Siemens-Strasse 1</street>
          <city>Munich</city>
          <code>80333</code>
          <country>Germany</country>
        </postal>
        <email>hendrik.brockhaus@siemens.com</email>
        <uri>https://www.siemens.com</uri>
      </address>
    </author>
    <author initials="D." surname="von Oheimb" fullname="David von Oheimb">
      <organization abbrev="Siemens" showOnFrontPage="true">Siemens</organization>
      <address>
        <postal>
          <street>Werner-von-Siemens-Strasse 1</street>
          <city>Munich</city>
          <code>80333</code>
          <country>Germany</country>
        </postal>
        <email>david.von.oheimb@siemens.com</email>
        <uri>https://www.siemens.com</uri>
      </address>
    </author>
    <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth">
      <organization abbrev="Entrust" showOnFrontPage="true">Entrust</organization>
      <address>
        <postal>
          <street>1187 Park Place</street>
          <city>Minneapolis</city>
          <region>MN</region>
          <code>55379</code>
          <country>United States of America</country>
        </postal>
        <email>mike.ounsworth@entrust.com</email>
        <uri>https://www.entrust.com</uri>
      </address>
    </author>
    <author initials="J." surname="Gray" fullname="John Gray">
      <organization abbrev="Entrust" showOnFrontPage="true">Entrust</organization>
      <address>
        <postal>
          <street>1187 Park Place</street>
          <city>Minneapolis</city>
          <region>MN</region>
          <code>55379</code>
          <country>United States of America</country>
        </postal>
        <email>john.gray@entrust.com</email>
        <uri>https://www.entrust.com</uri>
      </address>
    </author>
    <date month="07" year="2025"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>
    <keyword>CMP</keyword>
    <keyword>HTTP</keyword>
    <keyword>Certificate management</keyword>
    <keyword>PKI</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document describes how to layer the Certificate Management Protocol
(CMP) over HTTP.</t>
      <t indent="0" pn="section-abstract-2">It includes the updates to RFC 6712 specified in Section 3 of RFC 9480; these
updates introduce CMP URIs using a well-known prefix. It obsoletes
RFC 6712; and, together with RFC 9810, it also obsoletes
RFC 9480.</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 is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in 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/rfc9811" 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) 2025 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. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <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-changes-made-by-rfc-9480">Changes Made by RFC 9480</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-changes-made-by-this-docume">Changes Made by This Document</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-conventions-used-in-this-do">Conventions Used in This Document</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-http-based-protocol">HTTP-Based Protocol</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-general-form">General Form</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-media-type">Media Type</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-communication-workflow">Communication Workflow</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-http-request-uri">HTTP Request-URI</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-pushing-of-announcements">Pushing of Announcements</xref></t>
              </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-implementation-consideratio">Implementation Considerations</xref></t>
          </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-security-considerations">Security Considerations</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-iana-considerations">IANA Considerations</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-references">References</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-normative-references">Normative References</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-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><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" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Certificate Management Protocol (CMP) <xref target="RFC9810" format="default" sectionFormat="of" derivedContent="RFC9810"/> requires a well-defined
transfer mechanism to enable End Entities (EEs), Registration
Authorities (RAs), and Certification Authorities (CAs) to pass
PKIMessage structures between them.</t>
      <t indent="0" pn="section-1-2">The first version of the CMP specification <xref target="RFC2510" format="default" sectionFormat="of" derivedContent="RFC2510"/> included a brief
description of a simple transfer protocol layer on top of TCP.  Its
features were simple transfer-level error handling and a mechanism to
poll for outstanding PKI messages.  Additionally, it was mentioned
that PKI messages could also be conveyed using file-, email-, and
HTTP-based transfer, but those were not specified in detail.</t>
      <t indent="0" pn="section-1-3">Since the second version of the CMP specification <xref target="RFC4210" format="default" sectionFormat="of" derivedContent="RFC4210"/> incorporated
its own polling mechanism, the need for a transfer protocol
providing this functionality vanished.  The remaining features CMP
requires from its transfer protocols are connection and error
handling.</t>
      <t indent="0" pn="section-1-4">CMP can benefit from utilizing reliable transport, as it requires connection and error handling
from the transfer protocol. All these features are covered by HTTP.  Additionally,
delayed delivery of CMP response messages may be handled at transfer level,
regardless of the message contents.  Since <xref target="RFC9480" format="default" sectionFormat="of" derivedContent="RFC9480"/> extends the polling
mechanism specified in the second version of <xref target="RFC4210" format="default" sectionFormat="of" derivedContent="RFC4210">CMP</xref> to cover
all types of PKI management transactions, delays detected at application
level may also be handled within CMP, using pollReq and pollRep messages.</t>
      <t indent="0" pn="section-1-5">The usage of HTTP (e.g., HTTP/1.1 as specified in <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> and <xref target="RFC9112" format="default" sectionFormat="of" derivedContent="RFC9112"/>) for transferring CMP messages exclusively uses the POST
method for requests, effectively tunneling CMP over HTTP. While this is
generally considered bad practice (see <xref target="BCP56" format="default" sectionFormat="of" derivedContent="BCP56">RFC 9205</xref> for best current
practice on building protocols with HTTP) and should not be emulated, there
are good reasons to do so for transferring CMP.  HTTP is used
as it is generally easy to implement and it is able to traverse
network borders utilizing ubiquitous proxies.  Most importantly, HTTP
is already commonly used in existing CMP implementations.  Other HTTP
request methods, such as GET, are not used because PKI management
operations can only be triggered using CMP's PKI messages, which need
to be transferred using a POST request.</t>
      <t indent="0" pn="section-1-6">With its status codes, HTTP provides needed error reporting
capabilities.  General problems on the server side, as well as those
directly caused by the respective request, can be reported to the
client.</t>
      <t indent="0" pn="section-1-7">As CMP implements a transaction identification (transactionID), identifying transactions spanning
over more than just a single request/response pair, the statelessness
of HTTP is not blocking its usage as the transfer protocol for CMP
messages.</t>
      <section anchor="sect-1.1" numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-changes-made-by-rfc-9480">Changes Made by RFC 9480</name>
        <t indent="0" pn="section-1.1-1"><xref target="RFC9480" format="default" sectionFormat="of" derivedContent="RFC9480">CMP Updates</xref> updated <xref section="3.6" sectionFormat="of" target="RFC6712" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6712#section-3.6" derivedContent="RFC6712"/>, supporting the PKI
management operations specified in the <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483">Lightweight CMP Profile</xref>, in the following areas:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.1-2">
          <li pn="section-1.1-2.1">
            <t indent="0" pn="section-1.1-2.1.1">Introduced the HTTP URI path prefix '/.well-known/cmp'.</t>
          </li>
          <li pn="section-1.1-2.2">
            <t indent="0" pn="section-1.1-2.2.1">Added options for extending the URI structure with further segments and
defined a new protocol registry group to that aim.</t>
          </li>
        </ul>
      </section>
      <section anchor="sect-1.2" numbered="true" removeInRFC="false" toc="include" pn="section-1.2">
        <name slugifiedName="name-changes-made-by-this-docume">Changes Made by This Document</name>
        <t indent="0" pn="section-1.2-1">This document obsoletes <xref target="RFC6712" format="default" sectionFormat="of" derivedContent="RFC6712"/>.
It includes the changes specified in <xref section="3" sectionFormat="of" target="RFC9480" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9480#section-3" derivedContent="RFC9480"/>, as
described in <xref target="sect-1.1" format="default" sectionFormat="of" derivedContent="Section 1.1"/> of this document. Additionally, it adds the following changes:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1.2-2">
          <li pn="section-1.2-2.1">
            <t indent="0" pn="section-1.2-2.1.1">Removed the requirement to support HTTP/1.0 <xref target="RFC1945" format="default" sectionFormat="of" derivedContent="RFC1945"/> in accordance with Section <xref target="RFC9205" section="4.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9205#section-4.1" derivedContent="RFC9205"/> of RFC 9205 <xref target="BCP56" format="default" sectionFormat="of" derivedContent="BCP56"/>.</t>
          </li>
          <li pn="section-1.2-2.2">
            <t indent="0" pn="section-1.2-2.2.1">Implementations <bcp14>MUST</bcp14> forward CMP messages when an HTTP error status code occurs; see  <xref target="sect-3.1" format="default" sectionFormat="of" derivedContent="Section 3.1"/>.</t>
          </li>
          <li pn="section-1.2-2.3">
            <t indent="0" pn="section-1.2-2.3.1">Removed <xref section="3.8" sectionFormat="of" target="RFC6712" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6712#section-3.8" derivedContent="RFC6712"/> as it contains information redundant with current HTTP specification.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="sect-2" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
    </section>
    <section anchor="sect-3" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-http-based-protocol">HTTP-Based Protocol</name>
      <t indent="0" pn="section-3-1">For direct interaction between two entities, where a reliable
transport protocol like TCP <xref target="RFC9293" format="default" sectionFormat="of" derivedContent="RFC9293"/> is available, HTTP <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> <bcp14>SHOULD</bcp14> be
utilized for conveying CMP messages. This specification requires
using the POST method (<xref target="sect-3.1" format="default" sectionFormat="of" derivedContent="Section 3.1"/>) and the "Content-Type" header
field (<xref target="sect-3.2" format="default" sectionFormat="of" derivedContent="Section 3.2"/>), which are available since HTTP/1.0 <xref target="RFC1945" format="default" sectionFormat="of" derivedContent="RFC1945"/>.</t>
      <t indent="0" pn="section-3-2">Note: In some situations, CMP requires multiple request/response
pairs to perform a PKI management operation. Their affiliation
with a PKI management operation is indicated by a
transaction identifier in the CMP message header (see transactionID
described in <xref target="RFC9810" sectionFormat="of" section="5.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9810#section-5.1.1" derivedContent="RFC9810"/>).
For details on how to transfer multiple requests, see Section
<xref target="RFC9205" sectionFormat="bare" section="4.11" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9205#section-4.11" derivedContent="RFC9205"/> of RFC 9205 <xref target="BCP56" format="default" sectionFormat="of" derivedContent="BCP56"/>.</t>
      <section anchor="sect-3.1" numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-general-form">General Form</name>
        <t indent="0" pn="section-3.1-1">A DER-encoded <xref target="ITU.X690.2021" format="default" sectionFormat="of" derivedContent="ITU.X690.2021"/> PKIMessage (<xref section="5.1" sectionFormat="of" target="RFC9810" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9810#section-5.1" derivedContent="RFC9810"/>) <bcp14>MUST</bcp14> be sent as the
content of an HTTP POST request.  If this HTTP request is
successful, the server returns the CMP response in the content of the
HTTP response.  The HTTP response status code in this case <bcp14>MUST</bcp14> be
200 (OK); other Successful 2xx status codes <bcp14>MUST NOT</bcp14> be used for this purpose.
HTTP responses to pushed CMP announcement messages described in <xref target="sect-3.5" format="default" sectionFormat="of" derivedContent="Section 3.5"/>
utilize the status codes 201 and 202 to identify whether the received
information was processed.</t>
        <t indent="0" pn="section-3.1-2">While Redirection 3xx status codes <bcp14>MAY</bcp14> be supported by
implementations, clients should only be enabled to automatically
follow them after careful consideration of possible security
implications.  As described in <xref target="sect-5" format="default" sectionFormat="of" derivedContent="Section 5"/>, the 301 (Moved Permanently) status code
could be misused for permanent denial of service.</t>
        <t indent="0" pn="section-3.1-3">All applicable Client Error 4xx or Server Error 5xx status codes
<bcp14>MAY</bcp14> be used to inform the client about errors. Whenever
a client receives an HTTP response with a status code in the 2xx,
4xx, or 5xx ranges, it <bcp14>MUST</bcp14> support handling response message
content containing a CMP response PKIMessage.</t>
      </section>
      <section anchor="sect-3.2" numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-media-type">Media Type</name>
        <t indent="0" pn="section-3.2-1">The Internet media type "application/pkixcmp" <bcp14>MUST</bcp14> be set in the HTTP
"Content-Type" header field when conveying a PKIMessage.</t>
      </section>
      <section anchor="sect-3.3" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-communication-workflow">Communication Workflow</name>
        <t indent="0" pn="section-3.3-1">In CMP, most communication is initiated by the EEs where every CMP
request triggers a CMP response message from the CA or RA.</t>
        <t indent="0" pn="section-3.3-2">The CMP announcement messages described in <xref target="sect-3.5" format="default" sectionFormat="of" derivedContent="Section 3.5"/> are an
exception.  Their creation may be triggered by certain events or done
on a regular basis by a CA.  The recipient of the announcement only
replies with an HTTP status code acknowledging the receipt or
indicating an error, but not with a CMP response.</t>
        <t indent="0" pn="section-3.3-3">If the receipt of an HTTP request is not confirmed by receiving an
HTTP response, it <bcp14>MUST</bcp14> be assumed that the transferred CMP message
was not successfully delivered to its destination.</t>
      </section>
      <section anchor="sect-3.4" numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-http-request-uri">HTTP Request-URI</name>
        <t indent="0" pn="section-3.4-1">Each CMP server on a PKI management entity supporting HTTP or HTTPS transfer
<bcp14>MUST</bcp14> support the use of the path prefix '/.well-known/' as defined in
<xref target="RFC8615" format="default" sectionFormat="of" derivedContent="RFC8615"/> and the registered name 'cmp' to ease interworking
in a multi-vendor environment.</t>
        <t indent="0" pn="section-3.4-2">CMP clients have to be configured with sufficient information to form
the CMP server URI.  This is at least the authority portion of the URI, e.g.,
'www.example.com:80', or the full operation path segment of the PKI management
entity. Additionally, path segments <bcp14>MAY</bcp14> be added after the registered
application name as part of the full operation path to provide further distinction.
The path segment 'p' followed by an arbitraryLabel &lt;name&gt; could, for example,
support the differentiation of specific CAs or certificate profiles. Further
path segments, e.g., as specified in the Lightweight CMP Profile <xref target="RFC9483" format="default" sectionFormat="of" derivedContent="RFC9483"/>,
could indicate PKI management operations using an operationLabel &lt;operation&gt;.
The following list shows examples of valid full CMP URIs:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.4-3">
          <li pn="section-3.4-3.1">http://www.example.com/.well-known/cmp</li>
          <li pn="section-3.4-3.2">http://www.example.com/.well-known/cmp/&lt;operation&gt;</li>
          <li pn="section-3.4-3.3">http://www.example.com/.well-known/cmp/p/&lt;name&gt;</li>
          <li pn="section-3.4-3.4">http://www.example.com/.well-known/cmp/p/&lt;name&gt;/&lt;operation&gt;</li>
        </ul>
        <t indent="0" pn="section-3.4-4">Note that https can also be used instead of http; see <xref target="sect-5" format="default" sectionFormat="of" derivedContent="Section 5">item 5 in the Security Considerations</xref>.</t>
      </section>
      <section anchor="sect-3.5" numbered="true" removeInRFC="false" toc="include" pn="section-3.5">
        <name slugifiedName="name-pushing-of-announcements">Pushing of Announcements</name>
        <t indent="0" pn="section-3.5-1">A CMP server may create event-triggered announcements or generate
them on a regular basis.  It <bcp14>MAY</bcp14> utilize HTTP transfer to convey them
to a suitable recipient.  In this use case, the CMP server acts as an
HTTP client, and the recipient needs to utilize an HTTP server.  As
no request messages are specified for those announcements, they can
only be pushed to the recipient.</t>
        <t indent="0" pn="section-3.5-2">If an EE wants to poll for a potential CA Key Update Announcement or
the current Certificate Revocation List (CRL), a PKI Information Request using a general message as
described in <xref section="D.5" sectionFormat="of" target="RFC9810" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9810#appendix-D.5" derivedContent="RFC9810"/> can be used.</t>
        <t indent="0" pn="section-3.5-3">When pushing announcement messages, PKIMessage structures <bcp14>MUST</bcp14> be sent as
the content of an HTTP POST request.</t>
        <t indent="0" pn="section-3.5-4">Suitable recipients for CMP announcements might, for example, be
repositories storing the announced information, such as directory
services.  Those services listen for incoming messages, utilizing the
same HTTP Request-URI scheme as defined in <xref target="sect-3.4" format="default" sectionFormat="of" derivedContent="Section 3.4"/>.</t>
        <t indent="0" pn="section-3.5-5">The following types of PKIMessage are announcements that may be pushed by a
CA.  The prefixed numbers reflect ASN.1 tags of the PKIBody structure (<xref section="5.1.2" sectionFormat="of" target="RFC9810" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9810#section-5.1.2" derivedContent="RFC9810"/>).</t>
        <artwork align="left" pn="section-3.5-6">
   [15] CA Key Update Announcement
   [16] Certificate Announcement
   [17] Revocation Announcement
   [18] CRL Announcement
</artwork>
        <t indent="0" pn="section-3.5-7">CMP announcement messages do not require any CMP response.  However,
the recipient <bcp14>MUST</bcp14> acknowledge receipt with an HTTP response having
an appropriate status code and empty content.  When not receiving
such a response, it <bcp14>MUST</bcp14> be assumed that the delivery was not
successful.  If applicable, the sending side <bcp14>MAY</bcp14> try sending the
announcement again after waiting for an appropriate time span.</t>
        <t indent="0" pn="section-3.5-8">If the announced issue was successfully stored in a database or was
already present, the answer <bcp14>MUST</bcp14> be an HTTP response with a 201 (Created)
status code and empty content.</t>
        <t indent="0" pn="section-3.5-9">In case the announced information was only accepted for further
processing, the status code of the returned HTTP response <bcp14>MAY</bcp14> also be
202 (Accepted).  After an appropriate delay, the sender may then try
to send the announcement again and may repeat this until it receives
a confirmation that it has been successfully processed.  The
appropriate duration of the delay and the option to increase it
between consecutive attempts should be carefully considered.</t>
        <t indent="0" pn="section-3.5-10">A receiver <bcp14>MUST</bcp14> answer with a suitable 4xx or 5xx error code
when a problem occurs.</t>
      </section>
    </section>
    <section anchor="sect-4" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-implementation-consideratio">Implementation Considerations</name>
      <t indent="0" pn="section-4-1">Implementers should be aware that other implementations might exist that
use a different approach for transferring CMP over HTTP.
Further, implementations based on earlier documents that led to
<xref target="RFC6712" format="default" sectionFormat="of" derivedContent="RFC6712"/> might use an unregistered "application/pkixcmp-poll" media type.
Conforming implementations <bcp14>MAY</bcp14> handle this type like "application/pkixcmp".</t>
    </section>
    <section anchor="sect-5" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">All security considerations in HTTP <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> apply.
The following items need to be considered by implementers and users:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5-2"><li pn="section-5-2.1" derivedCounter="1.">
          <t indent="0" pn="section-5-2.1.1">There is the risk for denial-of-service attacks through resource
  consumption by opening many connections to an HTTP server. Therefore,
  idle connections should be terminated after an appropriate timeout; this
  may also depend on the available free resources.</t>
        </li>
        <li pn="section-5-2.2" derivedCounter="2.">
          <t indent="0" pn="section-5-2.2.1">Without being encapsulated in effective security protocols, such
  as Transport Layer Security (TLS) <xref target="RFC5246" format="default" sectionFormat="of" derivedContent="RFC5246"/> <xref target="RFC8446" format="default" sectionFormat="of" derivedContent="RFC8446"/>, or
  without using HTTP digest <xref target="RFC9530" format="default" sectionFormat="of" derivedContent="RFC9530"/>, there is no
  integrity protection at the HTTP level.  Therefore,
  information from the HTTP should not be used to change
  state of the transaction, regardless of whether any mechanism was
  used to ensure the authenticity or integrity of HTTP messages
  (e.g., TLS or HTTP digests).</t>
        </li>
        <li pn="section-5-2.3" derivedCounter="3.">
          <t indent="0" pn="section-5-2.3.1">Client users should be aware that storing the target location of
  an HTTP response with the 301 (Moved Permanently) status code
  could be exploited by a meddler-in-the-middle attacker trying to
  block them permanently from contacting the correct server.</t>
        </li>
        <li pn="section-5-2.4" derivedCounter="4.">
          <t indent="0" pn="section-5-2.4.1">If no measures to authenticate and protect the HTTP responses to
  pushed announcement messages are in place, their information
  regarding the announcement's processing state may not be trusted.
  In that case, the overall design of the PKI system must not
  depend on the announcements being reliably received and processed
  by their destination.</t>
        </li>
        <li pn="section-5-2.5" derivedCounter="5.">
          <t indent="0" pn="section-5-2.5.1">CMP provides inbuilt integrity protection and authentication.
  The information communicated unencrypted in CMP messages does not
  contain sensitive information endangering the security of the PKI
  when intercepted.  However, it might be possible for an
  eavesdropper to utilize the available information to gather
  confidential personal, technical, or business-critical information.
  The protection of the confidentiality of CMP messages together with
  an initial authentication of the RA/CA before the first CMP message
  is transmitted ensures the privacy of the EE requesting
  certificates. Therefore, users of the HTTP transfer for CMP messages
  should consider using HTTP over TLS according to <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> or using virtual
  private networks created, for example, by utilizing Internet
  Protocol Security according to <xref target="RFC7296" format="default" sectionFormat="of" derivedContent="RFC7296"/>.</t>
        </li>
      </ol>
    </section>
    <section anchor="sect-6" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">IANA has made the following updates:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6-2">
        <li pn="section-6-2.1">the reference for "application/pkixcmp" in the "Media Types" registry <eref target="https://www.iana.org/assignments/media-types" brackets="angle"/> refers to this document, instead of <xref target="RFC2510" format="default" sectionFormat="of" derivedContent="RFC2510"/>.  </li>
        <li pn="section-6-2.2">the reference for "application/pkixcmp" in the "CoAP Content-Formats" registry <eref target="https://www.iana.org/assignments/core-parameters" brackets="angle"/> refers to this document, instead of <xref target="RFC4210" format="default" sectionFormat="of" derivedContent="RFC4210"/>. </li>
        <li pn="section-6-2.3">the reference for "cmp" in the "Well-Known URIs" registry <eref target="https://www.iana.org/assignments/well-known-uris/" brackets="angle"/> 
refers to this document instead of <xref target="RFC4210" format="default" sectionFormat="of" derivedContent="RFC4210"/>.</li>
        <li pn="section-6-2.4">the reference for "p" in the "CMP Well-Known URI Path Segments" registry <eref target="https://www.iana.org/assignments/cmp" brackets="angle"/> refers to this document instead of <xref target="RFC9480" format="default" sectionFormat="of" derivedContent="RFC9480"/>. </li>
      </ul>
      <t indent="0" pn="section-6-3">No further action by IANA is necessary for this document or any anticipated
updates.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references" pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="ITU.X690.2021" target="https://www.itu.int/rec/T-REC-X.690-202102-I/en" quoteTitle="true" derivedAnchor="ITU.X690.2021">
          <front>
            <title>Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization showOnFrontPage="true">ITU-T</organization>
            </author>
            <date year="2021"/>
          </front>
          <seriesInfo name="ITU-T Recommendation" value="X.690"/>
        </reference>
        <reference anchor="RFC1945" target="https://www.rfc-editor.org/info/rfc1945" quoteTitle="true" derivedAnchor="RFC1945">
          <front>
            <title>Hypertext Transfer Protocol -- HTTP/1.0</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="H. Frystyk" initials="H." surname="Frystyk"/>
            <date month="May" year="1996"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1945"/>
          <seriesInfo name="DOI" value="10.17487/RFC1945"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <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 fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8615" target="https://www.rfc-editor.org/info/rfc8615" quoteTitle="true" derivedAnchor="RFC8615">
          <front>
            <title>Well-Known Uniform Resource Identifiers (URIs)</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="May" year="2019"/>
            <abstract>
              <t indent="0">This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8615"/>
          <seriesInfo name="DOI" value="10.17487/RFC8615"/>
        </reference>
        <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="RFC9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
        <reference anchor="RFC9112" target="https://www.rfc-editor.org/info/rfc9112" quoteTitle="true" derivedAnchor="RFC9112">
          <front>
            <title>HTTP/1.1</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.</t>
              <t indent="0">This document obsoletes portions of RFC 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference>
        <reference anchor="RFC9810" target="https://www.rfc-editor.org/info/rfc9810" quoteTitle="true" derivedAnchor="RFC9810">
          <front>
            <title>Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)</title>
            <author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
              <organization showOnFrontPage="true">Siemens</organization>
            </author>
            <author fullname="David von Oheimb" initials="D." surname="von Oheimb">
              <organization showOnFrontPage="true">Siemens</organization>
            </author>
            <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
              <organization showOnFrontPage="true">Entrust</organization>
            </author>
            <author fullname="John Gray" initials="J." surname="Gray">
              <organization showOnFrontPage="true">Entrust</organization>
            </author>
            <date month="July" year="2025"/>
          </front>
          <seriesInfo name="RFC" value="9810"/>
          <seriesInfo name="DOI" value="10.17487/RFC9810"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <referencegroup anchor="BCP56" target="https://www.rfc-editor.org/info/bcp56" derivedAnchor="BCP56">
          <reference anchor="RFC9205" target="https://www.rfc-editor.org/info/rfc9205" quoteTitle="true">
            <front>
              <title>Building Protocols with HTTP</title>
              <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
              <date month="June" year="2022"/>
              <abstract>
                <t indent="0">Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations.</t>
                <t indent="0">This document obsoletes RFC 3205.</t>
              </abstract>
            </front>
            <seriesInfo name="BCP" value="56"/>
            <seriesInfo name="RFC" value="9205"/>
            <seriesInfo name="DOI" value="10.17487/RFC9205"/>
          </reference>
        </referencegroup>
        <reference anchor="RFC2510" target="https://www.rfc-editor.org/info/rfc2510" quoteTitle="true" derivedAnchor="RFC2510">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate Management Protocols</title>
            <author fullname="C. Adams" initials="C." surname="Adams"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <date month="March" year="1999"/>
            <abstract>
              <t indent="0">This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2510"/>
          <seriesInfo name="DOI" value="10.17487/RFC2510"/>
        </reference>
        <reference anchor="RFC4210" target="https://www.rfc-editor.org/info/rfc4210" quoteTitle="true" derivedAnchor="RFC4210">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)</title>
            <author fullname="C. Adams" initials="C." surname="Adams"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="T. Kause" initials="T." surname="Kause"/>
            <author fullname="T. Mononen" initials="T." surname="Mononen"/>
            <date month="September" year="2005"/>
            <abstract>
              <t indent="0">This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4210"/>
          <seriesInfo name="DOI" value="10.17487/RFC4210"/>
        </reference>
        <reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246" quoteTitle="true" derivedAnchor="RFC5246">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
            <author fullname="T. Dierks" initials="T." surname="Dierks"/>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2008"/>
            <abstract>
              <t indent="0">This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5246"/>
          <seriesInfo name="DOI" value="10.17487/RFC5246"/>
        </reference>
        <reference anchor="RFC6712" target="https://www.rfc-editor.org/info/rfc6712" quoteTitle="true" derivedAnchor="RFC6712">
          <front>
            <title>Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)</title>
            <author fullname="T. Kause" initials="T." surname="Kause"/>
            <author fullname="M. Peylo" initials="M." surname="Peylo"/>
            <date month="September" year="2012"/>
            <abstract>
              <t indent="0">This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6712"/>
          <seriesInfo name="DOI" value="10.17487/RFC6712"/>
        </reference>
        <reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc7296" quoteTitle="true" derivedAnchor="RFC7296">
          <front>
            <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author fullname="C. Kaufman" initials="C." surname="Kaufman"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="Y. Nir" initials="Y." surname="Nir"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
            <date month="October" year="2014"/>
            <abstract>
              <t indent="0">This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="79"/>
          <seriesInfo name="RFC" value="7296"/>
          <seriesInfo name="DOI" value="10.17487/RFC7296"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t indent="0">This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC9293" target="https://www.rfc-editor.org/info/rfc9293" quoteTitle="true" derivedAnchor="RFC9293">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
        <reference anchor="RFC9480" target="https://www.rfc-editor.org/info/rfc9480" quoteTitle="true" derivedAnchor="RFC9480">
          <front>
            <title>Certificate Management Protocol (CMP) Updates</title>
            <author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/>
            <author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/>
            <author fullname="J. Gray" initials="J." surname="Gray"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">This document contains a set of updates to the syntax of Certificate Management Protocol (CMP) version 2 and its HTTP transfer mechanism. This document updates RFCs 4210, 5912, and 6712.</t>
              <t indent="0">The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments.</t>
              <t indent="0">CMP version 3 is introduced to enable signaling support of EnvelopedData instead of EncryptedValue and signal the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9480"/>
          <seriesInfo name="DOI" value="10.17487/RFC9480"/>
        </reference>
        <reference anchor="RFC9483" target="https://www.rfc-editor.org/info/rfc9483" quoteTitle="true" derivedAnchor="RFC9483">
          <front>
            <title>Lightweight Certificate Management Protocol (CMP) Profile</title>
            <author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/>
            <author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/>
            <author fullname="S. Fries" initials="S." surname="Fries"/>
            <date month="November" year="2023"/>
            <abstract>
              <t indent="0">This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9483"/>
          <seriesInfo name="DOI" value="10.17487/RFC9483"/>
        </reference>
        <reference anchor="RFC9530" target="https://www.rfc-editor.org/info/rfc9530" quoteTitle="true" derivedAnchor="RFC9530">
          <front>
            <title>Digest Fields</title>
            <author fullname="R. Polli" initials="R." surname="Polli"/>
            <author fullname="L. Pardue" initials="L." surname="Pardue"/>
            <date month="February" year="2024"/>
            <abstract>
              <t indent="0">This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields.</t>
              <t indent="0">This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9530"/>
          <seriesInfo name="DOI" value="10.17487/RFC9530"/>
        </reference>
      </references>
    </references>
    <section anchor="sect-7" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors wish to thank <contact fullname="Tomi Kause"/> and <contact fullname="Martin Peylo"/>, the
original authors of <xref target="RFC6712" format="default" sectionFormat="of" derivedContent="RFC6712"/>, for their work.</t>
      <t indent="0" pn="section-appendix.a-2">We also thank all reviewers for their valuable feedback.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
        <organization abbrev="Siemens" showOnFrontPage="true">Siemens</organization>
        <address>
          <postal>
            <street>Werner-von-Siemens-Strasse 1</street>
            <city>Munich</city>
            <code>80333</code>
            <country>Germany</country>
          </postal>
          <email>hendrik.brockhaus@siemens.com</email>
          <uri>https://www.siemens.com</uri>
        </address>
      </author>
      <author initials="D." surname="von Oheimb" fullname="David von Oheimb">
        <organization abbrev="Siemens" showOnFrontPage="true">Siemens</organization>
        <address>
          <postal>
            <street>Werner-von-Siemens-Strasse 1</street>
            <city>Munich</city>
            <code>80333</code>
            <country>Germany</country>
          </postal>
          <email>david.von.oheimb@siemens.com</email>
          <uri>https://www.siemens.com</uri>
        </address>
      </author>
      <author initials="M." surname="Ounsworth" fullname="Mike Ounsworth">
        <organization abbrev="Entrust" showOnFrontPage="true">Entrust</organization>
        <address>
          <postal>
            <street>1187 Park Place</street>
            <city>Minneapolis</city>
            <region>MN</region>
            <code>55379</code>
            <country>United States of America</country>
          </postal>
          <email>mike.ounsworth@entrust.com</email>
          <uri>https://www.entrust.com</uri>
        </address>
      </author>
      <author initials="J." surname="Gray" fullname="John Gray">
        <organization abbrev="Entrust" showOnFrontPage="true">Entrust</organization>
        <address>
          <postal>
            <street>1187 Park Place</street>
            <city>Minneapolis</city>
            <region>MN</region>
            <code>55379</code>
            <country>United States of America</country>
          </postal>
          <email>john.gray@entrust.com</email>
          <uri>https://www.entrust.com</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
