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

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lamps-rfc6712bis-10" number="9811" category="std" consensus="true" submissionType="IETF" xml:lang="en" obsoletes="6712 updates="" obsoletes="6712, 9480" tocDepth="4" tocInclude="true" sortRefs="false" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.25.0 -->

  <front>
    <title abbrev="HTTP Transfer for CMP">Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc6712bis-10"/> name="RFC" value="9811"/>
    <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
      <organization abbrev="Siemens">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">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">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">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 year="2025"/>
    <area>sec</area>
    <workgroup>LAMPS Working Group</workgroup> year="2025" month="July"/>
    <area>SEC</area>
    <workgroup>lamps</workgroup>

    <keyword>CMP</keyword>
    <keyword>HTTP</keyword>
    <keyword>Certificate management</keyword>
    <keyword>PKI</keyword>

    <abstract>
      <?line 88?>
<t>This document describes how to layer the Certificate Management Protocol
(CMP) over HTTP.</t>
      <t>It includes the updates to RFC 6712 specified in RFC 9480 Section 3. These 3 of RFC 9480; these
updates introduce CMP URIs using a Well-known well-known prefix. It obsoletes
RFC 6712 and 6712; and, together with I-D.ietf-lamps-rfc4210bis and RFC 9810, it also obsoletes
RFC 9480.</t>
    </abstract>
  </front>
  <middle>
    <?line 99?>

<section anchor="sect-1">
      <name>Introduction</name>
      <t>[RFC Editor: please delete:</t>
      <t>During IESG telechat the CMP Updates document was approved on condition that
LAMPS provides a RFC6712bis document.  Version -00 of this document shall
be identical to RFC 6712 and version -01 incorporates the changes specified
in CMP Updates Section 3.</t>
      <t>A history of changes is available in Appendix A of this document.</t>
      <t>The authors of this document wish to thank Tomi Kause and Martin Peylo, the
original authors of RFC 6712, for their work and invite them, next to further
volunteers, to join the -bis activity as co-authors.</t>
      <t>]</t>
      <t>The Certificate Management Protocol (CMP) <xref target="I-D.ietf-lamps-rfc4210bis"/> target="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>
<!-- [rfced] We have updated "E-mail-" to "email-", even though RFC 2510 refers to "(file based, on-line, E-mail, and WWW)".  Please let us know if you have concerns.

Original:
   Additionally, it was mentioned
   that PKI messages could also be conveyed using file-, E-mail-, and
   HTTP-based transfer, but those were not specified in detail.
-->
      <t>The first version of the CMP specification <xref target="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-, E-mail-, email-, and
HTTP-based transfer, but those were not specified in detail.</t>
      <t>Since the second version of the CMP specification <xref target="RFC4210"/> incorporated
its own polling mechanism and thus 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>CMP can benefit from utilizing reliable transport transport, as CMP 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"/> extends the polling
mechanism specified in the second version of <xref target="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>The usage of HTTP (e.g., HTTP/1.1 as specified in <xref target="RFC9110"/> and <xref target="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="RFC9205">BCP 56</xref> target="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 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>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>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">
        <name>Changes Made by RFC 9480</name>
        <t><xref target="RFC9480">CMP Updates</xref> updated <xref section="3.6" sectionFormat="of" target="RFC6712"/>, supporting the PKI
management operations specified in the <xref target="RFC9483">Lightweight CMP Profile</xref>, in the following areas:</t>
        <ul spacing="normal">
          <li>
            <t>Introduce
            <t>Introduced the HTTP URI path prefix '/.well-known/cmp'.</t>
          </li>
          <li>
            <t>Add
            <t>Added options for extending the URI structure with further segments and
define
defined a new protocol registry group to that aim.</t>
          </li>
        </ul>
      </section>
      <section anchor="sect-1.2">
        <name>Changes Made by This Document</name>
        <t>This document obsoletes <xref target="RFC6712"/>.
It includes the changes specified in <xref section="3" sectionFormat="of" target="RFC9480"/> target="RFC9480"/>, as
described in <xref target="sect-1.1"/> of this document. Additionally, it adds the following changes:</t>
        <ul spacing="normal">
          <li>
            <t>Removed the requirement to support HTTP/1.0 <xref target="RFC1945"/> in accordance with <xref section="4.1" sectionFormat="of" target="RFC9205"/>.</t>
          </li>
          <li>
            <t>Implementations <bcp14>MUST</bcp14> forward CMP messages when an HTTP error status code occurs, occurs; see  <xref target="sect-3.1"/>.</t>
          </li>
          <li>
            <t>Removed <xref section="3.8" sectionFormat="of" target="RFC6712"/> as it contains information redundant with current HTTP specification.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="sect-2">
      <name>Conventions Used in This Document</name>
      <t>The
        <t>
    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 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>
      <?line -18?> here.
        </t>
    </section>
    <section anchor="sect-3">
      <name>HTTP-Based Protocol</name>
      <t>For direct interaction between two entities, where a reliable
transport protocol like TCP <xref target="RFC9293"/> is available, HTTP <xref target="RFC9110"/> <bcp14>SHOULD</bcp14> be
utilized for conveying CMP messages. This specification requires
using the POST method (Section 3.1) (<xref target="sect-3.1"/>) and the "Content-Type" header
field (Section 3.2), (<xref target="sect-3.2"/>), which are available since HTTP/1.0 <xref target="RFC1945"/>.</t>
      <t>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 Section 5.1.1 of <xref target="I-D.ietf-lamps-rfc4210bis"/>). target="RFC9810" sectionFormat="of" section="5.1.1"/>).
