<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-acme-ari-08" number="9773" consensus="true" submissionType="IETF" category="std" updates="" obsoletes="" symRefs="true" sortRefs="true" xml:lang="en" tocInclude="true" indexInclude="true" prepTime="2025-06-17T09:08:22" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-acme-ari-08" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9773" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="ACME ARI">ACME Renewal Information (ARI) Extension</title>
    <seriesInfo name="RFC" value="9773" stream="IETF"/>
    <author initials="A." surname="Gable" fullname="A. Gable">
      <organization showOnFrontPage="true">Internet Security Research Group</organization>
      <address>
        <email>aaron@letsencrypt.org</email>
      </address>
    </author>
    <date month="06" year="2025"/>
    <area>SEC</area>
    <workgroup>acme</workgroup>
    <keyword>certificate</keyword>
    <keyword>CA</keyword>
    <keyword>x509</keyword>
    <keyword>pki</keyword>
    <keyword>webpki</keyword>
    <keyword>renew</keyword>
    <keyword>replace</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document specifies how an Automated Certificate Management Environment (ACME) server may provide suggestions to ACME clients as to when they should attempt to renew their certificates. This allows servers to mitigate load spikes and ensures that clients do not make false assumptions about appropriate certificate renewal periods.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9773" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-and-definitions">Conventions and Definitions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extensions-to-the-directory">Extensions to the Directory Object</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-getting-renewal-information">Getting Renewal Information</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-renewalinfo-resource">The RenewalInfo Resource</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-renewalinfo-objects">RenewalInfo Objects</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-schedule-for-checking-the-r">Schedule for Checking the RenewalInfo Resource</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-server-choice-of-retry-afte">Server Choice of Retry-After</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-client-handling-of-retry-af">Client Handling of Retry-After</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.3.1"><xref derivedContent="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-error-handling">Error Handling</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extensions-to-the-order-obj">Extensions to the Order Object</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acme-resource-type">ACME Resource Type</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acme-renewalinfo-object-fie">ACME RenewalInfo Object Fields</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acme-order-object-fields">ACME Order Object Fields</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acme-error-types">ACME Error Types</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-appendix-a-example-certific">Appendix A. Example Certificate</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Most ACME <xref target="RFC8555" format="default" sectionFormat="of" derivedContent="RFC8555"/> clients today choose when to attempt to renew a certificate in one of three ways:</t>
      <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-1-2">
    <li pn="section-1-2.1" derivedCounter="1.">they may be configured to renew at a specific interval (e.g., via cron),</li>
        <li pn="section-1-2.2" derivedCounter="2.">they may parse the issued certificate to determine its expiration date and renew a specific amount of time before then, or</li>
        <li pn="section-1-2.3" derivedCounter="3.">they may parse the issued certificate and renew when some percentage of its validity period has passed.</li>
      </ol>
      <t indent="0" pn="section-1-3">The first two create significant barriers against the issuing Certification Authority (CA) changing certificate lifetimes. All three ways  may lead to load clustering for the issuing CA due to its inability to schedule renewal requests.</t>
      <t indent="0" pn="section-1-4">Allowing issuing CAs to suggest a period in which clients should renew their certificates enables dynamic time-based load balancing. This allows a CA to better respond to exceptional circumstances. For example:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1-5">
        <li pn="section-1-5.1">a CA could suggest that clients renew prior to a mass-revocation event to mitigate the impact of the revocation, or</li>
        <li pn="section-1-5.2">a CA could suggest that clients renew earlier than they normally would to reduce the size of an upcoming mass-renewal spike.</li>
      </ul>
      <t indent="0" pn="section-1-6">This document specifies the ACME Renewal Information (ARI) extension, a mechanism by which ACME servers may provide suggested renewal windows to ACME clients and by which ACME clients may inform ACME servers that they have successfully renewed and replaced a certificate.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-conventions-and-definitions">Conventions and Definitions</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
      <t indent="0" pn="section-2-2">Throughout this document, the word "renewal" and its variants are taken to encompass any combination of "Renewal", "Re-Key", and "Modification" as defined in <xref target="RFC3647" format="default" sectionFormat="of" derivedContent="RFC3647"/>.</t>
      <t indent="0" pn="section-2-3">This document assumes that the certificates being issued by the ACME server are in compliance with <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/> and, in particular, contain the Authority Key Identifier extension and the keyIdentifier field within that extension.</t>
    </section>
    <section anchor="extensions-to-the-directory-object" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-extensions-to-the-directory">Extensions to the Directory Object</name>
      <t indent="0" pn="section-3-1">An ACME server that wishes to provide renewal information <bcp14>MUST</bcp14> include a new field, "<tt>renewalInfo</tt>", in its directory object.</t>
      <table align="center" pn="table-1">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Field</th>
            <th align="left" colspan="1" rowspan="1">URL in Value</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">renewalInfo</td>
            <td align="left" colspan="1" rowspan="1">Renewal information</td>
          </tr>
        </tbody>
      </table>
      <sourcecode type="json" markers="false" pn="section-3-3">
