Internet Engineering Task Force (IETF) A. Gable
Request for Comments: 9773 Internet Security Research Group
Category: Standards Track June 2025
ISSN: 2070-1721
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.
このドキュメントは、自動化された証明書管理環境（ACME）サーバーが、ACMEクライアントが証明書を更新しようとする時期について提案を提供する方法を指定します。これにより、サーバーはロードスパイクを軽減し、クライアントが適切な証明書更新期間について誤った仮定を行わないようにします。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9773.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9773で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Definitions
3. Extensions to the Directory Object
4. Getting Renewal Information
4.1. The RenewalInfo Resource
4.2. RenewalInfo Objects
4.3. Schedule for Checking the RenewalInfo Resource
4.3.1. Server Choice of Retry-After
4.3.2. Client Handling of Retry-After
4.3.3. Error Handling
5. Extensions to the Order Object
6. Security Considerations
7. IANA Considerations
7.1. ACME Resource Type
7.2. ACME RenewalInfo Object Fields
7.3. ACME Order Object Fields
7.4. ACME Error Types
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Example Certificate
Acknowledgments
Author's Address
Most ACME [RFC8555] clients today choose when to attempt to renew a certificate in one of three ways:
今日、ほとんどのACME [RFC8555]クライアントは、3つの方法のいずれかで証明書を更新しようとするタイミングを選択します。
1. they may be configured to renew at a specific interval (e.g., via cron),
1. 特定の間隔で更新するように構成されている場合があります（例：Cronを介して）、
2. they may parse the issued certificate to determine its expiration date and renew a specific amount of time before then, or
2. 発行された証明書を解析して有効期限を決定し、それ以前に特定の時間を更新するか、
3. they may parse the issued certificate and renew when some percentage of its validity period has passed.
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.
最初の2つは、証明書の寿命を変更する発行認証局（CA）に対する重要な障壁を生み出します。3つの方法はすべて、更新リクエストをスケジュールできないため、発行CAのロードクラスタリングにつながる可能性があります。
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:
発行CAがクライアントが証明書を更新する期間を提案できるようにすることで、動的な時間ベースの負荷分散を可能にします。これにより、CAは例外的な状況によりよく対応できます。例えば：
* a CA could suggest that clients renew prior to a mass-revocation event to mitigate the impact of the revocation, or
* CAは、クライアントが大量補償イベントの前に更新して、失効の影響を軽減することを示唆する可能性があります。
* a CA could suggest that clients renew earlier than they normally would to reduce the size of an upcoming mass-renewal spike.
* CAは、クライアントが今後の大量腎スパイクのサイズを削減するよりも早く更新することを示唆することができます。
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.
このドキュメントは、ACME更新情報（ARI）拡張機能を指定します。これは、ACMEサーバーがACMEクライアントに提案された更新ウィンドウを提供するメカニズムであり、ACMEクライアントがACMEサーバーに、証明書を更新および交換したことを正常に更新および交換したことを通知することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Throughout this document, the word "renewal" and its variants are taken to encompass any combination of "Renewal", "Re-Key", and "Modification" as defined in [RFC3647].
このドキュメント全体で、「更新」という言葉とそのバリアントは、[RFC3647]で定義されている「更新」、「再キー」、および「修正」の組み合わせを包含するように使用されます。
This document assumes that the certificates being issued by the ACME server are in compliance with [RFC5280] and, in particular, contain the Authority Key Identifier extension and the keyIdentifier field within that extension.
このドキュメントは、ACMEサーバーによって発行されている証明書が[RFC5280]に準拠していることを前提としており、特に、その拡張内の権限の識別子拡張機能とKeyIdentifierフィールドが含まれています。
An ACME server that wishes to provide renewal information MUST include a new field, "renewalInfo", in its directory object.
更新情報の提供を希望するACMEサーバーには、ディレクトリオブジェクトに新しいフィールド「LenewAlinfo」を含める必要があります。
+=============+=====================+
| Field | URL in Value |
+=============+=====================+
| renewalInfo | Renewal information |
+-------------+---------------------+
Table 1
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
}
}
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.
RenewAlinfoリソースは、ACMEプロトコルに導入された新しいリソースタイプです。この新しいリソースを使用すると、クライアントは証明書を更新する時期についての提案をサーバーに照会できます。
To request the suggested renewal information for a certificate, the client sends an unauthenticated GET request to a path under the server's renewalInfo URL.
証明書の提案された更新情報をリクエストするために、クライアントはサーバーのrennewAlinfo URLの下のパスに認知度のないGETリクエストを送信します。
The path component is a unique identifier for the certificate in question. 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 character ".", and the base64url encoding of the DER-encoded Serial Number field (without the tag and length bytes). All trailing "=" characters MUST be stripped from both parts of the unique identifier.
パスコンポーネントは、問題の証明書の一意の識別子です。一意の識別子は、証明書の権限識別子（AKI）[RFC5280]拡張機能、期間文字 "、およびder-encoded Serial数フィールドのbase64urlエンコーディング（タグと長さのフィールドのbase64urlエンコーディング）のキーアイデンティファイアフィールドの[RFC4648]をエンコードする[RFC4648]をエンコードするBase64URLを連結することにより構築されます。すべての後続の「=」文字は、一意の識別子の両方の部分から剥がす必要があります。
Thus, the full request URL is constructed as follows (split onto multiple lines for readability), where the "||" operator indicates string concatenation and the renewalInfo URL is taken from the Directory object:
したがって、完全なリクエストURLは次のように構築されます（読みやすさのために複数の行に分割されます）。オペレーターは文字列の連結を示し、更新用のURLはディレクトリオブジェクトから取得されます。
url = renewalInfo || '/' ||
base64url(AKI keyIdentifier) || '.' || base64url(Serial)
For example, to request renewal information for the end-entity certificate given in Appendix A, the client would make the request as follows:
たとえば、付録Aに記載されているエンドエンティティ証明書の更新情報を要求するために、クライアントは次のようにリクエストを行います。
1. The keyIdentifier field of the certificate's AKI extension has the hexadecimal bytes 69:88:5B:6B:87:46:40:41:E1:B3:7B:84:7B:A0:AE:2C:DE:01:C8:D4 as its ASN.1 Octet String value. The base64url encoding of those bytes is aYhba4dGQEHhs3uEe6CuLN4ByNQ=.
1. 証明書のAKI拡張機能のキーアイデンティファイアフィールドには、16進バイト69：88：5b：6b：87：46：40：41：e1：b3：7b：84：7b：a0：ae：2c：de：01：c8：d4がasn.1 octet string値です。これらのバイトのbase64urlエンコードは、ayhba4dgqehhs3uee6culn4bynq =です。
2. The certificate's Serial Number field has the hexadecimal bytes 00:87:65:43:21 as its DER encoding (note the leading zero byte to ensure the serial number remains positive despite the leading 1 bit in 0x87). The base64url encoding of those bytes is AIdlQyE=.
2. 証明書のシリアル番号フィールドには、DERエンコードとして16進バイト00：87：65：43：21があります（0x87の1ビットにもかかわらず、シリアル番号がプラスのままであることを確認するための主要なゼロバイトに注意してください）。これらのバイトのbase64urlエンコードは、aidlqye =です。
3. Stripping the trailing padding characters and concatenating with the separator, the unique identifier is therefore aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE, and the client makes the request:
3. したがって、トレーリングパディングキャラクターを剥ぎ取り、分離器と連結すると、一意の識別子はayhba4dgqehhs3uee6culn4bynq.aidlqyeであり、クライアントは次のようにリクエストを行います。
GET /renewal-info/aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE HTTP/1.1
Host: acme.example.com
Accept: application/json
The structure of an ACME RenewalInfo object is as follows:
ACME RenewAlinfoオブジェクトの構造は次のとおりです。
suggestedWindow (object, required):
scondedwindow（オブジェクト、必須）：
A JSON object with two keys, "start" and "end", whose values are timestamps, encoded in the format specified in [RFC3339], which bound the window of time in which the CA recommends renewing the certificate.
2つのキーを持つJSONオブジェクト、「Start」と「End」は、[RFC3339]で指定された形式でエンコードされたタイムスタンプであり、CAが証明書を更新することを推奨する時間の窓をバインドします。
explanationURL (string, optional):
Actonsurl（string、optional）：
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 SHOULD provide this URL to their operator, if present.
提案された更新ウィンドウに現在の値がある理由を説明するかもしれないページを指すURL。たとえば、CAの動的な負荷分散戦略を説明するページまたは、どの証明書が大量補償イベントの影響を受けるかを文書化するページである場合があります。クライアントは、存在する場合は、このURLをオペレーターに提供する必要があります。
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"
}
Clients MUST attempt renewal at a time of their choosing based on the suggested renewal window. The following algorithm is RECOMMENDED for choosing a renewal time:
クライアントは、提案された更新ウィンドウに基づいて、選択の時点で更新を試みる必要があります。更新時間を選択するには、次のアルゴリズムをお勧めします。
1. Make a renewalInfo request to get a suggested renewal window.
1. 提案された更新ウィンドウを取得するために、RenewAlinfoリクエストを作成します。
2. Select a uniform random time within the suggested window.
2. 提案されたウィンドウ内で均一なランダム時間を選択します。
3. If the selected time is in the past, attempt renewal immediately.
3. 選択した時間が過去にある場合は、すぐに更新を試みます。
4. Otherwise, if the client can schedule itself to attempt renewal at exactly the selected time, do so.
4. それ以外の場合、クライアントが正確に選択した時間に更新を試みるようにスケジュールできる場合は、そうしてください。
5. Otherwise, if the selected time is before the next time that the client would wake up normally, attempt renewal immediately.
5. それ以外の場合は、選択した時間が次回の時間の前にクライアントが通常目を覚ます前に、すぐに更新を試みます。
6. Otherwise, sleep until the time indicated by the Retry-After header and return to Step 1.
6. それ以外の場合は、再試行後のヘッダーによって示される時間まで眠り、ステップ1に戻ります。
In all cases, renewal attempts are subject to the client's existing error backoff and retry intervals.
すべての場合において、更新の試みは、クライアントの既存のエラーバックオフおよび再試行の対象となります。
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.
特に、Cronベースのクライアントは、ARIをより頻繁にチェックするために、実行周波数を増やす必要があると判断する場合があります。これらのクライアントは、障害に関する情報を保存する必要があり、実行周波数を増やすことで適切なバックオフなしで障害が再試行されないようにします。保存されている典型的な情報には、特定の注文の障害の数（注文上の識別子のセットで定義）および最新の障害の時間を含める必要があります。
A RenewalInfo object in which the end timestamp equals or precedes the start timestamp is invalid. Servers MUST NOT serve such a response, and clients MUST 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.).
エンドタイムスタンプがスタートタイムスタンプに等しいまたは先行する更新オブジェクトは無効です。サーバーはそのような応答を提供してはなりません。クライアントは、サーバーからの応答を受け取っていないかのように扱う必要があります（たとえば、適切な間隔で再試行したり、フォールバックスケジュールで更新するなど）。
Clients SHOULD fetch a certificate's RenewalInfo immediately after issuance.
クライアントは、発行直後に証明書のrennewAlinfoを取得する必要があります。
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 [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.
証明書の存続期間中、更新情報を頻繁に取得する必要があります。このプロトコルは、再試行後のヘッダー[RFC9110]を使用して、再試行頻度をクライアントに示します。他のHTTPアプリケーションでは、再試行後の再試行は、リクエストを再試行する前に待機する最小時間を示すことが多いことに注意してください。このプロトコルでは、待機するのに必要な（つまり、最小および最大の両方の最小値と最大の両方）を示します。
Clients MUST NOT check a certificate's RenewalInfo after the certificate has expired. Clients MUST NOT 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).
クライアントは、証明書の有効期限が切れた後、証明書のrennewAlinfoを確認してはなりません。クライアントは、証明書の交換を検討した後に証明書のrenledAlinfoをチェックしてはなりません（たとえば、同じ識別子の新しい証明書が受信および設定された後）。
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 renewalInfo endpoints.
サーバーは、取り消しを実行する速さに関する要件に基づいて、再試行後ヘッダーを設定します。たとえば、問題の通知から24時間以内に証明書を取り消す必要があるサーバーは、調査のために12時間、クライアントが更新されたRenewAlinfoオブジェクトを取得するのに6時間、クライアントが更新を行うのに6時間を保留することを選択する場合があります。再試行にわずかな値を設定することは、クライアントがより迅速に応答できることを意味しますが、サーバー上のより多くの負荷も発生することを意味します。サーバーは、クライアントの数に基づいて予想される負荷を推定する必要があります。サードパーティは、更新エンドポイントも監視する可能性があることに留意してください。
After an initial fetch of a certificate's RenewalInfo, clients MUST fetch it again as soon as possible after the time indicated in the Retry-After header (backoff on errors takes priority, though). Clients MUST 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.
証明書のrennewAlinfoの最初のフェッチの後、クライアントは再試行後のヘッダーに示された後、できるだけ早く再び取得する必要があります（ただし、エラーのバックオフは優先されます）。クライアントは、チェック間隔に合理的な制限を設定する必要があります。たとえば、1分未満の値は1分間であるかのように扱うことができ、1日以上の値は1日であるかのように扱うことができます。
Temporary errors include, for instance:
一時的なエラーには、たとえば：
* Connection timeout
* 接続タイムアウト
* Request timeout
* リクエストタイムアウト
* 5xx HTTP errors
* 5xx HTTPエラー
On receiving a temporary error, clients SHOULD do exponential backoff with a capped number of tries. If all tries are exhausted, clients MUST treat the request as a long-term error.
一時的なエラーを受信すると、クライアントはキャップの数のトライを使用して指数関数的なバックオフを行う必要があります。すべての試行が使い果たされている場合、クライアントはリクエストを長期的なエラーとして扱う必要があります。
Examples of long-term errors include:
長期エラーの例は次のとおりです。
* Retry-After is invalid or not present
* 再試行後は無効であるか、存在しません
* RenewalInfo object is invalid
* RenewAlinfoオブジェクトは無効です
* DNS lookup failure
* DNSルックアップ障害
* Connection refused
* 接続拒否
* Non-5xx HTTP error
* 非5xx HTTPエラー
On receiving a long-term error, clients MUST make the next renewalInfo request as soon as possible after six hours have passed (or some other locally configured default).
長期的なエラーを受信すると、クライアントは、6時間が経過した後、できるだけ早く次のRenewAlinfoリクエストを行う必要があります（または、ローカルで構成されたデフォルト）。
In order to convey information regarding which certificate requests represent renewals of previous certificates, a new field is added to the Order object:
どの証明書要求が以前の証明書の更新を表すかに関する情報を伝えるために、注文オブジェクトに新しいフィールドが追加されます。
replaces (string, optional):
交換（文字列、オプション）：
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 Section 4.1.
この注文が交換することを意図していることを以前に発行した証明書を一意に識別する文字列。この一意の識別子は、セクション4.1で説明されているGETリクエストのパスコンポーネントと同じ方法で構築されます。
Clients SHOULD include this field in newOrder requests if there is a clear predecessor certificate, as is the case for most certificate renewals. Clients SHOULD NOT include this field if the ACME server has not indicated that it supports this protocol by advertising the renewalInfo resource in its Directory.
クライアントは、ほとんどの証明書更新の場合と同様に、明確な前任者証明書がある場合は、このフィールドをNeworderリクエストに含める必要があります。ACMEサーバーがディレクトリにLenewAlinfoリソースを宣伝することによりこのプロトコルをサポートすることを示していない場合、クライアントはこのフィールドを含めるべきではありません。
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"
}
Servers SHOULD 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 SHOULD reject the newOrder request. If the server rejects the request because the identified certificate has already been marked as replaced, it MUST return an HTTP 409 (Conflict) with a problem document of type "alreadyReplaced" (see Section 7.4).
サーバーは、識別された証明書とneworderリクエストが同じACMEアカウントに対応していること、少なくとも1つの識別子を共有していること、および識別された証明書が「無効」ではない別の注文に置き換えられているとマークされていないことを確認する必要があります。これを超えた対応チェック（正確な識別子マッチングを要求するなど）は、サーバーポリシーに任されています。これらのチェックのいずれかが失敗した場合、サーバーはneworderリクエストを拒否する必要があります。識別された証明書が既に置き換えられているとマークされているため、サーバーがリクエストを拒否した場合、「既に繰り返された」タイプの問題文書でHTTP 409（競合）を返す必要があります（セクション7.4を参照）。
If the server accepts a newOrder request with a "replaces" field, it MUST reflect that field in the response and in subsequent requests for the corresponding Order object.
サーバーが「交換」フィールドを使用して新しい注文要求を受け入れる場合、応答およびその後の対応する注文オブジェクトのリクエストでそのフィールドを反映する必要があります。
This replacement information may serve many purposes, including but not limited to:
この代替情報は、以下を含むがこれらに限定されない多くの目的に役立つ場合があります。
* 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;
* 識別された前任者証明書の提案された更新ウィンドウ中に到着する新しい注文要求を許可するか、サーバーのポリシーがそのようなものを使用している場合、レート制限をバイパスすることができます。
* 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
* コンプライアンスインシデントの影響を受けた証明書の交換を追跡するため、交換後すぐに取り消すことができます。そして
* tying together certificates issued under the same contract with an entity identified by External Account Binding.
* 同じ契約に基づいて発行された証明書を組み合わせて、外部アカウントバインディングによって識別されたエンティティと発行されます。
The extensions to the ACME protocol described in this document build upon the security considerations and threat model defined in Section 10.1 of [RFC8555].
このドキュメントで説明されているACMEプロトコルの拡張は、[RFC8555]のセクション10.1で定義されているセキュリティ上の考慮事項と脅威モデルに基づいて構築されています。
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.
このドキュメントは、renledAlinfoリソースが認証されていないGETリクエストを介して公開およびアクセスされることを指定しています。これは、クライアントがサーバーからリソースを取得するためにゲット後のリクエストを送信するRFC 8555の要件からの逸脱です。これは、RenewAlinfoリソースに含まれる情報が機密と見なされていないためであり、RenewAlinfoリソースを簡単にキャッシュできるようにすることは、再試行後のヘッダーを尊重しないクライアントから負荷を当てるのに有利であるためです。いつものように、サーバーは、更新情報の認知度のない要求がサービス拒否攻撃をもたらすことができないようにするための措置を講じる必要があります。これらの測定には、キャッシュにキャッシュキーに余分な要求ヘッダーまたはクエリパラメーターが含まれていないこと、IPベースのレート制限を制定する、またはその他の一般的なベストプラクティス測定を含めることが含まれる場合があります。
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.
このプロトコルは、ACMEクライアントとサーバーの間に重要なクロックスキューが存在する場合、望ましくない動作を示す可能性があることに注意してください。たとえば、サーバーが過去に提案された更新ウィンドウを完全に配置してクライアントがすぐに更新することを奨励した場合、十分に遅いクライアントを持つクライアントは、それでもウィンドウを将来的に見ている可能性があります。同様に、一部のクライアントが時計を歪めた場合（またはARIをまったく実装していない）、非常に正確に更新をスケジュールしたいサーバーはそうすることが困難になる場合があります。サーバーオペレーターは、提案された更新ウィンドウを設定するときに、この懸念を考慮に入れる必要があります。ただし、他の多くのプロトコル（TLSハンドシェイク自体を含む）は、十分なクロックスキューでバラバラになりますので、これはこのプロトコルに固有のものではありません。
IANA has added the following entry to the "ACME Resource Types" registry within the "Automated Certificate Management Environment (ACME) Protocol" registry group at <https://www.iana.org/assignments/ acme>:
IANAは、「自動化された証明書管理環境（ACME）プロトコル」レジストリグループ内の「ACMEリソースタイプ」レジストリに次のエントリを追加しました。
+=============+====================+===============+
| Field Name | Resource Type | Reference |
+=============+====================+===============+
| renewalInfo | RenewalInfo object | This document |
+-------------+--------------------+---------------+
Table 2
IANA has added the following new registry to the "Automated Certificate Management Environment (ACME) Protocol" registry group at <https://www.iana.org/assignments/acme>:
IANAは、次の新しいレジストリを「自動化された証明書管理環境（ACME）プロトコル」レジストリグループに追加しました。
Registry Name:
レジストリ名：
ACME RenewalInfo Object Fields
ACME RenewAlinfoオブジェクトフィールド
Registration Procedure:
登録手順：
Specification Required (see [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.
必要な仕様（[RFC8126]を参照）。指定された専門家は、このレジストリに追加された新しいフィールドが、ACMEプロトコルの他の場所に属していない便利でユニークな情報を保証する必要があります。
Template:
テンプレート：
Field name:
フィールド名：
The string to be used as a field name in the JSON object
JSONオブジェクトのフィールド名として使用される文字列
Field type:
フィールドタイプ：
The type of value to be provided, e.g., string, boolean, array of string
提供される値のタイプ、例：文字列、ブール、文字列の配列
Reference:
参照：
Where this field is defined
このフィールドが定義されている場合
Initial contents:
最初の内容：
+=================+============+===============+
| Field Name | Field Type | Reference |
+=================+============+===============+
| suggestedWindow | object | This document |
+-----------------+------------+---------------+
| explanationURL | string | This document |
+-----------------+------------+---------------+
Table 3
IANA has added the following entry to the "ACME Order Object Fields" registry within the "Automated Certificate Management Environment (ACME) Protocol" registry group at <https://www.iana.org/assignments/ acme>:
IANAは、「自動化された証明書管理環境（ACME）プロトコル」レジストリグループ内の「ACME ORDERオブジェクトフィールド」レジストリに次のエントリを追加しました。
+============+============+==============+===============+
| Field Name | Field Type | Configurable | Reference |
+============+============+==============+===============+
| replaces | string | true | This document |
+------------+------------+--------------+---------------+
Table 4
IANA has added the following entry to the "ACME Error Types" registry within the "Automated Certificate Management Environment (ACME) Protocol" registry group at <https://www.iana.org/assignments/acme>:
IANAは、「自動化された証明書管理環境（ACME）プロトコル」レジストリグループ内の「ACMEエラータイプ」レジストリに次のエントリを追加しました。
+=================+==================================+===========+
| Type | Description | Reference |
+=================+==================================+===========+
| alreadyReplaced | The request specified a | This |
| | predecessor certificate that has | document |
| | already been marked as replaced | |
+-----------------+----------------------------------+-----------+
Table 5
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/info/rfc3647>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
-----BEGIN CERTIFICATE-----
MIIBQzCB66ADAgECAgUAh2VDITAKBggqhkjOPQQDAjAVMRMwEQYDVQQDEwpFeGFt
cGxlIENBMCIYDzAwMDEwMTAxMDAwMDAwWhgPMDAwMTAxMDEwMDAwMDBaMBYxFDAS
BgNVBAMTC2V4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEeBZu
7cbpAYNXZLbbh8rNIzuOoqOOtmxA1v7cRm//AwyMwWxyHz4zfwmBhcSrf47NUAFf
qzLQ2PPQxdTXREYEnKMjMCEwHwYDVR0jBBgwFoAUaYhba4dGQEHhs3uEe6CuLN4B
yNQwCgYIKoZIzj0EAwIDRwAwRAIge09+S5TZAlw5tgtiVvuERV6cT4mfutXIlwTb
+FYN/8oCIClDsqBklhB9KAelFiYt9+6FDj3z4KGVelYM5MdsO3pK
-----END CERTIFICATE-----
My thanks to Roland Shoemaker and Jacob Hoffman-Andrews for coming up with the initial idea of ARI and for helping me learn the IETF process. Thanks also to Samantha Frank, Matt Holt, Ilari Liusvaara, and Wouter Tinus for contributing client implementations, and to Freddy Zhang for contributing an independent server implementation. Finally, thanks to Rob Stradling, Andrew Ayer, and J.C. Jones for providing meaningful feedback and suggestions that significantly improved this specification.
Roland ShoemakerとJacob Hoffman Andrewsに、ARIの最初のアイデアを思いついてくれて、IETFプロセスの学習を手伝ってくれたことに感謝します。また、クライアントの実装を提供してくれたサマンサフランク、マットホルト、イラリリウスヴァーラ、およびワーターティヌス、および独立したサーバーの実装を提供してくれたフレディチャンにも感謝します。最後に、この仕様を大幅に改善した有意義なフィードバックと提案を提供してくれたRob Stradling、Andrew Ayer、およびJ.C. Jonesに感謝します。
A. Gable
Internet Security Research Group
Email: aaron@letsencrypt.org