For details on how to transfer multiple requests requests, see
Section 4.11 of
<xref target="RFC9205"/>.</t> target="RFC9205" sectionFormat="of" section="4.11"/>.</t>
      <section anchor="sect-3.1">
        <name>General Form</name>
        <t>A DER-encoded <xref target="ITU.X690.1994"/> PKIMessage (<xref section="5.1" sectionFormat="of" target="I-D.ietf-lamps-rfc4210bis"/>) target="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) status code; (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"/>
utilize the status codes 201 and 202 to identify whether the received
information was processed.</t>
        <t>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"/>, the 301 (Moved Permanently) status code
could be misused for permanent denial of service.</t>
        <t>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">
        <name>Media Type</name>
        <t>The Internet Media Type 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">
        <name>Communication Workflow</name>
        <t>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>The CMP announcement messages described in <xref target="sect-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>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">
        <name>HTTP Request-URI</name>
        <t>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"/> and the registered name 'cmp' to ease interworking
in a multi-vendor environment.</t>
        <t>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"/>,
could indicate PKI management operations using an operationLabel &lt;operation&gt;.
The following list shows examples of valid full CMP URIs:</t>
        <ul empty="true">
          <li>
            <t>http://www.example.com/.well-known/cmp</t>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <t>http://www.example.com/.well-known/cmp/&lt;operation&gt;</t>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <t>http://www.example.com/.well-known/cmp/p/&lt;name&gt;</t>
          </li>
        </ul>
        <ul empty="true">
          <li>
            <t>http://www.example.com/.well-known/cmp/p/&lt;name&gt;/&lt;operation&gt;</t>
          </li> spacing="normal">
          <li>http://www.example.com/.well-known/cmp</li>
          <li>http://www.example.com/.well-known/cmp/&lt;operation&gt;</li>
          <li>http://www.example.com/.well-known/cmp/p/&lt;name&gt;</li>
          <li>http://www.example.com/.well-known/cmp/p/&lt;name&gt;/&lt;operation&gt;</li>
        </ul>
        <t>Note that https can also be used instead of http, http; see <xref target="sect-5">item 5 in the Security Considerations</xref>.</t>
      </section>
      <section anchor="sect-3.5">
        <name>Pushing of Announcements</name>
        <t>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>If an EE wants to poll for a potential CA Key Update Announcement or
the current CRL, Certificate Revocation List (CRL), a PKI Information Request using a General Message general message as
described in <xref section="D.5" sectionFormat="of" target="I-D.ietf-lamps-rfc4210bis"/> target="RFC9810"/> can be used.</t>
        <t>When pushing announcement messages, PKIMessage structures <bcp14>MUST</bcp14> be sent as
the content of an HTTP POST request.</t>
        <t>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"/>.</t>
        <t>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="I-D.ietf-lamps-rfc4210bis"/>).</t> target="RFC9810"/>).</t>
        <artwork><![CDATA[
   [15] CA Key Update Announcement
   [16] Certificate Announcement
   [17] Revocation Announcement
   [18] CRL Announcement
]]></artwork>
        <t>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 an 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>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 an empty content.</t>
        <t>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>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">
      <name>Implementation Considerations</name>
      <t>Implementers should be aware that other implementations might exist that
use a different approach for transferring CMP over HTTP.
Further, implementations based on earlier I-Ds documents that led to
<xref target="RFC6712"/> might use an unregistered "application/pkixcmp-poll" Media Type. media type.
Conforming implementations <bcp14>MAY</bcp14> handle this type like "application/pkixcmp".</t>
    </section>
    <section anchor="sect-5">
      <name>Security Considerations</name>
      <t>All security considerations in HTTP <xref target="RFC9110"/> apply.
The following items need to be considered by implementers and users:</t>
      <ol spacing="normal" type="1"><li>
          <t>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>
          <t>Without being encapsulated in effective security protocols, such
  as Transport Layer Security (TLS) <xref target="RFC5246"/> or <xref target="RFC8446"/>, or
  without using HTTP digest <xref target="RFC9530"/> target="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>
          <t>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>
          <t>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>
          <t>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 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"/> or using virtual
  private networks created, for example, by utilizing Internet
  Protocol Security according to <xref target="RFC7296"/>.</t>
        </li>
      </ol>
    </section>
    <section anchor="sect-6">
      <name>IANA Considerations</name>
      <t>The
      <t>IANA has made the following updates:</t>
<ul>
<li>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"/> at https://www.iana.org/assignments/media-types/media-types.xhtml should be replaced with a target="RFC2510"/>.  </li>
      <li>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.</t>
      <t>The reference to document, instead of <xref target="RFC4210"/> at https://www.iana.org/assignments/core-parameters/core-parameters.xhtml should be replaced with a target="RFC4210"/>. </li>
      <li>the reference for "cmp" in the "Well-Known URIs" registry <eref target="https://www.iana.org/assignments/core-parameters" brackets="angle"/>
refers to this document.</t>
      <t>The reference to document instead of <xref target="RFC9480"/> at https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml and https://www.iana.org/assignments/cmp/cmp.xhtmlshould should be replaced with a target="RFC4210"/>.</li>
      <li>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.</t> document instead of <xref target="RFC9480"/>. </li>
</ul>

      <t>No further action by the IANA is necessary for this document or any anticipated
updates.</t>
    </section>
    <section anchor="sect-7">
      <name>Acknowledgments</name>
      <t>The authors wish to thank Tomi Kause and Martin Peylo, the
original authors of <xref target="RFC6712"/>, for their work.</t>
      <t>We also thank all reviewers for their valuable feedback.</t>
    </section>
  </middle>
  <back>

<!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="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>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="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>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
              <t>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">
          <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>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>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">
          <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>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>This document obsoletes portions of
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1945.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9112.xml"/>