HTTP/1.1 200 OK
Content-Type: application/json

{
  "newNonce": "https://acme.example.com/new-nonce",
  "newAccount": "https://acme.example.com/new-account",
  "newOrder": "https://acme.example.com/new-order",
  "newAuthz": "https://acme.example.com/new-authz",
  "revokeCert": "https://acme.example.com/revoke-cert",
  "keyChange": "https://acme.example.com/key-change",
  "renewalInfo": "https://acme.example.com/renewal-info",
  "meta": {
    "termsOfService": "https://example.com/acme/terms",
    "website": "https://example.com/acme/docs",
    "caaIdentities": ["example.com"],
    "externalAccountRequired": false
  }
}
</sourcecode>
    </section>
    <section anchor="getting-renewal-information" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-getting-renewal-information">Getting Renewal Information</name>
      <section anchor="the-renewalinfo-resource" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-the-renewalinfo-resource">The RenewalInfo Resource</name>
        <t indent="0" pn="section-4.1-1">The RenewalInfo resource is a new resource type introduced to the ACME protocol. This new resource allows clients to query the server for suggestions on when they should renew certificates.</t>
        <t indent="0" pn="section-4.1-2">To request the suggested renewal information for a certificate, the client sends an unauthenticated GET request to a path under the server's <tt>renewalInfo</tt> URL.</t>
        <t indent="0" pn="section-4.1-3">The path component is a unique identifier for the certificate in question. The unique identifier is constructed by concatenating the base64url encoding <xref target="RFC4648" format="default" sectionFormat="of" derivedContent="RFC4648"/> of the keyIdentifier field of the certificate's Authority Key Identifier (AKI) <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/> extension, the period character ".", and the base64url encoding of the DER-encoded Serial Number field (without the tag and length bytes). All trailing "<tt>=</tt>" characters <bcp14>MUST</bcp14> be stripped from both parts of the unique identifier.</t>
        <t indent="0" pn="section-4.1-4">Thus, the full request URL is constructed as follows (split onto multiple lines for readability), where the "<tt>||</tt>" operator indicates string concatenation and the <tt>renewalInfo</tt> URL is taken from the Directory object:</t>
        <sourcecode type="" markers="false" pn="section-4.1-5">
url = renewalInfo || '/' ||
      base64url(AKI keyIdentifier) || '.' || base64url(Serial)
</sourcecode>
        <t indent="0" pn="section-4.1-6">For example, to request renewal information for the end-entity certificate given in Appendix A, the client would make the request as follows:</t>
        <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-4.1-7">
