rfc9811.original.xml   rfc9811.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.0. -ietf-lamps-rfc6712bis-10" number="9811" category="std" consensus="true" submiss
2) --> ionType="IETF" xml:lang="en" updates="" obsoletes="6712, 9480" tocDepth="4" tocI
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft nclude="true" sortRefs="false" symRefs="true" version="3">
-ietf-lamps-rfc6712bis-10" category="std" consensus="true" submissionType="IETF"
xml:lang="en" obsoletes="6712 9480" tocDepth="4" tocInclude="true" sortRefs="fa
lse" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.25.0 -->
<front> <front>
<title abbrev="HTTP Transfer for CMP">Internet X.509 Public Key Infrastructu re -- HTTP Transfer for the Certificate Management Protocol (CMP)</title> <title abbrev="HTTP Transfer for CMP">Internet X.509 Public Key Infrastructu re -- HTTP Transfer for the Certificate Management Protocol (CMP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc6712bis-10"/> <seriesInfo name="RFC" value="9811"/>
<author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus"> <author initials="H." surname="Brockhaus" fullname="Hendrik Brockhaus">
<organization abbrev="Siemens">Siemens</organization> <organization abbrev="Siemens">Siemens</organization>
<address> <address>
<postal> <postal>
<street>Werner-von-Siemens-Strasse 1</street> <street>Werner-von-Siemens-Strasse 1</street>
<city>Munich</city> <city>Munich</city>
<code>80333</code> <code>80333</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>hendrik.brockhaus@siemens.com</email> <email>hendrik.brockhaus@siemens.com</email>
skipping to change at line 69 skipping to change at line 68
<street>1187 Park Place</street> <street>1187 Park Place</street>
<city>Minneapolis</city> <city>Minneapolis</city>
<region>MN</region> <region>MN</region>
<code>55379</code> <code>55379</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>john.gray@entrust.com</email> <email>john.gray@entrust.com</email>
<uri>https://www.entrust.com</uri> <uri>https://www.entrust.com</uri>
</address> </address>
</author> </author>
<date year="2025"/> <date year="2025" month="July"/>
<area>sec</area> <area>SEC</area>
<workgroup>LAMPS Working Group</workgroup> <workgroup>lamps</workgroup>
<keyword>CMP</keyword> <keyword>CMP</keyword>
<keyword>HTTP</keyword> <keyword>HTTP</keyword>
<keyword>Certificate management</keyword> <keyword>Certificate management</keyword>
<keyword>PKI</keyword> <keyword>PKI</keyword>
<abstract>
<?line 88?>
<abstract>
<t>This document describes how to layer the Certificate Management Protocol <t>This document describes how to layer the Certificate Management Protocol
(CMP) over HTTP.</t> (CMP) over HTTP.</t>
<t>It includes the updates to RFC 6712 specified in RFC 9480 Section 3. Th <t>It includes the updates to RFC 6712 specified in Section 3 of RFC 9480;
ese these
updates introduce CMP URIs using a Well-known prefix. It obsoletes updates introduce CMP URIs using a well-known prefix. It obsoletes
RFC 6712 and together with I-D.ietf-lamps-rfc4210bis and it also obsoletes RFC 6712; and, together with RFC 9810, it also obsoletes
RFC 9480.</t> RFC 9480.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 99?> <?line 99?>
<section anchor="sect-1"> <section anchor="sect-1">
<name>Introduction</name> <name>Introduction</name>
<t>[RFC Editor: please delete:</t> <t>The Certificate Management Protocol (CMP) <xref target="RFC9810"/> requ
<t>During IESG telechat the CMP Updates document was approved on condition ires a well-defined
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"/> requires a well-defined
transfer mechanism to enable End Entities (EEs), Registration transfer mechanism to enable End Entities (EEs), Registration
Authorities (RAs), and Certification Authorities (CAs) to pass Authorities (RAs), and Certification Authorities (CAs) to pass
PKIMessage structures between them.</t> 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 con
cerns.
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"/> inc luded a brief <t>The first version of the CMP specification <xref target="RFC2510"/> inc luded a brief
description of a simple transfer protocol layer on top of TCP. Its description of a simple transfer protocol layer on top of TCP. Its
features were simple transfer-level error handling and a mechanism to features were simple transfer-level error handling and a mechanism to
poll for outstanding PKI messages. Additionally, it was mentioned poll for outstanding PKI messages. Additionally, it was mentioned
that PKI messages could also be conveyed using file-, E-mail-, and that PKI messages could also be conveyed using file-, email-, and
HTTP-based transfer, but those were not specified in detail.</t> HTTP-based transfer, but those were not specified in detail.</t>
<t>Since the second version of the CMP specification <xref target="RFC4210 "/> incorporated <t>Since the second version of the CMP specification <xref target="RFC4210 "/> incorporated
its own polling mechanism and thus the need for a transfer protocol its own polling mechanism, the need for a transfer protocol
providing this functionality vanished. The remaining features CMP providing this functionality vanished. The remaining features CMP
requires from its transfer protocols are connection and error requires from its transfer protocols are connection and error
handling.</t> handling.</t>
<t>CMP can benefit from utilizing reliable transport as CMP requires conne ction and error handling <t>CMP can benefit from utilizing reliable transport, as it requires conne ction and error handling
from the transfer protocol. All these features are covered by HTTP. Additionall y, from the transfer protocol. All these features are covered by HTTP. Additionall y,
delayed delivery of CMP response messages may be handled at transfer level, delayed delivery of CMP response messages may be handled at transfer level,
regardless of the message contents. Since <xref target="RFC9480"/> extends the polling regardless of the message contents. Since <xref target="RFC9480"/> extends the polling
mechanism specified in the second version of <xref target="RFC4210">CMP</xref> t o cover mechanism specified in the second version of <xref target="RFC4210">CMP</xref> t o cover
all types of PKI management transactions, delays detected at application all types of PKI management transactions, delays detected at application
level may also be handled within CMP, using pollReq and pollRep messages.</t> 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 <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 method for requests, effectively tunneling CMP over HTTP. While this is
generally considered bad practice (see <xref target="RFC9205">BCP 56</xref> for best current generally considered bad practice (see <xref target="BCP56">RFC 9205</xref> for best current
practice on building protocols with HTTP) and should not be emulated, there practice on building protocols with HTTP) and should not be emulated, there
are good reasons to do so for transferring CMP. HTTP is used 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 as it is generally easy to implement and it is able to traverse
network borders utilizing ubiquitous proxies. Most importantly, HTTP network borders utilizing ubiquitous proxies. Most importantly, HTTP
is already commonly used in existing CMP implementations. Other HTTP is already commonly used in existing CMP implementations. Other HTTP
request methods, such as GET, are not used because PKI management request methods, such as GET, are not used because PKI management
operations can only be triggered using CMP's PKI messages, which need operations can only be triggered using CMP's PKI messages, which need
to be transferred using a POST request.</t> to be transferred using a POST request.</t>
<t>With its status codes, HTTP provides needed error reporting <t>With its status codes, HTTP provides needed error reporting
capabilities. General problems on the server side, as well as those capabilities. General problems on the server side, as well as those
directly caused by the respective request, can be reported to the directly caused by the respective request, can be reported to the
client.</t> client.</t>
<t>As CMP implements a transaction identification (transactionID), identif ying transactions spanning <t>As CMP implements a transaction identification (transactionID), identif ying transactions spanning
over more than just a single request/response pair, the statelessness over more than just a single request/response pair, the statelessness
of HTTP is not blocking its usage as the transfer protocol for CMP of HTTP is not blocking its usage as the transfer protocol for CMP
messages.</t> messages.</t>
<section anchor="sect-1.1"> <section anchor="sect-1.1">
<name>Changes Made by RFC 9480</name> <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 <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 Pr ofile</xref>, in the following areas:</t> management operations specified in the <xref target="RFC9483">Lightweight CMP Pr ofile</xref>, in the following areas:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Introduce the HTTP URI path prefix '/.well-known/cmp'.</t> <t>Introduced the HTTP URI path prefix '/.well-known/cmp'.</t>
</li> </li>
<li> <li>
<t>Add options for extending the URI structure with further segments <t>Added options for extending the URI structure with further segmen
and ts and
define a new protocol registry group to that aim.</t> defined a new protocol registry group to that aim.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="sect-1.2"> <section anchor="sect-1.2">
<name>Changes Made by This Document</name> <name>Changes Made by This Document</name>
<t>This document obsoletes <xref target="RFC6712"/>. <t>This document obsoletes <xref target="RFC6712"/>.
It includes the changes specified in <xref section="3" sectionFormat="of" target ="RFC9480"/> as It includes the changes specified in <xref section="3" sectionFormat="of" target ="RFC9480"/>, as
described in <xref target="sect-1.1"/> of this document. Additionally, it adds t he following changes:</t> described in <xref target="sect-1.1"/> of this document. Additionally, it adds t he following changes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <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> <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>
<li> <li>
<t>Implementations <bcp14>MUST</bcp14> forward CMP messages when an HTTP error status code occurs, see <xref target="sect-3.1"/>.</t> <t>Implementations <bcp14>MUST</bcp14> forward CMP messages when an HTTP error status code occurs; see <xref target="sect-3.1"/>.</t>
</li> </li>
<li> <li>
<t>Removed <xref section="3.8" sectionFormat="of" target="RFC6712"/> as it contains information redundant with current HTTP specification.</t> <t>Removed <xref section="3.8" sectionFormat="of" target="RFC6712"/> as it contains information redundant with current HTTP specification.</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="sect-2"> <section anchor="sect-2">
<name>Conventions Used in This Document</name> <name>Conventions Used in This Document</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 <t>
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and be interpreted as
only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
appear in all capitals, as shown here.</t> when, and only when, they appear in all capitals, as shown here.
<?line -18?> </t>
</section>
</section>
<section anchor="sect-3"> <section anchor="sect-3">
<name>HTTP-Based Protocol</name> <name>HTTP-Based Protocol</name>
<t>For direct interaction between two entities, where a reliable <t>For direct interaction between two entities, where a reliable
transport protocol like TCP <xref target="RFC9293"/> is available, HTTP <xref ta rget="RFC9110"/> <bcp14>SHOULD</bcp14> be transport protocol like TCP <xref target="RFC9293"/> is available, HTTP <xref ta rget="RFC9110"/> <bcp14>SHOULD</bcp14> be
utilized for conveying CMP messages. This specification requires utilized for conveying CMP messages. This specification requires
using the POST method (Section 3.1) and the "Content-Type" header using the POST method (<xref target="sect-3.1"/>) and the "Content-Type" header
field (Section 3.2), which are available since HTTP/1.0 <xref target="RFC1945"/> field (<xref target="sect-3.2"/>), which are available since HTTP/1.0 <xref targ
.</t> et="RFC1945"/>.</t>
<t>Note: In some situations, CMP requires multiple request/response <t>Note: In some situations, CMP requires multiple request/response
pairs to perform a PKI management operation. Their affiliation pairs to perform a PKI management operation. Their affiliation
with a PKI management operation is indicated by a with a PKI management operation is indicated by a
transaction identifier in the CMP message header (see transactionID transaction identifier in the CMP message header (see transactionID
described in Section 5.1.1 of <xref target="I-D.ietf-lamps-rfc4210bis"/>). described in <xref target="RFC9810" sectionFormat="of" section="5.1.1"/>).
For details on how to transfer multiple requests see For details on how to transfer multiple requests, see
Section 4.11 of <xref target="RFC9205"/>.</t> <xref target="RFC9205" sectionFormat="of" section="4.11"/>.</t>
<section anchor="sect-3.1"> <section anchor="sect-3.1">
<name>General Form</name> <name>General Form</name>
<t>A DER-encoded <xref target="ITU.X690.1994"/> PKIMessage (<xref sectio n="5.1" sectionFormat="of" target="I-D.ietf-lamps-rfc4210bis"/>) <bcp14>MUST</bc p14> be sent as the <t>A DER-encoded <xref target="ITU.X690.1994"/> PKIMessage (<xref sectio n="5.1" sectionFormat="of" target="RFC9810"/>) <bcp14>MUST</bcp14> be sent as th e
content of an HTTP POST request. If this HTTP request is content of an HTTP POST request. If this HTTP request is
successful, the server returns the CMP response in the content of the 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> b e HTTP response. The HTTP response status code in this case <bcp14>MUST</bcp14> b e
200 (OK) status code; other Successful 2xx status codes <bcp14>MUST NOT</bcp14> be used for this purpose. 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="se ct-3.5"/> HTTP responses to pushed CMP announcement messages described in <xref target="se ct-3.5"/>
utilize the status codes 201 and 202 to identify whether the received utilize the status codes 201 and 202 to identify whether the received
information was processed.</t> information was processed.</t>
<t>While Redirection 3xx status codes <bcp14>MAY</bcp14> be supported by <t>While Redirection 3xx status codes <bcp14>MAY</bcp14> be supported by
implementations, clients should only be enabled to automatically implementations, clients should only be enabled to automatically
follow them after careful consideration of possible security follow them after careful consideration of possible security
implications. As described in <xref target="sect-5"/>, 301 (Moved Permanently) status code implications. As described in <xref target="sect-5"/>, the 301 (Moved Permanent ly) status code
could be misused for permanent denial of service.</t> could be misused for permanent denial of service.</t>
<t>All applicable Client Error 4xx or Server Error 5xx status codes <t>All applicable Client Error 4xx or Server Error 5xx status codes
<bcp14>MAY</bcp14> be used to inform the client about errors. Whenever <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, 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 4xx, or 5xx ranges, it <bcp14>MUST</bcp14> support handling response message
content containing a CMP response PKIMessage.</t> content containing a CMP response PKIMessage.</t>
</section> </section>
<section anchor="sect-3.2"> <section anchor="sect-3.2">
<name>Media Type</name> <name>Media Type</name>
<t>The Internet Media Type "application/pkixcmp" <bcp14>MUST</bcp14> be set in the HTTP <t>The Internet media type "application/pkixcmp" <bcp14>MUST</bcp14> be set in the HTTP
"Content-Type" header field when conveying a PKIMessage.</t> "Content-Type" header field when conveying a PKIMessage.</t>
</section> </section>
<section anchor="sect-3.3"> <section anchor="sect-3.3">
<name>Communication Workflow</name> <name>Communication Workflow</name>
<t>In CMP, most communication is initiated by the EEs where every CMP <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> 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 <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 exception. Their creation may be triggered by certain events or done
on a regular basis by a CA. The recipient of the announcement only on a regular basis by a CA. The recipient of the announcement only
replies with an HTTP status code acknowledging the receipt or replies with an HTTP status code acknowledging the receipt or
skipping to change at line 253 skipping to change at line 249
in a multi-vendor environment.</t> in a multi-vendor environment.</t>
<t>CMP clients have to be configured with sufficient information to form <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., 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 '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 regist ered entity. Additionally, path segments <bcp14>MAY</bcp14> be added after the regist ered
application name as part of the full operation path to provide further distincti on. application name as part of the full operation path to provide further distincti on.
The path segment 'p' followed by an arbitraryLabel &lt;name&gt; could, for examp le, The path segment 'p' followed by an arbitraryLabel &lt;name&gt; could, for examp le,
support the differentiation of specific CAs or certificate profiles. Further support the differentiation of specific CAs or certificate profiles. Further
path segments, e.g., as specified in the Lightweight CMP Profile <xref target="R FC9483"/>, path segments, e.g., as specified in the Lightweight CMP Profile <xref target="R FC9483"/>,
could indicate PKI management operations using an operationLabel &lt;operation&g t;. could indicate PKI management operations using an operationLabel &lt;operation&g t;.
The following list examples of valid full CMP URIs:</t> The following list shows examples of valid full CMP URIs:</t>
<ul empty="true"> <ul spacing="normal">
<li> <li>http://www.example.com/.well-known/cmp</li>
<t>http://www.example.com/.well-known/cmp</t> <li>http://www.example.com/.well-known/cmp/&lt;operation&gt;</li>
</li> <li>http://www.example.com/.well-known/cmp/p/&lt;name&gt;</li>
</ul> <li>http://www.example.com/.well-known/cmp/p/&lt;name&gt;/&lt;operatio
<ul empty="true"> n&gt;</li>
<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;operati
on&gt;</t>
</li>
</ul> </ul>
<t>Note that https can also be used instead of http, see <xref target="s ect-5">item 5 in the Security Considerations</xref>.</t> <t>Note that https can also be used instead of http; see <xref target="s ect-5">item 5 in the Security Considerations</xref>.</t>
</section> </section>
<section anchor="sect-3.5"> <section anchor="sect-3.5">
<name>Pushing of Announcements</name> <name>Pushing of Announcements</name>
<t>A CMP server may create event-triggered announcements or generate <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 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 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 HTTP client, and the recipient needs to utilize an HTTP server. As
no request messages are specified for those announcements, they can no request messages are specified for those announcements, they can
only be pushed to the recipient.</t> only be pushed to the recipient.</t>
<t>If an EE wants to poll for a potential CA Key Update Announcement or <t>If an EE wants to poll for a potential CA Key Update Announcement or
the current CRL, a PKI Information Request using a General Message as the current Certificate Revocation List (CRL), a PKI Information Request using a
described in <xref section="D.5" sectionFormat="of" target="I-D.ietf-lamps-rfc42 general message as
10bis"/> can be used.</t> described in <xref section="D.5" sectionFormat="of" target="RFC9810"/> can be us
ed.</t>
<t>When pushing announcement messages, PKIMessage structures <bcp14>MUST </bcp14> be sent as <t>When pushing announcement messages, PKIMessage structures <bcp14>MUST </bcp14> be sent as
the content of an HTTP POST request.</t> the content of an HTTP POST request.</t>
<t>Suitable recipients for CMP announcements might, for example, be <t>Suitable recipients for CMP announcements might, for example, be
repositories storing the announced information, such as directory repositories storing the announced information, such as directory
services. Those services listen for incoming messages, utilizing the services. Those services listen for incoming messages, utilizing the
same HTTP Request-URI scheme as defined in <xref target="sect-3.4"/>.</t> 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 pushe d by a <t>The following types of PKIMessage are announcements that may be pushe d by a
CA. The prefixed numbers reflect ASN.1 tags of the PKIBody structure (<xref sec tion="5.1.2" sectionFormat="of" target="I-D.ietf-lamps-rfc4210bis"/>).</t> CA. The prefixed numbers reflect ASN.1 tags of the PKIBody structure (<xref sec tion="5.1.2" sectionFormat="of" target="RFC9810"/>).</t>
<artwork><![CDATA[ <artwork><![CDATA[
[15] CA Key Update Announcement [15] CA Key Update Announcement
[16] Certificate Announcement [16] Certificate Announcement
[17] Revocation Announcement [17] Revocation Announcement
[18] CRL Announcement [18] CRL Announcement
]]></artwork> ]]></artwork>
<t>CMP announcement messages do not require any CMP response. However, <t>CMP announcement messages do not require any CMP response. However,
the recipient <bcp14>MUST</bcp14> acknowledge receipt with an HTTP response havi ng the recipient <bcp14>MUST</bcp14> acknowledge receipt with an HTTP response havi ng
an appropriate status code and an empty content. When not receiving an appropriate status code and empty content. When not receiving
such a response, it <bcp14>MUST</bcp14> be assumed that the delivery was not 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 successful. If applicable, the sending side <bcp14>MAY</bcp14> try sending the
announcement again after waiting for an appropriate time span.</t> announcement again after waiting for an appropriate time span.</t>
<t>If the announced issue was successfully stored in a database or was <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) already present, the answer <bcp14>MUST</bcp14> be an HTTP response with a 201 ( Created)
status code and an empty content.</t> status code and empty content.</t>
<t>In case the announced information was only accepted for further <t>In case the announced information was only accepted for further
processing, the status code of the returned HTTP response <bcp14>MAY</bcp14> als o be processing, the status code of the returned HTTP response <bcp14>MAY</bcp14> als o be
202 (Accepted). After an appropriate delay, the sender may then try 202 (Accepted). After an appropriate delay, the sender may then try
to send the announcement again and may repeat this until it receives to send the announcement again and may repeat this until it receives
a confirmation that it has been successfully processed. The a confirmation that it has been successfully processed. The
appropriate duration of the delay and the option to increase it appropriate duration of the delay and the option to increase it
between consecutive attempts should be carefully considered.</t> between consecutive attempts should be carefully considered.</t>
<t>A receiver <bcp14>MUST</bcp14> answer with a suitable 4xx or 5xx erro r code <t>A receiver <bcp14>MUST</bcp14> answer with a suitable 4xx or 5xx erro r code
when a problem occurs.</t> when a problem occurs.</t>
</section> </section>
</section> </section>
<section anchor="sect-4"> <section anchor="sect-4">
<name>Implementation Considerations</name> <name>Implementation Considerations</name>
<t>Implementers should be aware that other implementations might exist tha t <t>Implementers should be aware that other implementations might exist tha t
use a different approach for transferring CMP over HTTP. use a different approach for transferring CMP over HTTP.
Further, implementations based on earlier I-Ds that led to Further, implementations based on earlier documents that led to
<xref target="RFC6712"/> might use an unregistered "application/pkixcmp-poll" Me <xref target="RFC6712"/> might use an unregistered "application/pkixcmp-poll" me
dia Type. dia type.
Conforming implementations <bcp14>MAY</bcp14> handle this type like "application /pkixcmp".</t> Conforming implementations <bcp14>MAY</bcp14> handle this type like "application /pkixcmp".</t>
</section> </section>
<section anchor="sect-5"> <section anchor="sect-5">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>All security considerations in HTTP <xref target="RFC9110"/> apply. <t>All security considerations in HTTP <xref target="RFC9110"/> apply.
The following items need to be considered by implementers and users:</t> The following items need to be considered by implementers and users:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1"><li>
<t>There is the risk for denial-of-service attacks through resource <t>There is the risk for denial-of-service attacks through resource
consumption by opening many connections to an HTTP server. Therefore, consumption by opening many connections to an HTTP server. Therefore,
idle connections should be terminated after an appropriate timeout; this idle connections should be terminated after an appropriate timeout; this
may also depend on the available free resources.</t> may also depend on the available free resources.</t>
</li> </li>
<li> <li>
<t>Without being encapsulated in effective security protocols, such <t>Without being encapsulated in effective security protocols, such
as Transport Layer Security (TLS) <xref target="RFC5246"/> or <xref target="RF as Transport Layer Security (TLS) <xref target="RFC5246"/> <xref target="RFC84
C8446"/>, or 46"/>, or
without using HTTP digest <xref target="RFC9530"/> there is no without using HTTP digest <xref target="RFC9530"/>, there is no
integrity protection at the HTTP level. Therefore, integrity protection at the HTTP level. Therefore,
information from the HTTP should not be used to change information from the HTTP should not be used to change
state of the transaction, regardless of whether any mechanism was state of the transaction, regardless of whether any mechanism was
used to ensure the authenticity or integrity of HTTP messages used to ensure the authenticity or integrity of HTTP messages
(e.g., TLS or HTTP digests).</t> (e.g., TLS or HTTP digests).</t>
</li> </li>
<li> <li>
<t>Client users should be aware that storing the target location of <t>Client users should be aware that storing the target location of
an HTTP response with the 301 (Moved Permanently) status code an HTTP response with the 301 (Moved Permanently) status code
could be exploited by a meddler-in-the-middle attacker trying to could be exploited by a meddler-in-the-middle attacker trying to
skipping to change at line 369 skipping to change at line 351
In that case, the overall design of the PKI system must not In that case, the overall design of the PKI system must not
depend on the announcements being reliably received and processed depend on the announcements being reliably received and processed
by their destination.</t> by their destination.</t>
</li> </li>
<li> <li>
<t>CMP provides inbuilt integrity protection and authentication. <t>CMP provides inbuilt integrity protection and authentication.
The information communicated unencrypted in CMP messages does not The information communicated unencrypted in CMP messages does not
contain sensitive information endangering the security of the PKI contain sensitive information endangering the security of the PKI
when intercepted. However, it might be possible for an when intercepted. However, it might be possible for an
eavesdropper to utilize the available information to gather eavesdropper to utilize the available information to gather
confidential personal, technical, or business critical information. confidential personal, technical, or business-critical information.
The protection of the confidentiality of CMP messages together with The protection of the confidentiality of CMP messages together with
an initial authentication of the RA/CA before the first CMP message an initial authentication of the RA/CA before the first CMP message
is transmitted ensures the privacy of the EE requesting is transmitted ensures the privacy of the EE requesting
certificates. Therefore, users of the HTTP transfer for CMP messages certificates. Therefore, users of the HTTP transfer for CMP messages
should consider using HTTP over TLS according to <xref target="RFC9110"/> or u sing virtual should consider using HTTP over TLS according to <xref target="RFC9110"/> or u sing virtual
private networks created, for example, by utilizing Internet private networks created, for example, by utilizing Internet
Protocol Security according to <xref target="RFC7296"/>.</t> Protocol Security according to <xref target="RFC7296"/>.</t>
</li> </li>
</ol> </ol>
</section> </section>
<section anchor="sect-6"> <section anchor="sect-6">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>The reference to <xref target="RFC2510"/> at https://www.iana.org/assig <t>IANA has made the following updates:</t>
nments/media-types/media-types.xhtml should be replaced with a reference to this <ul>
document.</t> <li>the reference for "application/pkixcmp" in the "Media Types" registry <eref
<t>The reference to <xref target="RFC4210"/> at https://www.iana.org/assig target="https://www.iana.org/assignments/media-types" brackets="angle"/> refers
nments/core-parameters/core-parameters.xhtml should be replaced with a reference to this document, instead of <xref target="RFC2510"/>. </li>
to this document.</t> <li>the reference for "application/pkixcmp" in the "CoAP Content-Formats"
<t>The reference to <xref target="RFC9480"/> at https://www.iana.org/assig registry <eref target="https://www.iana.org/assignments/core-parameters" bracket
nments/well-known-uris/well-known-uris.xhtml and https://www.iana.org/assignment s="angle"/> refers to this document, instead of <xref target="RFC4210"/>. </li>
s/cmp/cmp.xhtmlshould should be replaced with a reference to this document.</t> <li>the reference for "cmp" in the "Well-Known URIs" registry <eref target
<t>No further action by the IANA is necessary for this document or any ant ="https://www.iana.org/assignments/core-parameters" brackets="angle"/>
icipated refers to this document instead of <xref target="RFC4210"/>.</li>
<li>the reference for "p" in the "CMP Well-Known URI Path Segments" regist
ry <eref
target="https://www.iana.org/assignments/cmp" brackets="angle"/> refers to this
document instead of <xref target="RFC9480"/>. </li>
</ul>
<t>No further action by IANA is necessary for this document or any anticip
ated
updates.</t> updates.</t>
</section> </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> </middle>
<back> <back>
<!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC1945"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<front> 945.xml"/>
<title>Hypertext Transfer Protocol -- HTTP/1.0</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee 615.xml"/>
"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="R. Fielding" initials="R." surname="Fielding"/> 110.xml"/>
<author fullname="H. Frystyk" initials="H." surname="Frystyk"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<date month="May" year="1996"/> 112.xml"/>
<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="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, 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, 7
232, 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="R
eschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document specifies the HTTP/1.1 message syntax, message parsing, connectio
n management, and related security concerns.</t>
<t>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="I-D.ietf-lamps-rfc4210bis">
<front>
<title>Internet X.509 Public Key Infrastructure -- Certificate Manag
ement Protocol (CMP)</title>
<author fullname="Hendrik Brockhaus" initials="H." surname="Brockhau
s">
<organization>Siemens</organization>
</author>
<author fullname="David von Oheimb" initials="D." surname="von Oheim
b">
<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 Infras
tructure
(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 <!-- draft-ietf-lamps-rfc4210bis-18 companion doc RFC 9810 -->
EnvelopedData instead of EncryptedValue. This document also includes <reference anchor="RFC9810" target="https://www.rfc-editor.org/info/rfc9810">
the updates specified in Section 2 and Appendix A.2 of RFC 9480. <front>
<title>Internet X.509 Public Key Infrastructure -- Certificate Management Pr
otocol (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 month="July" year="2025"/>
</front>
<seriesInfo name="RFC" value="9810"/>
<seriesInfo name="DOI" value="10.17487/RFC9810"/>
</reference>
The updates maintain backward compatibility with CMP version 2 <!-- [rfced] The 1994 version of ITU-T Recommendation X.690
wherever possible. Updates to CMP version 2 are improving crypto (https://www.itu.int/rec/T-REC-X.690-199407-S/en) has been superseded
agility, extending the polling mechanism, adding new general message by the version published in February 2021
types, and adding extended key usages to identify special CMP server (https://www.itu.int/rec/T-REC-X.690-202102-I/en). May we update this
authorizations. CMP version 3 is introduced for changes to the ASN.1 reference to use the most current version?
syntax, which are support 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- Current:
rfc6712bis and it also obsoletes RFC 9480. Appendix F of this [ITU.X690.1994]
document updates the Section 9 of RFC 5912. International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 1994.
</t> Perhaps:
</abstract> [ITU.X690.2021]
</front> ITU-T, "Information Technology - ASN.1 encoding rules:
<seriesInfo name="Internet-Draft" value="draft-ietf-lamps-rfc4210bis-1 Specification of Basic Encoding Rules (BER), Canonical Encoding
5"/> Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T
</reference> Recommendation X.690, 2021,
<reference anchor="ITU.X690.1994"> <https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
-->
<!-- XML for most recent version of [ITU.X690.1994] with
updated cite tag.
<reference anchor="ITU.X690.2021" target="https://www.itu.int/rec/T-REC-
X.690-202102-I/en">
<front> <front>
<title>Information Technology - ASN.1 encoding rules: Specification <title>Information Technology - ASN.1 encoding rules:
of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Specification of Basic Encoding Rules (BER), Canonical Encoding
Encoding Rules (DER)</title> Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author> <author>
<organization>International Telecommunications Union</organization > <organization>ITU-T</organization>
</author> </author>
<date year="1994"/> <date 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</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference> </reference>
<reference anchor="RFC8174"> -->
<reference anchor="ITU.X690.1994" target="https://www.itu.int/rec/T-REC-
X.690-199407-S/en">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti <title>Information Technology - ASN.1 encoding rules:
tle> Specification of Basic Encoding Rules (BER), Canonical Encoding
<author fullname="B. Leiba" initials="B." surname="Leiba"/> Rules (CER) and Distinguished Encoding Rules (DER)</title>
<date month="May" year="2017"/> <author>
<abstract> <organization>ITU-T</organization>
<t>RFC 2119 specifies common key words that may be used in protoco </author>
l specifications. This document aims to reduce the ambiguity by clarifying that <date year="1994"/>
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="ITU-T Recommendation" value="X.690"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC9480">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<title>Certificate Management Protocol (CMP) Updates</title> 480.xml"/>
<author fullname="H. Brockhaus" initials="H." surname="Brockhaus"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="D. von Oheimb" initials="D." surname="von Oheimb"/ 483.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="J. Gray" initials="J." surname="Gray"/> 510.xml"/>
<date month="November" year="2023"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<abstract> 210.xml"/>
<t>This document contains a set of updates to the syntax of Certif <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
icate Management Protocol (CMP) version 2 and its HTTP transfer mechanism. This 246.xml"/>
document updates RFCs 4210, 5912, and 6712.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<t>The aspects of CMP updated in this document are using Enveloped 712.xml"/>
Data instead of EncryptedValue, clarifying the handling of p10cr messages, impro <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
ving the crypto agility, as well as adding new general message types, extended k 296.xml"/>
ey usages to identify certificates for use with CMP, and well-known URI path seg <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ments.</t> 446.xml"/>
<t>CMP version 3 is introduced to enable signaling support of Enve <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
lopedData instead of EncryptedValue and signal the use of an explicit hash Algor 530.xml"/>
ithmIdentifier in certConf messages, as far as needed.</t>
</abstract> <!--[rfced] FYI, We have updated the reference entry to RFC 9205 with
</front> one for BCP 56 since the BCP is mentioned in the text. Please review
<seriesInfo name="RFC" value="9480"/> and let us know of any objections.
<seriesInfo name="DOI" value="10.17487/RFC9480"/> -->
</reference>
<reference anchor="RFC9483"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
<front> 56.xml"/>
<title>Lightweight Certificate Management Protocol (CMP) Profile</ti <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
tle> 293.xml"/>
<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 T
hings (IoT) scenarios. This is achieved by profiling the Certificate Management
Protocol (CMP), the related Certificate Request Message Format (CRMF), and trans
fer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but s
ufficiently detailed and self-contained way. To make secure certificate manageme
nt for simple scenarios and constrained devices as lightweight as possible, only
the most crucial types of operations and options are specified as mandatory. Mo
re 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 Manageme
nt 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 Infrastru
cture (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 Manageme
nt 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 Infrastru
cture (PKI) Certificate Management Protocol (CMP). Protocol messages are defined
for X.509v3 certificate creation and management. CMP provides on-line interacti
ons between PKI components, including an exchange between a Certification Author
ity (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">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
e>
<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 of the Transport Layer Secu
rity (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. [STAN
DARDS-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 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 the Internet Key Exchange
(IKE) protocol. IKE is a component of IPsec used for performing mutual authentic
ation and establishing and maintaining Security Associations (SAs). This documen
t obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 t
o 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">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<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 Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</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 digest
s. The Content-Digest field can be used for the integrity of HTTP message conten
t. 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 inte
rest 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 us
e HTTP to define new application protocols. It is written primarily to guide IET
F efforts to define application protocols using HTTP for deployment on the Inter
net 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, a
nd it has continuously evolved over decades of use and growth of the Internet. O
ver 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 doc
ument 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 11
22, and it should be considered as a replacement for the portions of those docum
ents dealing with TCP requirements. It also updates RFC 5961 by adding a small c
larification in reset handling while in the SYN-RECEIVED state. The TCP header c
ontrol 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>
</references> </references>
<?line 446?> <section anchor="sect-7" numbered="false">
<name>Acknowledgements</name>
<section anchor="History"> <t>The authors wish to thank <contact fullname="Tomi Kause"/> and <contact
<name>History of Changes</name> fullname="Martin Peylo"/>, the
<t>Note: This appendix will be deleted in the final version of the documen original authors of <xref target="RFC6712"/>, for their work.</t>
t.</t> <t>We also thank all reviewers for their valuable feedback.</t>
<t>From version 09 -&gt; 10:</t>
<ul spacing="normal">
<li>
<t>Addressed IESG review comments from Mahesh Jethanandani and respond
ed 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 the
introduction of Section 3 as proposed by HTTPDIR review</t>
</li>
<li>
<t>Added reference to HTTP Security Considerations to Section 5 and up
dated 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 changes proposed by OPSDIR reviewer</t>
</li>
<li>
<t>Removed requirement to support HTTP/1.0</t>
</li>
<li>
<t>Added normative language in Sections 3.3 and 3.7 for clarity</t>
</li>
<li>
<t>Added the requirement to provide any HTTP response message content
to the application</t>
</li>
<li>
<t>Removed the paragraph on the "Content-Length" header field and Sect
ion 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-anim
a-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 threa
d "[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-le
ngth 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 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 this document and thanked the authors of
RFC6712
for their work.</t>
</li>
<li>
<t>Added 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> </section>
</back> </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=
<!-- [rfced] FYI - We have added an expansion for the following abbreviation
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Certificate Revocation List (CRL)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
--> -->
</rfc> </rfc>
 End of changes. 54 change blocks. 
807 lines changed or deleted 236 lines changed or added

This html diff was produced by rfcdiff 1.48.