<!-- draft-ietf-lamps-rfc4210bis-18 companion doc RFC 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference> 9810 -->
<reference anchor="I-D.ietf-lamps-rfc4210bis"> anchor="RFC9810" target="https://www.rfc-editor.org/info/rfc9810">
  <front>
    <title>Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)</title>
    <author fullname="Hendrik Brockhaus" initials="H." surname="Brockhaus">
      <organization>Siemens</organization>
    </author>
    <author fullname="David von Oheimb" initials="D." surname="von Oheimb">
      <organization>Siemens</organization>
    </author>
    <author fullname="Mike Ounsworth" initials="M." surname="Ounsworth">
      <organization>Entrust</organization>
    </author>
    <author fullname="John Gray" initials="J." surname="Gray">
      <organization>Entrust</organization>
    </author>
    <date day="18" month="November" year="2024"/>
            <abstract>
              <t>   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 interactions between client systems and PKI components such
   as a Registration Authority (RA) and a Certification Authority (CA).

   This document adds support for management of KEM certificates and use
   EnvelopedData instead of EncryptedValue.  This document also includes
   the updates specified in Section 2 and Appendix A.2 of RFC 9480. month="July" year="2025"/>
  </front>
  <seriesInfo name="RFC" value="9810"/>
  <seriesInfo name="DOI" value="10.17487/RFC9810"/>
</reference>

<!-- [rfced] The updates maintain backward compatibility with CMP version 2
   wherever possible.  Updates to CMP 1994 version 2 are improving crypto
   agility, extending of ITU-T Recommendation X.690
(https://www.itu.int/rec/T-REC-X.690-199407-S/en) has been superseded
by the polling mechanism, adding new general message
   types, and adding extended key usages to identify special CMP server
   authorizations.  CMP version 3 is introduced for changes published in February 2021
(https://www.itu.int/rec/T-REC-X.690-202102-I/en). May we update this
reference to use the most current version?

Current:
   [ITU.X690.1994]
              International Telecommunications Union, "Information
              Technology - ASN.1
   syntax, which are support encoding rules: Specification of EnvelopedData, certConf with hashAlg,
   POPOPrivKey with agreeMAC, and RootCaKeyUpdateContent in ckuann
   messages.

   This document obsoletes RFC 4210 and together with I-D.ietf-lamps-
   rfc6712bis Basic
              Encoding Rules (BER), Canonical Encoding Rules (CER) and it also obsoletes RFC 9480.  Appendix F
              Distinguished Encoding Rules (DER)", ITU-T Recommendation
              X.690, 1994.

Perhaps:
   [ITU.X690.2021]
              ITU-T, "Information Technology - ASN.1 encoding rules:
              Specification of this
   document updates the Section 9 Basic Encoding Rules (BER), Canonical Encoding
              Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T
	      Recommendation X.690, 2021,
	      <https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
-->

<!-- XML for most recent version of RFC 5912.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc4210bis-15"/>
        </reference> [ITU.X690.1994] with
     updated cite tag.

        <reference anchor="ITU.X690.1994"> anchor="ITU.X690.2021" target="https://www.itu.int/rec/T-REC-X.690-202102-I/en">
          <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>International Telecommunications Union</organization>
              <organization>ITU-T</organization>
            </author>
            <date year="1994"/> year="2021"/>
          </front>
          <seriesInfo name="ITU-T" value="Recommendation X.690"/>
        </reference>
        <reference anchor="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>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"/> name="ITU-T Recommendation" value="X.690"/>
        </reference>
-->

        <reference anchor="RFC8174"> anchor="ITU.X690.1994" target="https://www.itu.int/rec/T-REC-X.690-199407-S/en">
          <front>
            <title>Ambiguity
            <title>Information Technology - ASN.1 encoding rules:
            Specification of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/> Basic Encoding Rules (BER), Canonical Encoding
            Rules (CER) and Distinguished Encoding Rules (DER)</title>
            <author>
              <organization>ITU-T</organization>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>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> year="1994"/>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/> name="ITU-T Recommendation" value="X.690"/>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="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>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>The aspects of CMP

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9480.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9483.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2510.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6712.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9530.xml"/>

<!--[rfced] FYI, We have 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 reference entry to identify certificates for use RFC 9205 with CMP, and well-known URI path segments.</t>
              <t>CMP version 3 is introduced to enable signaling support of EnvelopedData instead of EncryptedValue and signal
one for BCP 56 since 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">
          <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>This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios. This BCP 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) mentioned 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="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>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">
          <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>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) text. Please review
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">
          <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>This document specifies Version 1.2 let us know 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">
          <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>This document describes how any objections.
-->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.56.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>

      </references>
    </references>
    <section anchor="sect-7" numbered="false">
      <name>Acknowledgements</name>
      <t>The authors wish 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">
          <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>This document describes version 2 of thank <contact fullname="Tomi Kause"/> and <contact fullname="Martin Peylo"/>, the Internet Key Exchange (IKE) protocol. IKE is a component
original authors of IPsec used <xref target="RFC6712"/>, for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes their work.</t>
      <t>We also thank all of the errata reviewers for it. It advances IKEv2 to be their valuable feedback.</t>
    </section>
  </back>

<!-- [rfced] FYI - We have added 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">
          <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>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>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="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>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>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>
        <reference anchor="RFC9205">
          <front>
            <title>Building Protocols with HTTP</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="June" year="2022"/>
            <abstract>
              <t>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 expansion for deployment on the Internet but might be applicable in other situations.</t>
              <t>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>
        <reference anchor="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>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 following abbreviation
per Section 3.6 of changes have been made to TCP as it was specified in RFC 793, though these have only been documented 7322 ("RFC Style Guide"). Please review each
expansion 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>
      </references>
    </references>
    <?line 446?>