<li pn="section-4.1-7.1" derivedCounter="1.">The keyIdentifier field of the certificate's AKI extension has the hexadecimal bytes <tt>69:88:5B:6B:87:46:40:41:E1:B3:7B:84:7B:A0:AE:2C:DE:01:C8:D4</tt> as its ASN.1 Octet String value. The base64url encoding of those bytes is <tt>aYhba4dGQEHhs3uEe6CuLN4ByNQ=</tt>.</li>
          <li pn="section-4.1-7.2" derivedCounter="2.">The certificate's Serial Number field has the hexadecimal bytes <tt>00:87:65:43:21</tt> as its DER encoding (note the leading zero byte to ensure the serial number remains positive despite the leading 1 bit in <tt>0x87</tt>). The base64url encoding of those bytes is <tt>AIdlQyE=</tt>.</li>
          <li pn="section-4.1-7.3" derivedCounter="3.">Stripping the trailing padding characters and concatenating with the separator, the unique identifier is therefore <tt>aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE</tt>, and the client makes the request:</li>
        </ol>
        <sourcecode type="" markers="false" pn="section-4.1-8">
GET /renewal-info/aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE HTTP/1.1
Host: acme.example.com
Accept: application/json
</sourcecode>
      </section>
      <section anchor="renewalinfo-objects" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-renewalinfo-objects">RenewalInfo Objects</name>
        <t indent="0" pn="section-4.2-1">The structure of an ACME RenewalInfo object is as follows:</t>
        <dl spacing="normal" newline="true" indent="3" pn="section-4.2-2">
          <dt pn="section-4.2-2.1"><tt>suggestedWindow</tt> (object, required):</dt>
          <dd pn="section-4.2-2.2">A JSON object with
  two keys, "<tt>start</tt>" and "<tt>end</tt>", whose values are timestamps,
  encoded in the format specified in <xref target="RFC3339" format="default" sectionFormat="of" derivedContent="RFC3339"/>, which bound the
  window of time in which the CA recommends renewing the certificate.</dd>
          <dt pn="section-4.2-2.3"><tt>explanationURL</tt> (string, optional):</dt>
          <dd pn="section-4.2-2.4">A URL pointing to a
  page that may explain why the suggested renewal window has its current
  value. For example, it may be a page explaining the CA's dynamic
  load-balancing strategy or a page documenting which certificates are
  affected by a mass-revocation event. Clients <bcp14>SHOULD</bcp14> provide
  this URL to their operator, if present.</dd>
        </dl>
        <sourcecode type="json" markers="false" pn="section-4.2-3">
HTTP/1.1 200 OK
Content-Type: application/json
Retry-After: 21600

{
  "suggestedWindow": {
    "start": "2025-01-02T04:00:00Z",
    "end": "2025-01-03T04:00:00Z"
  },
  "explanationURL": "https://acme.example.com/docs/ari"
}
</sourcecode>
        <t indent="0" pn="section-4.2-4">Clients <bcp14>MUST</bcp14> attempt renewal at a time of their choosing based on the suggested renewal window. The following algorithm is <bcp14>RECOMMENDED</bcp14> for choosing a renewal time:</t>
        <ol spacing="normal" indent="adaptive" start="1" type="1" pn="section-4.2-5">
