Diff: rfc9773.original.xml

	rfc9773.original.xml	rfc9773.xml

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

	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process
	or - mmark.miek.nl" -->	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do	cName="draft-ietf-acme-ari-08" number="9773" consensus="true" submissionType="IE
	cName="draft-ietf-acme-ari-08" submissionType="IETF" category="std" xml:lang="en	TF" category="std" updates="" obsoletes="" symRefs="true" sortRefs="true" xml:la
	" indexInclude="true">	ng="en" tocInclude="true" indexInclude="true">

		<!-- [rfced] Please note that the title of the document has been updated as
		follows:

		We have moved the expansion of ACME from the document title to its first use in
		the Abstract as generally we do not expand abbreviations within abbreviations.

		Original:
		Automated Certificate Management Environment (ACME) Renewal
		Information (ARI) Extension

		Current:
		ACME Renewal Information (ARI) Extension

		-->

	<front>	<front>

	<title abbrev="ACME ARI">Automated Certificate Management Environment (ACME) Ren	<title abbrev="ACME ARI">ACME Renewal Information (ARI) Extension</title>
	ewal Information (ARI) Extension</title><seriesInfo value="draft-ietf-acme-ari-0	<seriesInfo name="RFC" value="9773"/>
	8" stream="IETF" status="standard" name="Internet-Draft"/>	<author initials="A." surname="Gable">
	<author initials="A." surname="Gable"><organization>Internet Security Research G	<organization>Internet Security Research Group</organization>
	roup</organization><address><postal><street/>	<address>
	</postal><email>aaron@letsencrypt.org</email>	<email>aaron@letsencrypt.org</email>
	</address></author><date/>	</address>
	<area>Security Area (sec)</area>	</author>
	<workgroup>ACME Working Group</workgroup>
	<keyword>Internet-Draft</keyword>	<date month="May" year="2025"/>

		<area>SEC</area>
		<workgroup>acme</workgroup>

		<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->

		<keyword>example</keyword>

	<abstract>	<abstract>

	<t>This document specifies how an ACME server may provide suggestions to ACME cl ients as to when they should attempt to renew their certificates. This allows se rvers to mitigate load spikes, and ensures clients do not make false assumptions about appropriate certificate renewal periods.</t>	<t>This document specifies how an Automated Certificate Management Environment ( ACME) server may provide suggestions to ACME clients as to when they should atte mpt to renew their certificates. This allows servers to mitigate load spikes and ensures that clients do not make false assumptions about appropriate certificat e renewal periods.</t>
	</abstract>	</abstract>


	<note><name>Current Implementations</name>
	<t>Draft note: this section will be removed by the editor before final publicati
	on.</t>
	<t>Let's Encrypt's <eref target="https://github.com/letsencrypt/boulder">Boulder
	</eref> software fully implements the server side of an earlier version of this
	draft, and that implementation is deployed in both the <eref target="https://acm
	e-v02.api.letsencrypt.org/directory">Production</eref> and <eref target="https:/
	/acme-staging-v02.api.letsencrypt.org/directory">Staging</eref> environments. Go
	ogle Trust Services has <eref target="https://security.googleblog.com/2023/05/go
	ogle-trust-services-acme-api_0503894189.html">done the same</eref>. Client imple
	mentations include <eref target="https://github.com/go-acme/lego">Lego</eref>, <
	eref target="https://github.com/eggsampler/acme">eggsampler</eref>, <eref target
	="https://github.com/mholt/acmez">ACMEz</eref>, and <eref target="https://github
	.com/win-acme/win-acme">win-acme</eref>.</t>
	</note>

	</front>	</front>

	<middle>	<middle>


	<section anchor="introduction"><name>Introduction</name>	<section anchor="introduction"><name>Introduction</name>
	<t>Most ACME <xref target="RFC8555"/> clients today choose when to attempt to re
	new a certificate in one of three ways. They may be configured to renew at a spe	<t>Most ACME <xref target="RFC8555"/> clients today choose when to attempt to
	cific interval (e.g., via <tt>cron</tt>), they may parse the issued certificate	renew a certificate in one of three ways:</t>
	to determine its expiration date and renew a specific amount of time before then	<ol>
	, or they may parse the issued certificate and renew when some percentage of its	<li>they may be configured to renew at a specific interval (e.g., via <tt>cr
	validity period has passed. The first two techniques create significant barrier	on</tt>),</li>
	s against the issuing Certification Authority (CA) changing certificate lifetime	<li>they may parse the issued certificate to determine its expiration date a
	s. All three techniques may lead to load clustering for the issuing CA due to th	nd renew a specific amount of time before then, or</li>
	e inability of the issuing CA to schedule renewal requests.</t>	<li>they may parse the issued certificate and renew when some percentage of
	<t>Allowing issuing CAs to suggest a period in which clients should renew their	its validity period has passed.</li>
	certificates enables dynamic time-based load balancing. This allows a CA to bett	</ol>
	er respond to exceptional circumstances. For example, a CA could suggest that cl	<t>The first two create significant barriers against the issuing Certification
	ients renew prior to a mass-revocation event to mitigate the impact of the revoc	Authority (CA) changing certificate lifetimes. All three ways may lead to load
	ation, or a CA could suggest that clients renew earlier than they normally would	clustering for the issuing CA due to its inability to schedule renewal requests
	to reduce the size of an upcoming mass-renewal spike.</t>	.</t>
	<t>This document specifies ACME Renewal Information (ARI), a mechanism by which	<t>Allowing issuing CAs to suggest a period in which clients should renew thei
	ACME servers may provide suggested renewal windows to ACME clients, and by which	r certificates enables dynamic time-based load balancing. This allows a CA to be
	ACME clients may inform ACME servers that they have successfully renewed and re	tter respond to exceptional circumstances. For example:</t>
	placed a certificate.</t>	<ul>
		<li>a CA could suggest that clients renew prior to a mass-revocation event t
		o mitigate the impact of the revocation, or</li>
		<li>a CA could suggest that clients renew earlier than they normally would t
		o reduce the size of an upcoming mass-renewal spike.</li></ul>
		<t>This document specifies the ACME Renewal Information (ARI) extension, a mecha
		nism 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 r
		enewed and replaced a certificate.</t>
	</section>	</section>

	<section anchor="conventions-and-definitions"><name>Conventions and Definitions< /name>	<section anchor="conventions-and-definitions"><name>Conventions and Definitions< /name>

	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",	<t>
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	ocument are to be interpreted as described in BCP 14 <xref target="RFC2119"/><xr	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	ef target="RFC8174"/> when, and only when, they appear in all capitals, as shown	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	here.</t>	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"/> <xref target="RFC8174"/>
		when, and only when, they appear in all capitals, as shown here.
		</t>

	<t>Throughout this document, the word "renewal" and its variants are taken to en compass any combination of "Renewal", "Re-Key", and "Modification" as defined in <xref target="RFC3647"/>.</t>	<t>Throughout this document, the word "renewal" and its variants are taken to en compass any combination of "Renewal", "Re-Key", and "Modification" as defined in <xref target="RFC3647"/>.</t>

	<t>This document assumes that the certificates being issued by the ACME server a re in compliance with <xref target="RFC5280"/>, and in particular contain the Au thority Key Identifier extension and the keyIdentifier field within that extensi on.</t>	<t>This document assumes that the certificates being issued by the ACME server a re in compliance with <xref target="RFC5280"/> and, in particular, contain the A uthority Key Identifier extension and the keyIdentifier field within that extens ion.</t>
	</section>	</section>

	<section anchor="extensions-to-the-directory-object"><name>Extensions to the Dir ectory Object</name>	<section anchor="extensions-to-the-directory-object"><name>Extensions to the Dir ectory Object</name>

	<t>An ACME server which wishes to provide renewal information <bcp14>MUST</bcp14 > include a new field, <tt>renewalInfo</tt>, in its directory object.</t>	<t>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>	<table>
	<thead>	<thead>
	<tr>	<tr>
	<th>Field</th>	<th>Field</th>
	<th>URL in Value</th>	<th>URL in Value</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td>renewalInfo</td>	<td>renewalInfo</td>
	<td>Renewal info</td>	<td>Renewal info</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table>	</table>

	<sourcecode type="json"><![CDATA[HTTP/1.1 200 OK
		<sourcecode type="json"><![CDATA[
		HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json

	{	{
	"newNonce": "https://acme.example.com/new-nonce",	"newNonce": "https://acme.example.com/new-nonce",
	"newAccount": "https://acme.example.com/new-account",	"newAccount": "https://acme.example.com/new-account",
	"newOrder": "https://acme.example.com/new-order",	"newOrder": "https://acme.example.com/new-order",
	"newAuthz": "https://acme.example.com/new-authz",	"newAuthz": "https://acme.example.com/new-authz",
	"revokeCert": "https://acme.example.com/revoke-cert",	"revokeCert": "https://acme.example.com/revoke-cert",
	"keyChange": "https://acme.example.com/key-change",	"keyChange": "https://acme.example.com/key-change",
	"renewalInfo": "https://acme.example.com/renewal-info",	"renewalInfo": "https://acme.example.com/renewal-info",
	"meta": {	"meta": {
	"termsOfService": "https://example.com/acme/terms",	"termsOfService": "https://example.com/acme/terms",
	"website": "https://example.com/acme/docs",	"website": "https://example.com/acme/docs",
	"caaIdentities": ["example.com"],	"caaIdentities": ["example.com"],
	"externalAccountRequired": false	"externalAccountRequired": false
	}	}
	}	}

	]]>	]]></sourcecode>
	</sourcecode>
	</section>	</section>

	<section anchor="getting-renewal-information"><name>Getting Renewal Information< /name>	<section anchor="getting-renewal-information"><name>Getting Renewal Information< /name>

	<section anchor="the-renewalinfo-resource"><name>The "renewalInfo" Resource</nam e>	<section anchor="the-renewalinfo-resource"><name>The "renewalInfo" Resource</nam e>
	<t>The "<tt>renewalInfo</tt>" resource is a new resource type introduced to the ACME protocol. This new resource allows clients to query the server for suggesti ons on when they should renew certificates.</t>	<t>The "<tt>renewalInfo</tt>" resource is a new resource type introduced to the ACME protocol. This new resource allows clients to query the server for suggesti ons on when they should renew certificates.</t>
	<t>To request the suggested renewal information for a certificate, the client se nds an unauthenticated GET request to a path under the server's <tt>renewalInfo< /tt> URL.</t>	<t>To request the suggested renewal information for a certificate, the client se nds an unauthenticated GET request to a path under the server's <tt>renewalInfo< /tt> URL.</t>

	<t>The path component is a unique identifier for the certificate in question. Th
	e unique identifier is constructed by concatenating the base64url-encoding <xref
	target="RFC4648"/> of the <tt>keyIdentifier</tt> field of the certificate's Aut
	hority Key Identifier (AKI) <xref target="RFC5280"/> extension, a literal period
	, and the base64url-encoding of the DER-encoded Serial Number field (without the
	tag and length bytes). All trailing "<tt>=</tt>" characters MUST be stripped fr
	om both parts of the unique identifier.</t>
	<t>Thus the full request URL is constructed as follows (split onto multiple line
	s for readability), where the "<tt>\|\|</tt>" operator indicates string concatenat
	ion and the renewalInfo URL is taken from the Directory object:</t>


	<sourcecode type="text"><![CDATA[url = renewalInfo \|\| '/' \|\|	<!--[rfced] Please review our update to "a literal period" to make it match simi
		lar handling of the "=" character later in the paragraph and uses in the RFC Ser
		ies and let us know any objections.

		Original:

		The unique identifier is constructed by concatenating the
		base64url-encoding [RFC4648] of the keyIdentifier field of the
		certificate's Authority Key Identifier (AKI) [RFC5280] extension, a
		literal period, and the base64url-encoding of the DER-encoded Serial
		Number field (without the tag and length bytes).

		Current:

		The unique identifier is constructed by concatenating the
		base64url-encoding [RFC4648] of the keyIdentifier field of the
		certificate's Authority Key Identifier (AKI) [RFC5280] extension, the period cha
		racter ".", and the base64url-encoding of the DER-encoded Serial
		Number field (without the tag and length bytes).

		-->

		<t>The path component is a unique identifier for the certificate in question. Th
		e unique identifier is constructed by concatenating the base64url-encoding <xref
		target="RFC4648"/> of the <tt>keyIdentifier</tt> field of the certificate's Aut
		hority Key Identifier (AKI) <xref target="RFC5280"/> extension, the period chara
		cter ".", and the base64url-encoding of the DER-encoded Serial Number field (wit
		hout the tag and length bytes). All trailing "<tt>=</tt>" characters <bcp14>MUST
		</bcp14> be stripped from both parts of the unique identifier.</t>
		<t>Thus, the full request URL is constructed as follows (split onto multiple lin
		es for readability), where the "<tt>\|\|</tt>" operator indicates string concatena
		tion and the renewalInfo URL is taken from the Directory object:</t>

		<sourcecode type=""><![CDATA[
		url = renewalInfo \|\| '/' \|\|
	base64url(AKI keyIdentifier) \|\| '.' \|\| base64url(Serial)	base64url(AKI keyIdentifier) \|\| '.' \|\| base64url(Serial)

	]]>	]]></sourcecode>
	</sourcecode>
	<t>For example, to request renewal information for the end-entity certificate gi ven in Appendix A, the client would make the request as follows:</t>	<t>For example, to request renewal information for the end-entity certificate gi ven in Appendix A, the client would make the request as follows:</t>


	<ol spacing="compact">	<ol spacing="normal">
	<li>The <tt>keyIdentifier</tt> 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:D 4</tt> as its ASN.1 Octet String value. The base64url encoding of those bytes is <tt>aYhba4dGQEHhs3uEe6CuLN4ByNQ=</tt>.</li>	<li>The <tt>keyIdentifier</tt> 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:D 4</tt> as its ASN.1 Octet String value. The base64url encoding of those bytes is <tt>aYhba4dGQEHhs3uEe6CuLN4ByNQ=</tt>.</li>
	<li>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 base64 url encoding of those bytes is <tt>AIdlQyE=</tt>.</li>	<li>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 base64 url encoding of those bytes is <tt>AIdlQyE=</tt>.</li>
	<li>Stripping the trailing padding characters and concatenating with the separat or, the unique identifier is therefore <tt>aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE</ tt>, and the client makes the request:</li>	<li>Stripping the trailing padding characters and concatenating with the separat or, the unique identifier is therefore <tt>aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE</ tt>, and the client makes the request:</li>
	</ol>	</ol>


	<sourcecode type="text"><![CDATA[GET /renewal-info/aYhba4dGQEHhs3uEe6CuLN4ByNQ.A	<sourcecode type=""><![CDATA[
	IdlQyE HTTP/1.1	GET /renewal-info/aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE HTTP/1.1
	Host: acme.example.com	Host: acme.example.com
	Accept: application/json	Accept: application/json

	]]>	]]></sourcecode>
	</sourcecode>
	</section>	</section>

	<section anchor="renewalinfo-objects"><name>RenewalInfo Objects</name>	<section anchor="renewalinfo-objects"><name>RenewalInfo Objects</name>
	<t>The structure of an ACME <tt>renewalInfo</tt> resource is as follows:</t>	<t>The structure of an ACME <tt>renewalInfo</tt> resource is as follows:</t>

	<t><tt>suggestedWindow</tt> (object, required): A JSON object with two keys, "<t
	t>start</tt>" and "<tt>end</tt>", whose values are timestamps, encoded in the fo
	rmat specified in <xref target="RFC3339"/>, which bound the window of time in wh
	ich the CA recommends renewing the certificate.</t>
	<t><tt>explanationURL</tt> (string, optional): A URL pointing to a page which ma
	y explain why the suggested renewal window has its current value. For example, i
	t may be a page explaining the CA's dynamic load-balancing strategy, or a page d
	ocumenting which certificates are affected by a mass revocation event. Clients <
	bcp14>SHOULD</bcp14> provide this URL to their operator, if present.</t>


	<sourcecode type="json"><![CDATA[HTTP/1.1 200 OK	<dl spacing="normal" newline="true">
		<dt><tt>suggestedWindow</tt> (object, required):</dt><dd>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"/>, which bound the
		window of time in which the CA recommends renewing the certificate.</dd>
		<dt><tt>explanationURL</tt> (string, optional):</dt><dd>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"><![CDATA[
		HTTP/1.1 200 OK
	Content-Type: application/json	Content-Type: application/json
	Retry-After: 21600	Retry-After: 21600

	{	{
	"suggestedWindow": {	"suggestedWindow": {
	"start": "2025-01-02T04:00:00Z",	"start": "2025-01-02T04:00:00Z",
	"end": "2025-01-03T04:00:00Z"	"end": "2025-01-03T04:00:00Z"
	},	},
	"explanationURL": "https://acme.example.com/docs/ari"	"explanationURL": "https://acme.example.com/docs/ari"
	}	}

	]]>	]]></sourcecode>
	</sourcecode>
	<t>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>	<t>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="compact">	<ol spacing="normal">
	<li>Query the <tt>renewalInfo</tt> resource to get a suggested renewal window.</ li>	<li>Query the <tt>renewalInfo</tt> resource to get a suggested renewal window.</ li>
	<li>Select a uniform random time within the suggested window.</li>	<li>Select a uniform random time within the suggested window.</li>
	<li>If the selected time is in the past, attempt renewal immediately.</li>	<li>If the selected time is in the past, attempt renewal immediately.</li>
	<li>Otherwise, if the client can schedule itself to attempt renewal at exactly t he selected time, do so.</li>	<li>Otherwise, if the client can schedule itself to attempt renewal at exactly t he selected time, do so.</li>
	<li>Otherwise, if the selected time is before the next time that the client woul d wake up normally, attempt renewal immediately.</li>	<li>Otherwise, if the selected time is before the next time that the client woul d wake up normally, attempt renewal immediately.</li>
	<li>Otherwise, sleep until the time indicated by the <tt>Retry-After</tt> header and return to Step 1.</li>	<li>Otherwise, sleep until the time indicated by the <tt>Retry-After</tt> header and return to Step 1.</li>
	</ol>	</ol>


	<t>In all cases, renewal attempts are subject to the client's existing error bac koff and retry intervals.</t>	<t>In all cases, renewal attempts are subject to the client's existing error bac koff and retry intervals.</t>

	<t>In particular, cron-based clients may find they need to increase their run fr	<t>In particular, cron-based clients may find they need to increase their run fr
	equency to check ARI more frequently. Those clients will need to store informati	equency to check ARI more frequently. Those clients will need to store informati
	on about failures so that increasing their run frequency doesn't lead to retryin	on about failures so that increasing their run frequency doesn't lead to retryin
	g failures without proper backoff. Typical information stored should include: nu	g failures without proper backoff. Typical information stored should include: nu
	mber of failures for a given order (defined by the set of names on the order), a	mber of failures for a given order (defined by the set of names on the order) an
	nd time of the most recent failure.</t>	d time of the most recent failure.</t>
	<t>A RenewalInfo object in which the <tt>end</tt> timestamp equals or precedes t	<t>A RenewalInfo object in which the <tt>end</tt> timestamp equals or precedes t
	he <tt>start</tt> timestamp is invalid. Servers MUST NOT serve such a response,	he <tt>start</tt> timestamp is invalid. Servers <bcp14>MUST NOT</bcp14> serve su
	and clients MUST treat one as though they failed to receive any response from th	ch a response, and clients <bcp14>MUST</bcp14> treat one as though they failed t
	e server (e.g., retry at an appropriate interval, renew on a fallback schedule,	o receive any response from the server (e.g., retry at an appropriate interval,
	etc.).</t>	renew on a fallback schedule, etc.).</t>
	</section>	</section>


	<section anchor="schedule-for-checking-the-renewalinfo-resource"><name>Schedule	<section anchor="schedule-for-checking-the-renewalinfo-resource"><name>Schedule
	for checking the RenewalInfo resource</name>	for Checking the RenewalInfo Resource</name>
	<t>Clients SHOULD fetch a certificate's RenewalInfo immediately after issuance.<	<t>Clients <bcp14>SHOULD</bcp14> fetch a certificate's RenewalInfo immediately a
	/t>	fter issuance.</t>
	<t>During the lifetime of a certificate, the renewal information needs to be fet	<t>During the lifetime of a certificate, the renewal information needs to be fet
	ched frequently enough that clients learn about changes in the suggested window	ched frequently enough that clients learn about changes in the suggested window
	quickly, but without overwhelming the server. This protocol uses the Retry-After	quickly, but without overwhelming the server. This protocol uses the Retry-After
	header <xref target="RFC9110"/> to indicate to clients how often to retry. Note	header <xref target="RFC9110"/> to indicate to clients how often to retry. Note
	that in other HTTP applications, Retry-After often indicates the minimum time t	that in other HTTP applications, Retry-After often indicates the minimum time t
	o wait before retrying a request. In this protocol, it indicates the desired (i.	o 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>	e., both requested minimum and maximum) amount of time to wait.</t>
	<t>Clients MUST NOT check a certificate's RenewalInfo after the certificate has	<t>Clients <bcp14>MUST NOT</bcp14> check a certificate's RenewalInfo after the c
	expired. Clients MUST NOT check a certificate's RenewalInfo after they consider	ertificate has expired. Clients <bcp14>MUST NOT</bcp14> check a certificate's Re
	the certificate to be replaced (for instance, after a new certificate for the sa	newalInfo after they consider the certificate to be replaced (for instance, afte
	me identifiers has been received and configured).</t>	r a new certificate for the same identifiers has been received and configured).<
		/t>


	<section anchor="server-choice-of-retry-after"><name>Server choice of Retry-Afte	<section anchor="server-choice-of-retry-after"><name>Server Choice of Retry-Afte
	r</name>	r</name>
	<t>Servers set the Retry-After header based on their requirements on how quickly	<t>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 certificat	to perform a revocation. For instance, a server that needs to revoke certificat
	es within 24 hours of notification of a problem might choose to reserve twelve h	es within 24 hours of notification of a problem might choose to reserve twelve h
	ours for investigation, six hours for clients to fetch RenewalInfo, and six hour	ours for investigation, six hours for clients to fetch RenewalInfo, and six hour
	s for clients to perform a renewal. Setting a small value for Retry-After means	s 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.	that clients can respond more quickly but also incurs more load on the server. S
	Servers should estimate their expected load based on the number of clients, keep	ervers should estimate their expected load based on the number of clients, keepi
	ing in mind that third parties may also monitor RenewalInfo endpoints.</t>	ng in mind that third parties may also monitor RenewalInfo endpoints.</t>
	</section>	</section>


	<section anchor="client-handling-of-retry-after"><name>Client handling of Retry-	<section anchor="client-handling-of-retry-after"><name>Client Handling of Retry-
	After</name>	After</name>
	<t>After an initial fetch of a certificate's RenewalInfo, clients MUST fetch it	<t>After an initial fetch of a certificate's RenewalInfo, clients <bcp14>MUST</b
	again as soon as possible after the time indicated in the Retry-After header (ba	cp14> fetch it again as soon as possible after the time indicated in the Retry-A
	ckoff on errors takes priority, though). Clients MUST set reasonable limits on t	fter header (backoff on errors takes priority, though). Clients <bcp14>MUST</bcp
	heir checking interval. For example, values under one minute could be treated as	14> set reasonable limits on their checking interval. For example, values under
	if they were one minute, and values over one day could be treated as if they we	one minute could be treated as if they were one minute, and values over one day
	re one day.</t>	could be treated as if they were one day.</t>
	</section>	</section>


	<section anchor="error-handling"><name>Error handling</name>	<section anchor="error-handling"><name>Error Handling</name>
	<t>Temporary errors include, for instance:</t>	<t>Temporary errors include, for instance:</t>

	<ul spacing="compact">	<ul spacing="compact">
	<li>Connection timeout</li>	<li>Connection timeout</li>
	<li>Request timeout</li>	<li>Request timeout</li>
	<li>5xx HTTP errors</li>	<li>5xx HTTP errors</li>
	</ul>	</ul>

	<t>On receiving a temporary error, clients SHOULD do exponential backoff with a	<t>On receiving a temporary error, clients <bcp14>SHOULD</bcp14> do exponential
	capped number of tries. If all tries are exhausted, clients MUST treat the reque	backoff with a capped number of tries. If all tries are exhausted, clients <bcp1
	st as a long-term error.</t>	4>MUST</bcp14> treat the request as a long-term error.</t>
	<t>Long term errors include, for instance:</t>	<t>Examples of long-term errors include:</t>

	<ul spacing="compact">	<ul spacing="compact">
	<li>Retry-After is invalid or not present</li>	<li>Retry-After is invalid or not present</li>
	<li>RenewalInfo object is invalid</li>	<li>RenewalInfo object is invalid</li>
	<li>DNS lookup failure</li>	<li>DNS lookup failure</li>
	<li>Connection refused</li>	<li>Connection refused</li>
	<li>Non-5xx HTTP error</li>	<li>Non-5xx HTTP error</li>
	</ul>	</ul>

	<t>On receiving a long term error, clients MUST perform the next RenewalInfo fet ch as soon as possible after six hours have passed (or some other locally config ured default).</t>	<t>On receiving a long-term error, clients <bcp14>MUST</bcp14> perform the next RenewalInfo fetch as soon as possible after six hours have passed (or some other locally configured default).</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="extensions-to-the-order-object"><name>Extensions to the Order O bject</name>	<section anchor="extensions-to-the-order-object"><name>Extensions to the Order O bject</name>
	<t>In order to convey information regarding which certificate requests represent renewals of previous certificates, a new field is added to the Order object:</t >	<t>In order to convey information regarding which certificate requests represent renewals of previous certificates, a new field is added to the Order object:</t >

	<t><tt>replaces</tt> (string, optional): A string uniquely identifying a previou	<dl spacing="normal" newline="true">
	sly-issued certificate which this order is intended to replace. This unique iden	<dt><tt>replaces</tt> (string, optional):</dt><dd>A string uniquely
	tifier is constructed in the same way as the path component for GET requests des	identifying a previously issued certificate that this order is intended to
	cribed above.</t>	replace. This unique identifier is constructed in the same way as the path
		component for GET requests described above.</dd>
		</dl>
	<t>Clients <bcp14>SHOULD</bcp14> include this field in New Order requests if the re is a clear predecessor certificate, as is the case for most certificate renew als. 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>	<t>Clients <bcp14>SHOULD</bcp14> include this field in New Order requests if the re is a clear predecessor certificate, as is the case for most certificate renew als. 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="text"><![CDATA[POST /new-order HTTP/1.1	<sourcecode type=""><![CDATA[
		POST /new-order HTTP/1.1
	Host: acme.example.com	Host: acme.example.com
	Content-Type: application/jose+json	Content-Type: application/jose+json

	{	{
	"protected": base64url({	"protected": base64url({
	"alg": "ES256",	"alg": "ES256",
	"kid": "https://acme.example.com/acct/evOfKhNU60wg",	"kid": "https://acme.example.com/acct/evOfKhNU60wg",
	"nonce": "5XJ1L3lEkMG7tR6pA00clA",	"nonce": "5XJ1L3lEkMG7tR6pA00clA",
	"url": "https://acme.example.com/new-order"	"url": "https://acme.example.com/new-order"
	}),	}),
	"payload": base64url({	"payload": base64url({
	"identifiers": [	"identifiers": [
	{ "type": "dns", "value": "acme.example.com" }	{ "type": "dns", "value": "acme.example.com" }
	],	],
	"replaces": "aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE"	"replaces": "aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE"
	}),	}),
	"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"	"signature": "H6ZXtGjTZyUnPeKn...wEA4TklBdh3e454g"
	}	}

	]]>	]]></sourcecode>
	</sourcecode>	<t>Servers <bcp14>SHOULD</bcp14> check that the identified certificate and the N
	<t>Servers <bcp14>SHOULD</bcp14> check that the identified certificate and the N	ew Order request correspond to the same ACME Account, that they share at least o
	ew Order request correspond to the same ACME Account, that they share at least o	ne identifier, and that the identified certificate has not already been marked a
	ne identifier, and that the identified certificate has not already been marked a	s replaced by a different Order that is not "invalid". Correspondence checks bey
	s replaced by a different Order that is not "invalid". Correspondence checks bey	ond this (such as requiring exact identifier matching) are left up to Server pol
	ond this (such as requiring exact identifier matching) are left up to Server pol	icy. If any of these checks fail, the Server <bcp14>SHOULD</bcp14> reject the ne
	icy. If any of these checks fail, the Server <bcp14>SHOULD</bcp14> reject the ne	w-order request. If the Server rejects the request because the identified certif
	w-order request. If the Server rejects the request because the identified certif	icate has already been marked as replaced, it <bcp14>MUST</bcp14> return an HTTP
	icate has already been marked as replaced, it <bcp14>MUST</bcp14> return an HTTP	409 (Conflict) with a problem document of type "alreadyReplaced" (see <xref tar
	409 (Conflict) with a problem document of type "alreadyReplaced" (see Section 7	get="acme-error-types"/>).</t>
	.4).</t>
	<t>If the Server accepts a new-order request with a "replaces" field, it <bcp14> MUST</bcp14> reflect that field in the response and in subsequent requests for t he corresponding Order object.</t>	<t>If the Server accepts a new-order request with a "replaces" field, it <bcp14> MUST</bcp14> reflect that field in the response and in subsequent requests for t he corresponding Order object.</t>
	<t>This replacement information may serve many purposes, including but not limit ed to:</t>	<t>This replacement information may serve many purposes, including but not limit ed to:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>granting New Order requests which arrive during the suggested renewal window	<li>granting New Order requests that arrive during the suggested renewal window
	of their identified predecessor certificate higher priority or allow them to by	of their identified predecessor certificate higher priority or allowing them to
	pass rate limits, if the Server's policy uses such;</li>	bypass rate limits, if the Server's policy uses such;</li>
	<li>tracking the replacement of certificates which have been affected by a compl	<li>tracking the replacement of certificates that have been affected by a compli
	iance incident, so that they can be revoked immediately after they are replaced;	ance incident, so that they can be revoked immediately after they are replaced;
	and</li>	and</li>
	<li>tying together certificates issued under the same contract with an entity id entified by External Account Binding.</li>	<li>tying together certificates issued under the same contract with an entity id entified by External Account Binding.</li>
	</ul>	</ul>
	</section>	</section>

	<section anchor="security-considerations"><name>Security Considerations</name>	<section anchor="security-considerations"><name>Security Considerations</name>

	<t>The extensions to the ACME protocol described in this document builds upon th	<t>The extensions to the ACME protocol described in this document build upon the
	e Security Considerations and threat model defined in <xref target="RFC8555"/>,	security considerations and threat model defined in <xref target="RFC8555" sect
	Section 10.1.</t>	ion="10.1"/>.</t>
	<t>This document specifies that <tt>renewalInfo</tt> resources are exposed and a	<t>This document specifies that <tt>renewalInfo</tt> resources are exposed and a
	ccessed via unauthenticated GET requests, a departure from RFC8555's requirement	ccessed via unauthenticated GET requests, a departure from the requirement in RF
	that clients send POST-as-GET requests to fetch resources from the server. This	C 8555 that clients send POST-as-GET requests to fetch resources from the server
	is because the information contained in <tt>renewalInfo</tt> resources is not c	. This is because the information contained in <tt>renewalInfo</tt> resources is
	onsidered confidential, and because allowing <tt>renewalInfo</tt> to be easily c	not considered confidential and because allowing <tt>renewalInfo</tt> to be eas
	ached is advantageous to shed the load from clients which do not respect the Ret	ily cached is advantageous to shed the load from clients that do not respect the
	ry-After header. As always, servers should take measures to ensure that unauthen	Retry-After header. As always, servers should take measures to ensure that unau
	ticated requests for renewal information cannot result in denial-of-service atta	thenticated requests for renewal information cannot result in denial-of-service
	cks. These measures might include ensuring that a cache does not include superfl	attacks. These measures might include ensuring that a cache does not include sup
	uous request headers or query parameters in its cache key, instituting IP-based	erfluous request headers or query parameters in its cache key, instituting IP-ba
	rate limits, or other general best-practice measures.</t>	sed rate limits, or other general best-practice measures.</t>
	<t>Note that this protocol could exhibit undesired behavior in the presence of s	<t>Note that this protocol could exhibit undesired behavior in the presence of s
	ignificant clock skew between the ACME client and server. For example, if a serv	ignificant clock skew between the ACME client and server. For example, if a serv
	er places the suggested renewal window wholly in the past to encourage a client	er 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	to renew immediately, a client with a sufficiently slow clock might nonetheless
	see the window as being in the future. Similarly, a server which wishes to sched	see the window as being in the future. Similarly, a server that wishes to schedu
	ule renewals very precisely may have difficulty doing so if some clients have sk	le renewals very precisely may have difficulty doing so if some clients have ske
	ewed clocks (or do no implement ARI at all). Server operators should take this c	wed clocks (or do no implement ARI at all). Server operators should take this co
	oncern into account when setting suggested renewal windows. However, many other	ncern into account when setting suggested renewal windows. However, many other p
	protocols (including TLS handshakes themselves) fall apart with sufficient clock	rotocols (including TLS handshakes themselves) fall apart with sufficient clock
	skew, so this is not unique to this protocol.</t>	skew, so this is not unique to this protocol.</t>
	</section>	</section>


	<section anchor="iana-considerations"><name>IANA Considerations</name>	<section anchor="iana-considerations">
		<name>IANA Considerations</name>


	<section anchor="acme-resource-type"><name>ACME Resource Type</name>	<!--[rfced] We had the following questions related to the IANA
	<t>IANA will add the following entry to the "ACME Resource Types" registry withi	Considerations section:
	n the "Automated Certificate Management Environment (ACME) Protocol" registry gr
	oup at <eref target="https://www.iana.org/assignments/acme">https://www.iana.org	a) Section 7.1: In the Resource Type column of Table 2, please review if "Renewa
	/assignments/acme</eref>:</t>	l info", "Renewal Information", or "renewalInfo" or something else should be use
		d instead of "Renewal Info" as this is the only occurrence in the document of th
		is form (other than Table 1, which also uses "Renewal info").

		Original:
		Renewal Info object

		b) Section 7.2: FYI - we have added a citation to RFC 8126 in the
		description of the Registration Procedure and a corresponding entry in
		the Informative References section. Please let us know any concerns.

		c) FYI- we will communicate any nits/edits to IANA upon the completion
		of AUTH48.

		-->

		<section anchor="acme-resource-type">
		<name>ACME Resource Type</name>
		<t>IANA has added the following entry to the "ACME Resource Types" registry wi
		thin the "Automated Certificate Management Environment (ACME) Protocol" registry
		group at <eref target="https://www.iana.org/assignments/acme" brackets="angle"/
		>:</t>
	<table>	<table>
	<thead>	<thead>
	<tr>	<tr>
	<th>Field Name</th>	<th>Field Name</th>
	<th>Resource Type</th>	<th>Resource Type</th>
	<th>Reference</th>	<th>Reference</th>
	</tr>	</tr>
	</thead>	</thead>

	<tbody>	<tbody>
	<tr>	<tr>
	<td>renewalInfo</td>	<td>renewalInfo</td>
	<td>Renewal Info object</td>	<td>Renewal Info object</td>
	<td>This document</td>	<td>This document</td>
	</tr>	</tr>
	</tbody>	</tbody>
	</table></section>	</table></section>


	<section anchor="acme-renewal-info-object-fields"><name>ACME Renewal Info Object	<section anchor="acme-renewal-info-object-fields">
	Fields</name>	<name>ACME Renewal Info Object Fields</name>
	<t>IANA will add the following new registry to the "Automated Certificate Manage	<t>IANA has added the following new registry to the "Automated Certificate
	ment Environment (ACME) Protocol" registry group at <eref target="https://www.ia	Management Environment (ACME) Protocol" registry group at <eref
	na.org/assignments/acme">https://www.iana.org/assignments/acme</eref>:</t>	target="https://www.iana.org/assignments/acme" brackets="angle"/>:</t>
	<t>Registry Name: ACME Renewal Info Object Fields</t>
	<t>Registration Procedure: Specification Required. The designated expert should
	ensure that any new fields added to this registry carry useful and unique inform
	ation that does not better belong elsewhere in the ACME protocol.</t>
	<t>Template:</t>

	<ul spacing="compact">
	<li>Field name: The string to be used as a field name in the JSON object</li>
	<li>Field type: The type of value to be provided, e.g., string, boolean, array o
	f string</li>
	<li>Reference: Where this field is defined</li>
	</ul>
	<t>Initial contents:</t>
	<table>
	<thead>
	<tr>
	<th>Field Name</th>
	<th>Field type</th>
	<th>Reference</th>
	</tr>
	</thead>


	<tbody>	<dl spacing="normal" newline="true">
	<tr>	<dt>Registry Name:</dt><dd>ACME Renewal Info Object Fields</dd>
	<td>suggestedWindow</td>	<dt>Registration Procedure:</dt><dd>Specification Required (see <xref target
	<td>object</td>	="RFC8126"/>). The designated
	<td>This document</td>	expert should ensure that any new fields added to this registry carry
	</tr>	useful and unique information that does not better belong elsewhere in the
		ACME protocol.</dd>
		<dt>Template:</dt>
		<dd>
		<dl spacing="compact" newline="false">
		<dt>Field name:</dt><dd>The string to be used as a field name in the JSON
		object</dd>
		<dt>Field type:</dt><dd>The type of value to be provided, e.g., string, b
		oolean, array of string</dd>
		<dt>Reference:</dt><dd>Where this field is defined</dd>
		</dl>
		</dd>
		<dt>Initial contents:</dt>
		<dd>
		<table>
		<thead>
		<tr>
		<th>Field Name</th>
		<th>Field Type</th>
		<th>Reference</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>suggestedWindow</td>
		<td>object</td>
		<td>This document</td>
		</tr>
		<tr>
		<td>explanationURL</td>
		<td>string</td>
		<td>This document</td>
		</tr>
		</tbody>
		</table>
		</dd>
		</dl>


	<tr>	</section>
	<td>explanationURL</td>
	<td>string</td>
	<td>This document</td>
	</tr>
	</tbody>
	</table></section>


	<section anchor="acme-order-object-fields"><name>ACME Order Object Fields</name>	<section anchor="acme-order-object-fields">
	<t>IANA will add the following entry to the "ACME Order Object Fields" registry	<name>ACME Order Object Fields</name>
	within the "Automated Certificate Management Environment (ACME) Protocol" regist	<t>IANA has added the following entry to the "ACME Order Object Fields"
	ry group at <eref target="https://www.iana.org/assignments/acme">https://www.ian	registry within the "Automated Certificate Management Environment (ACME)
	a.org/assignments/acme</eref>:</t>	Protocol" registry group at <eref
	<table>	target="https://www.iana.org/assignments/acme" brackets="angle"/>:</t>
	<thead>
	<tr>
	<th>Field Name</th>
	<th>Field Type</th>
	<th>Configurable</th>
	<th>Reference</th>
	</tr>
	</thead>


	<tbody>	<table>
	<tr>	<thead>
	<td>replaces</td>	<tr>
	<td>string</td>	<th>Field Name</th>
	<td>true</td>	<th>Field Type</th>
	<td>This document</td>	<th>Configurable</th>
	</tr>	<th>Reference</th>
	</tbody>	</tr>
	</table></section>	</thead>
		<tbody>
		<tr>
		<td>replaces</td>
		<td>string</td>
		<td>true</td>
		<td>This document</td>
		</tr>
		</tbody>
		</table>
		</section>


	<section anchor="acme-error-types"><name>ACME Error Types</name>	<section anchor="acme-error-types">
	<t>IANA will add the following entry to the "ACME Error Types" registry within t	<name>ACME Error Types</name>
	he "Automated Certificate Management Environment (ACME) Protocol" registry group	<t>IANA has added the following entry to the "ACME Error Types" registry
	at <eref target="https://www.iana.org/assignments/acme">https://www.iana.org/as	within the "Automated Certificate Management Environment (ACME) Protocol"
	signments/acme</eref>:</t>	registry group at <eref
	<table>	target="https://www.iana.org/assignments/acme" brackets="angle"/>:</t>
	<thead>
	<tr>
	<th>Type</th>
	<th>Description</th>
	<th>Reference</th>
	</tr>
	</thead>


	<tbody>	<table>
	<tr>	<thead>
	<td>alreadyReplaced</td>	<tr>
	<td>The request specified a predecessor certificate which has already been marke	<th>Type</th>
	d as replaced</td>	<th>Description</th>
	<td>This document</td>	<th>Reference</th>
	</tr>	</tr>
	</tbody>	</thead>
	</table></section>	<tbody>
		<tr>
		<td>alreadyReplaced</td>
		<td>The request specified a predecessor certificate that has already been
		marked as replaced</td>
		<td>This document</td>
		</tr>
		</tbody>
		</table>
		</section>
	</section>	</section>

	</middle>	</middle>

	<back>	<back>
	<references><name>References</name>	<references><name>References</name>
	<references><name>Normative References</name>	<references><name>Normative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3339.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml" />
	</references>	</references>
	<references><name>Informative References</name>	<references><name>Informative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3647.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3647.xml" />

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

	<section anchor="appendix-a-example-certificate" numbered="false"><name>Appendix A. Example Certificate</name>	<section anchor="appendix-a-example-certificate" numbered="false"><name>Appendix A. Example Certificate</name>


	<sourcecode type="text"><![CDATA[-----BEGIN CERTIFICATE-----	<sourcecode type=""><![CDATA[
		-----BEGIN CERTIFICATE-----
	MIIBQzCB66ADAgECAgUAh2VDITAKBggqhkjOPQQDAjAVMRMwEQYDVQQDEwpFeGFt	MIIBQzCB66ADAgECAgUAh2VDITAKBggqhkjOPQQDAjAVMRMwEQYDVQQDEwpFeGFt
	cGxlIENBMCIYDzAwMDEwMTAxMDAwMDAwWhgPMDAwMTAxMDEwMDAwMDBaMBYxFDAS	cGxlIENBMCIYDzAwMDEwMTAxMDAwMDAwWhgPMDAwMTAxMDEwMDAwMDBaMBYxFDAS
	BgNVBAMTC2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeBZu	BgNVBAMTC2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeBZu
	7cbpAYNXZLbbh8rNIzuOoqOOtmxA1v7cRm//AwyMwWxyHz4zfwmBhcSrf47NUAFf	7cbpAYNXZLbbh8rNIzuOoqOOtmxA1v7cRm//AwyMwWxyHz4zfwmBhcSrf47NUAFf
	qzLQ2PPQxdTXREYEnKMjMCEwHwYDVR0jBBgwFoAUaYhba4dGQEHhs3uEe6CuLN4B	qzLQ2PPQxdTXREYEnKMjMCEwHwYDVR0jBBgwFoAUaYhba4dGQEHhs3uEe6CuLN4B
	yNQwCgYIKoZIzj0EAwIDRwAwRAIge09+S5TZAlw5tgtiVvuERV6cT4mfutXIlwTb	yNQwCgYIKoZIzj0EAwIDRwAwRAIge09+S5TZAlw5tgtiVvuERV6cT4mfutXIlwTb
	+FYN/8oCIClDsqBklhB9KAelFiYt9+6FDj3z4KGVelYM5MdsO3pK	+FYN/8oCIClDsqBklhB9KAelFiYt9+6FDj3z4KGVelYM5MdsO3pK
	-----END CERTIFICATE-----	-----END CERTIFICATE-----

	]]>	]]></sourcecode>
	</sourcecode>
	</section>	</section>


	<section anchor="acknowledgments" numbered="false"><name>Acknowledgments</name>	<section anchor="acknowledgments" numbered="false">
	<t>My thanks to Roland Shoemaker and Jacob Hoffman-Andrews for coming up with th	<name>Acknowledgments</name>
	e initial idea of ARI and for helping me learn the IETF process. Thanks also to	<t>My thanks to <contact fullname="Roland Shoemaker"/> and <contact fullname="Ja
	Samantha Frank, Matt Holt, Ilari Liusvaara, and Wouter Tinus for contributing cl	cob Hoffman-Andrews"/> for coming up with the initial idea of ARI and for helpin
	ient implementations, and to Freddy Zhang for contributing an independent server	g me learn the IETF process. Thanks also to <contact fullname="Samantha Frank"/>
	implementation. Finally, thanks to Rob Stradling, Andrew Ayer, and J.C. Jones f	, <contact fullname="Matt Holt"/>, <contact fullname="Ilari Liusvaara"/>, and <c
	or providing meaningful feedback and suggestions which significantly improved th	ontact fullname="Wouter Tinus"/> for contributing client implementations, and to
	is specification.</t>	<contact fullname="Freddy Zhang"/> for contributing an independent server imple
		mentation. Finally, thanks to <contact fullname="Rob Stradling"/>, <contact full
		name="Andrew Ayer"/>, and <contact fullname="J.C. Jones"/> for providing meaning
		ful feedback and suggestions that significantly improved this specification.</t>
	</section>	</section>

	</back>	</back>


		<!--[rfced] Please review the following questions related to terminology use thr
		oughout the document.

		a) We see mixed marking of the following terms throughout the
		document. Please let us know if/how these may be made uniform:

		"renewalInfo" resource vs. renewalInfo resource

		New Order request vs. new-order request

		Server vs. server

		base64url-encoding vs. base64url encoding

		b) There are instances of simply RenewalInfo. Should a label follow
		(e.g., object, resource, etc.) for the ease of the reader?

		-->

		<!--[rfced] We note the use of the <tt> element to mark text in this document. S
		ee the list of marked terms below.

		a) We recommend authors review the output of this element in all
		output formats (text, pdf, html, etc.) to ensure it appears as
		expected across formats.

		b) Please review for consistent use throughout the document (as we see some occu
		rrences that are not marked with <tt>) and either update the edited XML file dir
		ectly or let the RPC know if/how we may update.

		00:87:65:43:21
		0x87
		69:88:5B:6B:87:46:40:41:E1:B3:7B:84:7B:A0:AE:2C:DE:01:C8:D4
		AIdlQyE=
		aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE
		aYhba4dGQEHhs3uEe6CuLN4ByNQ=
		cron
		end
		explanationURL
		keyIdentifier
		renewalInfo
		replaces
		Retry-After
		start
		suggestedWindow
		=
		\|\|

		-->

		<!-- [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. 48 change blocks.
	293 lines changed or deleted	447 lines changed or added
This html diff was produced by rfcdiff 1.48.