<section anchor="History">
      <name>History of Changes</name>
      <t>Note: This appendix will be deleted in the final version of the document.</t>
      <t>From version 09 -&gt; 10:</t>
      <ul spacing="normal">
        <li>
          <t>Addressed IESG review comments from Mahesh Jethanandani and responded carefully to comments from Orie Steele and Zaheduzzaman Sarker via email</t>
        </li>
      </ul>
      <t>From version 08 -&gt; 09:</t>
      <ul spacing="normal">
        <li>
          <t>Incorporated relevant text from former Sections 3.1 and 3.2 in ensure correctness.

 Certificate Revocation List (CRL)
-->

<!-- [rfced] Please review the introduction "Inclusive Language" portion of Section 3 as proposed by HTTPDIR review</t>
        </li>
        <li>
          <t>Added reference to HTTP Security Considerations to Section 5 and updated the first item as proposed by HTTPDIR review</t>
        </li>
      </ul>
      <t>From version 07 -&gt; 08:</t>
      <ul spacing="normal">
        <li>
          <t>Addressed HTTPDIR, SECDIR, OPSDIR and ARTART review comments</t>
        </li>
        <li>
          <t>Aligned the terminology with https://httpwg.org/admin/editors/style-guide</t>
        </li>
        <li>
          <t>Implemented editorial online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes proposed by OPSDIR reviewer</t>
        </li>
        <li>
          <t>Removed requirement to support HTTP/1.0</t>
        </li>
        <li>
          <t>Added normative language are needed.  Updates of this nature typically
result in Sections 3.3 and 3.7 more precise language, which is helpful for clarity</t>
        </li>
        <li>
          <t>Added the requirement to provide readers.

Note that our script did not flag any HTTP response message content to the application</t>
        </li>
        <li>
          <t>Removed the paragraph on the "Content-Length" header field and Section 3.8 to reduce redundancy with current versions HTTP/1.1</t>
        </li>
      </ul>
      <t>From version 06 -&gt; 07:</t>
      <ul spacing="normal">
        <li>
          <t>Updated the the page header to 'HTTP Transfer for CMP'</t>
        </li>
        <li>
          <t>Removed one instruction to RFC Editors</t>
        </li>
        <li>
          <t>Deprecated PKIMessages as plural of PKIMessage to prevent confusion with ASN.1 type PKIMessages</t>
        </li>
        <li>
          <t>Fixed some nits in Section 1</t>
        </li>
        <li>
          <t>Aligned Section 3.6 and Section 5 with RFC 9483 and draft-ietf-anima-brski-ae</t>
        </li>
      </ul>
      <t>From version 05 -&gt; 06:</t>
      <ul spacing="normal">
        <li>
          <t>Updates IANA considerations addressing IANA early review (see thread "[IANA #1368693] Early review: draft-ietf-lamps-rfc4210bis-12 (IETF 120)").</t>
        </li>
      </ul>
      <t>From version 04 -&gt; 05:</t>
      <ul spacing="normal">
        <li>
          <t>Added IANA considerations addressing IANA early review.</t>
        </li>
      </ul>
      <t>From version 03 -&gt; 04:</t>
      <ul spacing="normal">
        <li>
          <t>Aligned with released RFC 9480 - RFC 9483.</t>
        </li>
      </ul>
      <t>From version 02 -&gt; 03:</t>
      <ul spacing="normal">
        <li>
          <t>Fixing one formatting nit.</t>
        </li>
      </ul>
      <t>From version 01 -&gt; 02:</t>
      <ul spacing="normal">
        <li>
          <t>Updated Section 3.4 including the requirement to add the content-length filed
into the HTTP header.</t>
        </li>
        <li>
          <t>Added a reference to TLS 1.3.</t>
        </li>
        <li>
          <t>Addressed idnits feedback, specifically changing the following RFC references:
RFC2616 -&gt; RFC9112; RFC2818 -&gt; RFC9110, and RFC5246 -&gt; RFC8446</t>
        </li>
      </ul>
      <t>From version 00 -&gt; 01:</t>
      <ul spacing="normal">
        <li>
          <t>Performed all updates specified words in CMP Updates Section 3.</t>
        </li>
      </ul>
      <t>Version 00:</t>
      <t>This version consists of the text of RFC6712 with the following changes:</t>
      <ul spacing="normal">
        <li>
          <t>Introduced the authors of particular, but this document and thanked the authors of RFC6712
for their work.</t>
        </li>
        <li>
          <t>Added should
still be reviewed as a paragraph to the introduction explaining the background of this document.</t>
        </li>
        <li>
          <t>Added the change history to this appendix.</t>
        </li>
      </ul>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81c63Ybx5H+30/RS/2gmANABC8SyWSd0BRtMxYlLknFyWr1