<li pn="section-4.2-5.1" derivedCounter="1.">Make a <tt>renewalInfo</tt> request to get a suggested renewal window.</li>
          <li pn="section-4.2-5.2" derivedCounter="2.">Select a uniform random time within the suggested window.</li>
          <li pn="section-4.2-5.3" derivedCounter="3.">If the selected time is in the past, attempt renewal immediately.</li>
          <li pn="section-4.2-5.4" derivedCounter="4.">Otherwise, if the client can schedule itself to attempt renewal at exactly the selected time, do so.</li>
          <li pn="section-4.2-5.5" derivedCounter="5.">Otherwise, if the selected time is before the next time that the client would wake up normally, attempt renewal immediately.</li>
          <li pn="section-4.2-5.6" derivedCounter="6.">Otherwise, sleep until the time indicated by the Retry-After header and return to Step 1.</li>
        </ol>
        <t indent="0" pn="section-4.2-6">In all cases, renewal attempts are subject to the client's existing error backoff and retry intervals.</t>
        <t indent="0" pn="section-4.2-7">In particular, cron-based clients may find they need to increase their run frequency to check ARI more frequently. Those clients will need to store information about failures so that increasing their run frequency doesn't lead to retrying failures without proper backoff. Typical information stored should include: number of failures for a given order (defined by the set of identifiers on the order) and time of the most recent failure.</t>
        <t indent="0" pn="section-4.2-8">A RenewalInfo object in which the <tt>end</tt> timestamp equals or precedes the <tt>start</tt> timestamp is invalid. Servers <bcp14>MUST NOT</bcp14> serve such a response, and clients <bcp14>MUST</bcp14> treat one as though they failed to receive any response from the server (e.g., retry at an appropriate interval, renew on a fallback schedule, etc.).</t>
      </section>
      <section anchor="schedule-for-checking-the-renewalinfo-resource" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-schedule-for-checking-the-r">Schedule for Checking the RenewalInfo Resource</name>
        <t indent="0" pn="section-4.3-1">Clients <bcp14>SHOULD</bcp14> fetch a certificate's RenewalInfo immediately after issuance.</t>
        <t indent="0" pn="section-4.3-2">During the lifetime of a certificate, the renewal information needs to be fetched frequently enough that clients learn about changes in the suggested window quickly, but without overwhelming the server. This protocol uses the Retry-After header <xref target="RFC9110" format="default" sectionFormat="of" derivedContent="RFC9110"/> to indicate to clients how often to retry. Note that in other HTTP applications, Retry-After often indicates the minimum time to wait before retrying a request. In this protocol, it indicates the desired (i.e., both requested minimum and maximum) amount of time to wait.</t>
        <t indent="0" pn="section-4.3-3">Clients <bcp14>MUST NOT</bcp14> check a certificate's RenewalInfo after the certificate has expired. Clients <bcp14>MUST NOT</bcp14> check a certificate's RenewalInfo after they consider the certificate to be replaced (for instance, after a new certificate for the same identifiers has been received and configured).</t>
        <section anchor="server-choice-of-retry-after" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.1">
          <name slugifiedName="name-server-choice-of-retry-afte">Server Choice of Retry-After</name>
          <t indent="0" pn="section-4.3.1-1">Servers set the Retry-After header based on their requirements on how quickly to perform a revocation. For instance, a server that needs to revoke certificates within 24 hours of notification of a problem might choose to reserve twelve hours for investigation, six hours for clients to fetch updated RenewalInfo objects, and six hours for clients to perform a renewal. Setting a small value for Retry-After means that clients can respond more quickly but also incurs more load on the server. Servers should estimate their expected load based on the number of clients, keeping in mind that third parties may also monitor <tt>renewalInfo</tt> endpoints.</t>
        </section>
        <section anchor="client-handling-of-retry-after" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.2">
          <name slugifiedName="name-client-handling-of-retry-af">Client Handling of Retry-After</name>
          <t indent="0" pn="section-4.3.2-1">After an initial fetch of a certificate's RenewalInfo, clients <bcp14>MUST</bcp14> fetch it again as soon as possible after the time indicated in the Retry-After header (backoff on errors takes priority, though). Clients <bcp14>MUST</bcp14> set reasonable limits on their checking interval. For example, values under one minute could be treated as if they were one minute, and values over one day could be treated as if they were one day.</t>
        </section>
        <section anchor="error-handling" numbered="true" removeInRFC="false" toc="include" pn="section-4.3.3">
          <name slugifiedName="name-error-handling">Error Handling</name>
          <t indent="0" pn="section-4.3.3-1">Temporary errors include, for instance:</t>
          <ul spacing="compact" bare="false" empty="false" indent="3" pn="section-4.3.3-2">
            <li pn="section-4.3.3-2.1">Connection timeout</li>
            <li pn="section-4.3.3-2.2">Request timeout</li>
            <li pn="section-4.3.3-2.3">5xx HTTP errors</li>
          </ul>
          <t indent="0" pn="section-4.3.3-3">On receiving a temporary error, clients <bcp14>SHOULD</bcp14> do exponential backoff with a capped number of tries. If all tries are exhausted, clients <bcp14>MUST</bcp14> treat the request as a long-term error.</t>
          <t indent="0" pn="section-4.3.3-4">Examples of long-term errors include:</t>
          <ul spacing="compact" bare="false" empty="false" indent="3" pn="section-4.3.3-5">
            <li pn="section-4.3.3-5.1">Retry-After is invalid or not present</li>
            <li pn="section-4.3.3-5.2">RenewalInfo object is invalid</li>
            <li pn="section-4.3.3-5.3">DNS lookup failure</li>
            <li pn="section-4.3.3-5.4">Connection refused</li>
            <li pn="section-4.3.3-5.5">Non-5xx HTTP error</li>
          </ul>
          <t indent="0" pn="section-4.3.3-6">On receiving a long-term error, clients <bcp14>MUST</bcp14> make the next <tt>renewalInfo</tt> request as soon as possible after six hours have passed (or some other locally configured default).</t>
        </section>
      </section>
    </section>
    <section anchor="extensions-to-the-order-object" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-extensions-to-the-order-obj">Extensions to the Order Object</name>
      <t indent="0" pn="section-5-1">In order to convey information regarding which certificate requests represent renewals of previous certificates, a new field is added to the Order object:</t>
      <dl spacing="normal" newline="true" indent="3" pn="section-5-2">
        <dt pn="section-5-2.1"><tt>replaces</tt> (string, optional):</dt>
        <dd pn="section-5-2.2">A string uniquely
  identifying a previously issued certificate that this order is intended to
  replace. This unique identifier is constructed in the same way as the path
  component for GET requests described in <xref target="the-renewalinfo-resource" format="default" sectionFormat="of" derivedContent="Section 4.1"/>.</dd>
      </dl>
      <t indent="0" pn="section-5-3">Clients <bcp14>SHOULD</bcp14> include this field in newOrder requests if there is a clear predecessor certificate, as is the case for most certificate renewals. Clients <bcp14>SHOULD NOT</bcp14> include this field if the ACME server has not indicated that it supports this protocol by advertising the <tt>renewalInfo</tt> resource in its Directory.</t>
      <sourcecode type="" markers="false" pn="section-5-4">
