[要約] RFC 8739は、ACMEでの短期間自動更新（STAR）証明書のサポートに関するものです。目的は、ACMEを使用して短期間で自動的に更新される証明書を効率的に管理することです。
Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 8739 Intuit
Category: Standards Track D. Lopez
ISSN: 2070-1721 O. Gonzalez de Dios
A. Pastor Perales
Telefonica I+D
T. Fossati
ARM
March 2020
Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)
自動証明書管理環境（ACME）での短期の自動更新（STAR）証明書のサポート
Abstract
概要
Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an Automated Certificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates.
公開鍵証明書は、侵害された場合、つまり、関連付けられた秘密鍵が不正なエンティティに公開された場合、取り消す必要があります。ただし、失効プロセスは信頼できないことがよくあります。失効の代わりに、それぞれが有効期間の短い証明書のシーケンスを発行し、侵害が発生するとシーケンスを終了します。このメモは、短期の自動更新（STAR）X.509証明書の発行を可能にする自動証明書管理環境（ACME）拡張を提案します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8739.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8739で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Name Delegation Use Case
1.2. Terminology
1.3. Conventions Used in This Document
2. Protocol Flow
2.1. Bootstrap
2.2. Auto Renewal
2.3. Termination
3. Protocol Details
3.1. ACME Extensions
3.1.1. Extending the Order Resource
3.1.2. Canceling an Auto-renewal Order
3.2. Capability Discovery
3.3. Fetching the Certificates
3.4. Negotiating an Unauthenticated GET
3.5. Computing notBefore and notAfter of STAR Certificates
3.5.1. Example
4. Operational Considerations
4.1. The Meaning of "Short Term" and the Impact of Skewed Clocks
4.2. Impact on Certificate Transparency (CT) Logs
4.3. HTTP Caching and Dependability
5. IANA Considerations
5.1. New Registries
5.2. New Error Types
5.3. New Fields in Order Objects
5.4. Fields in the "auto-renewal" Object within an Order Object
5.5. New Fields in the "meta" Object within a Directory Object
5.6. Fields in the "auto-renewal" Object within a Directory
Metadata Object
5.7. Cert-Not-Before and Cert-Not-After HTTP Headers
6. Security Considerations
6.1. No Revocation
6.2. Denial-of-Service Considerations
6.3. Privacy Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
The ACME protocol [RFC8555] automates the process of issuing a certificate to a named entity (an Identifier Owner or IdO). Typically, but not always, the identifier is a domain name.
ACMEプロトコル[RFC8555]は、名前付きエンティティ（識別子所有者またはIdO）に証明書を発行するプロセスを自動化します。通常、ただし常にではありませんが、識別子はドメイン名です。
If the IdO wishes to obtain a string of short-term certificates originating from the same private key (see [TOPALOVIC] about why using short-lived certificates might be preferable to explicit revocation), she must go through the whole ACME protocol each time a new short-term certificate is needed, e.g., every 2-3 days. If done this way, the process would involve frequent interactions between the registration function of the ACME Certification Authority (CA) and the identity provider infrastructure (e.g., DNS, web servers), therefore making the issuance of short-term certificates exceedingly dependent on the reliability of both.
IdOが同じ秘密鍵から発信された短期証明書の文字列を取得したい場合（短期的な証明書の使用が明示的な失効よりも望ましい理由については[TOPALOVIC]を参照）、毎回ACMEプロトコル全体を実行する必要があります。新しい短期証明書が必要です（2〜3日ごとなど）。この方法で行う場合、プロセスにはACME証明機関（CA）の登録機能とIDプロバイダーインフラストラクチャ（DNS、Webサーバーなど）の間の頻繁な対話が含まれるため、短期証明書の発行は、両方の信頼性。
This document presents an extension of the ACME protocol that optimizes this process by making short-term certificates first-class objects in the ACME ecosystem. Once the Order for a string of short-term certificates is accepted, the CA is responsible for publishing the next certificate at an agreed upon URL before the previous one expires. The IdO can terminate the automatic renewal before the negotiated deadline if needed, e.g., on key compromise.
このドキュメントでは、ACMEエコシステムで短期証明書をファーストクラスのオブジェクトにすることで、このプロセスを最適化するACMEプロトコルの拡張について説明します。一連の短期証明書の注文が受理されると、CAは、前の証明書が期限切れになる前に、合意されたURLで次の証明書を発行する責任があります。 IdOは、必要に応じて、たとえば鍵の侵害などの場合、交渉された期限の前に自動更新を終了できます。
For a more generic treatment of STAR certificates, readers are referred to [SHORT-TERM-CERTS].
STAR証明書のより一般的な扱いについては、[SHORT-TERM-CERTS]を参照してください。
The proposed mechanism can be used as a building block of an efficient name-delegation protocol, for example, one that exists between a Content Distribution Network (CDN) or a cloud provider and its customers [STAR-DELEGATION]. At any time, the service customer (i.e., the IdO) can terminate the delegation by simply instructing the CA to stop the automatic renewal and letting the currently active certificate expire shortly thereafter.
提案されたメカニズムは、効率的な名前委任プロトコルのビルディングブロックとして使用できます。たとえば、コンテンツ配信ネットワーク（CDN）またはクラウドプロバイダーとその顧客の間に存在するものです[STAR-DELEGATION]。いつでも、サービスの顧客（つまり、IdO）は、CAに自動更新を停止するように指示するだけで委任を終了でき、その後すぐに現在アクティブな証明書の有効期限が切れます。
Note that in the name delegation use case, the delegated entity needs to access the auto-renewed certificate without being in possession of the ACME account key that was used for initiating the STAR issuance. This leads to the optional use of unauthenticated GET in this protocol (Section 3.4).
名前の委任の使用例では、委任されたエンティティは、STAR発行の開始に使用されたACMEアカウントキーを所有せずに、自動更新された証明書にアクセスする必要があることに注意してください。これにより、このプロトコルで非認証GETをオプションで使用できます（セクション3.4）。
IdO Identifier Owner, the owner of an identifier, e.g., a domain name, a telephone number, etc. STAR Short-Term, Automatically Renewed X.509 certificates.
IdO Identifier Owner、ドメイン名、電話番号などの識別子の所有者。STAR短期、自動更新されたX.509証明書。
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]で説明されているように解釈されます。
The following subsections describe the three main phases of the protocol:
次のサブセクションでは、プロトコルの3つの主要なフェーズについて説明します。
* Bootstrap: the IdO asks an ACME CA to create a short-term, automatically renewed (STAR) certificate (Section 2.1); * Auto-renewal: the ACME CA periodically reissues the short-term certificate and posts it to the star-certificate URL (Section 2.2); * Termination: the IdO requests the ACME CA to discontinue the automatic renewal of the certificate (Section 2.3).
* ブートストラップ：IdOはACME CAに短期の自動更新（STAR）証明書（セクション2.1）の作成を要求します。 *自動更新：ACME CAは定期的に短期証明書を再発行し、それをスター証明書のURLに投稿します（セクション2.2）。 *終了：IdOはACME CAに証明書の自動更新の中止を要求します（セクション2.3）。
The IdO, in its role as an ACME client, requests the CA to issue a STAR certificate, i.e., one that:
IdOは、ACMEクライアントとしての役割で、CAにSTAR証明書、つまり次の証明書の発行を要求します。
* Has a short validity, e.g., 24 to 72 hours. Note that the exact definition of "short" depends on the use case; * Is automatically renewed by the CA for a certain period of time; * Is downloadable from a (highly available) location.
* 有効期間が短い（24時間から72時間など）。 「短い」の正確な定義はユースケースに依存することに注意してください。 * CAによって一定期間自動的に更新されます。 *（高可用性）ロケーションからダウンロードできます。
Other than that, the ACME protocol flows as usual between IdO and CA. In particular, IdO is responsible for satisfying the requested ACME challenges until the CA is willing to issue the requested certificate. Per normal ACME processing, the IdO is given back an Order resource associated with the STAR certificate to be used in subsequent interaction with the CA (e.g., if the certificate needs to be terminated.)
それ以外は、ACMEプロトコルは通常どおりIdOとCAの間を流れます。特に、IdOは、CAが要求された証明書を発行する用意があるまで、要求されたACMEチャレンジを満たす責任があります。通常のACME処理ごとに、IDOは、STA証明書に関連付けられたOrderリソースに返され、CAとのその後の対話で使用されます（たとえば、証明書を終了する必要がある場合）。
The bootstrap phase ends when the ACME CA updates the Order resource to include the URL for the issued STAR certificate.
ACME CAがOrderリソースを更新して、発行されたSTAR証明書のURLを含めると、ブートストラップフェーズが終了します。
The CA issues the initial certificate after the authorization completes successfully. It then automatically reissues the certificate using the same Certificate Signing Request (CSR) (and therefore the same identifier and public key) before the previous one expires and publishes it to the URL that was returned to the IdO at the end of the bootstrap phase. The certificate user, which could be either the IdO itself or a delegated third party as described in [STAR-DELEGATION], obtains the certificate (Section 3.3) and uses it.
認証が正常に完了すると、CAは初期証明書を発行します。次に、前の証明書が期限切れになる前に、同じ証明書署名要求（CSR）（したがって同じ識別子と公開鍵）を使用して証明書を自動的に再発行し、ブートストラップフェーズの最後にIdOに返されたURLに発行します。 [STAR-DELEGATION]で説明されているように、IdO自体または委任されたサードパーティのいずれかである証明書ユーザーは、証明書を取得し（セクション3.3）、それを使用します。
The auto-renewal process (Figure 1) goes on until either:
自動更新プロセス（図1）は、次のいずれかになるまで続きます。
* IdO explicitly terminates the automatic renewal (Section 2.3); or * Automatic renewal expires.
* IdOは明示的に自動更新を終了します（2.3節）。または*自動更新の期限が切れます。
Certificate ACME/STAR
User Server
| Retrieve cert | [...]
|---------------------->| |
| +------. /
| | | /
| | Automatic renewal :
| | | \
| |<-----' \
| Retrieve cert | |
|---------------------->| short validity period
| | |
| +------. /
| | | /
| | Automatic renewal :
| | | \
| |<-----' \
| Retrieve cert | |
|---------------------->| short validity period
| | |
| +------. /
| | | /
| | Automatic renewal :
| | | \
| |<-----' \
| | |
| [...] | [...]
Figure 1: Auto-renewal
図1：自動更新
The IdO may request early termination of the STAR certificate by sending a cancellation request to the Order resource as described in Section 3.1.2. After the CA receives and verifies the request, it shall:
IdOは、セクション3.1.2で説明されているように、注文リソースにキャンセル要求を送信することにより、STAR証明書の早期終了を要求できます。 CAは要求を受信して確認した後、次のことを行います。
* Cancel the automatic renewal process for the STAR certificate; * Change the certificate publication resource to return an error indicating the termination of the issuance; * Change the status of the Order to "canceled".
* STAR証明書の自動更新プロセスをキャンセルします。 *証明書発行リソースを変更して、発行の終了を示すエラーを返します。 *注文のステータスを「キャンセル済み」に変更します。
Note that it is not necessary to explicitly revoke the short-term certificate.
短期証明書を明示的に取り消す必要はないことに注意してください。
Certificate ACME/STAR
User IdO Server
| | |
| | Cancel Order |
| +---------------------->|
| | +-------.
| | | |
| | | End auto-renewal
| | | Remove cert link
| | | etc.
| | | |
| | Done |<------'
| |<----------------------+
| | |
| |
| Retrieve cert |
+---------------------------------------------->|
| Error: autoRenewalCanceled |
|<----------------------------------------------+
| |
Figure 2: Termination
図2：終了
This section describes the protocol details, namely the extensions to the ACME protocol required to issue STAR certificates.
このセクションでは、プロトコルの詳細、つまり、STAR証明書を発行するために必要なACMEプロトコルの拡張について説明します。
This protocol extends the ACME protocol to allow for automatically renewed Orders.
このプロトコルは、ACMEプロトコルを拡張して、自動的に更新された注文を可能にします。
The Order resource is extended with a new "auto-renewal" object that MUST be present for STAR certificates. The "auto-renewal" object has the following structure:
Orderリソースは、STAR証明書に存在する必要がある新しい「自動更新」オブジェクトで拡張されます。 「自動更新」オブジェクトの構造は次のとおりです。
* start-date (optional, string): The earliest date of validity of the first certificate issued, in [RFC3339] format. When omitted, the start date is as soon as authorization is complete. * end-date (required, string): The latest date of validity of the last certificate issued, in [RFC3339] format. * lifetime (required, integer): The maximum validity period of each STAR certificate, an integer that denotes a number of seconds. This is a nominal value that does not include any extra validity time due to server or client adjustment (see below). * lifetime-adjust (optional, integer): The amount of "left pad" added to each STAR certificate, an integer that denotes a number of seconds. The default is 0. If present, the value of the notBefore field that would otherwise appear in the STAR certificates is pre-dated by the specified number of seconds. See Section 4.1 for why a client might want to use this control, and Section 3.5 for how the effective certificate lifetime is computed. The value reflected by the server, together with the value of the lifetime attribute, can be used by the client as a hint to configure its polling timer. * allow-certificate-get (optional, boolean): See Section 3.4.
* start-date（オプション、文字列）：発行された最初の証明書の有効期限の最も早い日付（[RFC3339]形式）。省略した場合、開始日は承認が完了するとすぐになります。 *終了日（必須、文字列）：[RFC3339]形式の、最後に発行された証明書の有効期限の最新の日付。 *ライフタイム（必須、整数）：各STAR証明書の最大有効期間。秒数を表す整数。これは、サーバーまたはクライアントの調整による余分な有効期間を含まない公称値です（以下を参照）。 * lifetime-adjust（オプション、整数）：各STAR証明書に追加される「左パッド」の量。秒数を表す整数。デフォルトは0です。存在する場合、STAR証明書に表示されるnotBeforeフィールドの値は、指定された秒数だけ前の日付になります。クライアントがこのコントロールを使用する理由についてはセクション4.1を、有効な証明書の有効期間の計算方法についてはセクション3.5を参照してください。サーバーによって反映された値は、lifetime属性の値とともに、ポーリングタイマーを構成するためのヒントとしてクライアントによって使用できます。 * allow-certificate-get（オプション、ブール）：セクション3.4を参照してください。
These attributes are included in a POST message when creating the Order as part of the object encoded as "payload". They are returned when the Order has been created. The ACME server MAY adjust them at will according to its local policy (see also Section 3.2).
これらの属性は、「ペイロード」としてエンコードされたオブジェクトの一部として注文を作成するときに、POSTメッセージに含まれます。注文が作成されると返されます。 ACMEサーバーは、ローカルポリシーに従ってセクションを自由に調整できます（セクション3.2も参照）。
The optional notBefore and notAfter fields defined in Section 7.1.3 of [RFC8555] MUST NOT be present in a STAR Order. If they are included, the server MUST return an error with status code 400 (Bad Request) and type "malformedRequest".
[RFC8555]のセクション7.1.3で定義されているオプションのnotBeforeおよびnotAfterフィールドは、STAR Orderに存在してはなりません。それらが含まれている場合、サーバーはステータスコード400（Bad Request）でエラーを返し、「malformedRequest」と入力する必要があります。
Section 7.1.6 of [RFC8555] defines the following values for the Order resource's status: "pending", "ready", "processing", "valid", and "invalid". In the case of auto-renewal Orders, the status MUST be "valid" as long as STAR certificates are being issued. This document adds a new status value: "canceled" (see Section 3.1.2).
[RFC8555]のセクション7.1.6は、注文リソースのステータスの値を「保留」、「準備完了」、「処理中」、「有効」、「無効」と定義しています。自動更新注文の場合、STAR証明書が発行されている限り、ステータスは「有効」でなければなりません。このドキュメントは、新しいステータス値「キャンセル」を追加します（セクション3.1.2を参照）。
A STAR certificate is by definition a dynamic resource, i.e., it refers to an entity that varies over time. Instead of overloading the semantics of the "certificate" attribute, this document defines a new attribute, "star-certificate", to be used instead of "certificate".
STAR証明書は、定義により動的リソースです。つまり、時間の経過とともに変化するエンティティを指します。このドキュメントでは、「certificate」属性のセマンティクスをオーバーロードする代わりに、「certificate」の代わりに使用する「star-certificate」という新しい属性を定義しています。
* star-certificate (optional, string): A URL for the (rolling) STAR certificate that has been issued in response to this Order.
* star-certificate（オプション、文字列）：この注文に応じて発行された（ローリング）STAR証明書のURL。
An important property of the auto-renewal Order is that it can be canceled by the IdO with no need for certificate revocation. To cancel the Order, the ACME client sends a POST to the Order URL as shown in Figure 3.
自動更新注文の重要な特性は、証明書の失効を必要とせずにIdOによってキャンセルできることです。注文をキャンセルするには、図3に示すように、ACMEクライアントが注文URLにPOSTを送信します。
POST /acme/order/ogfr8EcolOT HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/gw06UNhKfOve",
"nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
"url": "https://example.com/acme/order/ogfr8EcolOT"
}),
"payload": base64url({
"status": "canceled"
}),
"signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H"
}
Figure 3: Canceling an Auto-renewal Order
図3：自動更新注文のキャンセル
After a successful cancellation, the server MUST NOT issue any additional certificates for this Order.
キャンセルが成功した後、サーバーはこの注文に対して追加の証明書を発行してはなりません。
When the Order is canceled, the server:
注文がキャンセルされると、サーバーは次のことを行います。
* MUST update the status of the Order resource to "canceled" and MUST set an appropriate "expires" date; * MUST respond with 403 (Forbidden) to any requests to the star-certificate endpoint. The response SHOULD provide additional information using a problem document [RFC7807] with type "urn:ietf:params:acme:error:autoRenewalCanceled".
* Orderリソースのステータスを「キャンセル」に更新し、適切な「有効期限」日を設定する必要があります。 * star-certificateエンドポイントへのリクエストには403（禁止）で応答する必要があります。応答は、タイプ「urn：ietf：params：acme：error：autoRenewalCanceled」の問題ドキュメント[RFC7807]を使用して追加情報を提供する必要があります（SHOULD）。
Issuing a cancellation for an Order that is not in "valid" state is not allowed. A client MUST NOT send such a request, and a server MUST return an error response with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:autoRenewalCancellationInvalid".
「有効」な状態でない注文に対してキャンセルを発行することはできません。クライアントはそのようなリクエストを送信してはならず（MUST NOT）、サーバーはステータスコード400（Bad Request）のエラー応答を返し、「urn：ietf：params：acme：error：autoRenewalCancellationInvalid」と入力する必要があります。
The state machine described in Section 7.1.6 of [RFC8555] is extended as illustrated in Figure 4.
[RFC8555]のセクション7.1.6で説明されているステートマシンは、図4に示すように拡張されています。
pending --------------+
| |
| All authz |
| "valid" |
V |
ready ---------------+
| |
| Receive |
| finalize |
| request |
V |
processing ------------+
| |
| First |
| certificate | Error or
| issued | Authorization failure
| |
| V
| invalid
V
valid----------------+
| |
| STAR |
| Certificate | Natural
| canceled | Expiration
V |
canceled ='=
Figure 4: State Transitions for STAR Order Objects
図4：STAR注文オブジェクトの状態遷移
Explicit certificate revocation using the revokeCert interface (Section 7.6 of [RFC8555]) is not supported for STAR certificates. A server receiving a revocation request for a STAR certificate MUST return an error response with status code 403 (Forbidden) and type "urn:ietf:params:acme:error:autoRenewalRevocationNotSupported".
STAR証明書では、revokeCertインターフェースを使用した明示的な証明書失効（[RFC8555]のセクション7.6）はサポートされていません。 STAR証明書の失効リクエストを受信したサーバーは、ステータスコード403（禁止）のエラー応答を返し、「urn：ietf：params：acme：error：autoRenewalRevocationNotSupported」と入力する必要があります。
In order to support the discovery of STAR capabilities, the "meta" field inside the directory object defined in Section 9.7.6 of [RFC8555] is extended with a new "auto-renewal" object. The "auto-renewal" object MUST be present if the server supports STAR. Its structure is as follows:
STAR機能の検出をサポートするために、[RFC8555]のセクション9.7.6で定義されたディレクトリオブジェクト内の「メタ」フィールドは、新しい「自動更新」オブジェクトで拡張されています。サーバーがSTARをサポートしている場合、「自動更新」オブジェクトが存在しなければなりません。その構造は次のとおりです。
* min-lifetime (required, integer): Minimum acceptable value for auto-renewal lifetime, in seconds. * max-duration (required, integer): Maximum allowed delta between the end-date and start-date attributes of the Order's auto-renewal object. * allow-certificate-get (optional, boolean): See Section 3.4.
* min-lifetime（必須、整数）：自動更新の有効期間の最小許容値（秒単位）。 * max-duration（必須、整数）：Orderの自動更新オブジェクトのend-date属性とstart-date属性間の最大許容デルタ。 * allow-certificate-get（オプション、ブール）：セクション3.4を参照してください。
An example directory object advertising STAR support with one-day min-lifetime and one-year max-duration and supporting certificate fetching with an HTTP GET is shown in Figure 5.
1日の最短有効期間と1年の最長有効期間でSTARサポートを宣伝し、HTTP GETで証明書のフェッチをサポートするディレクトリオブジェクトの例を図5に示します。
{
"new-nonce": "https://example.com/acme/new-nonce",
"new-account": "https://example.com/acme/new-account",
"new-order": "https://example.com/acme/new-order",
"new-authz": "https://example.com/acme/new-authz",
"revoke-cert": "https://example.com/acme/revoke-cert",
"key-change": "https://example.com/acme/key-change",
"meta": {
"terms-of-service": "https://example.com/acme/terms/2017-5-30",
"website": "https://www.example.com/",
"caa-identities": ["example.com"],
"auto-renewal": {
"min-lifetime": 86400,
"max-duration": 31536000,
"allow-certificate-get": true
}
}
}
Figure 5: Directory Object with STAR Support
図5：STARをサポートするディレクトリオブジェクト
The certificate is fetched from the star-certificate endpoint with POST-as-GET as per Section 7.4.2 of [RFC8555] unless the client and server have successfully negotiated the "unauthenticated GET" option described in Section 3.4. In such case, the client can simply issue a GET to the star-certificate resource without authenticating itself to the server as illustrated in Figure 6.
[RFC8555]のセクション7.4.2に従い、クライアントとサーバーがセクション3.4で説明されている「非認証GET」オプションを正常にネゴシエートしていない限り、証明書はPOST-as-GETを使用してスター証明書エンドポイントからフェッチされます。このような場合、クライアントは、図6に示すように、サーバーに対して自身を認証することなく、スター証明書リソースに対してGETを発行するだけで済みます。
GET /acme/cert/g7m3ZQeTEqa HTTP/1.1
Host: example.com
Accept: application/pem-certificate-chain
HTTP/1.1 200 OK
Content-Type: application/pem-certificate-chain
Link: <https://example.com/acme/some-directory>;rel="index"
Cert-Not-Before: Thu, 3 Oct 2019 00:00:00 GMT
Cert-Not-After: Thu, 10 Oct 2019 00:00:00 GMT
-----BEGIN CERTIFICATE-----
[End-entity certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Issuer certificate contents]
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
[Other certificate contents]
-----END CERTIFICATE-----
Figure 6: Fetching a STAR Certificate with Unauthenticated GET
図6：認証されていないGETによるSTAR証明書の取得
The server SHOULD include the "Cert-Not-Before" and "Cert-Not-After" HTTP header fields in the response. When they exist, they MUST be equal to the respective fields inside the end-entity certificate. Their format is "HTTP-date" as defined in Section 7.1.1.2 of [RFC7231]. Their purpose is to enable client implementations that do not parse the certificate.
サーバーは、応答に "Cert-Not-Before"および "Cert-Not-After" HTTPヘッダーフィールドを含める必要があります（SHOULD）。それらが存在する場合、それらはエンドエンティティ証明書内のそれぞれのフィールドと等しい必要があります。その形式は、[RFC7231]のセクション7.1.1.2で定義されている「HTTP-date」です。その目的は、証明書を解析しないクライアント実装を可能にすることです。
The following are further clarifications regarding usage of these header fields as per Section 8.3.1 of [RFC7231]. All apply to both headers.
[RFC7231]のセクション8.3.1に従って、これらのヘッダーフィールドの使用に関する詳細を以下に示します。すべてが両方のヘッダーに適用されます。
* This header field is a single value, not a list. * The header field is used only in responses to GET, HEAD, and POST-as-GET requests, and only for MIME types that denote public key certificates. * Header field semantics are independent of context. * The header field is not hop-by-hop. * Intermediaries MAY insert or delete the value; * If an intermediary inserts the value, it MUST ensure that the newly added value matches the corresponding value in the certificate. * The header field is not appropriate for a Vary field. * The header field is allowed within message trailers. * The header field is not appropriate within redirects. * The header field does not introduce additional security considerations. It discloses in a simpler form information that is already available inside the certificate.
* このヘッダーフィールドは単一の値であり、リストではありません。 *ヘッダーフィールドは、GET、HEAD、POST-as-GETリクエストへの応答でのみ使用され、公開鍵証明書を示すMIMEタイプでのみ使用されます。 *ヘッダーフィールドのセマンティクスは、コンテキストに依存しません。 *ヘッダーフィールドはホップバイホップではありません。 *仲介者が値を挿入または削除する場合があります。 *仲介者が値を挿入する場合、新しく追加された値が証明書の対応する値と一致することを確認する必要があります。 *ヘッダーフィールドはVaryフィールドには適していません。 *ヘッダーフィールドはメッセージトレーラー内で使用できます。 *ヘッダーフィールドはリダイレクト内では適切ではありません。 *ヘッダーフィールドでは、セキュリティに関する追加の考慮事項は導入されていません。証明書内ですでに利用可能な情報をより簡単な形式で開示します。
To improve robustness, the next certificate MUST be made available by the ACME CA at the URL indicated by "star-certificate" halfway through the lifetime of the currently active certificate at the latest. It is worth noting that this has an implication in case of cancellation; in fact, from the time the next certificate is made available, the cancellation is not completely effective until the "next" certificate also expires. To avoid the client accidentally entering a broken state, the notBefore of the "next" certificate MUST be set so that the certificate is already valid when it is published at the "star-certificate" URL. Note that the server might need to increase the auto-renewal lifetime-adjust value to satisfy the latter requirement. For a detailed description of the renewal scheduling logic, see Section 3.5. For further rationale on the need for adjusting the certificate validity, see Section 4.1.
堅牢性を向上させるために、次の証明書は、遅くとも現在アクティブな証明書の有効期間の途中で、「star-certificate」によって示されるURLでACME CAによって利用可能にされる必要があります。これは、キャンセルの場合に影響があることに注意してください。実際、次の証明書が使用可能になったときから、「次の」証明書も期限切れになるまで、キャンセルは完全には有効になりません。クライアントが誤って壊れた状態になるのを防ぐために、「次の」証明書のnotBeforeを設定して、「スター証明書」のURLで公開されたときに証明書がすでに有効であるようにする必要があります。サーバーは、後者の要件を満たすために自動更新のライフタイム調整値を増やす必要がある場合があることに注意してください。更新スケジュールロジックの詳細については、セクション3.5を参照してください。証明書の有効性を調整する必要性のさらなる根拠については、セクション4.1を参照してください。
The server MUST NOT issue any certificates for this Order with notAfter after the auto-renewal end-date.
サーバーは、自動更新の終了日の後、notAfterを使用してこの注文の証明書を発行してはなりません（MUST NOT）。
For expired Orders, the server MUST respond with 403 (Forbidden) to any requests to the star-certificate endpoint. The response SHOULD provide additional information using a problem document [RFC7807] with type "urn:ietf:params:acme:error:autoRenewalExpired". Note that the Order resource's state remains "valid", as per the base protocol.
期限切れの注文の場合、サーバーはスター証明書エンドポイントへの要求に403（禁止）で応答する必要があります。応答は、タイプ「urn：ietf：params：acme：error：autoRenewalExpired」の問題ドキュメント[RFC7807]を使用して追加情報を提供する必要があります（SHOULD）。 Orderプロトコルの状態は、基本プロトコルに従って「有効」のままであることに注意してください。
In order to enable the name delegation workflow defined in [STAR-DELEGATION] and to increase the reliability of the STAR ecosystem (see Section 4.3 for details), this document defines a mechanism that allows a server to advertise support for accessing star-certificate resources via unauthenticated GET (in addition to POST-as-GET), and a client to enable this service with per-Order granularity.
[STAR-DELEGATION]で定義された名前委任ワークフローを有効にし、STARエコシステムの信頼性を高めるために（詳細についてはセクション4.3を参照）、このドキュメントでは、サーバーがスター証明書リソースへのアクセスのサポートを通知できるようにするメカニズムを定義します認証されていないGET（POST-as-GETに加えて）、およびこのサービスを注文ごとの粒度で有効にするクライアント。
Specifically, a server states its availability to grant unauthenticated access to a client's Order star-certificate by setting the allow-certificate-get attribute to "true" in the auto-renewal object of the meta field inside the directory object:
具体的には、サーバーは、ディレクトリオブジェクト内のメタフィールドの自動更新オブジェクトでallow-certificate-get属性を「true」に設定することにより、クライアントのOrder star-certificateへの非認証アクセスを許可する可用性を示します。
* allow-certificate-get (optional, boolean): If this field is present and set to "true", the server allows GET (and HEAD) requests to star-certificate URLs.
* allow-certificate-get（オプション、ブール）：このフィールドが存在し、「true」に設定されている場合、サーバーはGET（およびHEAD）リクエストにスター証明書のURLを許可します。
A client states its desire to access the issued star-certificate via unauthenticated GET by adding an allow-certificate-get attribute to the auto-renewal object of the payload of its newOrder request and setting it to "true".
クライアントは、newOrderリクエストのペイロードの自動更新オブジェクトにallow-certificate-get属性を追加し、それを「true」に設定することで、認証されていないGETを介して発行されたスター証明書にアクセスすることを望んでいます。
* allow-certificate-get (optional, boolean): If this field is present and set to "true", the client requests the server to allow unauthenticated GET (and HEAD) to the star-certificate associated with this Order.
* allow-certificate-get（オプション、ブール）：このフィールドが存在し、「true」に設定されている場合、クライアントはサーバーに、この注文に関連付けられているスター証明書への非認証GET（およびHEAD）を許可するように要求します。
If the server accepts the request, it MUST reflect the attribute setting in the resulting order object.
サーバーが要求を受け入れる場合、結果の注文オブジェクトの属性設定を反映する必要があります。
Note that even when the use of unauthenticated GET has been agreed upon, the server MUST also allow POST-as-GET requests to the star-certificate resource.
認証されていないGETの使用が合意されている場合でも、サーバーはstar-certificateリソースへのPOST-as-GETリクエストを許可する必要があります。
We define "nominal renewal date" as the point in time when a new short-term certificate for a given STAR Order is due. Its cadence is a multiple of the Order's auto-renewal lifetime that starts with the issuance of the first short-term certificate and is upper-bounded by the Order's auto-renewal end-date (Figure 7).
「公称更新日」は、特定のSTAR注文の新しい短期証明書の期日と定義されます。その周期は、最初の短期証明書の発行から始まり、注文の自動更新の終了日によって上限が定められた、注文の自動更新の有効期間の倍数です（図7）。
T - STAR Order's auto-renewal lifetime end - STAR Order's auto-renewal end-date nrd[i] - nominal renewal date of the i-th STAR certificate
T-STAR注文の自動更新の有効期間終了-STAR注文の自動更新の終了日nrd [i]-i番目のSTAR証明書の名目上の更新日
.- T -. .- T -. .- T -. .__.
/ \ / \ / \ / end
-----------o---------o---------o---------o----X-------> t
nrd[0] nrd[1] nrd[2] nrd[3]
Figure 7: Nominal Renewal Date
図7：公称更新日
The rules to determine the notBefore and notAfter values of the i-th STAR certificate are as follows:
i番目のSTAR証明書のnotBeforeとnotAfterの値を決定する規則は次のとおりです。
notAfter = min(nrd[i] + T, end)
notBefore = nrd[i] - max(adjust_client, adjust_server)
Where "adjust_client" is the minimum value between the auto-renewal lifetime-adjust value ("la"), optionally supplied by the client, and the auto-renewal lifetime of each short-term certificate ("T"); "adjust_server" is the amount of padding added by the ACME server to make sure that all certificates being published are valid at the time of publication. The server padding is a fraction (f) of T (i.e., f * T with .5 <= f < 1; see Section 3.3):
ここで、「adjust_client」は、オプションでクライアントから提供される自動更新のライフタイム調整値（「la」）と各短期証明書の自動更新のライフタイム（「T」）の間の最小値です。 "adjust_server"は、発行されるすべての証明書が発行時に有効であることを確認するためにACMEサーバーによって追加されるパディングの量です。サーバーのパディングはTの分数（f）です（つまり、f * Tで.5 <= f <1。セクション3.3を参照）。
adjust_client = min(T, la)
adjust_server = f * T
Note that the ACME server MUST NOT set the notBefore of the first STAR certificate to a date prior to the auto-renewal start-date.
ACMEサーバーは、最初のSTAR証明書のnotBeforeを自動更新開始日の前の日付に設定してはならないことに注意してください。
Given a server that intends to publish the next STAR certificate halfway through the lifetime of the previous one, and a STAR Order with the following attributes:
次のSTAR証明書を前の証明書の存続期間の途中で公開することを目的とするサーバーと、次の属性を持つSTAR Orderがあるとします。
"auto-renewal": {
"start-date": "2019-01-10T00:00:00Z",
"end-date": "2019-01-20T00:00:00Z",
"lifetime": 345600, // 4 days
"lifetime-adjust": 259200 // 3 days
}
The amount of time that needs to be subtracted from each nominal renewal date is 3 days, i.e., max(min(345600, 259200), 345600 * .5).
各名目更新日から差し引く必要がある時間は3日、つまりmax（min（345600、259200）、345600 * .5）です。
The notBefore and notAfter of each short-term certificate are:
各短期証明書のnotBeforeとnotAfterは次のとおりです。
+----------------------+----------------------+
| notBefore | notAfter |
+======================+======================+
| 2019-01-10T00:00:00Z | 2019-01-14T00:00:00Z |
+----------------------+----------------------+
| 2019-01-11T00:00:00Z | 2019-01-18T00:00:00Z |
+----------------------+----------------------+
| 2019-01-15T00:00:00Z | 2019-01-20T00:00:00Z |
+----------------------+----------------------+
Table 1
表1
The value of the notBefore is also the time at which the client should expect the new certificate to be available from the star-certificate endpoint.
notBeforeの値は、スター証明書のエンドポイントから新しい証明書が利用可能になることをクライアントが期待する時間でもあります。
"Short Term" is a relative concept; therefore, trying to define a cutoff point that works in all cases would be a useless exercise. In practice, the expected lifetime of a STAR certificate will be counted in minutes, hours, or days, depending on different factors: the underlying requirements for revocation, how much clock synchronization is expected among relying parties and the issuing CA, etc.
「短期」は相対的な概念です。したがって、すべてのケースで機能するカットオフポイントを定義しようとしても、無駄な作業になります。実際には、STAR証明書の予想される有効期間は、さまざまな要因に応じて、分、時間、または日単位でカウントされます。失効の基本的な要件、証明書利用者と発行元CAの間で予想されるクロック同期の量などです。
Nevertheless, this section attempts to provide reasonable suggestions for the Web use case, informed by current operational and research experience.
それでも、このセクションでは、現在の運用および調査の経験に基づいて、Webユースケースについて合理的な提案を提供することを試みます。
Acer et al. [ACER] find that one of the main causes of "HTTPS error" warnings in browsers is misconfigured client clocks. In particular, they observe that roughly 95% of the "severe" clock skews -- the 6.7% of clock-related breakage reports that account for clients that are more than 24 hours behind -- happen to be within 6-7 days.
エイサー等。 [ACER]ブラウザの「HTTPSエラー」警告の主な原因の1つがクライアントクロックの設定ミスであることがわかりました。特に、「重大な」クロックスキューの約95％（24時間以上遅れているクライアントを説明するクロック関連の破損レポートの6.7％）が6〜7日以内に発生していることがわかります。
In order to avoid these spurious warnings about a not yet valid server certificate, site owners could use the auto-renewal lifetime-adjust attribute to control the effective lifetime of their Web-facing certificates. The exact number depends on the percentage of the "clock-skewed" population that the site owner expects to protect -- 5 days cover 97.3%, 7 days cover 99.6% -- as well as the nominal auto-renewal lifetime of the STAR Order. Note that exact choice is also likely to depend on the kinds of client that are prevalent for a given site or app -- for example, Android and Mac OS clients are known to behave better than Windows clients. These considerations are clearly out of scope of this document.
まだ有効でないサーバー証明書に関するこれらの誤った警告を回避するために、サイト所有者は自動更新のライフタイム調整属性を使用して、Web向け証明書の有効なライフタイムを制御できます。正確な数は、サイト所有者が保護することを期待している「クロックのずれた」人口の割合に依存します。5日間は97.3％をカバーし、7日間は99.6％をカバーします。また、STAR Orderの名目上の自動更新寿命。正確な選択は、特定のサイトまたはアプリで一般的なクライアントの種類にも依存する可能性が高いことに注意してください。たとえば、AndroidおよびMac OSクライアントは、Windowsクライアントよりも動作が優れていることがわかっています。これらの考慮事項は明らかにこのドキュメントの範囲外です。
In terms of security, STAR certificates and certificates with the Online Certificate Status Protocol (OCSP) "must-staple" flag asserted [RFC7633] can be considered roughly equivalent if the STAR certificate's and the OCSP response's lifetimes are the same. (Here, "must-staple" refers to a certificate carrying a TLS feature extension with the "status_request" extension identifier [RFC6066].) Given OCSP responses can be cached, on average, for 4 days [STARK], it is RECOMMENDED that a STAR certificate that is used on the Web has an "effective" lifetime (excluding any adjustment to account for clock skews) no longer than 4 days.
セキュリティの観点から、STAR証明書とオンライン証明書ステータスプロトコル（OCSP）の「必須」フラグがアサートされた証明書[RFC7633]は、STAR証明書とOCSP応答のライフタイムが同じである場合、ほぼ同等と見なすことができます。 （ここで、「必須」とは、「status_request」拡張識別子[RFC6066]を使用したTLS機能拡張を含む証明書を指します。）OCSP応答は、平均して4日間[STARK]キャッシュできるため、次のことをお勧めします。 Webで使用されるSTAR証明書の有効期間（クロックスキューを考慮した調整を除く）の有効期間は4日以内です。
Even in the highly unlikely case STAR becomes the only certificate issuance model, discussion with the IETF TRANS Working Group and implementers of Certificate Transparency (CT) logs suggests that existing CT Log server implementations are capable of sustaining the resulting 100-fold increase in ingestion rate. Additionally, such a future higher load could be managed with a variety of techniques (e.g., sharding by modulo of certificate hash, using "smart" load-balancing CT proxies, etc.). With regards to the increase in the log size, current CT log growth is already being managed with schemes like Chrome's Log Policy [OBRIEN], which allow Operators to define their log life cycle, as well as allowing the CAs, User Agents, Monitors, and any other interested entities to build in support for that life cycle ahead of time.
非常にまれなケースですが、STARが唯一の証明書発行モデルになる場合でも、IETF TRANSワーキンググループおよび証明書の透明性（CT）ログの実装者との議論により、既存のCTログサーバーの実装は、取り込み率の100倍の増加を維持できることが示唆されています。さらに、そのような将来のより高い負荷は、さまざまな手法（たとえば、証明書ハッシュのモジュロによるシャーディング、「スマートな」負荷分散CTプロキシの使用など）で管理できます。ログサイズの増加に関して、現在のCTログの増加は、Chromeのログポリシー[OBRIEN]などのスキームですでに管理されており、オペレーターはログのライフサイクルを定義できるだけでなく、CA、ユーザーエージェント、モニター、そして、そのライフサイクルのサポートを事前に構築するその他の関心のあるエンティティ。
When using authenticated POST-as-GET, the HTTPS endpoint from where the STAR certificate is fetched can't be easily replicated by an on-path HTTP cache. Reducing the caching properties of the protocol makes STAR clients increasingly dependent on the ACME server availability. This might be problematic given the relatively high rate of client-server interactions in a STAR ecosystem, especially when multiple endpoints (e.g., a high number of CDN edge nodes) end up requesting the same certificate. Clients and servers should consider using the mechanism described in Section 3.4 to mitigate the risk.
認証されたPOST-as-GETを使用する場合、STAR証明書がフェッチされるHTTPSエンドポイントは、パス上のHTTPキャッシュによって簡単に複製できません。プロトコルのキャッシングプロパティを減らすと、STARクライアントはACMEサーバーの可用性にますます依存するようになります。これは、特に複数のエンドポイント（たとえば、多数のCDNエッジノード）が同じ証明書を要求してしまう場合、STARエコシステムでのクライアントサーバーの相互作用の割合が比較的高いため、問題になる可能性があります。クライアントとサーバーは、セクション3.4で説明されているメカニズムを使用してリスクを軽減することを検討する必要があります。
When using unauthenticated GET to fetch the STAR certificate, the server SHALL use the appropriate cache directives to set the freshness lifetime of the response (Section 5.2 of [RFC7234]) such that on-path caches will consider it stale before or at the time its effective lifetime is due to expire.
認証されていないGETを使用してSTAR証明書をフェッチする場合、サーバーは適切なキャッシュディレクティブを使用して応答のフレッシュネスライフタイムを設定する必要があります（[RFC7234]のセクション5.2）。これにより、オンパスキャッシュは、その前またはその時点で古いと見なします有効寿命は期限切れです。
Per this document, IANA has created the following new registries:
このドキュメントに従って、IANAは次の新しいレジストリを作成しました。
* ACME Order Auto-Renewal Fields (Section 5.4) * ACME Directory Metadata Auto-Renewal Fields (Section 5.6)
* ACME注文自動更新フィールド（セクション5.4）* ACMEディレクトリメタデータ自動更新フィールド（セクション5.6）
These registries are administered under a Specification Required policy [RFC8126].
これらのレジストリは、Specification Requiredポリシー[RFC8126]に基づいて管理されます。
Per this document, IANA has added the following entries to the "ACME Error Types" registry:
このドキュメントに従って、IANAは次のエントリを「ACMEエラータイプ」レジストリに追加しました。
+-----------------------------------+-------------------+-----------+
| Type | Description | Reference |
+===================================+===================+===========+
| autoRenewalCanceled | The short-term | RFC 8739 |
| | certificate is | |
| | no longer | |
| | available | |
| | because the | |
| | auto-renewal | |
| | Order has been | |
| | explicitly | |
| | canceled by | |
| | the IdO | |
+-----------------------------------+-------------------+-----------+
| autoRenewalExpired | The short-term | RFC 8739 |
| | certificate is | |
| | no longer | |
| | available | |
| | because the | |
| | auto-renewal | |
| | Order has | |
| | expired | |
+-----------------------------------+-------------------+-----------+
| autoRenewalCancellationInvalid | A request to | RFC 8739 |
| | cancel an | |
| | auto-renewal | |
| | Order that is | |
| | not in state | |
| | "valid" has | |
| | been received | |
+-----------------------------------+-------------------+-----------+
| autoRenewalRevocationNotSupported | A request to | RFC 8739 |
| | revoke an | |
| | auto-renewal | |
| | Order has been | |
| | received | |
+-----------------------------------+-------------------+-----------+
Table 2
表2
Per this document, IANA has added the following entries to the "ACME Order Object Fields" registry:
このドキュメントに従って、IANAは次のエントリを「ACME Order Object Fields」レジストリに追加しました。
+------------------+------------+--------------+-----------+
| Field Name | Field Type | Configurable | Reference |
+==================+============+==============+===========+
| auto-renewal | object | true | RFC 8739 |
+------------------+------------+--------------+-----------+
| star-certificate | string | false | RFC 8739 |
+------------------+------------+--------------+-----------+
Table 3
表3
The "ACME Order Auto-Renewal Fields" registry lists field names that are defined for use in the JSON object included in the "auto-renewal" field of an ACME order object.
「ACME注文自動更新フィールド」レジストリには、ACME注文オブジェクトの「自動更新」フィールドに含まれるJSONオブジェクトで使用するために定義されたフィールド名が一覧表示されます。
Template:
テンプレート：
* Field name: The string to be used as a field name in the JSON object * Field type: The type of value to be provided, e.g., string, boolean, array of string * Configurable: Boolean indicating whether the server should accept values provided by the client * Reference: Where this field is defined
* フィールド名：JSONオブジェクトのフィールド名として使用される文字列*フィールドタイプ：提供される値のタイプ。たとえば、文字列、ブール、文字列の配列*構成可能：サーバーが提供する値をサーバーが受け入れるかどうかを示すブール値クライアント*参照：このフィールドが定義されている場所
Initial contents: The fields and descriptions defined in Section 3.1.1.
初期コンテンツ：セクション3.1.1で定義されているフィールドと説明。
+-----------------------+------------+--------------+-----------+
| Field Name | Field Type | Configurable | Reference |
+=======================+============+==============+===========+
| start-date | string | true | RFC 8739 |
+-----------------------+------------+--------------+-----------+
| end-date | string | true | RFC 8739 |
+-----------------------+------------+--------------+-----------+
| lifetime | integer | true | RFC 8739 |
+-----------------------+------------+--------------+-----------+
| lifetime-adjust | integer | true | RFC 8739 |
+-----------------------+------------+--------------+-----------+
| allow-certificate-get | boolean | true | RFC 8739 |
+-----------------------+------------+--------------+-----------+
Table 4
表4
Per this document, IANA has added the following entry to the "ACME Directory Metadata Fields":
このドキュメントに従って、IANAは次のエントリを「ACMEディレクトリメタデータフィールド」に追加しました。
+--------------+------------+-----------+
| Field Name | Field Type | Reference |
+==============+============+===========+
| auto-renewal | object | RFC 8739 |
+--------------+------------+-----------+
Table 5
表5
5.6. Fields in the "auto-renewal" Object within a Directory Metadata Object
5.6. ディレクトリメタデータオブジェクト内の「自動更新」オブジェクトのフィールド
The "ACME Directory Metadata Auto-Renewal Fields" registry lists field names that are defined for use in the JSON object included in the "auto-renewal" field of an ACME directory "meta" object.
「ACMEディレクトリメタデータ自動更新フィールド」レジストリには、ACMEディレクトリ「メタ」オブジェクトの「自動更新」フィールドに含まれるJSONオブジェクトで使用するために定義されたフィールド名が一覧表示されます。
Template:
テンプレート：
* Field name: The string to be used as a field name in the JSON object * Field type: The type of value to be provided, e.g., string, boolean, array of string * Reference: Where this field is defined
* フィールド名：JSONオブジェクトでフィールド名として使用される文字列*フィールドタイプ：提供される値のタイプ（例：文字列、ブール、文字列の配列）*参照：このフィールドが定義されている場所
Initial contents: The fields and descriptions defined in Section 3.2.
初期コンテンツ：セクション3.2で定義されているフィールドと説明。
+-----------------------+------------+-----------+
| Field Name | Field Type | Reference |
+=======================+============+===========+
| min-lifetime | integer | RFC 8739 |
+-----------------------+------------+-----------+
| max-duration | integer | RFC 8739 |
+-----------------------+------------+-----------+
| allow-certificate-get | boolean | RFC 8739 |
+-----------------------+------------+-----------+
Table 6
表6
The "Message Headers" registry has been updated with the following additional values:
「メッセージヘッダー」レジストリは、次の追加の値で更新されました。
+-------------------+----------+----------+-----------------------+
| Header Field Name | Protocol | Status | Reference |
+===================+==========+==========+=======================+
| Cert-Not-Before | http | standard | RFC 8739, Section 3.3 |
+-------------------+----------+----------+-----------------------+
| Cert-Not-After | http | standard | RFC 8739, Section 3.3 |
+-------------------+----------+----------+-----------------------+
Table 7
表7
STAR certificates eliminate an important security feature of PKI, which is the ability to revoke certificates. Revocation allows the administrator to limit the damage done by a rogue node or an adversary who has control of the private key. With STAR certificates, expiration replaces revocation so there is potential for lack of timeliness in the revocation taking effect. To that end, see also the discussion on clock skew in Section 4.1.
STAR証明書は、PKIの重要なセキュリティ機能である証明書を取り消す機能を排除します。取り消しにより、管理者は、秘密キーを制御する悪意のあるノードまたは攻撃者による被害を制限できます。 STAR証明書では、失効が失効に置き換わるため、失効が有効になるタイミングが不十分になる可能性があります。そのためには、セクション4.1のクロックスキューに関する説明も参照してください。
It should be noted that revocation also has timeliness issues because both Certificate Revocation Lists (CRLs) and OCSP responses have nextUpdate fields that tell relying parties (RPs) how long they should trust this revocation data. These fields are typically set to hours, days, or even weeks in the future. Any revocation that happens before the time in nextUpdate goes unnoticed by the RP.
証明書失効リスト（CRL）とOCSP応答の両方に、証明書利用者（RP）にこの失効データを信頼する必要がある期間を伝えるnextUpdateフィールドがあるため、失効にも適時性の問題があることに注意してください。これらのフィールドは通常、将来の数時間、数日、または数週間に設定されます。 nextUpdateの時刻より前に発生する取り消しは、RPによって気付かれません。
One situation where the lack of explicit revocation could create a security risk to the IdO is when the Order is created with a start-date of some appreciable amount of time in the future. Recall that when authorizations have been fulfilled, the Order moves to the "valid" state and the star-certificate endpoint is populated with the first cert (Figure 4). So, if an attacker manages to get hold of the private key as well as the first (post-dated) certificate, there is a time window in the future when they will be able to successfully impersonate the IdO. Note that cancellation is pointless in this case. In order to mitigate the described threat, it is RECOMMENDED that IdO place their Orders at a time that is close to the Order's start-date.
明示的な失効の欠如がIdOにセキュリティリスクをもたらす可能性がある状況の1つは、開始日がかなり長い時間の開始日で作成された場合です。承認が完了すると、注文は「有効」状態に移行し、スター証明書のエンドポイントに最初の証明書が入力されることを思い出してください（図4）。そのため、攻撃者が秘密鍵と最初の（日付が指定された）証明書を取得できた場合、IdOを正常に偽装できるようになるまでの時間枠があります。この場合、キャンセルは無意味です。上記の脅威を軽減するために、IdOは注文の開始日に近い時間に注文を出すことをお勧めします。
More discussion of the security of STAR certificates is available in [TOPALOVIC].
STAR証明書のセキュリティの詳細については、[TOPALOVIC]を参照してください。
STAR adds a new attack vector that increases the threat of denial-of-service attacks, caused by the change to the CA's behavior. Each STAR request amplifies the resource demands upon the CA, where one Order produces not one but potentially dozens or hundreds of certificates, depending on the auto-renewal "lifetime" parameter. An attacker can use this property to aggressively reduce the auto-renewal "lifetime" (e.g., 1 second) jointly with other ACME attack vectors identified in Section 10 of [RFC8555]. Other collateral impact is related to the certificate endpoint resource where the client can retrieve the certificates periodically. If this resource is external to the CA (e.g., a hosted web server), the previous attack will be reflected to that resource.
STARは、CAの動作の変更によって引き起こされるサービス拒否攻撃の脅威を増大させる新しい攻撃ベクトルを追加します。各STAR要求は、CAに対するリソース要求を増幅します。1つの注文は、自動更新の「ライフタイム」パラメーターに応じて、1つではなく数十または数百の証明書を生成します。攻撃者はこのプロパティを使用して、[RFC8555]のセクション10で特定された他のACME攻撃ベクトルと連携して、自動更新の「ライフタイム」（1秒など）を積極的に短縮できます。その他の付随的な影響は、クライアントが定期的に証明書を取得できる証明書エンドポイントリソースに関連しています。このリソースがCA（ホストされているWebサーバーなど）の外部にある場合、以前の攻撃はそのリソースに反映されます。
Mitigation recommendations from ACME still apply, but some of them need to be adjusted. For example, applying rate limiting to the initial request, due to the nature of the auto-renewal behavior, cannot solve the above problem. The CA server needs complementary mitigation, and specifically, it SHOULD enforce a minimum value on auto-renewal "lifetime". Alternatively, the CA can set a rate limit for internal certificate generation processes. Note that this limit has to take account of already scheduled renewal issuances as well as new incoming requests.
ACMEからの緩和の推奨事項は引き続き適用されますが、それらのいくつかは調整する必要があります。たとえば、自動更新動作の性質上、最初のリクエストにレート制限を適用しても、上記の問題を解決できません。 CAサーバーは補完的な緩和が必要であり、具体的には、自動更新の「ライフタイム」に最小値を適用する必要があります（SHOULD）。あるいは、CAは内部証明書生成プロセスのレート制限を設定できます。この制限では、すでにスケジュールされている更新の発行と新しい着信要求を考慮する必要があることに注意してください。
In order to avoid correlation of certificates by account, if unauthenticated GET is negotiated (Section 3.4), the recommendation in Section 10.5 of [RFC8555] regarding the choice of URL structure applies, i.e., servers SHOULD choose URLs of certificate resources in a non-guessable way, for example, using capability URLs [W3C.CAPABILITY-URLS].
アカウントによる証明書の相関を回避するために、認証されていないGETがネゴシエートされた場合（セクション3.4）、URL構造の選択に関する[RFC8555]のセクション10.5の推奨が適用されます。つまり、サーバーは、証明書リソースのURLをたとえば、機能のURL [W3C.CAPABILITY-URLS]を使用するなど、推測可能な方法です。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC3339] Klyne、G。およびC. Newman、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https://www.rfc-editor.org/info/rfc3339 >。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<https://www.rfc-editor.org/info/rfc7234>。
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, <https://www.rfc-editor.org/info/rfc7807>.
[RFC7807]ノッティンガム、M。およびE.ワイルド、「HTTP APIの問題の詳細」、RFC 7807、DOI 10.17487 / RFC7807、2016年3月、<https://www.rfc-editor.org/info/rfc7807>。
[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>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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>.
[RFC8555] Barnes、R.、Hoffman-Andrews、J.、McCarney、D。、およびJ. Kasten、「自動証明書管理環境（ACME）」、RFC 8555、DOI 10.17487 / RFC8555、2019年3月、<https：/ /www.rfc-editor.org/info/rfc8555>。
[ACER] Acer, M.E., Stark, E., Felt, A.P., Fahl, S., Bhargava, R., Dev, B., Braithwaite, M., Sleevi, R., and P. Tabriz, "Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors", DOI 10.1145/3133956.3134007, October 2017, <https://acmccs.github.io/papers/p1407-acerA.pdf>.
[ACER] Acer、ME、Stark、E.、Felt、AP、Fahl、S.、Bhargava、R.、Dev、B.、Braithwaite、M.、Sleevi、R.、P。Tabriz、「Where the Wild警告は次のとおりです：Chrome HTTPS証明書エラーの根本的な原因」、DOI 10.1145 / 3133956.3134007、2017年10月、<https://acmccs.github.io/papers/p1407-acerA.pdf>。
[OBRIEN] O'Brien, D. and R. Sleevi, "Chromium Certificate Transparency Policy", April 2017, <https://github.com/chromium/ct-policy>.
[OBRIEN] O'Brien、D。およびR. Sleevi、「Chromium Certificate Transparency Policy」、2017年4月、<https://github.com/chromium/ct-policy>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066] Eastlake 3rd、D。、「Transport Layer Security（TLS）Extensions：Extension Definitions」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https://www.rfc-editor.org/info/rfc6066> 。
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) Feature Extension", RFC 7633, DOI 10.17487/RFC7633, October 2015, <https://www.rfc-editor.org/info/rfc7633>.
[RFC7633] Hallam-Baker、P。、「X.509v3トランスポート層セキュリティ（TLS）機能拡張」、RFC 7633、DOI 10.17487 / RFC7633、2015年10月、<https://www.rfc-editor.org/info/ rfc7633>。
[SHORT-TERM-CERTS] Nir, Y., Fossati, T., Sheffer, Y., and T. Eckert, "Considerations For Using Short Term Certificates", Work in Progress, Internet-Draft, draft-nir-saag-star-01, 5 March 2018, <https://tools.ietf.org/html/draft-nir-saag-star-01>.
[SHORT-TERM-CERTS] Nir、Y.、Fossati、T.、Sheffer、Y。、およびT. Eckert、「短期証明書の使用に関する考慮事項」、進行中の作業、インターネットドラフト、draft-nir-saag- star-01、2018年3月5日、<https://tools.ietf.org/html/draft-nir-saag-star-01>。
[STAR-DELEGATION] Sheffer, Y., Lopez, D., Pastor, A., and T. Fossati, "An ACME Profile for Generating Delegated STAR Certificates", Work in Progress, Internet-Draft, draft-ietf-acme-star-delegation-03, 8 March 2020, <https://tools.ietf.org/html/ draft-ietf-acme-star-delegation-03>.
[STAR-DELEGATION] Sheffer、Y.、Lopez、D.、Pastor、A。、およびT. Fossati、「委任されたSTAR証明書を生成するためのACMEプロファイル」、進行中の作業、インターネットドラフト、draft-ietf-acme- star-delegation-03、2020年3月8日、<https://tools.ietf.org/html/draft-ietf-acme-star-delegation-03>。
[STARK] Stark, E., Huang, L.S., Israni, D., Jackson, C., and D. Boneh, "The case for prefetching and prevalidating TLS server certificates", February 2012, <https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-prefetch.html>.
[STARK] Stark、E.、Huang、LS、Israni、D.、Jackson、C。、およびD. Boneh、「TLSサーバー証明書のプリフェッチと事前検証のケース」、2012年2月、<https：//crypto.stanford .edu /〜dabo / pubs / abstracts / ssl-prefetch.html>。
[TOPALOVIC] Topalovic, E., Saeta, B., Huang, L.S., Jackson, C., and D. Boneh, "Towards Short-Lived Certificates", 2012, <https://www.ieee-security.org/TC/W2SP/2012/papers/ w2sp12-final9.pdf>.
[TOPALOVIC] Topalovic、E.、Saeta、B.、Huang、LS、Jackson、C。、およびD. Boneh、「Toward Short-Lived Certificates」、2012、<https://www.ieee-security.org/ TC / W2SP / 2012 / papers / w2sp12-final9.pdf>。
[W3C.CAPABILITY-URLS] Tennison, J., "Good Practices for Capability URLs", W3C First Public Working Draft, Latest version available at <https://www.w3.org/TR/capability-urls/>, February 2014, <https://www.w3.org/TR/2014/WD-capability-urls-20140218>.
[W3C.CAPABILITY-URLS] Tennison、J.、「機能URLの推奨事項」、W3C最初の公開草案、<https://www.w3.org/TR/capability-urls/>で入手可能な最新バージョン、2月2014、<https://www.w3.org/TR/2014/WD-capability-urls-20140218>。
Acknowledgments
謝辞
This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI). This support does not imply endorsement.
この作業は、ホライゾン2020助成金契約No. 688421ミドルボックスインターネット（MAMI）の測定とアーキテクチャ。このサポートは保証を意味するものではありません。
Thanks to Ben Kaduk, Richard Barnes, Roman Danyliw, Jon Peterson, Eric Rescorla, Ryan Sleevi, Sean Turner, Alexey Melnikov, Adam Roach, Martin Thomson, and Mehmet Ersue for helpful comments and discussions that have shaped this document.
このドキュメントを形作った有益なコメントと議論をしてくれたBen Kaduk、Richard Barnes、Roman Danyliw、Jon Peterson、Eric Rescorla、Ryan Sleevi、Sean Turner、Alexey Melnikov、Adam Roach、Martin Thomson、Mehmet Ersueに感謝します。
Authors' Addresses
著者のアドレス
Yaron Sheffer Intuit
Yaron Sheffer Intuit
Email: yaronf.ietf@gmail.com
Diego Lopez Telefonica I+D
ディエゴロペステレフォニカI + D
Email: diego.r.lopez@telefonica.com
Oscar Gonzalez de Dios Telefonica I+D
オスカーゴンザレスデディオステレフォニカI + D
Email: oscar.gonzalezdedios@telefonica.com
Antonio Agustin Pastor Perales Telefonica I+D
アントニオ・アグスティン牧師ペラレス・テレフォニカI + D
Email: antonio.pastorperales@telefonica.com
Thomas Fossati ARM
Thomas Fossati ARM
Email: thomas.fossati@arm.com