[要約] RFC 9115は、委任された証明書を生成するためのACMEプロファイルを定義しています。この文書の目的は、自動化された証明書管理環境を提供し、セキュリティを強化することです。利用場面としては、ウェブサーバーなどのインターネットサービスで、安全な通信を確保するために使用されます。
Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 9115 Intuit
Category: Standards Track D. López
ISSN: 2070-1721 A. Pastor Perales
Telefonica I+D
T. Fossati
ARM
September 2021
An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates
委任証明書を生成するための自動証明書管理環境（ACME）プロファイル
Abstract
概要
This document defines a profile of the Automatic Certificate Management Environment (ACME) protocol by which the holder of an identifier (e.g., a domain name) can allow a third party to obtain an X.509 certificate such that the certificate subject is the delegated identifier while the certified public key corresponds to a private key controlled by the third party. A primary use case is that of a Content Delivery Network (CDN), the third party, terminating TLS sessions on behalf of a content provider (the holder of a domain name). The presented mechanism allows the holder of the identifier to retain control over the delegation and revoke it at any time. Importantly, this mechanism does not require any modification to the deployed TLS clients and servers.
このドキュメントは、識別子の保持者（例えば、ドメイン名）の保持者が第三者が委任識別子であるように第三者がX.509証明書を取得できるようにすることができる自動証明書管理環境（ACME）プロトコルのプロファイルを定義する。認証された公開鍵は、第三者によって管理されている秘密鍵に対応しています。主なユースケースは、コンテンツ配信ネットワーク（CDN）、サードパーティで、コンテンツプロバイダ（ドメイン名の保持者）に代わってTLSセッションを終了します。提示されたメカニズムは、識別子のホルダが代表団の制御を保持し、いつでもそれを取り消すことを可能にする。重要なことに、このメカニズムは、デプロイされたTLSクライアントおよびサーバーを変更する必要はありません。
Status of This Memo
本文書の位置付け
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/rfc9115.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9115で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 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 LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Terminology
1.2. Conventions Used in This Document
2. Protocol Flow
2.1. Preconditions
2.2. Overview
2.3. Delegated Identity Profile
2.3.1. Delegation Configuration
2.3.2. Order Object Transmitted from NDC to IdO and to ACME
Server (STAR)
2.3.3. Order Object Transmitted from NDC to IdO and to ACME
Server (Non-STAR)
2.3.4. Capability Discovery
2.3.5. Negotiating an Unauthenticated GET
2.3.6. Terminating the Delegation
2.4. Proxy Behavior
3. CA Behavior
4. CSR Template
4.1. Template Syntax
4.2. Example
5. Further Use Cases
5.1. CDN Interconnection (CDNI)
5.1.1. Multiple Parallel Delegates
5.1.2. Chained Delegation
5.2. Secure Telephone Identity Revisited (STIR)
6. IANA Considerations
6.1. New Fields in the "meta" Object within a Directory Object
6.2. New Fields in the Order Object
6.3. New Fields in the Account Object
6.4. New Error Types
6.5. CSR Template Extensions
7. Security Considerations
7.1. Trust Model
7.2. Delegation Security Goal
7.3. New ACME Channels
7.4. Restricting CDNs to the Delegation Mechanism
8. References
8.1. Normative References
8.2. Informative References
Appendix A. CSR Template: CDDL
Appendix B. CSR Template: JSON Schema
Acknowledgements
Authors' Addresses
This document is related to [RFC8739], in that some important use cases require both documents to be implemented. To avoid duplication, we give here a bare-bones description of the motivation for this solution. For more details, please refer to the introductory sections of [RFC8739].
この文書は[RFC8739]に関連していますが、いくつかの重要な使用例では、両方の文書を実装する必要があります。重複を避けるために、ここではこの解決策の動機づけのベアーンボーンの説明を与えます。詳しくは、[RFC8739]の紹介セクションを参照してください。
An Identifier Owner (IdO) has agreements in place with one or more Name Delegation Consumer (NDC) to use and attest its identity.
識別子所有者（IDO）は、その身元を使用して検証するために、1つまたは複数の名前委任消費者（NDC）を備えている契約を持っています。
In the primary use case, the IdO is a content provider, and we consider a Content Delivery Network (CDN) provider contracted to serve the content over HTTPS. The CDN terminates the HTTPS connection at one of its edge cache servers and needs to present its clients (browsers, mobile apps, set-top boxes) a certificate whose name matches the domain name of the URL that is requested, i.e., that of the IdO. Understandably, some IdOs may balk at sharing their long-term private keys with another organization; equally, delegates would rather not have to handle other parties' long-term secrets. Other relevant use cases are discussed in Section 5.
プライマリユースケースでは、IDOはコンテンツプロバイダであり、Content Delivery Network（CDN）プロバイダがHTTPSを介したコンテンツにサービスを提供することを検討します。CDNは、そのエッジキャッシュサーバーのうちの1つでHTTPS接続を終了し、そのクライアント（ブラウザ、モバイルアプリ、セットトップボックス）が要求されているURLのドメイン名と一致する証明書、つまり、その名前を表示する必要があります。私がやります。当然のことながら、いくつかのIDOは、長期の秘密鍵を別の組織と共有するのに悩まされる可能性があります。同様に、代表者は他の締約国の長期秘密を取り扱う必要はなく、むしろ対象となるでしょう。その他の関連するユースケースについては、セクション5で説明します。
This document describes a profile of the ACME protocol [RFC8555] that allows the NDC to request from the IdO, acting as a profiled ACME server, a certificate for a delegated identity -- i.e., one belonging to the IdO. The IdO then uses the ACME protocol (with the extensions described in [RFC8739]) to request issuance of a Short-Term, Automatically Renewed (STAR) certificate for the same delegated identity. The generated short-term certificate is automatically renewed by the ACME Certification Authority (CA), is periodically fetched by the NDC, and is used to terminate HTTPS connections in lieu of the IdO. The IdO can end the delegation at any time by simply instructing the CA to stop the automatic renewal and letting the certificate expire shortly thereafter.
この文書では、Profiled Acmeサーバーとして機能するIDOから、IDOから機能するIDOから、IDOに属する証明書をIDOから要求できるACMEプロトコル[RFC8555]のプロファイルについて説明します。IDOは次にACMEプロトコル（[RFC8739]に記載されている拡張機能）を使用して、同じ委任されたIDのために自動的に更新された（スター）証明書の発行を要求します。生成された短期証明書はACME認証局（CA）によって自動的に更新され、NDCによって定期的にフェッチされ、IDOの代わりにHTTPS接続を終了するために使用されます。IDOは、自動更新を停止させ、その直後に証明書が期限切れになるようにCAに任意の時期に委任を終了することができます。
While the primary use case we address is a delegation of STAR certificates, the mechanism proposed here also accommodates long-lived certificates managed with the ACME protocol. The most noticeable difference between long-lived and STAR certificates is the way the termination of the delegation is managed. In the case of long-lived certificates, the IdO uses the "revokeCert" URL exposed by the CA and waits for the explicit revocation based on the Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) to propagate to the relying parties.
私たちが宛てた主要なユースケースはスター証明書の委任ですが、ここで提案されているメカニズムは、ACMEプロトコルで管理されている長年の証明書にも対応しています。長年の証明書とスター証明書の中で最も注目に値する違いは、委任の終了が管理されている方法です。長期的な証明書の場合、IDOはCAによって公開されている「Revokecert」URLを使用し、証明書失効リスト（CRL）とオンライン証明書ステータスプロトコル（OCSP）に基づく明示的な失効を待ちます（OCSP）。。
In case the delegated identity is a domain name, this document also provides a way for the NDC to inform the IdO about the CNAME mappings that need to be installed in the IdO's DNS zone to enable the aliasing of the delegated name, thus allowing the complete name delegation workflow to be handled using a single interface.
委任されたIDがドメイン名である場合、このドキュメントでは、NDCがIDOのDNSゾーンにインストールする必要があるCNAMEマッピングについてIDOにIDOに通知することで、委任名のエイリアシングを可能にします。単一のインタフェースを使用して処理される名前委任ワークフロー。
We note that other standardization efforts address the problem of certificate delegation for TLS connections, specifically [TLS-SUBCERTS] and [MGLT-LURK-TLS13]. The former extends the TLS certificate chain with a customer-owned signing certificate; the latter separates the server's private key into a dedicated, more-secure component. Compared to these other approaches, the current document does not require changes to the TLS network stack of the client or the server, nor does it introduce additional latency to the TLS connection.
他の標準化努力は、TLS接続、特に[TLS-SUBCERTS]と[MGLT-LURK-TLS13]の証明書委任の問題に対処していることに注意してください。前者は、TLS証明書チェーンを顧客所有の署名証明書と共に拡張します。後者はサーバーの秘密鍵を専用の、より安全なコンポーネントに分離します。これらの他のアプローチと比較して、現在の文書はクライアントまたはサーバーのTLSネットワークスタックへの変更を必要とせず、TLS接続に追加の待ち時間を導入しません。
IdO Identifier Owner, the holder (current owner) of an identifier (e.g., a domain name) that needs to be delegated. Depending on the context, the term IdO may also be used to designate the (profiled) ACME server deployed by the Identifier Owner or the ACME client used by the Identifier Owner to interact with the CA.
IDO識別子の所有者、委任される必要がある識別子（例えば、ドメイン名）の保持者（現在の所有者）。コンテキストによっては、IDOという用語は、識別子所有者によって展開された（プロファイリングされた）ACMEサーバまたはCAと対話するために識別子所有者によって使用されるACMEクライアントを指定するためにも使用され得る。
NDC Name Delegation Consumer, the entity to which the domain name is delegated for a limited time. This is a CDN in the primary use case (in fact, readers may note the similarity of the two abbreviations). Depending on the context, the term NDC may also be used to designate the (profiled) ACME client used by the Name Delegation Consumer.
NDC名委任消費者、ドメイン名が限られた期間委任されているエンティティ。これは主要なユースケースのCDNです（実際、読者は2つの略語の類似性に注意してもよい）。コンテキストに応じて、NDCという用語は、名前委任消費者によって使用される（プロファイリングされた）ACMEクライアントを指定するためにも使用され得る。
CDN Content Delivery Network, a widely distributed network that serves the domain's web content to a wide audience at high performance.
CDN Content Delivery Networkは、ドメインのWebコンテンツを高性能で広い視聴者にサービスする広く分散したネットワークです。
STAR Short-Term, Automatically Renewed, as applied to X.509 certificates.
X.509証明書に適用されるように、スター短期間、自動的に更新されました。
ACME Automated Certificate Management Environment, a certificate management protocol [RFC8555].
ACME自動証明書管理環境、証明書管理プロトコル[RFC8555]。
CA Certification Authority, specifically one that implements the ACME protocol. In this document, the term is synonymous with "ACME server deployed by the Certification Authority".
CA認証局、特にACMEプロトコルを実装するもの。この文書では、この用語は「認証局によって展開されたACMEサーバー」と同義です。
CSR Certificate Signing Request, specifically a PKCS#10 [RFC2986] Certificate Signing Request, as supported by ACME.
CSR証明書の署名要求、特にPKCS＃10 [RFC2986] ACMEでサポートされている証明書署名要求。
FQDN Fully Qualified Domain Name.
FQDN完全修飾ドメイン名。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This section presents the protocol flow. For completeness, we include the ACME profile proposed in this document as well as the ACME STAR protocol described in [RFC8739].
このセクションではプロトコルフローを示します。完全性については、[RFC8739]に記載されているACMEスタープロトコルと同様に、この文書で提案されているACMEプロファイルを含みます。
The protocol assumes the following preconditions are met:
プロトコルは次の前提条件を満たしていると仮定します。
* The IdO exposes an ACME server interface to the NDC(s) comprising the account management interface.
* IDOは、アカウント管理インターフェイスを含むNDCにACMEサーバインタフェースを公開します。
* The NDC has registered an ACME account with the IdO.
* NDCはIDOとACMEアカウントを登録しました。
* The NDC and IdO have agreed on a "CSR template" to use, including at a minimum: subject name (e.g., "abc.ido.example"), requested algorithms and key length, key usage, and extensions. The NDC will use this template for every CSR created under the same delegation.
* NDCとIDOは、最小限のもの名（例えば、「abc.ido.example」）、要求されたアルゴリズムとキー長、鍵の使用法、および拡張子を含む「CSRテンプレート」について合意しました。NDCは、同じ委任下で作成されたCSRごとにこのテンプレートを使用します。
* The IdO has registered an ACME account with the Certification Authority (CA).
* IDOは認証局（CA）とACMEアカウントを登録しました。
Note that even if the IdO implements the ACME server role, it is not acting as a CA; in fact, from the point of view of the certificate issuance process, the IdO only works as a "policing" forwarder of the NDC's key pair and is responsible for completing the identity verification process towards the CA.
IDOがACMEサーバーの役割を実装していても、CAとして機能していません。実際、証明書発行プロセスの観点からは、IDOはNDCの鍵ペアの「ポリシング」フォワーダとしてのみ機能し、CAに向けてID検証プロセスを完了する責任があります。
For clarity, the protocol overview presented here covers the main use case of this protocol, namely delegation of STAR certificates. Protocol behavior for non-STAR certificates is similar, and the detailed differences are listed in the following sections.
明確にするために、ここに提示されているプロトコルの概要は、このプロトコルの主なユースケース、すなわちスター証明書の委任を網羅しています。非スター証明書のプロトコル動作は似ており、詳細な違いは次のセクションにリストされています。
The interaction between the NDC and the IdO is governed by the profiled ACME workflow detailed in Section 2.3. The interaction between the IdO and the CA is ruled by ACME [RFC8555], ACME STAR [RFC8739], and any other ACME extension that applies (e.g., [TOKEN-TNAUTHLIST] for Secure Telephone Identity Revisited (STIR)).
NDCとIDOとの間の相互作用は、セクション2.3に詳述されているプロファイリングされたACMEワークフローによって管理されています。IDOとCAの間の相互作用は、ACME [RFC8555]、ACME STAR [RFC8739]、およびその他のACME拡張機能（例えば、安全な電話IDの再検討（STIR））によって統一されています。
The outline of the combined protocol for STAR certificates is as follows (Figure 1):
STAR証明書の複合プロトコルの概要は以下の通りです（図1）。
* NDC sends an Order1 for the delegated identifier to IdO.
* NDCは、委任識別子にIDOに注文1を送信します。
* IdO creates an Order1 resource in state "ready" with a "finalize" URL.
* IDOは、「最終的な」URLを使用して、「準備完了」に順序1リソースを作成します。
* NDC immediately sends a "finalize" request (which includes the CSR) to the IdO.
* NDCはすぐにIDOに「CSRを含む」要求（CSRを含む）を送信します。
* IdO verifies the CSR according to the agreed upon CSR template.
* IDOは合意されたCSRテンプレートに従ってCSRを検証します。
* If the CSR verification fails, Order1 is moved to an "invalid" state and everything stops.
* CSR検証が失敗した場合、Order1は「無効な」状態に移動し、すべてが停止します。
* If the CSR verification is successful, IdO moves Order1 to state "processing" and sends a new Order2 (using its own account) for the delegated identifier to the CA.
* CSR検証が成功した場合、IDOはOrder1を「処理」状態に移動し、委任識別子のために（それ自身のアカウントを使用して）CAに送信されます。
* If the ACME STAR protocol fails, Order2 moves to "invalid", and the same state is reflected in Order1 (i.e., the NDC Order).
* ACMEスタープロトコルが失敗した場合、順序2は「無効」に移動し、同じ状態が順序1（すなわち、NDC順序）に反映される。
* If the ACME STAR run is successful (i.e., Order2 is "valid"), IdO copies the "star-certificate" URL from Order2 to Order1 and updates the Order1 state to "valid".
* ACMEスターの実行が成功した場合（すなわち、ORDER2が「有効」）、IDOはOrder2からOrder1に "Star-Certificate" URLをコピーし、Order1状態を "有効"に更新します。
The NDC can now download, install, and use the short-term certificate bearing the name delegated by the IdO. The STAR certificate can be used until it expires, at which time the NDC is guaranteed to find a new certificate it can download, install, and use. This continues with subsequent certificates until either Order1 expires or the IdO decides to cancel the automatic renewal process with the CA.
NDCは、IDOによって委任された名前をベアリングした短期証明書をダウンロード、インストール、および使用できるようになりました。STAR証明書は、それが期限切れになるまで使用することができ、その時点でNDCはダウンロード、インストール、および使用できる新しい証明書を見つけることが保証されています。どちらの順序1が期限切れになるか、またはIDOがCAで自動更新プロセスをキャンセルすることを決定するまで、これはその後の証明書を続けます。
Note that the interactive identifier authorization phase described in Section 7.5 of [RFC8555] is suppressed on the NDC-IdO side because the delegated identity contained in the CSR presented to the IdO is validated against the configured CSR template (Section 4.1). Therefore, the NDC sends the "finalize" request, including the CSR, to the IdO immediately after Order1 has been acknowledged. The IdO SHALL buffer a (valid) CSR until the Validation phase completes successfully.
[RFC8555]のセクション7.5で説明されている対話型ID認証フェーズは、IDOに表示されているCSRに含まれる委任されたIDが設定されたCSRテンプレートに対して検証されているため（セクション4.1）。したがって、NDCは、Order1が承認された直後のIDOに、CSRを含む「ファイナライズ」要求をIDOに送信します。IDOは、検証フェーズが正常に完了するまで（有効）CSRをバッファします。
Also note that the successful negotiation of the unauthenticated GET (Section 3.4 of [RFC8739]) is required in order to allow the NDC to access the "star-certificate" URL on the CA.
また、NDCがCA上の「スター証明書」URLにアクセスできるようにするためには、未認証GET（RFC8739]のセクション3.4）の交渉が成功していることにも注意してください。
.------. .---------------. .------.
| NDC | | IdO | | ACME |
+--------+ +--------+--------+ +--------+
| Client | | Server | Client | | Server |
'---+----' '----+---+---+----' '----+---'
| | | |
| Order1 | | |
| Signature | | |
o------------------->| | |
| | | |
| [ No identity ] | | |
| [ validation via ] | | |
| [ authorizations ] | | |
| | | |
| CSR | | |
| Signature | | |
o------------------->| | |
| Acknowledgement | | Order2 |
|<-------------------o | Signature |
| | o------------------->|
| | | Required |
| | | Authorizations |
| | |<-------------------o
| | | Responses |
| | | Signature |
| | o------------------->|
| | | |
| | |<~~~~Validation~~~~>|
| | | |
| | | CSR |
| | | Signature |
| | o------------------->|
| | | Acknowledgement |
| | |<-------------------o
| | | |
|<~~Await issuance~->| |<~~Await issuance~~>|
| |
| (unauthenticated) GET STAR certificate |
o------------------------------------------------>|
| Certificate #1 |
|<------------------------------------------------o
| (unauthenticated) GET STAR certificate |
o------------------------------------------------>|
| Certificate #2 |
|<------------------------------------------------o
| [...] |
| (unauthenticated) GET STAR certificate |
o------------------------------------------------>|
| Certificate #n |
|<------------------------------------------------o
Figure 1: End-to-End STAR Delegation Flow
図1：エンドツーエンドスター委任フロー
This section defines a profile of the ACME protocol to be used between the NDC and IdO.
このセクションでは、NDCとIDOの間で使用されるACMEプロトコルのプロファイルを定義します。
The IdO must be preconfigured to recognize one or more NDCs and present them with details about certificate delegations that apply to each one.
IDOは、1つ以上のNDCを認識し、それぞれに適用される証明書の委任に関する詳細でそれらを提示するために事前設定されなければなりません。
An NDC identifies itself to the IdO as an ACME account. The IdO can delegate multiple names to an NDC, and these configurations are described through "delegation" objects associated with the NDC's account object on the IdO.
NDCは、ACMEアカウントとしてIDOをIDOに識別します。IDOは複数の名前をNDCに委任することができ、これらの構成はIDO上のNDCのアカウントオブジェクトに関連付けられている「委任」オブジェクトを介して記述されています。
As shown in Figure 2, the ACME account resource on the IdO is extended with a new "delegations" attribute:
図2に示すように、IDO上のACMEアカウントリソースは、新しい "delegations"属性で拡張されています。
delegations (required, string): A URL from which a list of delegations configured for this account (Section 2.3.1.3) can be fetched via a POST-as-GET request.
委任（必須、文字列）：このアカウントに設定されている代表団のリスト（セクション2.3.1.3）をPost-AS-GETリクエストを介してフェッチできるURL。
{
"status": "valid",
"contact": [
"mailto:delegation-admin@ido.example"
],
"termsOfServiceAgreed": true,
"orders": "https://example.com/acme/orders/saHpfB",
"delegations": "https://acme.ido.example/acme/delegations/adFqoz"
}
Figure 2: Example Account Object with Delegations
図2：代理人のアカウントオブジェクトの例
Each account object includes a "delegations" URL from which a list of delegation configurations created by the IdO can be fetched via a POST-as-GET request. The result of the request MUST be a JSON object whose "delegations" field is an array of URLs, each identifying a delegation configuration made available to the NDC account (Section 2.3.1.3). The server MAY return an incomplete list, along with a "Link" header field with a "next" link relation indicating where further entries can be acquired.
各アカウントオブジェクトには、IDOによって作成された委任構成のリストがPost-AS-GET要求を介してフェッチできる「代表団」のURLが含まれています。リクエストの結果は、 "delegations"フィールドがURLの配列であるJSONオブジェクトでなければなりません。それぞれNDCアカウントで利用可能にされた委任設定を識別します（2.3.1.3項）。サーバは、「リンク」ヘッダフィールドと共に、「リンク」ヘッダフィールドと共に、「次のインストール」リンク関係を取得することができる。
HTTP/1.1 200 OK
Content-Type: application/json
Link: <https://acme.ido.example/acme/directory>;rel="index"
Link: <https://acme.ido.example/acme/delegations/adFqoz?/
cursor=2>;rel="next"
{
"delegations": [
"https://acme.ido.example/acme/delegation/ogfr8EcolOT",
"https://acme.ido.example/acme/delegation/wSi5Lbb61E4",
/* more URLs not shown for example brevity */
"https://acme.ido.example/acme/delegation/gm0wfLYHBen"
]
}
Note that in the figure above, https://acme.ido.example/acme/delegations/adFqoz?cursor=2 includes a line break for the sake of presentation.
上の図では、https：//acme.ido.example/acme/delegations/adfqoz？cursor = 2には、プレゼンテーションのためのラインブレークが含まれています。
This profile extends the ACME resource model with a new read-only "delegation" object that represents a delegation configuration that applies to a given NDC.
このプロファイルは、特定のNDCに適用される委任設定を表す新しい読み取り専用の「委任」オブジェクトを使用してACMEリソースモデルを拡張します。
A "delegation" object contains the CSR template (see Section 4) that applies to that delegation and, optionally, any related CNAME mapping for the delegated identifiers. Its structure is as follows:
「委任」オブジェクトには、その委任に適用されるCSRテンプレート（セクション4を参照）、および任意の委任識別子の任意の関連CNAMEマッピングが含まれています。その構造は次のとおりです。
csr-template (required, object): CSR template, as defined in Section 4.
CSR-Template（必須、オブジェクト）：4セクション4で定義されているように、CSRテンプレート。
cname-map (optional, object): A map of FQDN pairs. In each pair, the name is the delegated identifier; the value is the corresponding NDC name that is aliased in the IdO's zone file to redirect the resolvers to the delegated entity. Both names and values MUST be FQDNs with a terminating '.'. This field is only meaningful for identifiers of type "dns".
cname-map（オプション、オブジェクト）：FQDNペアのマップ。各ペアでは、名前は委任識別子です。値は、IDOのゾーンファイルでエイリアスされて、リゾルバを委任されたエンティティにリダイレクトするための対応するNDC名です。名前と値の両方が終了したFQDNSでなければなりません。このフィールドは、 "DNS"の型の識別子にのみ意味があります。
An example "delegation" object in JSON format is shown in Figure 3.
JSON形式の「委任」オブジェクトの例を図3に示します。
{
"csr-template": {
"keyTypes": [
{
"PublicKeyType": "id-ecPublicKey",
"namedCurve": "secp256r1",
"SignatureType": "ecdsa-with-SHA256"
}
],
"subject": {
"country": "CA",
"stateOrProvince": "**",
"locality": "**"
},
"extensions": {
"subjectAltName": {
"DNS": [
"abc.ido.example"
]
},
"keyUsage": [
"digitalSignature"
],
"extendedKeyUsage": [
"serverAuth"
]
}
},
"cname-map": {
"abc.ido.example.": "abc.ndc.example."
}
}
Figure 3: Example Delegation Configuration Object
図3：委任設定オブジェクトの例
In order to indicate which specific delegation applies to the requested certificate, a new "delegation" attribute is added to the order object on the NDC-IdO side (see Figures 4 and 7). The value of this attribute is the URL pointing to the delegation configuration object that is to be used for this certificate request. If the "delegation" attribute in the order object contains a URL that does not correspond to a configuration available to the requesting ACME account, the IdO MUST return an error response with status code 403 (Forbidden), providing a problem document [RFC7807] with type "urn:ietf:params:acme:error:unknownDelegation".
要求された証明書にどの特定の委任が適用されるかを示すために、NDC-IDO側のOrderオブジェクトに新しい「委任」属性が追加されます（図4および7を参照）。この属性の値は、この証明書要求に使用される委任設定オブジェクトを指すURLです。Orderオブジェクトの "delegation"属性に、要求側のACMEアカウントで利用可能な構成に対応しないURLが含まれている場合、IDOはステータスコード403（禁止）でエラー応答を返す必要があり、問題文書[RFC7807]type "urn：ietf：params：acme：error：egrange：unknownDelegation"を入力します。
2.3.2. Order Object Transmitted from NDC to IdO and to ACME Server (STAR)
2.3.2. NDCからIDOへ、およびACME Server（Star）から送信されたオブジェクトを注文する
If the delegation is for a STAR certificate, the request object created by the NDC:
委任がSTAR証明書の場合は、NDCによって作成された要求オブジェクト。
* MUST have a "delegation" attribute indicating the preconfigured delegation that applies to this Order;
* この順序に適用される事前設定された委任を示す「委任」属性が必要です。
* MUST have entries in the "identifiers" field for each delegated name present in the configuration;
* 構成に存在する各委任名の「識別子」フィールドにエントリが必要です。
* MUST NOT contain the "notBefore" and "notAfter" fields; and
* "notbefore"と "notafter"フィールドを含んではいけません。と
* MUST contain an "auto-renewal" object and, inside it, the fields listed in Section 3.1.1 of [RFC8739]. In particular, the "allow-certificate-get" attribute MUST be present and set to true.
* 「自動更新」オブジェクト、内側にある[RFC8739]のセクション3.1.1にリストされているフィールドを含める必要があります。特に、 "allow-certificate-get"属性が存在し、trueに設定されている必要があります。
POST /acme/new-order HTTP/1.1
Host: acme.ido.example
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
"nonce": "Alc00Ap6Rt7GMkEl3L1JX5",
"url": "https://acme.ido.example/acme/new-order"
}),
"payload": base64url({
"identifiers": [
{
"type": "dns",
"value": "abc.ido.example"
}
],
"auto-renewal": {
"end-date": "2021-04-20T00:00:00Z",
"lifetime": 345600, // 4 days
"allow-certificate-get": true
},
"delegation":
"https://acme.ido.example/acme/delegation/gm0wfLYHBen"
}),
"signature": "g454e3hdBlkT4AEw...nKePnUyZTjGtXZ6H"
}
Figure 4: New STAR Order from NDC
図4：NDCからの新しい星の注文
The order object that is created on the IdO:
IDO上に作成されたOrderオブジェクト：
* MUST start in the "ready" state;
* 「準備完了」状態で始める必要があります。
* MUST contain an "authorizations" array with zero elements;
* ゼロ要素を持つ "承認"配列を含める必要があります。
* MUST contain the indicated "delegation" configuration;
* 示された「委任」構成を含める必要があります。
* MUST contain the indicated "auto-renewal" settings; and
* 示された「自動更新」設定を含める必要があります。と
* MUST NOT contain the "notBefore" and "notAfter" fields.
* "notbefore"と "notafter"フィールドを含んではいけません。
{
"status": "ready",
"expires": "2021-05-01T00:00:00Z",
"identifiers": [
{
"type": "dns",
"value": "abc.ido.example"
}
],
"auto-renewal": {
"end-date": "2021-04-20T00:00:00Z",
"lifetime": 345600,
"allow-certificate-get": true
},
"delegation": "https://acme.ido.example/acme/delegation/gm0wfLYHBen",
"委任"： "https：//acme.ido.example/acme/delegation/gm0wflyhben"、
"authorizations": [],
"finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize"
}
Figure 5: STAR Order Resource Created on IdO
図5：IDOに作成されたスターオーダーリソース
The Order is then finalized by the NDC supplying the CSR containing the delegated identifiers. The IdO checks the provided CSR against the template contained in the "delegation" object that applies to this request, as described in Section 4.1. If the CSR fails validation for any of the identifiers, the IdO MUST return an error response with status code 403 (Forbidden) and an appropriate type, e.g., "rejectedIdentifier" or "badCSR". The error response SHOULD contain subproblems (Section 6.7.1 of [RFC8555]) for each failed identifier. If the CSR is successfully validated, the order object status moves to "processing" and the twin ACME protocol instance is initiated on the IdO-CA side.
その後、順序は、委任された識別子を含むCSRを供給するNDCによって確定されます。IDOは、セクション4.1で説明されているように、この要求に適用される「委任」オブジェクトに含まれるテンプレートに対して提供されたCSRをチェックします。CSRが任意の識別子に対して検証に失敗した場合、IDOはステータスコード403（禁止）と適切なタイプ、例えば「拒否識別子」または「BADCSR」でエラー応答を返す必要があります。失敗した識別子ごとに、エラー応答には、サブアレブス（RFC8555]のセクション6.7.1）を含める必要があります。CSRが正常に検証されている場合、順序オブジェクトのステータスは「処理」に移行し、Twin ACMEプロトコルインスタンスはIDO-CA側で開始されます。
The request object created by the IdO:
IDOによって作成された要求オブジェクト：
* MUST copy the identifiers sent by the NDC;
* NDCによって送信された識別子をコピーする必要があります。
* MUST strip the "delegation" attribute; and
* 「委任」属性を削除する必要があります。と
* MUST carry a copy of the "auto-renewal" object sent by the NDC.
* NDCによって送信された「自動更新」オブジェクトのコピーを持ちます。
When the identifiers' authorization has been successfully completed and the certificate has been issued by the CA, the IdO:
識別子の承認が正常に完了し、証明書がCAによって発行された場合、IDO
* MUST move its Order resource status to "valid" and
* 注文資源のステータスを「有効」に移動する必要があります。
* MUST copy the "star-certificate" field from the STAR Order returned by the CA into its Order resource. When dereferenced, the "star-certificate" URL includes (via the "Cert-Not-Before" and "Cert-Not-After" HTTP header fields) the renewal timers needed by the NDC to inform its certificate reload logic.
* CAによって返されたスターオーダーから「STAR-Certificate」フィールドをその注文リソースにコピーする必要があります。間接参照されると、「STAR-Certificate」URLには、（ "cert-not-before" and "http-not-httpヘッダーフィールドを介して）必要とされる更新タイマーは、その証明書のリロードロジックに通知するためにNDCに必要な更新タイマーです。
{
"status": "valid",
"expires": "2021-05-01T00:00:00Z",
"identifiers": [
{
"type": "dns",
"value": "abc.ido.example"
}
],
"auto-renewal": {
"end-date": "2021-04-20T00:00:00Z",
"lifetime": 345600,
"allow-certificate-get": true
},
"delegation": "https://acme.ido.example/acme/delegation/gm0wfLYHBen",
"委任"： "https：//acme.ido.example/acme/delegation/gm0wflyhben"、
"authorizations": [],
"finalize": "https://acme.ido.example/acme/order/TO8rfgo/finalize",
"star-certificate": "https://acme.ca.example/acme/order/yTr23sSDg9"
}
Figure 6: STAR Order Resource Updated on IdO
図6：IDO上で更新されたスターオーダーリソース
This delegation protocol is predicated on the NDC being able to fetch certificates periodically using an unauthenticated HTTP GET, since, in general, the NDC does not possess an account on the CA; as a consequence, it cannot issue the standard POST-as-GET ACME request. Therefore, before forwarding the Order request to the CA, the IdO SHOULD ensure that the selected CA supports unauthenticated GET by inspecting the relevant settings in the CA's directory object, as per Section 3.4 of [RFC8739]. If the CA does not support unauthenticated GET of STAR certificates, the IdO MUST NOT forward the Order request. Instead, it MUST move the Order status to "invalid" and set the "allow-certificate-get" in the "auto-renewal" object to "false". The same occurs in case the Order request is forwarded and the CA does not reflect the "allow-certificate-get" setting in its Order resource. The combination of "invalid" status and denied "allow-certificate-get" in the Order resource at the IdO provides an unambiguous (asynchronous) signal to the NDC about the failure reason.
この委任プロトコルは、NDCが認証されていないHTTP GETを使用して定期的に証明書を取得できるようになっています。一般的に、NDCはCA上のアカウントを所有していないため、結果として、標準のPost AS GET ACME要求を発行することはできません。したがって、注文要求をCAに転送する前に、[RFC8739]のセクション3.4に従って、CAのディレクトリオブジェクトの関連設定を検査することで、選択されたCAが認証されていないGETを確実にサポートしていることを確認する必要があります。 CAが星証明書の認証されていない取得をサポートしていない場合、IDOは注文要求を転送してはいけません。代わりに、注文ステータスを「無効」に移動し、「自動更新」オブジェクトの「allow-certificate-get」を "false"に設定する必要があります。注文要求が転送され、CAはその注文リソースで「許可証GET」設定を反映していない場合も同様です。 IDOの順序リソース内の「無効な」ステータスと拒否された「許可証GET」の組み合わせは、障害の理由についてNDCに明確な（非同期）信号を提供します。
If one of the objects in the "identifiers" list is of type "dns", the IdO can add the CNAME records specified in the "delegation" object to its zone, for example:
「識別子」リスト内のオブジェクトの1つが "dns"のタイプである場合、IDOは「委任」オブジェクトで指定されたCNAMEレコードをそのゾーンに追加できます。
abc.ido.example. CNAME abc.ndc.example.
abc.ido.example。cname abc.ndc.example。
2.3.3. Order Object Transmitted from NDC to IdO and to ACME Server (Non-STAR)
2.3.3. NDCからIDOへ、およびACMEサーバー（非星）から送信されたオーダーオブジェクト
If the delegation is for a non-STAR certificate, the request object created by the NDC:
委任が非星証明書の場合、NDCによって作成された要求オブジェクト。
* MUST have a "delegation" attribute indicating the preconfigured delegation that applies to this Order;
* この順序に適用される事前設定された委任を示す「委任」属性が必要です。
* MUST have entries in the "identifiers" field for each delegated name present in the configuration; and
* 構成に存在する各委任名の「識別子」フィールドにエントリが必要です。と
* MUST have the "allow-certificate-get" attribute set to true.
* "allow-certificate-get"属性をtrueに設定する必要があります。
POST /acme/new-order HTTP/1.1
Host: acme.ido.example
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://acme.ido.example/acme/acct/evOfKhNU60wg",
"nonce": "IYBkoQfaCS80UcCn9qH8Gt",
"url": "https://acme.ido.example/acme/new-order"
}),
"payload": base64url({
"identifiers": [
{
"type": "dns",
"value": "abc.ido.example"
}
],
"delegation":
"https://acme.ido.example/acme/delegation/gm0wfLYHBen",
"allow-certificate-get": true
}),
"signature": "j9JBUvMigi4zodud...acYkEKaa8gqWyZ6H"
}
Figure 7: New Non-STAR Order from NDC
図7：NDCからの新しいスターの注文
The order object that is created on the IdO:
IDO上に作成されたOrderオブジェクト：
* MUST start in the "ready" state;
* 「準備完了」状態で始める必要があります。
* MUST contain an "authorizations" array with zero elements;
* ゼロ要素を持つ "承認"配列を含める必要があります。
* MUST contain the indicated "delegation" configuration; and
* 示された「委任」構成を含める必要があります。と
* MUST contain the indicated "allow-certificate-get" setting.
* 指定された「許可証を得る」設定を含める必要があります。
{
"status": "ready",
"expires": "2021-05-01T00:00:00Z",
"identifiers": [
{
"type": "dns",
"value": "abc.ido.example"
}
],
"delegation": "https://acme.ido.example/acme/delegation/gm0wfLYHBen",
"委任"： "https：//acme.ido.example/acme/delegation/gm0wflyhben"、
"allow-certificate-get": true,
"authorizations": [],
"finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize"
}
Figure 8: Non-STAR Order Resource Created on IdO
図8：IDOで作成された非スターオーダーリソース
The Order finalization by the NDC and the subsequent validation of the CSR by the IdO proceed in the same way as for the STAR case. If the CSR is successfully validated, the order object status moves to "processing" and the twin ACME protocol instance is initiated on the IdO-CA side.
NDCによる注文ファイナライズとIDOによるCSRの検証は、スターケースと同じ方法で進行します。CSRが正常に検証されている場合、順序オブジェクトのステータスは「処理」に移行し、Twin ACMEプロトコルインスタンスはIDO-CA側で開始されます。
The request object created by the IdO:
IDOによって作成された要求オブジェクト：
* MUST copy the identifiers sent by the NDC;
* NDCによって送信された識別子をコピーする必要があります。
* MUST strip the "delegation" attribute; and
* 「委任」属性を削除する必要があります。と
* MUST copy the "allow-certificate-get" attribute.
* "allow-certificate-get"属性をコピーする必要があります。
When the identifiers' authorization has been successfully completed and the certificate has been issued by the CA, the IdO:
識別子の承認が正常に完了し、証明書がCAによって発行された場合、IDO
* MUST move its Order resource status to "valid" and
* 注文資源のステータスを「有効」に移動する必要があります。
* MUST copy the "certificate" field from the Order returned by the CA into its Order resource, as well as "notBefore" and "notAfter" if these fields exist.
* これらのフィールドが存在する場合は、CAによって返された順序からその注文リソースに「証明書」フィールドをコピーする必要があります。
{
"status": "valid",
"expires": "2021-05-01T00:00:00Z",
"identifiers": [
{
"type": "dns",
"value": "abc.ido.example"
}
],
"delegation": "https://acme.ido.example/acme/delegation/gm0wfLYHBen",
"委任"： "https：//acme.ido.example/acme/delegation/gm0wflyhben"、
"allow-certificate-get": true,
"authorizations": [],
"finalize": "https://acme.ido.example/acme/order/3ZDlhYy/finalize",
"certificate": "https://acme.ca.example/acme/order/YtR23SsdG9"
}
Figure 9: Non-STAR Order Resource Updated on IdO
図9：IDO上で更新されていない非スターオーダーリソース
At this point of the protocol flow, the same considerations as in Section 2.3.2.1 apply.
プロトコルフローのこの時点で、2.3.2.1.1項のような同じ考慮事項が適用されます。
Before forwarding the Order request to the CA, the IdO SHOULD ensure that the selected CA supports unauthenticated GET by inspecting the relevant settings in the CA's directory object, as per Section 2.3.5. If the CA does not support unauthenticated GET of certificate resources, the IdO MUST NOT forward the Order request. Instead, it MUST move the Order status to "invalid" and set the "allow-certificate-get" attribute to "false". The same occurs in case the Order request is forwarded and the CA does not reflect the "allow-certificate-get" setting in its Order resource. The combination of "invalid" status and denied "allow-certificate-get" in the Order resource at the IdO provides an unambiguous (asynchronous) signal to the NDC about the failure reason.
注文要求をCAに転送する前に、IDOは、セクション2.3.5に従って、CAのDirectoryオブジェクトの関連設定を検査することで、選択されたCAが認証されていないGETをサポートしていることを確認する必要があります。CAが認証されていない証明書リソースの取得をサポートしていない場合、IDOは注文要求を転送してはいけません。代わりに、注文ステータスを「無効」に移動し、「allow-certificate-get」属性を "false"に設定する必要があります。注文要求が転送され、CAはその注文リソースで「許可証GET」設定を反映していない場合も同様です。IDOの順序リソース内の「無効な」ステータスと拒否された「許可証GET」の組み合わせは、障害の理由についてNDCに明確な（非同期）信号を提供します。
In order to help a client discover support for this profile, the directory object of an ACME server (typically, one deployed by the IdO) contains the following attribute in the "meta" field:
このプロファイルのクライアントをサポートするのを助けるために、ACMEサーバーのディレクトリオブジェクト（通常はIDOによってデプロイされているもの）には、 "Meta"フィールドに次の属性が含まれています。
delegation-enabled (optional, boolean): Boolean flag indicating support for the profile specified in this memo. An ACME server that supports this delegation profile MUST include this key and MUST set it to true.
delegation-enabled（オプション、ブール値）：このメモで指定されたプロファイルのサポートを示すブールフラグ。この委任プロファイルをサポートするACMEサーバーには、このキーを含めて、Trueに設定する必要があります。
The IdO MUST declare its support for delegation using "delegation-enabled" regardless of whether it supports delegation of STAR certificates, non-STAR certificates, or both.
IDOは、スター証明書の委任、非スター証明書、またはその両方をサポートしているかにかかわらず、「委任対象」を使用して委任を支持する必要があります。
In order to help a client discover support for certificate fetching using unauthenticated HTTP GET, the directory object of an ACME server (typically, one deployed by the CA) contains the following attribute in the "meta" field:
認証されていないHTTP GETを使用している証明書フェッチのサポートをサポートするのを助けるために、ACMEサーバーのディレクトリオブジェクト（通常はCAによってデプロイされているもの）には、 "Meta"フィールドに次の属性が含まれています。
allow-certificate-get (optional, boolean): See Section 2.3.5.
allow-certificate-get（オプション、ブール値）：セクション2.3.5を参照してください。
In order to enable the name delegation of non-STAR certificates, this document defines a mechanism that allows a server to advertise support for accessing certificate resources via unauthenticated GET (in addition to POST-as-GET) and a client to enable this service with per-Order granularity.
ノンスター証明書の名前委任を可能にするために、このドキュメントは、サーバーが認証されていない取得（Post-AS-GETに加えて）およびクライアントを介して証明書リソースにアクセスするためのサポートを提供するメカニズムを定義しています。ご注文ごとの粒度。
It is worth pointing out that the protocol elements described in this section have the same names and semantics as those introduced in Section 3.4 of [RFC8739] for the STAR use case (except, of course, they apply to the certificate resource rather than the star-certificate resource). However, they differ in terms of their position in the directory meta and order objects; rather than being wrapped in an "auto-renewal" subobject, they are located at the top level.
このセクションに記載されているプロトコル要素には、Star Use Caseのセクション3.4で導入されたものと同じ名前とセマンティクスがあることを指摘する価値があります（もちろん、星ではなく証明書リソースに適用される証明書リソースに適用されます。有限資料）ただし、ディレクトリメタと順序オブジェクト内の位置に関して異なります。「自動更新」サブオブジェクトに折り返されるのではなく、それらは最上位レベルにあります。
A server states its availability to grant unauthenticated access to a client's Order certificate by setting the "allow-certificate-get" attribute to "true" in the "meta" field inside the directory object:
サーバーは、ディレクトリオブジェクト内の「Meta」フィールドに "all-certificate-get"属性を "true"に設定することによって、クライアントの注文証明書への認証されていないアクセスを許可するための可用性を述べています。
allow-certificate-get (optional, boolean): If this field is present and set to "true", the server allows GET (and HEAD) requests to certificate URLs.
allow-certificate-get（オプション、boolean）：このフィールドが存在して "true"に設定されている場合、サーバーはGet（およびHead）要求を証明書URLに許可します。
A client states its desire to access the issued certificate via unauthenticated GET by adding an "allow-certificate-get" attribute to the payload of its newOrder request and setting it to "true".
クライアントは、「allow-certificate-get」属性を新しいOrdery要求のペイロードに追加し、それを "true"に設定することによって、未認証された取得によって発行された証明書にアクセスしたいという願望を述べています。
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 certificate associated with this Order.
allow-certificate-get（オプション、ブール値）：このフィールドが存在して "true"に設定されている場合、クライアントはこの順序に関連付けられている証明書に認証されていない取得（および先頭）を許可するようにサーバーに要求します。
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 certificate resource.
認証されていないGETの使用が合意されている場合であっても、サーバーは証明書リソースへのPost-ASE GETリクエストも許可する必要があることに注意してください。
Identity delegation is terminated differently depending on whether or not this is a STAR certificate.
これはSTAR証明書かどうかによって、Identity Delegationは異なる方法で終了します。
The IdO can terminate the delegation of a STAR certificate by requesting its cancellation (see Section 3.1.2 of [RFC8739]).
IDOは、キャンセルを要求することによってスター証明書の委任を終了することができます（[RFC8739]のセクション3.1.2を参照）。
Cancellation of the ACME STAR certificate is a prerogative of the IdO. The NDC does not own the relevant account key on the CA; therefore, it can't issue a cancellation request for the STAR certificate. Potentially, since it holds the STAR certificate's private key, it could request the revocation of a single STAR certificate. However, STAR explicitly disables the revokeCert interface.
ACME STAR証明書のキャンセルは、IDOの有人的です。NDCはCAの関連アカウントキーを所有していません。したがって、スター証明書のキャンセル要求を発行することはできません。潜在的には、STAR証明書の秘密鍵を保持しているので、それは単一のスター証明書の失効を要求する可能性があります。ただし、星は明示的にRevokecertインターフェースを無効にします。
Shortly after the automatic renewal process is stopped by the IdO, the last issued STAR certificate expires and the delegation terminates.
自動更新プロセスがIDOによって停止された直後に、最後に発行されたスター証明書が期限切れと委任が終了します。
The IdO can terminate the delegation of a non-STAR certificate by requesting it to be revoked using the "revokeCert" URL exposed by the CA.
IDOは、CAによって公開されている「Revokecert」URLを使用して取り消されるように要求することで、非スター証明書の委任を終了できます。
According to Section 7.6 of [RFC8555], the revocation endpoint can be used with either the account key pair or the certificate key pair. In other words, an NDC that learns the "revokeCert" URL of the CA (which is publicly available via the CA's directory object) would be able to revoke the certificate using the associated private key. However, given the trust relationship between the NDC and IdO expected by the delegation trust model (Section 7.1), as well as the lack of incentives for the NDC to prematurely terminate the delegation, this does not represent a significant security risk.
[RFC8555]のセクション7.6によると、失効エンドポイントはアカウントキーペアまたは証明書鍵ペアのいずれかで使用できます。つまり、CAの「Revokecert」URL（CAのディレクトリオブジェクトを介して公開されている）を学習するNDCは、関連付けられている秘密鍵を使用して証明書を取り消すことができます。ただし、代表団信託モデル（セクション7.1）が予想しているNDCとIDOの信頼関係、ならびに委任を途中で最終的に終了させるためのインセンティブの欠如は、重要なセキュリティリスクを表していません。
There are cases where the ACME Delegation flow should be proxied, such as the use case described in Section 5.1.2. This section describes the behavior of such proxies.
5.1.2項に記載されているユースケースなど、ACME委任フローをプロキシする必要がある場合があります。このセクションでは、そのようなプロキシの動作について説明します。
An entity implementing the IdO server role -- an "ACME Delegation server" -- may behave, on a per-identity case, either as a proxy into another ACME Delegation server or as an IdO and obtain a certificate directly. The determining factor is whether it can successfully be authorized by the next-hop ACME server for the identity associated with the certificate request.
IDOサーバーロールを実装するエンティティ - 「ACME委任サーバー」 - 他のACME委任サーバーへのプロキシとして、またはIDOとして直接証明書を取得することのいずれかで、IDごとの場合には動作します。決定要因は、証明書要求に関連付けられているアイデンティティについては、ネクストホップACMEサーバによって正常に許可されたかどうかである。
The identities supported by each server and the disposition for each of them are preconfigured.
各サーバーでサポートされているアイデンティティと、それらのそれぞれの処分は事前設定されています。
Following is the proxy's behavior for each of the messages exchanged in the ACME Delegation process:
以下は、ACME委任プロセスで交換された各メッセージのプロキシの動作です。
New-order request: * The complete "identifiers" attribute MUST be copied as is. * Similarly, the "auto-renewal" object MUST be copied as is. New-order response: * The "status", "expires", "authorizations", "identifiers", and "auto-renewal" attributes/objects MUST be copied as is. * The "finalize" URL is rewritten so that the "finalize" request will be made to the proxy. * Similarly, the "Location" header MUST be rewritten to point to an order object on the proxy. * Any "Link" relations MUST be rewritten to point to the proxy. Get Order response: * The "status", "expires", "authorizations", "identifiers", and "auto-renewal" attributes/objects MUST be copied as is. * Similarly, the "star-certificate" URL (or the "certificate" URL in case of non-STAR requests) MUST be copied as is. * The "finalize" URL is rewritten so that the "finalize" request will be made to the proxy. * The "Location" header MUST be rewritten to point to an order object on the proxy. * Any "Link" relations MUST be rewritten to point to the proxy. "finalize" request: * The CSR MUST be copied as is. "finalize" response: * The "Location" header, "Link" relations, and the "finalize" URLs are rewritten as for Get Order.
新規注文要求：*完全な「識別子」属性はそのままコピーする必要があります。 *同様に、「自動更新」オブジェクトはそのままコピーする必要があります。新規注文の応答：*「ステータス」、「期限切れ」、「承認」、「識別子」、および「自動更新」属性/オブジェクトは、そのままコピーする必要があります。 ※「ファイナライズ」URLを書き換えることで、「ファイナライズ」リクエストがプロキシに行われるようになります。 *同様に、プロキシの注文オブジェクトを指すように「場所」ヘッダーを書き換える必要があります。 *「リンク」の関係は、プロキシを指すように書き直す必要があります。注文応答を取得する：*「ステータス」、「期限切れ」、「承認」、「識別子」、および「自動更新」属性/オブジェクトは、そのままコピーする必要があります。 *同様に、「スター証明書」URL（または非スター要求の場合の「証明書」URL）は、そのままコピーする必要があります。 ※「ファイナライズ」URLを書き換えることで、「ファイナライズ」リクエストがプロキシに行われるようになります。 *「場所」ヘッダーは、プロキシの注文オブジェクトを指すように書き直す必要があります。 *「リンク」の関係は、プロキシを指すように書き直す必要があります。 "Finalize"リクエスト：* CSRはそのままコピーする必要があります。 「Finalize」応答：*「場所」ヘッダー、「リンク」リレーション、および「ファイナライズ」URLは、Get Order向けに書き換えられます。
We note that all the above messages are authenticated; therefore, each proxy must be able to authenticate any subordinate server.
上記のすべてのメッセージが認証されていることに注意してください。したがって、各プロキシは下位サーバーを認証できなければなりません。
Although most of this document, and in particular Section 2, is focused on the protocol between the NDC and IdO, the protocol does affect the ACME server running in the CA. A CA that wishes to support certificate delegation MUST also support unauthenticated certificate fetching, which it declares using "allow-certificate-get" (Section 2.3.5, Paragraph 3).
この文書のほとんどは、NDCとIDOの間のプロトコルに焦点を当てていますが、プロトコルはCAで実行されているACMEサーバーに影響します。証明書の委任をサポートしたいCAも認証されていない証明書の取得をサポートしている必要があります。これは、「allow-certificate-get」を使用して宣言します（セクション2.3.5、段落3）。
The CSR template is used to express and constrain the shape of the CSR that the NDC uses to request the certificate. The CSR is used for every certificate created under the same delegation. Its validation by the IdO is a critical element in the security of the whole delegation mechanism.
CSRテンプレートは、NDCが証明書を要求するために使用するCSRの形状を表現および拘束するために使用されます。CSRは、同じ委任下で作成されたすべての証明書に使用されます。IDOによるその検証は、委任全体のメカニズムのセキュリティの重要な要素です。
Instead of defining every possible CSR attribute, this document takes a minimalist approach by declaring only the minimum attribute set and deferring the registration of further, more-specific attributes to future documents.
可能なすべてのCSR属性を定義する代わりに、このドキュメントは最小属性セットのみを宣言し、将来の文書へのさらなる特定の属性の登録を延期することによってミニマリストのアプローチを取ります。
The template is a JSON document. Each field (with the exception of "keyTypes", see below) denotes one of the following:
テンプレートはJSON文書です。各フィールド（「キータイプ」を除く（下記参照）は、次のいずれかを示します。
* A mandatory field where the template specifies the literal value of that field. This is denoted by a literal string, such as "abc.ido.example".
* テンプレートがそのフィールドのリテラル値を指定する必須フィールド。これは、 "abc.ido.ido.example"のような文字通り文字列によって表されます。
* A mandatory field where the content of the field is defined by the client. This is denoted by "**".
* フィールドの内容がクライアントによって定義されている必須フィールド。これは「**」で表されます。
* An optional field where the client decides whether the field is included in the CSR and, if so, what its value is. This is denoted by "*".
* クライアントがフィールドがCSRに含まれているかどうかをクライアントが決定し、そうであれば、その値が何であるかを決定するオプションのフィールド。これは「*」で表されます。
The NDC MUST NOT include any fields in the CSR, including any extensions, unless they are specified in the template.
NDCには、テンプレートで指定されていない限り、拡張機能を含め、CSR内のフィールドを含めてはなりません。
The structure of the template object is defined by the Concise Data Definition Language (CDDL) [RFC8610] document in Appendix A. An alternative, nonnormative JSON Schema syntax is given in Appendix B. While the CSR template must follow the syntax defined here, neither the IdO nor the NDC are expected to validate it at runtime.
テンプレートオブジェクトの構造は、付録Aの簡潔なデータ定義言語（CDDL）[RFC8610]ドキュメントで定義されています。代替的な非公式のJSONスキーマ構文は付録Bに記載されています.CSRテンプレートはここで定義された構文に従わなければならない。IDOもNDCは実行時に検証することが期待されています。
The "subject" field and its subfields are mapped into the "subject" field of the CSR, as per Section 4.1.2.6 of [RFC5280]. Other extension fields of the CSR template are mapped into the CSR according to the table in Section 6.5.
「件名」フィールドとそのサブフィールドは、[RFC5280]のセクション4.1.2.6に従って、CSRの「件名」フィールドにマッピングされています。CSRテンプレートの他の拡張フィールドは、セクション6.5の表に従ってCSRにマッピングされます。
The "subjectAltName" field is currently defined for the following identifiers: DNS names, email addresses, and URIs. New identifier types may be added in the future by documents that extend this specification. Each new identifier type SHALL have an associated identifier validation challenge that the CA can use to obtain proof of the requester's control over it.
"subjectaltName"フィールドは現在、次の識別子に定義されています.DNS名、電子メールアドレス、およびURI。新しい識別子タイプは、この仕様を拡張する文書によって将来追加できます。新しい識別子タイプの各々は、CAが要求者の制御の証明を得るために使用できる関連識別子検証課題を有するものとします。
The "keyTypes" property is not copied into the CSR. Instead, this property constrains the "SubjectPublicKeyInfo" field of the CSR, which MUST have the type/size defined by one of the array members of the "keyTypes" property.
"keytypes"プロパティはCSRにコピーされません。代わりに、このプロパティはCSRの "subjectPublicKeyInfo"フィールドを制限します。これは、 "keytypes"プロパティのいずれかの配列メンバによって定義されたタイプ/サイズを持つ必要があります。
When the IdO receives the CSR, it MUST verify that the CSR is consistent with the template contained in the "delegation" object referenced in the Order. The IdO MAY enforce additional constraints, e.g., by restricting field lengths. In this regard, note that a "subjectAltName" of type "DNS" can be specified using the wildcard notation, meaning that the NDC can be required ("**") or offered the possibility ("*") to define the delegated domain name by itself. If this is the case, the IdO MUST apply application-specific checks on top of the control rules already provided by the CSR template to ensure the requested domain name is legitimate according to its local policy.
IDOがCSRを受信すると、CSRが順序で参照されている「委任」オブジェクトに含まれるテンプレートと一致していることを確認する必要があります。IDOは、例えばフィールド長を制限することによって、追加の制約を強制することができる。この点で、「DNS」の「DNS」の「SubjectalTname」をワイルドカード表記を使用して指定できます。つまり、NDCを必要とする（「**」）、または委任ドメインを定義する可能性（ "*"）を提供したことに注意してください。それ自体で名前を付けます。この場合、IDOは、要求されたドメイン名がそのローカルポリシーに従って正当なものであることを確認するために、CSRテンプレートによって既に提供されているコントロールルールの上にアプリケーション固有のチェックを適用する必要があります。
The CSR template in Figure 10 represents one possible CSR template governing the delegation exchanges provided in the rest of this document.
図10のCSRテンプレートは、この文書の残りの部分に提供された委任交換を管理する1つの可能なCSRテンプレートを表しています。
{
"keyTypes": [
{
"PublicKeyType": "rsaEncryption",
"PublicKeyLength": 2048,
"SignatureType": "sha256WithRSAEncryption"
},
{
"PublicKeyType": "id-ecPublicKey",
"namedCurve": "secp256r1",
"SignatureType": "ecdsa-with-SHA256"
}
],
"subject": {
"country": "CA",
"stateOrProvince": "**",
"locality": "**"
},
"extensions": {
"subjectAltName": {
"DNS": [
"abc.ido.example"
]
},
"keyUsage": [
"digitalSignature"
],
"extendedKeyUsage": [
"serverAuth",
"clientAuth"
]
}
}
Figure 10: Example CSR Template
図10：CSRテンプレートの例
This nonnormative section describes additional use cases implementing the STAR certificate delegation in nontrivial ways.
この非公式のセクションでは、STAR証明書の委任を実装している追加のユースケースについて、非通の方法が記載されています。
[HTTPS-DELEGATION] discusses several solutions addressing different delegation requirements for the CDN Interconnection (CDNI) environment. This section discusses two of the stated requirements in the context of the STAR delegation workflow.
[HTTPS委任] CDN相互接続（CDNI）環境のさまざまな委任要件に対処するいくつかの解決策について説明します。このセクションでは、STAR委任ワークフローのコンテキストでは、次の2つの要件について説明します。
This section uses specific CDNI terminology, e.g., Upstream CDN (uCDN) and Downstream (dCDN), as defined in [RFC7336].
このセクションでは、[RFC7336]で定義されているように、特定のCDNI用語、例えばアップストリームCDN（UCDN）および下流（DCDN）を使用しています。
In some cases, the content owner (IdO) would like to delegate authority over a website to multiple NDCs (CDNs). This could happen if the IdO has agreements in place with different regional CDNs for different geographical regions or if a "backup" CDN is used to handle overflow traffic by temporarily altering some of the CNAME mappings in place. The STAR delegation flow enables this use case naturally, since each CDN can authenticate separately to the IdO (via its own separate account) specifying its CSR, and the IdO is free to allow or deny each certificate request according to its own policy.
場合によっては、コンテンツ所有者（IDO）は、Webサイトを超える権限を複数のNDC（CDN）に委任したいと思います。これは、IDOがさまざまな地理的地域に対して異なる地域CDNとの適切な契約を持っている場合、または「バックアップ」CDNが一時的に一部のCNameマッピングを一時的に変更することによってオーバーフロートラフィックを処理する場合に使用される可能性があります。スター委任フローにより、各CDNがCSRを指定するIDO（独自の個別アカウントを介して）個別に認証でき、IDOは自らのポリシーに従って各証明書要求を自由に許可または拒否することができます。
In other cases, a content owner (IdO) delegates some domains to a large CDN (uCDN), which in turn delegates to a smaller regional CDN (dCDN). The IdO has a contractual relationship with uCDN, and uCDN has a similar relationship with dCDN. However, IdO may not even know about dCDN.
他の場合では、コンテンツ所有者（IDO）はいくつかのドメインを大規模なCDN（UCDN）に委任し、それは次により小さい地域CDN（DCDN）に参加する。IDOはUCDNと契約上の関係を持ち、UCDNはDCDNと同様の関係を持ちます。しかし、IDOはDCDNについてさえ知らないかもしれません。
If needed, the STAR protocol can be chained to support this use case: uCDN could forward requests from dCDN to IdO and forward responses back to dCDN. Whether such proxying is allowed is governed by policy and contracts between the parties.
必要に応じて、STARプロトコルをこのユースケースをサポートするように連鎖できます.UCDNはDCDNからIDOへの要求を転送し、DCDNに返信します。そのようなプロキシが許可されているかどうかは、当事者間の政策と契約によって支配されます。
A mechanism is necessary at the interface between uCDN and dCDN, by which the uCDN can advertise:
UCDNとDCDNの間のインタフェースでは、UCDNが宣伝できるようにするメカニズムが必要です。
* the names that the dCDN is allowed to use and
* DCDNが使用できる名前
* the policy for creating the key material (allowed algorithms, minimum key lengths, key usage, etc.) that the dCDN needs to satisfy.
* DCDNが満たす必要があるキーマテリアル（許可されたアルゴリズム、最小キー長、キー使用法など）を作成するためのポリシー。
Note that such mechanism is provided by the CSR template.
そのようなメカニズムはCSRテンプレートによって提供されていることに注意してください。
A User Agent (UA), e.g., a browser or set-top box, wants to fetch the video resource at the following URI: "https://video.cp.example/ movie". Redirection between the content provider (CP) and upstream and downstream CDNs is arranged as a CNAME-based aliasing chain, as illustrated in Figure 11.
ユーザエージェント（UA）、例えばブラウザまたはセットトップボックスは、次のURIでビデオリソースをフェッチしたいと考えています。 "https：//video.cp.example/映画"。図11に示すように、コンテンツプロバイダ（CP）とアップストリームおよびダウンストリームCDN間のリダイレクトは、CNAMEベースのエイリアシングチェーンとして配置されている。
.------------.
video.cp.example ? | .-----. |
.---------------------------------->| | |
| (a) | | DNS | CP |
| .-------------------------------+ | |
| | CNAME video.ucdn.example | '-----' |
| | '------------'
| |
| |
.-----------|---v--. .------------.
| .-----.-+-----. | video.ucdn.example ? | .-----. |
| | | +----------------------------->| | |
| UA | TLS | DNS | | (b) | | DNS | uCDN |
| | | |<-----------------------------+ | |
| '--+--'-----+-' | CNAME video.dcdn.example | '-----' |
'------|----^---|--' '------------'
| | |
| | |
| | | .------------.
| | | video.dcdn.example ? | .-----. |
| | '------------------------------>| | |
| | (c) | | DNS | |
| '-----------------------------------+ | |
| A 192.0.2.1 | +-----+ dCDN |
| | | | |
'--------------------------------------->| TLS | |
SNI: video.cp.example | | | |
| '-----' |
'------------'
Figure 11: DNS Redirection
図11：DNSリダイレクト
Unlike HTTP-based redirection, where the original URL is supplanted by the one found in the "Location" header of the 302 response, DNS redirection is completely transparent to the User Agent. As a result, the TLS connection to the dCDN edge is done with a Server Name Indication (SNI) equal to the "host" in the original URI -- in the example, "video.cp.example". So, in order to successfully complete the handshake, the landing dCDN node has to be configured with a certificate whose "subjectAltName" field matches "video.cp.example", i.e., a content provider's name.
元のURLが302応答の「Location」ヘッダーにあるものによってサポートされているHTTPベースのリダイレクトとは異なり、DNSリダイレクトはユーザーエージェントに対して完全に透過的です。その結果、DCDNエッジへのTLS接続は、オリジナルのURIの「ホスト」と同じサーバ名指示（SNI）が「Video.CP.Example」で行われます。したがって、ハンドシェイクを正常に完了するために、LANDING DCDNノードは、 "件名名"フィールドが "video.cp.example"、すなわちコンテンツプロバイダの名前と一致する証明書を使用して設定する必要があります。
Figure 12 illustrates the cascaded delegation flow that allows dCDN to obtain a STAR certificate that bears a name belonging to the content provider with a private key that is only known to the dCDN.
図12は、DCDNがDCDNにのみ知られている秘密鍵を持つコンテンツプロバイダに属する名前を持つSTAR証明書を取得できるようにするカスケード委任フローを示しています。
.--------------------.
| .------.------. |
| | STAR | ACME |<-------------.
| CP | dele | STAR | | |
| | srv | cli +-----. |
| '---+--'------' | | 6
'---------|------^---' 5 |
| | | .--|-------.
| | | | .-+----. |
7 | '---->| ACME | |
| | | | STAR | C |
| 4 | +------| A |
| | | | HTTP | |
| | | '----+-' |
| .-' '--^--|----'
.--------------v--|--. | |
| .------.----+-. | | 10
| | | STAR | | | |
| uCDN | CDNI | dele | | | |
| | | fwd | | | |
| '----+-'-+----' | | |
'-------^--|---|--^--' | |
| | | | | |
| 2 8 | | |
1 | | 3 | |
| | | | 9 |
.-------|--v---v--|---------. | |
| .-+----.----+-.------. | | |
| | | STAR | +------------' |
| dCDN | CDNI | dele | HTTP | | |
| | | cli | |<--------------'
| '------'------'------' |
'---------------------------'
Figure 12: Two-Level Delegation in CDNI
図12：CDNIにおける2レベルの委任
uCDN is configured to delegate to dCDN, and CP is configured to delegate to uCDN, both as defined in Section 2.3.1.
UCDNはDCDNに委任するように構成されており、CPはセクション2.3.1で定義されているようにUCDNに委任するように構成されています。
1. dCDN requests CDNI path metadata to uCDN.
1. CDNはCDNパスメタデータをCDNに要求します。
2. uCDN replies with, among other CDNI metadata, the STAR delegation configuration, which includes the delegated content provider's name.
2. UCDNは、委任されたコンテンツプロバイダの名前を含むSTAR委任設定であるSTAR委任設定で返信します。
3. dCDN creates a key pair and the CSR with the delegated name. It then places an order for the delegated name to uCDN.
3. DCDNは、委任名を持つキーペアとCSRを作成します。その後、委任名の順序をUCDNに配置します。
4. uCDN forwards the received order to the content provider (CP).
4. UCDN受信した順序をコンテンツプロバイダ（CP）に転送します。
5. CP creates an order for a STAR certificate and sends it to the CA. The order also requests unauthenticated access to the certificate resource.
5. CPはスター証明書の注文を作成し、それをCAに送信します。注文は証明書リソースへの認証されていないアクセスを要求します。
6. After all authorizations complete successfully, the STAR certificate is issued.
6. すべての承認が正常に完了したら、STAR証明書が発行されます。
7. CP notifies uCDN that the STAR certificate is available at the order's "star-certificate" URL.
7. CP STAR証明書が注文の「STAR-Certificate」URLで入手可能であることをUCDNに通知します。
8. uCDN forwards the information to dCDN. At this point, the ACME signaling is complete.
8. UCDNは情報をDCDNに転送します。この時点で、ACMEシグナリングは完了です。
9. dCDN requests the STAR certificate using unauthenticated GET from the CA.
9. DCDNは、CAから認証されていないGETを使用してSTAR証明書を要求します。
10. The CA returns the certificate. Now dCDN is fully configured to handle HTTPS traffic in lieu of the content provider.
10. CAは証明書を返します。今すぐDCDNは、コンテンツプロバイダの代わりにHTTPSトラフィックを処理するように完全に構成されています。
Note that 9 and 10 repeat until the delegation expires or is terminated.
委任が期限切れになるか終了するまで、9と10は繰り返します。
As a second use case, we consider the delegation of credentials in the STIR ecosystem [RFC9060].
2回目のユースケースとして、撹拌エコシステム[RFC9060]の資格の委任を検討します。
This section uses STIR terminology. The term Personal Assertion Token (PASSporT) is defined in [RFC8225], and "TNAuthList" is defined in [RFC8226].
このセクションでは撹拌用語を使用しています。Personal Assertion Token（Passport）という用語は[RFC8225]で定義され、[RFC8226]で「TNAuthList」が定義されています。
In the STIR delegated mode, a service provider SP2 -- the NDC -- needs to sign PASSporTs [RFC8225] for telephone numbers (e.g., TN=+123) belonging to another service provider, SP1 -- the IdO. In order to do that, SP2 needs a STIR certificate and a private key that includes TN=+123 in the TNAuthList [RFC8226] certificate extension.
攪拌委任モードでは、サービスプロバイダSP2 - NDC - 他のサービスプロバイダ、SP1 - IDOに属する電話番号（例えば、TN = 123）についてパスポート[RFC8225]に署名する必要がある。それをするために、SP2は攪拌証明書とTNAuthList [RFC8226]証明書拡張子のTN = 123を含む秘密鍵を必要とします。
In detail (Figure 13):
詳細（図13）：
1. SP1 and SP2 agree on the configuration of the delegation -- in particular, the CSR template that applies.
1. SP1およびSP2は、特に適用されるCSRテンプレートの委任の構成について同意します。
2. SP2 generates a private/public key pair and sends a CSR to SP1, requesting creation of a certificate with an SP1 name, an SP2 public key, and a TNAuthList extension with the list of TNs that SP1 delegates to SP2. (Note that the CSR sent by SP2 to SP1 needs to be validated against the CSR template agreed upon in step 1.).
2. SP2はプライベート/公開鍵ペアを生成し、SP1の名前、SP2公開鍵、およびSP1がSP2を委任するTNSのリストを含む証明書の作成を要求し、SP1にCSRを送信します。（SP2からSP1が送信されたCSRは、手順1で合意されたCSRテンプレートに対して検証される必要があります。
3. SP1 sends an order for the CSR to the CA. The order also requests unauthenticated access to the certificate resource.
3. SP1はCSRの注文をCAに送信します。注文は証明書リソースへの認証されていないアクセスを要求します。
4. Subsequently, after the required TNAuthList authorizations are successfully completed, the CA moves the order to a "valid" state; at the same time, the star-certificate endpoint is populated.
4. その後、必要なTANUTHLIST権限が正常に完了した後、CAは次数を「有効な」状態に移動させます。同時に、Star-Certificateエンドポイントが入力されます。
5. The contents of the order are forwarded from SP1 to SP2 by means of the paired "delegation" order.
5. 注文の内容は、対になった「委任」順序によってSP1からSP2に転送されます。
6. SP2 dereferences the "star-certificate" URL in the order to fetch the rolling STAR certificate bearing the delegated identifiers.
6. SP2は、委任された識別子をベアリングする転がりスターの証明書を取得するための「スター証明書」のURLを参照してください。
7. The STAR certificate is returned to SP2.
7. STAR証明書はSP2に戻ります。
.-------------------.
| .------.------. |
| | STAR | STAR |<--------------.
.-->| SP1 | dele | dele | | |
| | | srv | cli +-----. |
| | '----+-'------' | | 4
| '------^--|---------' 3 |
| | | | .----|-----.
| | 5 | | .---+--. |
| | | '--->| ACME | |
| | | | | STAR | C |
1 | | | +------| A |
| | | .--->| HTTP | |
| 2 | | | '---+--' |
| | | | '----|-----'
| .------|--v---------. 6 |
| | .-+----.------. | | 7
| | | STAR | +-----' |
'-->| SP2 | dele | HTTP | | |
| | cli | |<--------------'
| '----+-'-+----' |
'-------------------'
Figure 13: Delegation in STIR
図13：委任中の委任
As shown, the STAR delegation profile described in this document applies straightforwardly; the only extra requirement being the ability to instruct the NDC about the allowed TNAuthList values. This can be achieved by a simple extension to the CSR template.
示されるように、この文書に記載されているスター委任プロファイルは直接的に適用されます。唯一の追加の要件は、許可されたTANUTHLIST値についてNDCに指示する能力であることです。これは、CSRテンプレートへの単純な拡張によって達成できます。
This document adds the following entries to the "ACME Directory Metadata Fields" registry:
このドキュメントでは、「ACME Directoryメタデータフィールド」レジストリに次のエントリを追加します。
+=======================+============+===========+
| Field Name | Field Type | Reference |
+=======================+============+===========+
| delegation-enabled | boolean | RFC 9115 |
+-----------------------+------------+-----------+
| allow-certificate-get | boolean | RFC 9115 |
+-----------------------+------------+-----------+
Table 1
表1
This document adds the following entries to the "ACME Order Object Fields" registry:
このドキュメントでは、 "Acme Order Object Fields"レジストリに次のエントリを追加します。
+=======================+============+==============+===========+
| Field Name | Field Type | Configurable | Reference |
+=======================+============+==============+===========+
| allow-certificate-get | boolean | true | RFC 9115 |
+-----------------------+------------+--------------+-----------+
| delegation | string | true | RFC 9115 |
+-----------------------+------------+--------------+-----------+
Table 2
表2.
This document adds the following entries to the "ACME Account Object Fields" registry:
このドキュメントでは、 "ACMEアカウントオブジェクトフィールド"レジストリに次のエントリを追加します。
+=============+============+==========+===========+
| Field Name | Field Type | Requests | Reference |
+=============+============+==========+===========+
| delegations | string | none | RFC 9115 |
+-------------+------------+----------+-----------+
Table 3
表3.
Note that the "delegations" field is only reported by ACME servers that have "delegation-enabled" set to true in their meta Object.
「代表団」フィールドは、「委任対象」がMETAオブジェクトでTRUEに設定されているACMEサーバによってのみ報告されていることに注意してください。
This document adds the following entries to the "ACME Error Types" registry:
このドキュメントでは、 "ACMEエラータイプ"レジストリに次のエントリを追加します。
+===================+================================+===========+
| Type | Description | Reference |
+===================+================================+===========+
| unknownDelegation | An unknown configuration is | RFC 9115 |
| | listed in the "delegation" | |
| | attribute of the order request | |
+-------------------+--------------------------------+-----------+
Table 4
表4.
IANA has established the "STAR Delegation CSR Template Extensions" registry, with "Specification Required" as its registration procedure.
IANAは「STAR代表団CSRテンプレート拡張」レジストリを登録手順として「必須」を設定しました。
Each extension registered must specify:
登録された各拡張子は次のように指定する必要があります。
* an extension name,
* エクステンション名、
* an extension syntax, as a reference to a CDDL document that defines this extension, and
* この拡張子を定義するCDDL文書への参照としての拡張構文。
* the extension's mapping into an X.509 certificate extension.
* 拡張子のX.509証明書拡張子への拡張。
The initial contents of this registry are the extensions defined by the CDDL in Appendix A.
このレジストリの初期内容は、付録AのCDDLによって定義された拡張子です。
+==================+===========+===============================+
| Extension Name | Extension | Mapping to X.509 Certificate |
| | Syntax | Extension |
+==================+===========+===============================+
| keyUsage | See | [RFC5280], Section 4.2.1.3 |
| | Appendix | |
| | A | |
+------------------+-----------+-------------------------------+
| extendedKeyUsage | See | [RFC5280], Section 4.2.1.12 |
| | Appendix | |
| | A | |
+------------------+-----------+-------------------------------+
| subjectAltName | See | [RFC5280], Section 4.2.1.6 |
| | Appendix | (note that only specific name |
| | A | formats are allowed: URI, DNS |
| | | name, email address) |
+------------------+-----------+-------------------------------+
Table 5
表5.
When evaluating a request for an assignment in this registry, the designated expert should follow this guidance:
このレジストリでの割り当ての要求を評価するとき、指定された専門家はこのガイダンスに従うべきです。
* The definition must include a full CDDL definition, which the expert will validate.
* 定義には、専門家が検証する完全なCDDL定義を含める必要があります。
* The definition must include both positive and negative test cases.
* 定義は、正と負のテストケースの両方を含める必要があります。
* Additional requirements that are not captured by the CDDL definition are allowed but must be explicitly specified.
* CDDL定義によってキャプチャされていない追加の要件は許可されていますが、明示的に指定する必要があります。
The ACME trust model needs to be extended to include the trust relationship between NDC and IdO. Note that once this trust link is established, it potentially becomes recursive. Therefore, there has to be a trust relationship between each of the nodes in the delegation chain; for example, in case of cascading CDNs, this is contractually defined. Note that when using standard [RFC6125] identity verification, there are no mechanisms available to the IdO to restrict the use of the delegated name once the name has been handed over to the first NDC. It is, therefore, expected that contractual measures are in place to get some assurance that redelegation is not being performed.
ACME Trustモデルは、NDCとIDOの間の信頼関係を含むように拡張する必要があります。この信頼リンクが確立されると、潜在的に再帰的になることに注意してください。したがって、代表団チェーン内の各ノード間に信頼関係がある必要があります。たとえば、CDNをカスケードする場合、これは契約的に定義されています。標準[RFC6125] IDの検証を使用する場合、名前が最初のNDCに引き渡された後に委任名の使用を制限するためにIDOに使用可能なメカニズムはありません。したがって、再認識が行われていないことをいくつかの保証を得るために契約上の対策が整っていると予想されます。
Delegation introduces a new security goal: only an NDC that has been authorized by the IdO, either directly or transitively, can obtain a certificate with an IdO identity.
委任は新しいセキュリティ目標を紹介します。IDOによって直接的または渡して承認されたNDCだけが、IDO IDを持つ証明書を取得できます。
From a security point of view, the delegation process has five separate parts:
セキュリティの観点から、委任プロセスには5つの別々の部分があります。
1. enabling a specific third party (the intended NDC) to submit requests for delegated certificates
1. 特定の第三者（意図したNDC）を有効にして委任証明書の要求を送信する
2. making sure that any request for a delegated certificate matches the intended "shape" in terms of delegated identities as well as any other certificate metadata, e.g., key length, x.509 extensions, etc.
2. 委任された証明書の要求が、委任されたIDの観点から意図された「図形」と一致すること、およびその他の証明書メタデータ、例えば、キー長、X.509拡張など
3. serving the certificate back to the NDC
3. 証明書をNDCに送り返します
4. handling revocation of the delegation
4. 代表団の取り消しの取扱い
5. handling revocation of the certificate itself
5. 証明書そのものの失効を処理する
The first part is covered by the NDC's ACME account that is administered by the IdO, whose security relies on the correct handling of the associated key pair. When a compromise of the private key is detected, the delegate MUST use the account deactivation procedures defined in Section 7.3.6 of [RFC8555].
最初の部分は、IDOによって管理されているNDCのACMEアカウントでカバーされ、そのセキュリティは関連するキーペアの正しい処理に依存しています。秘密鍵の妥協が検出されると、デリゲートは[RFC8555]のセクション7.3.6で定義されているアカウント無効化手順を使用する必要があります。
The second part is covered by the act of checking an NDC's certificate request against the intended CSR template. The steps of shaping the CSR template correctly, selecting the right CSR template to check against the presented CSR, and making sure that the presented CSR matches the selected CSR template are all security relevant.
2番目の部分は、目的のCSRテンプレートに対してNDCの証明書要求をチェックする行為によってカバーされています。CSRテンプレートを正しくシェープする手順で、表示されたCSRをチェックするための右のCSRテンプレートを選択し、表示されたCSRが選択されたCSRテンプレートと一致するようにすることはすべて、すべてのセキュリティ関連が関連しています。
The third part builds on the trust relationship between NDC and IdO that is responsible for correctly forwarding the certificate URL from the Order returned by the CA.
3番目の部分は、CAによって返される順序から証明書URLを正しく転送する責任があるNDCとIDOの間の信頼関係に基づいています。
The fourth part is associated with the ability of the IdO to unilaterally remove the "delegation" object associated with the revoked identity, therefore, disabling any further NDC requests for such identity. Note that, in more extreme circumstances, the IdO might decide to disable the NDC account, thus entirely blocking any further interaction.
4番目の部分は、失効された識別情報に関連した「委任」オブジェクトを一方的に除去するためのIDOの能力に関連付けられているため、そのようなIDのためのさらなるNDC要求を無効にします。より極端な状況では、IDOはNDCアカウントを無効にすることを決定し、したがってさらなるインタラクションを完全にブロックすることを決定することに注意してください。
The fifth is covered by two different mechanisms, depending on the nature of the certificate. For STAR, the IdO shall use the cancellation interface defined in Section 2.3 of [RFC8739]. For non-STAR, the certificate revocation interface defined in Section 7.6 of [RFC8555]) is used.
証明書の性質に応じて、5番目の異なるメカニズムでカバーされています。スターの場合、IDOは[RFC8739]のセクション2.3で定義されているキャンセルインターフェイスを使用します。ノンスターの場合、[RFC8555]のセクション7.6で定義されている証明書失効インターフェイスが使用されます。
The ACME account associated with the delegation plays a crucial role in the overall security of the presented protocol. This, in turn, means that (in delegation scenarios) the security requirements and verification associated with an ACME account may be more stringent than in base ACME deployments, since the out-of-band configuration of delegations that an account is authorized to use (combined with account authentication) takes the place of the normal ACME authorization challenge procedures. Therefore, the IdO MUST ensure that each account is associated with the exact policies (via their matching "delegation" objects) that define which domain names can be delegated to the account and how. The IdO is expected to use out-of-band means to preregister each NDC to the corresponding account.
委任に関連するACMEアカウントは、提示されたプロトコルの全体的なセキュリティにおいて重要な役割を果たしています。これにより、アカウントが使用することを許可されている代理人の帯域外の構成は、（委任シナリオで）、アカウントの帯域外の構成であるため、ACMEアカウントに関連するセキュリティ要件と検証を基本ACME展開よりも厳しくすることができます（委任シナリオ）。アカウント認証と組み合わせると、通常のACME認証チャレンジ手順の代わりになります。したがって、IDOは、どのドメイン名をアカウントに委任できるか、およびどのようにどのドメイン名を委任できるかを定義する、各アカウントに（一致する「委任」オブジェクトを介して）各アカウントが確実に関連付けられている必要があります。IDOは、各NDCを対応するアカウントに事前に配置するために、帯域外の手段を使用すると予想されます。
Using the model established in Section 10.1 of [RFC8555], we can decompose the interactions of the basic delegation workflow, as shown in Figure 14.
[RFC8555]のセクション10.1で確立されたモデルを使用して、図14に示すように、基本委任ワークフローの相互作用を分解することができます。
.-----. ACME Channel .--------.
| NDC +------------->| IdO |
'--+--' | server |
| '--o-----'
| |
| | ACME Channel
| | .------------>-------------.
| | | |
| .--o--+--. .--+---.
| | IdO | | CA |
| | client | '--+-+-'
| '-----+--' | |
| '-----------<--------------' |
| Validation Channel |
'-------------------->-------------------------------'
(subset of) ACME Channel [1]
[1] Unauthenticated certificate fetch and non-STAR certificate revocation.
[1] 認証されていない証明書の取得と非スターの証明書の失効。
Figure 14: Delegation Channels Topology
図14：代表団チャネルトポロジー
The considerations regarding the security of the ACME Channel and Validation Channel discussed in [RFC8555] apply verbatim to the IdO-CA leg. The same can be said for the ACME Channel on the NDC-IdO leg. A slightly different set of considerations apply to the ACME Channel between the NDC and CA, which consists of a subset of the ACME interface comprising two API endpoints: the unauthenticated certificate retrieval and, potentially, non-STAR revocation via certificate private key. No specific security considerations apply to the former, but the privacy considerations in Section 6.3 of [RFC8739] do. With regard to the latter, it should be noted that there is currently no means for an IdO to disable authorizing revocation based on certificate private keys. So, in theory, an NDC could use the revocation API directly with the CA, therefore, bypassing the IdO. The NDC SHOULD NOT directly use the revocation interface exposed by the CA unless failing to do so would compromise the overall security, for example, if the certificate private key is compromised and the IdO is not currently reachable.
[RFC8555]で説明されているACMEチャネルと検証チャネルのセキュリティに関する考慮事項は、IDO-CAレッグに逐語的に適用されます。 NDC-IDOの脚のACMEチャンネルについても同じことが言えます。 2つのAPIエンドポイントを含むACMEインタフェースのサブセットからなるNDCとCAの間のACMEチャネルには、わずかに異なる一連の考慮事項が適用されます。認証されていない証明書の取得と、証明書の秘密鍵を介した潜在的には非星の失効。前者には特定のセキュリティ上の考慮は適用されませんが、[RFC8739]のセクション6.3のプライバシーに関する考慮事項。後者に関しては、証明書の秘密鍵に基づいて失効を許可することを無効にするためのIDOが現在、現在は手段がないことに注意してください。したがって、理論的には、NDCはRevocation APIをCAと直接使用することができ、したがってIDOを迂回します。 NDCは、証明書秘密鍵が侵害されていて、IDOが現在到達できない場合に、全体的なセキュリティを危うくすることがない限り、NDCはCAによって公開されている失効インターフェイスを直接使用しないでください。
All other security considerations from [RFC8555] and [RFC8739] apply as is to the delegation topology.
[RFC8555]と[RFC8739]からの他のすべてのセキュリティ上の考慮事項は、委任トポロジと同様に適用されます。
When a website is delegated to a CDN, the CDN can in principle modify the website at will, e.g., create and remove pages. This means that a malicious or breached CDN can pass the ACME (as well as common non-ACME) HTTPS-based validation challenges and generate a certificate for the site. This is true regardless of whether or not the CNAME mechanisms defined in the current document is used.
WebサイトがCDNに委任されると、CDNは原則としてウェブサイトを変更して、ページを作成してページを作成および削除します。つまり、悪意のあるまたは侵害されたCDNがACME（および一般的な非ACME）HTTPSベースの検証の課題に合格し、そのサイトの証明書を生成できることを意味します。これは、現在の文書で定義されているCNAMEメカニズムが使用されているかどうかにかかわらず当てはまります。
In some cases, this is the desired behavior; the domain holder trusts the CDN to have full control of the cryptographic credentials for the site. However, this document assumes a scenario where the domain holder only wants to delegate restricted control and wishes to retain the capability to cancel the CDN's credentials at a short notice.
場合によっては、これが望ましい行動です。ドメインホルダーは、CDNを信頼して、サイトの暗号化資格情報を完全に制御できます。ただし、この文書では、ドメインホルダーが制限されたコントロールを委任したいシナリオであり、短い通知でCDNの資格情報をキャンセルする機能を保持したいと考えています。
The following is a possible mitigation when the IdO wishes to ensure that a rogue CDN cannot issue unauthorized certificates:
不正な証明書が不正な証明書を発行できないことを確認する場合は、次のような緩和です。
* The domain holder makes sure that the CDN cannot modify the DNS records for the domain. The domain holder should ensure it is the only entity authorized to modify the DNS zone. Typically, it establishes a CNAME resource record from a subdomain into a CDN-managed domain.
* ドメインホルダーは、CDNがドメインのDNSレコードを変更できないことを確認します。ドメインホルダーは、DNSゾーンを変更することを許可されている唯一のエンティティであることを確認する必要があります。通常、サブドメインからCDN管理ドメインへのCNAMEリソースレコードを確立します。
* The domain holder uses a Certification Authority Authorization (CAA) record [RFC8659] to restrict certificate issuance for the domain to specific CAs that comply with ACME and are known to implement [RFC8657].
* ドメインホルダーは、CERTIFICATION権限認証（CAA）レコード[RFC8659]を使用して、ACMEに準拠した特定のCASの証明書発行を制限し、[RFC8657]を実装することが知られています。
* The domain holder uses the ACME-specific CAA mechanism [RFC8657] to restrict issuance to a specific CA account that is controlled by it and MUST require "dns-01" as the sole validation method.
* ドメインホルダーは、ITによって制御されている特定のCAアカウントへの発行を制限するためにACME固有のCAAメカニズムを使用し、ソール検証方法として「DNS-01」を必要とする必要があります。
We note that the above solution may need to be tweaked depending on the exact capabilities and authorization flows supported by the selected CA. In addition, this mitigation may be bypassed if a malicious or misconfigured CA does not comply with CAA restrictions.
選択されたCAでサポートされている正確な機能と承認フローに応じて、上記の解決策を調整する必要がある場合があります。さらに、悪意のあるまたは誤ったCAがCAAの制限に準拠していない場合、この緩和はバイパスされる可能性があります。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/info/rfc2986>.
[RFC2986] NYSTROM、M.およびB.Kaliski、「PKCS＃10：認証依頼版仕様バージョン1.7」、RFC 2986、DOI 10.17487 / RFC2986、2000年11月、<https：//www.rfc-editor.org/info/ RFC2986>。
[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>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[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>。
[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>。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/ RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[RFC8739] Sheffer, Y., Lopez, D., Gonzalez de Dios, O., Pastor Perales, A., and T. Fossati, "Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME)", RFC 8739, DOI 10.17487/RFC8739, March 2020, <https://www.rfc-editor.org/info/rfc8739>.
[RFC8739] Sheffer、Y、Lopez、D.、Gonzalez De Dios、O.、Perales、A。、およびT.Fossati、 "自動証明書管理環境の短期、自動的に更新された（スター）証明書のサポート（ACME） "、RFC 8739、DOI 10.17487 / RFC8739、2020年3月、<https://www.rfc-editor.org/info/rfc8739>。
[HTTPS-DELEGATION] Fieau, F., Stephan, E., and S. Mishra, "CDNI extensions for HTTPS delegation", Work in Progress, Internet-Draft, draft-ietf-cdni-interfaces-https-delegation-06, 10 September 2021, <https://datatracker.ietf.org/doc/html/ draft-ietf-cdni-interfaces-https-delegation-06>.
[https-delegation] F.、F.、Stephan、E.、S. Mishra、「HTTPS代表団のCDNI拡張」、進行中の作業、インターネットドラフト、Draft-IETF-CDNI-Interfaces-HTTPS-DELEGATION-062021年9月10日、<https://datatracker.ietf.org/doc/html/ proft-ietf-cdni-interfaces-https-delegation-06>。
[json-schema-07] Wright, A., Andrews, H., and B. Hutton, "JSON Schema Validation: A Vocabulary for Structural Validation of JSON", Work in Progress, Internet-Draft, draft-handrews-json-schema-validation-02, 17 September 2019, <https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-validation-02>.
[JSON-SCHEMA-07]ライト、A。、Andrews、H.、およびB.Hutton、「JSONスキーマ検証：JSONの構造検証のための語彙」、進行中の作業、インターネットドラフト、ドラフト手順 - JSON-Schema-Validation-02,2019、<https://datatracker.ietf.org/doc/html/draft-handrews-json-schema-validation-02>
[MGLT-LURK-TLS13] Migault, D., "LURK Extension version 1 for (D)TLS 1.3 Authentication", Work in Progress, Internet-Draft, draft-mglt-lurk-tls13-05, 26 July 2021, <https://datatracker.ietf.org/doc/html/draft-mglt-lurk-tls13-05>.
[MGLT-LURK-TLS13] Migautt、D.、「LURK拡張バージョン1（D）TLS 1.3認証用」、進行中の作業、インターネットドラフト、ドラフト - MGLT-LURK-TLS13-05,2021,26 7月26日、<HTTPS：//datatracker.ietf.org/doc/html/draft-mglt-lurk-tls13-05>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Transport Layer Security（TLS）のコンテキストでのX.509（PKIX）証明書を使用したInternet Publicキーインフラストラクチャ内のインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証の表現と検証RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, <https://www.rfc-editor.org/info/rfc7336>.
[RFC7336] Peterson、L.、Davie、B.およびR. van Brandenburg、「コンテンツ配信ネットワーク相互接続のためのフレームワーク（CDNI）」、RFC 7336、DOI 10.17487 / RFC7336、2014年8月、<https：//www.rfc-editor.org/info/rfc7336>。
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, <https://www.rfc-editor.org/info/rfc8225>.
[RFC8225] Wendt、C.およびJ.Peterson、 "Passport：Personal Assertion Token"、RFC 8225、DOI 10.17487 / RFC8225、2018年2月、<https：//www.rfc-editor.org/info/rfc8225>。
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, <https://www.rfc-editor.org/info/rfc8226>.
[RFC8226] Peterson、J.およびS. Turner、「Secure Phereth Identity Credentials：証明書」、RFC 8226、DOI 10.17487 / RFC8226、2018年2月、<https：//www.rfc-editor.org/info/rfc8226>。
[RFC8657] Landau, H., "Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding", RFC 8657, DOI 10.17487/RFC8657, November 2019, <https://www.rfc-editor.org/info/rfc8657>.
[RFC8657] Landau、H.、「認証局権認証（CAA）アカウントURIおよび自動証明書管理環境（ACME）メソッドバインディングの拡張機能（ACME）メソッドバインディング、RFC 8657、DOI 10.17487 / RFC8657、2019年11月、<https：// www。rfc-editor.org/info/rfc8657>。
[RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, <https://www.rfc-editor.org/info/rfc8659>.
[RFC8659]ハラムベイカー、P.、Stradling、R.、およびJ.Hoffman-Andrews、「DNS認証局承認（CAA）資源記録」、RFC 8659、DOI 10.17487 / RFC8659、2019年11月、<https：//www.rfc-editor.org/info/rfc8659>。
[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, September 2021, <https://www.rfc-editor.org/info/rfc9060>.
[RFC9060] Peterson、J.、「安全な電話アイデンティティ」、RFC 9060、DOI 10.17487 / RFC9060、2021年9月、<https://www.rfc-editor.org/info/rfc9060>。
[TLS-SUBCERTS] Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, "Delegated Credentials for TLS", Work in Progress, Internet-Draft, draft-ietf-tls-subcerts-10, 24 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10>.
[TLS-SUBCERTS] Barnes、R.、Iyengar、S.、Sullivan、N.、およびE. Rescorla、「TLSの代表資格情報」、進行中の作業、インターネットドラフト、草案-TLS-SUBCERTS-10、2021年1月24日、<https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-10>。
[TOKEN-TNAUTHLIST] Wendt, C., Hancock, D., Barnes, M., and J. Peterson, "TNAuthList profile of ACME Authority Token", Work in Progress, Internet-Draft, draft-ietf-acme-authority-token-tnauthlist-08, 27 March 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-tnauthlist-08>.
[TOKEN-TNAUTHLIST] Wendt、C、Hancock、D.、Barnes、M.、およびJ.Peterson、「ACME Authority TokenのTanuthlistプロファイル」、進行中の作業、インターネットドラフト、ドラフト-IETF-acme-orcirual-TOKEN-TNAUTHLIST-08,2021、<https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-tnauthlist-08>。
Appendix A. CSR Template: CDDL
付録A. CSRテンプレート：CDDL.
Following is the normative definition of the CSR template using CDDL [RFC8610]. The CSR template MUST be a valid JSON document that is compliant with the syntax defined here.
以下はCDDL [RFC8610]を使用したCSRテンプレートの規範的定義です。CSRテンプレートは、ここで定義されている構文に準拠している有効なJSON文書でなければなりません。
There are additional constraints not expressed in CDDL that MUST be validated by the recipient, including:
CDDLで表現されていない追加の制約があります。これを含む、受信者によって検証する必要があります。
* the value of each "subjectAltName" entry is compatible with its type and
* 各 "subjectaltname"エントリの値はそのタイプと互換性があります
* the parameters in each "keyTypes" entry form an acceptable combination.
* 各 "keytypes"エントリのパラメータは許容可能な組み合わせを形成します。
csr-template-schema = {
keyTypes: [ + $keyType ]
? subject: non-empty<distinguishedName>
extensions: extensions
}
non-empty<M> = (M) .and ({ + any => any })
mandatory-wildcard = "**"
optional-wildcard = "*"
wildcard = mandatory-wildcard / optional-wildcard
; regtext matches all text strings but "*" and "**"
regtext = text .regexp "([^\*].*)|([\*][^\*].*)|([\*][\*].+)"
regtext-or-wildcard = regtext / wildcard
distinguishedName = {
? country: regtext-or-wildcard
? stateOrProvince: regtext-or-wildcard
? locality: regtext-or-wildcard
? organization: regtext-or-wildcard
? organizationalUnit: regtext-or-wildcard
? emailAddress: regtext-or-wildcard
? commonName: regtext-or-wildcard
}
$keyType /= rsaKeyType
$keyType /= ecdsaKeyType
rsaKeyType = {
PublicKeyType: "rsaEncryption" ; OID: 1.2.840.113549.1.1.1
PublicKeyLength: rsaKeySize
SignatureType: $rsaSignatureType
}
rsaKeySize = uint
; RSASSA-PKCS1-v1_5 with SHA-256
$rsaSignatureType /= "sha256WithRSAEncryption"
; RSASSA-PCKS1-v1_5 with SHA-384
$rsaSignatureType /= "sha384WithRSAEncryption"
; RSASSA-PCKS1-v1_5 with SHA-512
$rsaSignatureType /= "sha512WithRSAEncryption"
; RSASSA-PSS with SHA-256, MGF-1 with SHA-256, and a 32 byte salt
$rsaSignatureType /= "sha256WithRSAandMGF1"
; RSASSA-PSS with SHA-384, MGF-1 with SHA-384, and a 48 byte salt
$rsaSignatureType /= "sha384WithRSAandMGF1"
; RSASSA-PSS with SHA-512, MGF-1 with SHA-512, and a 64 byte salt
$rsaSignatureType /= "sha512WithRSAandMGF1"
ecdsaKeyType = {
PublicKeyType: "id-ecPublicKey" ; OID: 1.2.840.10045.2.1
namedCurve: $ecdsaCurve
SignatureType: $ecdsaSignatureType
}
$ecdsaCurve /= "secp256r1" ; OID: 1.2.840.10045.3.1.7
$ecdsaCurve /= "secp384r1" ; OID: 1.3.132.0.34
$ecdsaCurve /= "secp521r1" ; OID: 1.3.132.0.3
$ecdsaSignatureType /= "ecdsa-with-SHA256" ; paired with secp256r1
$ecdsaSignatureType /= "ecdsa-with-SHA384" ; paired with secp384r1
$ecdsaSignatureType /= "ecdsa-with-SHA512" ; paired with secp521r1
subjectaltname = {
? DNS: [ + regtext-or-wildcard ]
? Email: [ + regtext ]
? URI: [ + regtext ]
* $$subjectaltname-extension
}
extensions = {
? keyUsage: [ + keyUsageType ]
? extendedKeyUsage: [ + extendedKeyUsageType ]
subjectAltName: non-empty<subjectaltname>
}
keyUsageType /= "digitalSignature"
keyUsageType /= "nonRepudiation"
keyUsageType /= "keyEncipherment"
keyUsageType /= "dataEncipherment"
keyUsageType /= "keyAgreement"
keyUsageType /= "keyCertSign"
keyUsageType /= "cRLSign"
keyUsageType /= "encipherOnly"
keyUsageType /= "decipherOnly"
extendedKeyUsageType /= "serverAuth"
extendedKeyUsageType /= "clientAuth"
extendedKeyUsageType /= "codeSigning"
extendedKeyUsageType /= "emailProtection"
extendedKeyUsageType /= "timeStamping"
extendedKeyUsageType /= "OCSPSigning"
extendedKeyUsageType /= oid
oid = text .regexp "([0-2])((\.0)|(\.[1-9][0-9]*))*"
Appendix B. CSR Template: JSON Schema
付録B. CSRテンプレート：JSONスキーマ
This appendix includes an alternative, nonnormative JSON Schema definition of the CSR template. The syntax used is that of draft 7 of JSON Schema, which is documented in [json-schema-07]. Note that later versions of this (now-expired) draft describe later versions of the JSON Schema syntax. At the time of writing, a stable reference for this syntax is not yet available, and we have chosen to use the draft version, which is currently best supported by tool implementations.
この付録には、CSRテンプレートの代替的な非公式のJSONスキーマ定義が含まれています。使用される構文は、JSONスキーマのドラフト7のドラフト7のものです。これの後のバージョン（現在期限切れ）ドラフトでは、JSONスキーマ構文の後のバージョンについて説明します。書き込み時には、この構文の安定した参照はまだ入手できません。これは現在ツールの実装で最もよくサポートされているドラフトバージョンを使用するように選択しました。
The same considerations about additional constraints checking discussed in Appendix A apply here as well.
付録Aで説明した追加の制約検査についても同じ考察がここに適用されます。
{
"title": "JSON Schema for the STAR Delegation CSR template",
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "http://ietf.org/acme/drafts/star-delegation/csr-template",
"$defs": {
"distinguished-name": {
"$id": "#distinguished-name",
"type": "object",
"minProperties": 1,
"properties": {
"country": {
"type": "string"
},
"stateOrProvince": {
"type": "string"
},
"locality": {
"type": "string"
},
"organization": {
"type": "string"
},
"organizationalUnit": {
"type": "string"
},
"emailAddress": {
"type": "string"
},
"commonName": {
"type": "string"
}
},
"additionalProperties": false
},
"rsaKeyType": {
"$id": "#rsaKeyType",
"type": "object",
"properties": {
"PublicKeyType": {
"type": "string",
"const": "rsaEncryption"
},
"PublicKeyLength": {
"type": "integer"
},
"SignatureType": {
"type": "string",
"enum": [
"sha256WithRSAEncryption",
"sha384WithRSAEncryption",
"sha512WithRSAEncryption",
"sha256WithRSAandMGF1",
"sha384WithRSAandMGF1",
"sha512WithRSAandMGF1"
]
}
},
"required": [
"PublicKeyType",
"PublicKeyLength",
"SignatureType"
],
"additionalProperties": false
},
"ecdsaKeyType": {
"$id": "#ecdsaKeyType",
"type": "object",
"properties": {
"PublicKeyType": {
"type": "string",
"const": "id-ecPublicKey"
},
"namedCurve": {
"type": "string",
"enum": [
"secp256r1",
"secp384r1",
"secp521r1"
]
},
"SignatureType": {
"type": "string",
"enum": [
"ecdsa-with-SHA256",
"ecdsa-with-SHA384",
"ecdsa-with-SHA512"
]
}
},
"required": [
"PublicKeyType",
"namedCurve",
"SignatureType"
],
"additionalProperties": false
}
},
"type": "object",
"properties": {
"keyTypes": {
"type": "array",
"minItems": 1,
"items": {
"anyOf": [
{
"$ref": "#rsaKeyType"
},
{
"$ref": "#ecdsaKeyType"
}
]
}
},
"subject": {
"$ref": "#distinguished-name"
},
"extensions": {
"type": "object",
"properties": {
"keyUsage": {
"type": "array",
"minItems": 1,
"items": {
"type": "string",
"enum": [
"digitalSignature",
"nonRepudiation",
"keyEncipherment",
"dataEncipherment",
"keyAgreement",
"keyCertSign",
"cRLSign",
"encipherOnly",
"decipherOnly"
]
}
},
"extendedKeyUsage": {
"type": "array",
"minItems": 1,
"items": {
"anyOf": [
{
"type": "string",
"enum": [
"serverAuth",
"clientAuth",
"codeSigning",
"emailProtection",
"timeStamping",
"OCSPSigning"
]
},
{
"type": "string",
"pattern": "^([0-2])((\\.0)|(\\.[1-9][0-9]*))*$",
"description": "Used for OID values"
}
]
}
},
"subjectAltName": {
"type": "object",
"minProperties": 1,
"properties": {
"DNS": {
"type": "array",
"minItems": 1,
"items": {
"anyOf": [
{
"type": "string",
"enum": [
"*",
"**"
]
},
{
"type": "string",
"format": "hostname"
}
]
}
},
"Email": {
"type": "array",
"minItems": 1,
"items": {
"type": "string",
"format": "email"
}
},
"URI": {
"type": "array",
"minItems": 1,
"items": {
"type": "string",
"format": "uri"
}
}
},
"additionalProperties": false
}
},
"required": [
"subjectAltName"
],
"additionalProperties": false
}
},
"required": [
"extensions",
"keyTypes"
],
"additionalProperties": false
}
Acknowledgements
謝辞
We would like to thank the following people who contributed significantly to this document with their review comments and design proposals: Richard Barnes, Carsten Bormann, Roman Danyliw, Lars Eggert, Frédéric Fieau, Russ Housley, Ben Kaduk, Eric Kline, Sanjay Mishra, Francesca Palombini, Jon Peterson, Ryan Sleevi, Emile Stephan, and Éric Vyncke.
この文書に大幅に貢献してくれてありがとうございます。Palombini、Jon Peterson、Ryan Sleevi、Emile Stephan、そしてエリコのVyncke。
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補助金契約番号の下で欧州委員会によって部分的に支えられています。ミドルボックスインターネット（MAMI）の測定とアーキテクチャ。このサポートは承認を意味するものではありません。
Authors' Addresses
著者の住所
Yaron Sheffer Intuit
Yaron Sheffer Tuituit
Email: yaronf.ietf@gmail.com
Diego López Telefonica I+D
DiegoLópezTelefonica I D.
Email: diego.r.lopez@telefonica.com
Antonio Agustín Pastor Perales Telefonica I+D
AntonioAgustín牧師牧師Telefonica I D.
Email: antonio.pastorperales@telefonica.com
Thomas Fossati ARM
トーマスフォサティアーム
Email: thomas.fossati@arm.com