POST /new-order HTTP/1.1
Host: acme.example.com
Content-Type: application/jose+json

{
  "protected": base64url({
    "alg": "ES256",
    "kid": "https://acme.example.com/acct/evOfKhNU60wg",
    "nonce": "5XJ1L3lEkMG7tR6pA00clA",
    "url": "https://acme.example.com/new-order"
  }),
  "payload": base64url({
    "identifiers": [
      { "type": "dns", "value": "acme.example.com" }
    ],
    "replaces": "aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE"
  }),
  "signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
}
</sourcecode>
      <t indent="0" pn="section-5-5">Servers <bcp14>SHOULD</bcp14> check that the identified certificate and the newOrder request correspond to the same ACME Account, that they share at least one identifier, and that the identified certificate has not already been marked as replaced by a different Order that is not "invalid". Correspondence checks beyond this (such as requiring exact identifier matching) are left up to server policy. If any of these checks fail, the server <bcp14>SHOULD</bcp14> reject the newOrder request. If the server rejects the request because the identified certificate has already been marked as replaced, it <bcp14>MUST</bcp14> return an HTTP 409 (Conflict) with a problem document of type "alreadyReplaced" (see <xref target="acme-error-types" format="default" sectionFormat="of" derivedContent="Section 7.4"/>).</t>
      <t indent="0" pn="section-5-6">If the server accepts a newOrder request with a "replaces" field, it <bcp14>MUST</bcp14> reflect that field in the response and in subsequent requests for the corresponding Order object.</t>
      <t indent="0" pn="section-5-7">This replacement information may serve many purposes, including but not limited to:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-8">
        <li pn="section-5-8.1">granting newOrder requests that arrive during the suggested renewal window of their identified predecessor certificate higher priority or allowing them to bypass rate limits, if the server's policy uses such;</li>
        <li pn="section-5-8.2">tracking the replacement of certificates that have been affected by a compliance incident, so that they can be revoked immediately after they are replaced; and</li>
        <li pn="section-5-8.3">tying together certificates issued under the same contract with an entity identified by External Account Binding.</li>
      </ul>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">The extensions to the ACME protocol described in this document build upon the security considerations and threat model defined in <xref target="RFC8555" section="10.1" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc8555#section-10.1" derivedContent="RFC8555"/>.</t>
      <t indent="0" pn="section-6-2">This document specifies that RenewalInfo resources are exposed and accessed via unauthenticated GET requests, a departure from the requirement in RFC 8555 that clients send POST-as-GET requests to fetch resources from the server. This is because the information contained in RenewalInfo resources is not considered confidential and because allowing RenewalInfo resources to be easily cached is advantageous to shed the load from clients that do not respect the Retry-After header. As always, servers should take measures to ensure that unauthenticated requests for renewal information cannot result in denial-of-service attacks. These measures might include ensuring that a cache does not include superfluous request headers or query parameters in its cache key, instituting IP-based rate limits, or other general best-practice measures.</t>
      <t indent="0" pn="section-6-3">Note that this protocol could exhibit undesired behavior in the presence of significant clock skew between the ACME client and server. For example, if a server places the suggested renewal window wholly in the past to encourage a client to renew immediately, a client with a sufficiently slow clock might nonetheless see the window as being in the future. Similarly, a server that wishes to schedule renewals very precisely may have difficulty doing so if some clients have skewed clocks (or do not implement ARI at all). Server operators should take this concern into account when setting suggested renewal windows. However, many other protocols (including TLS handshakes themselves) fall apart with sufficient clock skew, so this is not unique to this protocol.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="acme-resource-type" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-acme-resource-type">ACME Resource Type</name>
        <t indent="0" pn="section-7.1-1">IANA has added the following entry to the "ACME Resource Types" registry within the "Automated Certificate Management Environment (ACME) Protocol" registry group at <eref target="https://www.iana.org/assignments/acme" brackets="angle"/>:</t>
        <table align="center" pn="table-2">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Field Name</th>
              <th align="left" colspan="1" rowspan="1">Resource Type</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">renewalInfo</td>
              <td align="left" colspan="1" rowspan="1">RenewalInfo object</td>
              <td align="left" colspan="1" rowspan="1">This document</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="acme-renewalinfo-object-fields" numbered="true" removeInRFC="false" toc="include" pn="section-7.2">
        <name slugifiedName="name-acme-renewalinfo-object-fie">ACME RenewalInfo Object Fields</name>
        <t indent="0" pn="section-7.2-1">IANA has added the following new registry to the "Automated Certificate
  Management Environment (ACME) Protocol" registry group at <eref target="https://www.iana.org/assignments/acme" brackets="angle"/>:</t>
        <dl spacing="normal" newline="true" indent="3" pn="section-7.2-2">
          <dt pn="section-7.2-2.1">Registry Name:</dt>
          <dd pn="section-7.2-2.2">ACME RenewalInfo Object Fields</dd>
          <dt pn="section-7.2-2.3">Registration Procedure:</dt>
          <dd pn="section-7.2-2.4">Specification Required (see <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>). The designated
    expert should ensure that any new fields added to this registry carry
    useful and unique information that does not better belong elsewhere in the
    ACME protocol.</dd>
          <dt pn="section-7.2-2.5">Template:</dt>
          <dd pn="section-7.2-2.6">
            <dl spacing="compact" newline="false" indent="3" pn="section-7.2-2.6.1">
              <dt pn="section-7.2-2.6.1.1">Field name:</dt>
              <dd pn="section-7.2-2.6.1.2">The string to be used as a field name in the JSON object</dd>
              <dt pn="section-7.2-2.6.1.3">Field type:</dt>
              <dd pn="section-7.2-2.6.1.4">The type of value to be provided, e.g., string, boolean, array of string</dd>
              <dt pn="section-7.2-2.6.1.5">Reference:</dt>
              <dd pn="section-7.2-2.6.1.6">Where this field is defined</dd>
            </dl>
          </dd>
          <dt pn="section-7.2-2.7">Initial contents:</dt>
          <dd pn="section-7.2-2.8">
            <table align="center" pn="table-3">
              <thead>
                <tr>
                  <th align="left" colspan="1" rowspan="1">Field Name</th>
                  <th align="left" colspan="1" rowspan="1">Field Type</th>
                  <th align="left" colspan="1" rowspan="1">Reference</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="left" colspan="1" rowspan="1">suggestedWindow</td>
                  <td align="left" colspan="1" rowspan="1">object</td>
                  <td align="left" colspan="1" rowspan="1">This document</td>
                </tr>
                <tr>
                  <td align="left" colspan="1" rowspan="1">explanationURL</td>
                  <td align="left" colspan="1" rowspan="1">string</td>
                  <td align="left" colspan="1" rowspan="1">This document</td>
                </tr>
              </tbody>
            </table>
          </dd>
        </dl>
      </section>
      <section anchor="acme-order-object-fields" numbered="true" removeInRFC="false" toc="include" pn="section-7.3">
        <name slugifiedName="name-acme-order-object-fields">ACME Order Object Fields</name>
        <t indent="0" pn="section-7.3-1">IANA has added the following entry to the "ACME Order Object Fields"
  registry within the "Automated Certificate Management Environment (ACME)
  Protocol" registry group at <eref target="https://www.iana.org/assignments/acme" brackets="angle"/>:</t>
        <table align="center" pn="table-4">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Field Name</th>
              <th align="left" colspan="1" rowspan="1">Field Type</th>
              <th align="left" colspan="1" rowspan="1">Configurable</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">replaces</td>
              <td align="left" colspan="1" rowspan="1">string</td>
              <td align="left" colspan="1" rowspan="1">true</td>
              <td align="left" colspan="1" rowspan="1">This document</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="acme-error-types" numbered="true" removeInRFC="false" toc="include" pn="section-7.4">
        <name slugifiedName="name-acme-error-types">ACME Error Types</name>
        <t indent="0" pn="section-7.4-1">IANA has added the following entry to the "ACME Error Types" registry
  within the "Automated Certificate Management Environment (ACME) Protocol"
  registry group at <eref target="https://www.iana.org/assignments/acme" brackets="angle"/>:</t>
        <table align="center" pn="table-5">
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Type</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">alreadyReplaced</td>
              <td align="left" colspan="1" rowspan="1">The request specified a predecessor certificate that has already been marked as replaced</td>
              <td align="left" colspan="1" rowspan="1">This document</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3339" quoteTitle="true" derivedAnchor="RFC3339">
          <front>
            <title>Date and Time on the Internet: Timestamps</title>
            <author fullname="G. Klyne" initials="G." surname="Klyne"/>
            <author fullname="C. Newman" initials="C." surname="Newman"/>
            <date month="July" year="2002"/>
            <abstract>
              <t indent="0">This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3339"/>
          <seriesInfo name="DOI" value="10.17487/RFC3339"/>
        </reference>
        <reference anchor="RFC4648" target="https://www.rfc-editor.org/info/rfc4648" quoteTitle="true" derivedAnchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
            <date month="October" year="2006"/>
            <abstract>
              <t indent="0">This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" quoteTitle="true" derivedAnchor="RFC5280">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
            <author fullname="D. Cooper" initials="D." surname="Cooper"/>
            <author fullname="S. Santesson" initials="S." surname="Santesson"/>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="S. Boeyen" initials="S." surname="Boeyen"/>
            <author fullname="R. Housley" initials="R." surname="Housley"/>
            <author fullname="W. Polk" initials="W." surname="Polk"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5280"/>
          <seriesInfo name="DOI" value="10.17487/RFC5280"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8555" target="https://www.rfc-editor.org/info/rfc8555" quoteTitle="true" derivedAnchor="RFC8555">
          <front>
            <title>Automatic Certificate Management Environment (ACME)</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes"/>
            <author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman-Andrews"/>
            <author fullname="D. McCarney" initials="D." surname="McCarney"/>
            <author fullname="J. Kasten" initials="J." surname="Kasten"/>
            <date month="March" year="2019"/>
            <abstract>
              <t indent="0">Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8555"/>
          <seriesInfo name="DOI" value="10.17487/RFC8555"/>
        </reference>
        <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="RFC9110">
          <front>
            <title>HTTP Semantics</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
              <t indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="97"/>
          <seriesInfo name="RFC" value="9110"/>
          <seriesInfo name="DOI" value="10.17487/RFC9110"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC3647" target="https://www.rfc-editor.org/info/rfc3647" quoteTitle="true" derivedAnchor="RFC3647">
          <front>
            <title>Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework</title>
            <author fullname="S. Chokhani" initials="S." surname="Chokhani"/>
            <author fullname="W. Ford" initials="W." surname="Ford"/>
            <author fullname="R. Sabett" initials="R." surname="Sabett"/>
            <author fullname="C. Merrill" initials="C." surname="Merrill"/>
            <author fullname="S. Wu" initials="S." surname="Wu"/>
            <date month="November" year="2003"/>
            <abstract>
              <t indent="0">This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3647"/>
          <seriesInfo name="DOI" value="10.17487/RFC3647"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
      </references>
    </references>
    <section anchor="appendix-a-example-certificate" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-appendix-a-example-certific">Appendix A. Example Certificate</name>
      <sourcecode type="" markers="false" pn="section-appendix.a-1">