ozHTACYazCBzIYVotc+yz7JPtvVVdff0AJCt+OyeEx/bBObSXV1VXfXVpTEc
DtXDmT5U2bI6003V1s3B/v7p/oFKy6QwC3um08pMm2Fmm+kwN4tlPaymyfMX
44NJVg/H+yoxzZmum1SVk7rMbWPrM72L+/r06GR/VyVlUduibnGZxre7qm4n
i6yus7JoVkua4Ory/juVm2J2pm2hltmZ0ropk/A8f0vtspnTpSN8r1eLyk7r
6Im6rBp3aWrymq41WZPT4N/QzauisVVhG/3n0fH+qb5pJ3mW6B/tiu5MK1PT
IEnTVlYTM7T+4f7+Rt9XpqinttLTstLN3OoLWzXZNKPVWn1tCjOzC1s0+qYq
ibgy108vrm/2lJlMKkv83ByDbitTWUO8sol6pLW+Or++udM/ldWHrJjp76uy
XaoPdvVYVumZGvILQx4IX6LZF2F2unHz45WaZc28nZzpHRHP4+xZslgO22VK
T9c7xFn6QzLamTfNsj579sw/NpIXR1kZv/DsZ+Q9mjeLfEfhuTN9sH9wrEzb
zMsK9Iqy/GCLtMo+6G+rMvkwN21NDC0rWu1dBpLx1fOou0ICsJYo/AlSqoYP
ZTF0N4d3DcmntnpMjyVlSjPsnuwfHh5C5knWrM70dVtkyZxvt0VT0ZXvbUU8
WtEluzBZfqbnQtRo4on6Qy3Dj5JyQY+1VUYPOe48Pj6O4tt+ZS/NQ5bq/9RE
nX4zt9li8s+wtBRUjWjYUck0/ZqVXWcfrH7TFjWpXjP3q7os2BpEq+qu+FWN
xycv9I2pPuib3CSW7lR2Rvuaxnzdrer4+PDFabSqrCisWZZ5VsdLe1tkjU31
XQMl1OVUny9sRRrfrXVBdI5KT+cfrJDzpZXGt/1K/1jOC9ppZvXPu8i/Eomj
GZH4j6wvK8jELEyTPVgYz9vvLmB7u4+H7uPB8dhfPToIH48Pjp67j9jn7uOL
g1N/9eQoPHB6fBjGPdg/Dh9PaYpijYbx6ZF/4OT5ODw7DhPTR57tavhy1Lc3
oI7sDd+8fzv68/PT/dH49PToTKnhcEjCIuGYpFFK3c+zWpOvatkcp7ZOqmxC
vJ2Xj+Q2dG5W9qsMuGIDrssHehxGd6TUVaOzIslbGpRHcAYSwxLxmn1cvbQJ
jUoyzQq+CsbrO5s0pCH6cKTv57a2yr+akdDKtE0szLt+e3tV67aG+TdkIfJ8
+KEoHwu9JE+WfRxpIiA4VRWmNEVKJMwskVTpRzLhX+YfP5s1mjxiuTYU6BwJ
NxdZmuZWqSdwlEweE//pCXmqZjj+rNQ7vHGZZg2Zer3MrSGzlVoMRgJ5SapJ
K7i6vPteN3QxmZtGOI4luoUHCT0aomq5rIjRqaZZCB7QuJivofeUOEXczsB2
45VyEkl5pPWfbAX8oIf7+9hFTU8J6rnJczWxmoYoGpJ43hMZePIQ3h9DxmW1
LCuRLdFNCyhm9DnIlvZXbzGdeJU61zQ38WUFOvyb4PwDbWczyS0U43y5JBeU
fdTnG9SOoMJWix+tNxfzmNVzkE/cKT7o+3KR6R/Jg1lexrUhnS70jV3l5QC0
q7LKZllBK44G9CsfeDCTkd4Q7BDtKB7IJOHqYqAL+7HBZNO2gnaphzInw2WJ
WQNc/muZFcyhIesWMYHeXWmSaFIO3YS0nveypK9CTPrTpy9q7+fPZGn/1mYV
K8Ij9kdKG6MggTQeWi2gbkVWL0CfLZjhl7QsMuOkVfTi08vLem+gb8lkw2ZA
buqcSXX3b89xH6zoCIZwew9d0EOYYUkeWxHmurZ1TQvSATrWemKbR2uZPwsn
1GlW1U3QNRat7AqnWW6mT5+caaYFO4OT0oInVWanSizasnEjGF1nC9qBOnBg
6fkppg4bqVzi0fuLG9opV02tptYIjY+WQO7aAMPcPthc26oi5SBepjnbowIk
xNxV5Mxy1qCybeqGHsBzxAt6iplR02znqWxm2oCrASwPtjvETtcgNpiG+BV4
xjwV+0QblozBg13R6sUoTrPcDgf6cgjXOGQhKdjm4YQMUBpWMNCTFhanpF3B
KyzKpm+YU9vQCCSVO+IvKztQeBkZgp8XDhRShOMtBdmEhjYXjDWxBcR2vGID
PW/FmBSWSADXzKbIlNg5vM2bftoWiXAP2+oBo81tSmyFMlUACAWzxYsTIULY
IdOqXGgQtTEN7Z6KeVs4uwUCWd7Ky5tYg6UnpiAxFLTJGhmvbbI8+zsmrWye
8e7i4YkJDfY9XgoUbJshaJTi8cCRDfpG+pw0q4Gj7NYmJJN4iH2TlbjkNf2i
vQGdT+GKCHWICRaKiECKOjs1W5gV9IuJweZqOipY/QfEx5mp6GZde11wL2NZ
DWkw1FvUh1UC/pNUggwmWXYRtdME1WlCTwm3a907Ivj90ydOydjI8LKVAU8o
PmZ6eM90NpSJN8xqsszMhhpKTtyX1ZGHzZ0GK9nf4IDfZp4NAA/i2gZux2EJ
t/ZvLD/5vOy2txi1lplCNHGM+9SOZqMBf342Ho2hE71FC6/GvH0wqP9+8Pnz
nrgjJwfGEBBekJn9SKawJsHmK5rU+eabN3f3xGDa7LKroHwU3RIX7HQK5ePH
m5Y0MfcjdphO/zTPoMLYbATMZ6TqFVQJMq4JLbCyGVo6wGVGon5aW6vffXtx
o4+fi5SAeoVyQpmNTtqqQiQe3iCpTtos503dbUCGaSBhj7lQz9nswU6ROOyi
RYyesgevLNIEelbSAisCWkQYdCItNcluG8NGLmORAUqSXSIJ0O6lb93qaJjV
sCmHbPhZgRwuhBfnPV1iWGilVQX5MYCDSVkRQ+rIBLSTjHZ6U5Jlo5V9zNji
X5fEBRqYDIIpGlh9Tllg5JzoT8HbxaIsRIisE/YjuWIvnEATKytGfMPAlkdx
0tUicBJy3SZz6Nj3l/cDNhFgIY87sQnDov5OUeXSitOv2bgxHRPYoGw2Y3GL
3hMlu3XPMw3045yCb7bfqinlJcf58JphffRKSBvkJ8gZRpgcZNPWHBzWwpIO
1GJI6+1jZcE6mI3ELM2EeN0IY78X8eE1EtGiZs/OJqSCPkNdB2AFcBH+sv9T
KVnipIFGG2HLil+CRZTd4YkdOGPvCIA7LRlBJnkmsPS87guo9i5MDI9D18FR
Po3uXb0kSOXur9i9RQaLDIQp4MgUb8xFWVlGt/qvFM4ywClmeaDzWTDmS5NV
A2EBwmeY6oL+U94UkcrxhsrLhDNqEIMYK1NvdzwhMReZuCdP9IVD8dcmtWCg
D5fUpzNa1L/uSFg0Gu8gMoriAmcg6Mk9FyvC3nXBwnMHxoHFP3+GMi+d7MW0
/XilIhsfae6GG3n3KpvNCW7i/ywkAtUAS4GCQ/Bfnp2SGS8fWVthTyhgU78J
gZ5gIWYfBaPEYlJfiT717rPRYwhJkSDcHeFN8sBEmtAF9okD9GvAIF06la2e
iyVIb2dOiwjFaS1InsRd2MdOIJXA9JWeIR3q4h5SigyQeptsOPx/6YKlNQEd
QED9/ECIgcURiSRGG5H+RgQoriyI0gnSYQBTK593cA96DaGbG/HeJkY2qQMQ
nagcAWfg+K1dcLAs+5ixloCA0muQd7/7sirkXRitUohGgDU1AC0si24JR+Sr
3SLIoYEH0Iq+LdbXb8m4kZAfCRn1ffPj3ALkieaIIYssni4T8osw1+Q9PTsO
wY5RvKB4b5z09oYWJwbkRZgXaROX36Jnyfq2Ba2pkSU5ByyU9KA7NEaRxiCm
KGRBb50H6mmNT3QcfBaA88GuEB6TTHbAgJ2B/NWv3/Dn28t/e3t1e/kSn+9+
OH/1KnxQ7om7H968ffWy+9S9efHm+vry9Ut5ma7q3iW1c33+lx2JRXfe3Nxf
vXl9/mpH9nGsxPB74pEyFDZovzLqW9NCAi3/89/jI+LyvyC8HI9Pia/y5WT8
4oi+QIgyG7tF+UpatlIEH62pWIPIuZBjyhrCjuxuCLpQ0AOcAlm+A2fen+nf
TZLl+OgbdwEL7l30POtdZJ5tXtl4WZi45dKWaQI3e9fXON2n9/wvve+e79HF
3/0+h6kajk9+/w2rFMeg33IMGrIZTokOSYm+o90gflgE5PxlSBA8IlMh6Qmg
DESsJsRXqouvusgeCXoK5x16Pjg9xPaOckwOYcRg27FoYpUAOBeFSoS9jrVH
siP6ka+P65RgHY++HRjTT7vNO95zMa/VOxcSLQ3vKXTZIT0hO10pMqF5742D
PY+voMxdrqzmAGubOSNte12i7HRVEBJe4NGmNS4C6oWhhKabbLkFQSggCEbT
5FphUIDf+oFVcLqcuM0oap+SX80kkGJ78+VXIJGMXGHCjp98k1Hb4JKtvGeO
JOAYJfFGD0j1N7Xn4PFoLAb8Z9NneyPRRc5+MIB0WfEufbbGqxomW0VOwk0S
+wm4YQ9OafhFz+seCiw61y8vb4e2gDeAoe8l8Uk7oxTa084NHMuafm5F4pMm
gMFF44CdchE658ecT+rhcq2vnBfmez6qoAiQ4omE6Ji2+SAG12RR26qog5QC
BnWSiybE/G5Uecala3rXes7R2/MEWXS3HHWwv6+fvvlxL37yt7pk5HQXiNQH
Hz/2QgvtzS1YwoBfUrw0/LKtlhQRjPrUifq3yCvxygiJly3tOVbl4N63wZnD
EYnfG5MAwwMhB/tjNgIH+weYwoN/2DdehKCXxFIIkqrYnyNDSJYOK7QpQigO
0W+tWFA2FxuLPv8Lq4CgH95sai2OpPCG45jax9o+8pMcMUc7pm1KEJEAiSkB
X5y+pV1PZpsEREiYmO6TA8YnYYmvdcbmyhL8yBqZ3dlNToNuZ+ExUP8hMerp
NQOgG67mWoTNPcEryYoStYusDlJd+qdp7CKjzUeUQF+zBK4YKTSX9QFlF7x6
fcnQ7IgYSH/uRLnl2vEaU5VjKk8HAbKIRNtlLDMp20bAXo1MCpkAzlP5+066
ddiDQfud4dzYBBb6PFBE3kA7kirGvQyLWbU9wg2J6fXcXtj8DixKWN7btJ2x
cdbrmpTLaHioNdvlIgbbdYx0j+qdKKn2bPkh+0gx0U5kjxq/KE5dbHWEWhwh
o+fOE5tNCi/KxQLFf1E59IhMSTnXqD0EtVcuf7dAHibpvcb+iGCG90eg7fKy
dpDDcsbUp5BhD11SpF7nn/dRIYN7cQ5x3Z67jOCvsCPi9gtlPyZ2Kf7WOdyE
glSm3qVsu0wNrSCxFWQM2rG14dvKwioknBE6tjmB1ompaeFwv0RnyJ0n2TLr
LHafXJgGYgIJ17pMndfgWGNNgkiYTMfMoyFW+CW9Xynn96VyIntEqhLISDj1
j3mK6vK0P8g02jfeP/HrpCjTrFoIB2STyTx9y97tmQkyHnW74JjR1WLj3FWE
OxSsL5dLgo8hM+ny6c4QNCxHWluIqp4IBCYjzYQOKepfU80jqOalIXzHFRUx
PCymNfTEQHgVp0J45FISgHeBbtWzBlyNr62X5pfTFruACK5oSDqoGMmgGcGl
o0UCyDnwctEloneR6+ByoqldiPUoTVqoAxvBTEPSwBTpj+Ihq8rCVXK5huL8
ztw8+DCNJThrK5dyp2UQqkxYH2NP2HCCd6FCIUrYRtxlNc6krtxo1N+FB8bV
KFeaudfVseidgebUvNrlZpGPBv4RzSJnJ/u7bG4540DyjhAsM9IlavxQawlV
Edh6FiN+Mfhnk3Ihk31pn9EqMqXCdIAAU4VJt9EF4CIp1JBTSjmRnIhe3ntN
8AvYJTGKV3d4nKRXTTJSqWr1ykxsrv/jd5j8G6lCDlw+izk1ULGupdmUdBBL
DxjAx0pkZNgQJVG1eynZOPKS37lCeo8/TjIbtRLM9IXEXqg5UeQ3cPDAxxpf
DEhCb0nRXfPrDhe+EcZ1qaeceOq5wLWnB5NnqUjEN60giajUN9yP5NuROg1b
Txx+/ZPPYsL+gdfwIkvy17yzNimHmWI4ud2K8+S+cuZKGKTFJgVv8ISkud5l
DQHHYy/HO4cMkX7qwCNSxIIE95wdvSEoDq6jFSzySfWaPT2WoCqyCnCP7Cut
eMNh5yhj58a6KZWgxioGt5vektsEeNd6eM9GOESJXJMEWmF0jGoIgbk2axhp
Bt+KUVxoA9uM8Gag12wZRbU19N47LzGWg8gWe0eNIgkHK56k4JN5JAbZqih1
VyJymAPIottWEg6Vdd/l15LngmiVDwxcUCRVkGhV7Klp8stLClXAUNgh3wph
6GPDdiEHKkJLsRQDetIEQmAg7XKVF7evBs4VXkX237nTUFvyQbaPlDfzzKGv
6OXo+BciZ1/uaX2URRB06ZRvK3gb6O19LmsBuFqLh7cG4ErdbahL7asva/q6
gO3r22IEyChT1WhAA0hDw5VHYf7tNPalXaVQwsiyWikXK9XsTKER/gKbPGIH
pkSLx0LaOTwbugIoYv0a3mod/eg6oY1h+2CjA7xHnDfpm9m4tB8EXK2pqZgh
h4SdgnJiKSBbQT2ALu1iAuxO33NkHs/vXo/GujGzOnLk35bpKqrP9FMvo4Nf
Sr7QIv6L/lFa63fj4/c/o/HyyPP3vSawzQdevCcuPpS+42rj/sl77JX+DaZA
/UzMUTKgdelAemjVR95a/0CAgEzIQPUtDit2h/I7aN4LCUJURPgOkBDOAe2M
ywpxVj9iQA8VRQOLZbPyW4Sm560nJDosr0RZvxLKh24Xh92jJJZkuro0gE9q
SYEOfoitPApsdVe1Uz1GmhkiLEFtjyZjTM6mrr/QJkMOdmmKLpSJdiLRbJm+
XlyBbStbw2hSGYM2LvgnelD5bgFS6JpdgoxYPxIZgRVfSCwg9/T0gp1huqd+
UQQcNHP27Yv2g2lnz2ASRKjOk/i+SJevItZ0BelQ+/JxHVKI9F6fYrDfgQmF
VNnTczf+HjwaM32N0dzd0wnSuf4GSkRyhDPG5c2o1smRbuF5Mp+W9QfemfxV
DhXzGRvkcCTINKETF/fnBm2NNFFPil2yjk2Q6hHbdlkyp6voO3L0Sd1YskvA
LgivGuXrInxQKGm5ScE0DWQWsncIoiQb12vW4f5btwqnJk5lfMrJux2XAkOK
ScqVnGeTMqZvsXBlS0Zma7XQNRjnqz1HSMD4B2F9O3LNo6kcjJQs7lqCUvyc
9MJI6zM39XahhigBQuitbVJRo7oLMgYbU0ibJFFvTZWj8EDG3fkUSYGqqAru
CJLWYtKRKCzelvkaAgPtRPmxkSIeYQNx78V6JZnUXrrORAXh/aSstTWrhj6M
L0Foz/vjz5L09DnYfpoWqa/NohjmWq0HPADu0pTTheuhGWzVLYUzYwVaf+gT
IqAxF4lIyplUCqqs/sDCkvzssJwOHcSAPpNnwWNV2c7msAdlW/FhEszWLmRn
0HQUinAOE8d8oo5Khp3rEJhnpwkpWtUULeS290Kni0T6AumbEI1vseVl2/yW
ZUNDhV7B1AJf+s6jrkw3rawNa8CGIVag9QkJ4okF+bZIzLKWvjbu+fLdeZ28
QnecgDWcwanlzBzH3a+4nTkowdP7V3d7IkycV0FnRSVfcToFiXUC2Zr3PagQ
DM3cSrMZULXowfEh9KDxYitKcI5kOwsk+Q7WpmuN4Q5KsXYRvyNvETKjIp5e
d59PqEtLB58rAs+dgYxqfQPd70H1lRMoQtdSCl+pw6A4WFnZkAvi4w5YCCNZ
vyrfIOUhEr3v2jaJpz7V5thU74k0Xf2AdX27VYsxeGOqmSWj4pFcOYU0t3pr
PP41JRCtQxHEflzmZeaLqrQMHFephlkxpMGGcnrF7TAEq5V0nEGy3AsmJZ1l
N5GIi+sFSei+SsqKK/ZubzETCNdQhLkgR8WRj5SMhMkQITfJisZ0wo8LbUSB
A+3boSp4SXtjiWNlA3cwI1IrOWlGGrEe6mCU3VA1Y2jXyMnQldc6PhsGB+mC
chJYF5DDd6Cxg6LJbFbEib56VSONsUAnHqClXjcBvehEtrrrXPC5aV5t2qEE
iGHlFtfPI0PNrqO+yKxA52zzhf0IJNdxn0eQECjeiF0BBD2aJO6kWi2dCeo1
MKWlrd0KXeEIMIoCTJioeESLXqOZDaoezFfHNZgdAAlOFQuai6IMAClxrYjh
fOVQEDWO/RkCYCmZ4qUkWuICa3yGqJcmnhmGoVpgW+oSEDRCjYQsCZnMBbiQ
c6J3AmMIo5LgOAuOQ0XDeS5GrHYri8d2C+6xsHcGTfa7lJvyNUH5AW/Pn1HE
OGELKllePh8TlyM0+1LYxEXWQG5i4Fx/fZU9mCRw/vLS5xcQQuk4A1vHvtEZ
MfdWP7PlUxCRaXTGzoOA2JMw5oLNlL46MTM9gFH65x+yqmlNDgsAqhscBOG+
6tpl7dL1FMcqSjT48iO9HhqMgifcnBxHNV1rhr46f33+BcT03BU3iS9AmIkN
A7jDRz7l6bKnmSnMqKxmzygEJTvBe/7ZAoBvyNmL+PPoI46GR54C9TST+IqH
6U+67QTcJlXu1M3XUEUcscOlqczCAqetf///oM43f34FdV3meUgi3PjuqIOF
++WFLpb4T15x6/mVy3odzvlp36EmNWJWIYAjCwtuqlXXVNI10gouMQw4lnwg
yp1xFTU8D3kUcRVOBV987h93/D843RiFMOsHHJHntIJkZQI4vco+ZPYRFqF7
+MHkrQBbigImhCOwCByNxWfu+OvOePoO5E9P3MXPvjONS3TGp2QfM5ps4s/J
hgLPlOlfO3YWSeU7YBN/e/9UD7/ROC/tWq8rdqly1lYWwi5P0ql489rMLbH0
jxYLNvBdGfNSYEnqoGjvlTdVZvVdY20ubP93GiJt//53Q3hJ35kKoOqBgjw+
oK7WKTwBhfunvq28OyAHXGAf0Kfb4FQpTwWvI6BeDNPhSJqGDkcHnj9ZfASZ
2NP1XEufEHqawomwl1e3jg2OPzxtpPNstr8USNL9kP6UyM417Xe+iYs6vzBx
nx8vmB8n6xJzLw303eUF/31zc4dBMO357T39uy5Pfj+nje8IkiCuzMvZSra3
txX4+zgTS5HSI88sH9Sun9XNKrfDWUtL7nV3w63yI3DVvtU9XqGjze+UuGf7
FxrQOzGEHwPQ+GWXFuntrn8Rkj90kn8hfam54Uaq8H6z2e3uq78wPP3IYu2o
ni/ixKfg1hrp4RtmlVnOPbIN/TqvbDFr5msdOyA1blZvSu5DT2xoR09W/X50
pxB1OBq3rijPWVFeiKK8jTRPyOt6Qmmu3a2/J7MbL6osLBcmK7d13Il3ObTP
yvTSLgmh8zRdzYGrccu8raSfLCpGMMO5tMhIsGWqeYmutIAUTjQQpviOSxHc
nlugbyTqWB3H+hyfiYlZeywTuAM3oiHRz9GQMVuY4aSqP2RDY9cZeswMfR4z
tBZftpYZMrIrGWjhNrJjK7/9pAN3jmS03nnH95+MD5+fPD89fK8voye3/zCS
K5YMxwf6KX7XSI8P9vd29jYM+xETexzMBIz6P0jqxpiHPOaRG9OxmhkKU8y5
wPALFcPA5I1hDniYQxmGJMrl6YJDFtrRHDCTcDdeG/NrB3197gR95E7YdM1T
vb1NC407a4c570I+AZ5Kiqbs4LtsjFHHujWkA4g+Hh2O+iY4S1knvYsfdO3u
nFSGHfTEdclBcCmMXfufUXk+5t3rjrL+lq+djE+6a/tS0nbJKncdiap1ru0z
18bCtRtpS8eCCDv43wzp9Yh86Wco/hQGPHNnnvwUrFHo7PYZJ3jj7rBNl5XZ
dvooPiqWRi1HW36oQpL8hLI2H3RTEfM28Fknwc4iO1H3kAByQK67E/cgQBwR
K9JtP6gR+xBZS/iRDo+DPUyjp/8Xi7/PeANNAAA= best practice.
-->

</rfc>