-----BEGIN CERTIFICATE-----
MIIBQzCB66ADAgECAgUAh2VDITAKBggqhkjOPQQDAjAVMRMwEQYDVQQDEwpFeGFt
cGxlIENBMCIYDzAwMDEwMTAxMDAwMDAwWhgPMDAwMTAxMDEwMDAwMDBaMBYxFDAS
BgNVBAMTC2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeBZu
7cbpAYNXZLbbh8rNIzuOoqOOtmxA1v7cRm//AwyMwWxyHz4zfwmBhcSrf47NUAFf
qzLQ2PPQxdTXREYEnKMjMCEwHwYDVR0jBBgwFoAUaYhba4dGQEHhs3uEe6CuLN4B
yNQwCgYIKoZIzj0EAwIDRwAwRAIge09+S5TZAlw5tgtiVvuERV6cT4mfutXIlwTb
+FYN/8oCIClDsqBklhB9KAelFiYt9+6FDj3z4KGVelYM5MdsO3pK
-----END CERTIFICATE-----
</sourcecode>
    </section>
    <section anchor="acknowledgments" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.b-1">My thanks to <contact fullname="Roland Shoemaker"/> and <contact fullname="Jacob Hoffman-Andrews"/> for coming up with the initial idea of ARI and for helping me learn the IETF process. Thanks also to <contact fullname="Samantha Frank"/>, <contact fullname="Matt Holt"/>, <contact fullname="Ilari Liusvaara"/>, and <contact fullname="Wouter Tinus"/> for contributing client implementations, and to <contact fullname="Freddy Zhang"/> for contributing an independent server implementation. Finally, thanks to <contact fullname="Rob Stradling"/>, <contact fullname="Andrew Ayer"/>, and <contact fullname="J.C. Jones"/> for providing meaningful feedback and suggestions that significantly improved this specification.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author initials="A." surname="Gable" fullname="A. Gable">
        <organization showOnFrontPage="true">Internet Security Research Group</organization>
        <address>
          <email>aaron@letsencrypt.org</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
