Internet Engineering Task Force (IETF) F. Fieau, Ed.
Request for Comments: 9538 E. Stephan
Category: Standards Track Orange
ISSN: 2070-1721 S. Mishra
Verizon
February 2024
This document defines metadata to support delegating the delivery of HTTPS content between two or more interconnected Content Delivery Networks (CDNs). Specifically, this document defines a Content Delivery Network Interconnection (CDNI) Metadata interface object to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC 9115. Per RFC 9115, delegating entities can remain in full control of the delegation and can revoke it at any time. This avoids the need to share private cryptographic key material between the involved entities.
このドキュメントでは、メタデータを定義して、2つ以上の相互接続されたコンテンツ配信ネットワーク（CDN）間でHTTPSコンテンツの配信を委任することをサポートしています。具体的には、このドキュメントでは、コンテンツ配信ネットワークの相互接続（CDNI）メタデータインターフェイスオブジェクトを定義して、RFC 9115で定義された委任スキームを活用するX.509証明書の委任を有効にします。いつでも。これにより、関係するエンティティ間で民間の暗号化キー資料を共有する必要性が回避されます。
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/rfc9538.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9538で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
2. Advertising Delegation Metadata for CDNI through FCI
3. ACME Delegation Metadata for CDNI
3.1. ACMEDelegationMethod Object
3.1.1. Examples
4. IANA Considerations
4.1. CDNI MI ACMEDelegationMethod Payload Type
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
Content delivery over HTTPS using two or more cooperating CDNs along the path requires credential management, specifically when DNS-based redirection is used. In such cases, an upstream CDN (uCDN) needs to delegate its credentials to a downstream CDN (dCDN) for content delivery.
パスに沿って2つ以上の協力CDNを使用したHTTPSを介したコンテンツ配信には、特にDNSベースのリダイレクトが使用される場合、資格管理が必要です。このような場合、上流のCDN（UCDN）は、その資格情報をコンテンツ配信のために下流のCDN（DCDN）に委任する必要があります。
[RFC9115] defines delegation methods that allow a uCDN on behalf of the content provider, the holder of the domain, to generate on-demand an X.509 certificate that binds the designated domain name with a key pair owned by the dCDN. For further details, please refer to Sections 1 and 5.1.2.1 of [RFC9115].
[RFC9115]は、コンテンツプロバイダーであるドメインの所有者に代わってUCDNを許可する委任方法を定義し、DCDNが所有するキーペアで指定ドメイン名を結合するX.509証明書をオンデマンドで生成します。詳細については、[RFC9115]のセクション1および5.1.2.1を参照してください。
This document defines CDNI Metadata to make use of HTTPS delegation between a uCDN and a dCDN based on the mechanism specified in [RFC9115]. Furthermore, it adds a delegation method to the "CDNI Payload Types" IANA registry.
このドキュメントでは、[RFC9115]で指定されたメカニズムに基づいて、UCDNとDCDNの間のHTTPS委任を使用するために、CDNIメタデータを定義しています。さらに、「CDNIペイロードタイプ」IANAレジストリに委任方法を追加します。
Section 2 presents delegation metadata for the Footprint & Capabilities Advertisement interface (FCI). Section 3 addresses the metadata for handling HTTPS delegation with the Metadata interface.
セクション2では、フットプリントおよび機能広告インターフェイス（FCI）の委任メタデータを示します。セクション3では、メタデータインターフェイスでHTTPS委任を処理するためのメタデータについて説明します。
This document uses terminology from CDNI framework documents such as: CDNI framework document [RFC7336] and CDNI interface specifications documents: CDNI Metadata interface [RFC8006] and CDNI Footprint and Capabilities Advertisement interface [RFC8008]. It also uses terminology from Section 1.2 of [RFC8739] and Section 1.1 of [RFC9115], including Short-Term, Automatically Renewed (STAR), as applied to X.509 certificates.
このドキュメントでは、CDNIフレームワークドキュメント[RFC7336]やCDNIインターフェイス仕様ドキュメントなどのCDNIフレームワークドキュメントの用語を使用しています。また、X.509証明書に適用されるように、短期、自動的に更新された（STAR）を含む[RFC8739]のセクション1.2および[RFC9115]のセクション1.1の用語を使用します。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The Footprint & Capabilities Advertisement interface (FCI) defined in [RFC8008] allows a dCDN to send a FCI capability type object to a uCDN.
[RFC8008]で定義されているフットプリントおよび機能広告インターフェイス（FCI）により、DCDNはFCI機能タイプオブジェクトをUCDNに送信できます。
This document uses the CDNI Metadata capability object serialization from [RFC8008] for a CDN that supports delegation methods.
このドキュメントでは、委任方法をサポートするCDNについて、[RFC8008]のCDNIメタデータ機能オブジェクトのシリアル化を使用します。
The following is an example of the supported delegated methods capability object for a dCDN implementing the ACME delegation method.
以下は、ACME委任法を実装するDCDNのサポートされている委任メソッド機能オブジェクトの例です。
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": [
// list of supported delegation methods
"ACMEDelegationMethod"
]
},
"footprints": [
"Footprint objects"
]
}
]
}
When a uCDN delegates the delivery of HTTPS traffic to a dCDN using DNS redirection [RFC7336], the dCDN must use a certificate bound to the origin's name to successfully authenticate to the end-user (see also Section 5.1.2.1 of [RFC9115]).
UCDNがDNSリダイレクト[RFC7336]を使用してHTTPSトラフィックのDCDNへの配信をDCDNに委任する場合、DCDNは原点の名前に縛られた証明書を使用して、エンドユーザーに正常に認証する必要があります（[RFC9115]のセクション5.1.2.1も参照））。
To that end, this section defines the AcmeDelegationMethod object, which describes metadata for using the ACME delegation interface [RFC9115].
そのために、このセクションでは、Acme委任インターフェイス[RFC9115]を使用するためのメタデータを記述するAcmedeLegationMethodオブジェクトを定義します。
The ACMEDelegationMethod applies to both ACME STAR delegation, which provides a delegation model based on short-term certificates with automatic renewal (Section 2.3.2 of [RFC9115]), and non-STAR delegation, which allows delegation between CDNs using long-term certificates (Section 2.3.3 of [RFC9115]).
AcmedelegationMethodは、自動更新（[RFC9115]のセクション2.3.2）の短期証明書に基づく委任モデルと、長期的な証明書を使用したCDN間の委任を可能にする非星委任モデルを提供する両方のACME STAR委任に適用されます。（[RFC9115]のセクション2.3.3）。
Figure 1 provides a high-level view of the combined CDNI and ACME delegation message flows to obtain a STAR certificate from the Certification Authority (CA) bound to the Content Provider's (CP) name.
図1は、CDNIとACMEの委任メッセージフローを組み合わせて、コンテンツプロバイダー（CP）名にバインドされた認定機関（CA）からSTAR証明書を取得するための高レベルのビューを示しています。
.----. .----. .----. .----.
|dCDN| |uCDN| | CP | | CA |
'-+--' '-+--' '--+-' '--+-'
| GET metadata | | |
+--------[CDNI]------>| | |
| 200 OK, metadata | | |
| (inc. dele config) | | |
|<-------[CDNI]-------+ | |
| | | |
| GET delegation | | |
+-----[ACME dele]---->| | |
| 200 OK, delegation | | |
| (inc. CSR template) | | |
|<----[ACME dele]-----+ | |
| | | |
+----. | | |
| | | | |
| create key pair and| | |
| CSR w/ delegated | | |
| name | | |
| | | | |
|<---' | | |
| | | |
| POST Order1 | | |
+-----[ACME dele]---->| | |
| | forward Order1 | |
| +-----[ACME dele]---->| |
| | | POST Order2 |
| | +-----[ACME STAR]----->|
| | | |
| | |<---authorizations--->|
| | | |
|<---wait issuance--->|<---wait issuance--->|<---wait issuance---->|
| |
| (unauthenticated) GET star-certificate |
+----------------------------------------------------------------->|
| certificate #1 |
|<-----------------------------------------------------------------+
| ... |
Figure 1: Example Call Flow of STAR Delegation in CDNI Showing Two Levels of Delegation
図1：2つのレベルの委任を示すCDNIの星代表団のコールフローの例
Note: The delegation object defined in Section 2.3.1.3 of [RFC9115] only allows DNS mappings to be specified using CNAME RRs. A future document updating [RFC9115] could expand the delegation object to also include SVCB/HTTPS-based mappings [RFC9460].
注：[RFC9115]のセクション2.3.1.3で定義されている委任オブジェクトは、CNAME RRSを使用してDNSマッピングのみを指定できます。[RFC9115]を更新する将来のドキュメントは、委任オブジェクトを拡張して、SVCB/HTTPSベースのマッピング[RFC9460]も含めることができます。
Section 3.1 defines the objects used for bootstrapping the ACME delegation method between a uCDN and a delegate dCDN.
セクション3.1では、UCDNと代表DCDNの間のACME委任法のブートストラップに使用されるオブジェクトを定義します。
The ACMEDelegationMethod object allows a uCDN to define both STAR and non-STAR delegations. The dCDN, the consumer of the delegation, can determine the type of delegation by the presence (or absence) of the "lifetime" property. That is, the presence of the "lifetime" property explicitly means a short-term delegation with lifetime of the certificate based on that property (and the optional "lifetime-adjust" attribute). A non-STAR delegation will not have the "lifetime" property in the delegation. See also the examples in Section 3.1.1.
ACMedElegationMethodオブジェクトにより、UCDNは星と非星の両方の委任を定義できます。代表団の消費者であるDCDNは、「生涯」プロパティの存在（または不在）による委任のタイプを決定できます。つまり、「生涯」プロパティの存在は、そのプロパティ（およびオプションの「生涯調整」属性）に基づいた証明書の生涯を持つ短期委任を明示的に意味します。星以外の代表団は、代表団に「生涯」のプロパティを持っていません。セクション3.1.1の例も参照してください。
The ACMEDelegationMethod object is defined with the properties shown below.
AcmedElegationMethodオブジェクトは、以下に示すプロパティで定義されています。
* Property: acme-delegation
* プロパティ：Acme-Delegation
- Description: A URL pointing at an ACME delegation object, either STAR or non-STAR, associated with the dCDN account on the uCDN ACME server (see Section 2.3.1.3 of [RFC9115] for the details). The URL MUST use the https scheme.
- 説明：UCDN ACMEサーバーのDCDNアカウントに関連付けられたACME委任オブジェクト（星または非星のいずれか）を指すURL（詳細については、[RFC9115]のセクション2.3.1.3を参照）。URLはHTTPSスキームを使用する必要があります。
- Type: String
- タイプ：文字列
- Mandatory-to-Specify: Yes
- 必須の仕様：はい
* Property: time-window
* プロパティ：Time-Window
- Description: Validity period of the certificate. According to Section 4.3.4 of [RFC8006], a TimeWindow object is defined by a window "start" time and a window "end" time. In the case of a STAR method, the "start" and "end" properties of the window MUST be understood respectively as the start-date and end-date of the certificate validity. In the case of a non-STAR method, the "start" and "end" properties of the window MUST be understood, respectively, as the notBefore and notAfter fields of the certificate.
- 説明：証明書の有効期間。[RFC8006]のセクション4.3.4によると、TimeWindowオブジェクトは、ウィンドウ「開始」時間とウィンドウ「終了」時間によって定義されます。STARメソッドの場合、ウィンドウの「開始」および「終了」プロパティは、それぞれ証明書の有効性の開始日と終了日として理解する必要があります。星以外の方法の場合、ウィンドウの「開始」プロパティと「終了」プロパティは、それぞれ証明書のフィールドとノートファイターの前に、それぞれ理解する必要があります。
- Type: TimeWindow
- タイプ：TimeWindow
- Mandatory-to-Specify: Yes
- 必須の仕様：はい
* Property: lifetime
* プロパティ：生涯
- Description: See lifetime in Section 3.1.1 of [RFC8739]
- 説明：[RFC8739]のセクション3.1.1の寿命を参照してください
- Type: Integer
- タイプ：整数
- Mandatory-to-Specify: Yes, only if a STAR delegation method is specified
- 必須の仕様：はい、星の委任方法が指定されている場合にのみ
* Property: lifetime-adjust
* プロパティ：生涯調整
- Description: See lifetime-adjust in Section 3.1.1 of [RFC8739]
- 説明：[RFC8739]のセクション3.1.1の寿命調整を参照してください
- Type: Integer
- タイプ：整数
- Mandatory-to-Specify: No
- 必須の仕様：いいえ
The following example shows an ACMEDelegationMethod object for a STAR-based ACME delegation.
次の例は、星ベースのACME代表団のacmedelegationmethodオブジェクトを示しています。
{
"generic-metadata-type": "MI.ACMEDelegationMethod",
"generic-metadata-value": {
"acme-delegation": "https://acme.ucdn.example/delegation/ogfr",
"time-window": {
"start": 1665417434,
"end": 1665676634
},
"lifetime": 345600,
"lifetime-adjust": 259200
}
}
The example below shows an ACMEDelegationMethod object for a non-STAR ACME delegation. The delegation object is defined as per Section 4.3 of [RFC8006].
以下の例は、星以外のACME代表団のacmedelegationMethodオブジェクトを示しています。委任オブジェクトは、[RFC8006]のセクション4.3に従って定義されます。
{
"generic-metadata-type": "MI.ACMEDelegationMethod",
"generic-metadata-value": {
"acme-delegation": "https://acme.ucdn.example/delegation/wSi5",
"time-window": {
"start": 1570982234,
"end": 1665417434
}
}
}
Per this document, the following type has been registered in the "CDNI Payload Types" registry:
このドキュメントに従って、次のタイプは「CDNIペイロードタイプ」レジストリに登録されています。
+=========================+===========+
| Payload Type | Reference |
+=========================+===========+
| MI.ACMEDelegationMethod | RFC 9538 |
+-------------------------+-----------+
Table 1
Purpose:
目的：
The purpose of this Payload Type is to distinguish AcmeDelegationMethod MI objects (and any associated capability advertisement)
このペイロードタイプの目的は、acmedelegationmethod miオブジェクト（および関連する機能広告）を区別することです
Interface:
インターフェース：
MI/FCI
MI/FCI
Encoding:
エンコーディング：
See Section 3.1
セクション3.1を参照してください
The metadata object defined in this document does not introduce any new security or privacy concerns over those already discussed in [RFC9115], [RFC8006], and [RFC8008].
このドキュメントで定義されているメタデータオブジェクトは、[RFC9115]、[RFC8006]、および[RFC8008]ですでに議論されているものについて、新しいセキュリティまたはプライバシーの懸念を導入しません。
The reader is expected to understand the ACME delegation trust model (Section 7.1 of [RFC9115]) and security goal (Section 7.2 of [RFC9115]). In particular, the reader is expected to understand that it is critical to protect the user account associated with the delegation; this account authorizes all the security-relevant operations between a dCDN and a uCDN over the ACME channel. The dCDN's ACME account is also relevant to the privacy of the entire scheme; for example, the acme-delegation resource in the Metadata object is only accessible to the holder of the account key, who is allowed to fetch its content exclusively via POST-as-GET (Section 2.3.1.2 of [RFC9115]).
読者は、ACME委任信託モデル（[RFC9115]のセクション7.1）およびセキュリティ目標（[RFC9115]のセクション7.2）を理解することが期待されています。特に、読者は、委任に関連するユーザーアカウントを保護することが重要であることを理解することが期待されています。このアカウントは、ACMEチャネル上のDCDNとUCDNの間のすべてのセキュリティ関連操作を承認します。DCDNのACMEアカウントは、スキーム全体のプライバシーにも関連しています。たとえば、メタデータオブジェクトのAcme-Delegationリソースは、アカウントキーの所有者のみがアクセスできるようになります。キーは、ポストアサイズ（[RFC9115]のセクション2.3.1.2）を介してそのコンテンツのみを取得することができます。
In addition, the Metadata interface authentication and confidentiality requirements defined in Section 8 of [RFC8006] MUST be followed.
さらに、[RFC8006]のセクション8で定義されているメタデータインターフェイス認証と機密性の要件に従う必要があります。
Implementers MUST adhere to the security considerations defined in Section 7 of [RFC8008], "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics".
実装者は、[RFC8008]のセクション7で定義されているセキュリティ上の考慮事項を遵守する必要があります。
When TLS is used to achieve the above security objectives, the general TLS usage guidance in [RFC9325] MUST be followed.
上記のセキュリティ目標を達成するためにTLSを使用する場合、[RFC9325]の一般的なTLS使用ガイダンスに従う必要があります。
[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>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"Content Delivery Network Interconnection (CDNI)
Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
<https://www.rfc-editor.org/info/rfc8006>.
[RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
R., and K. Ma, "Content Delivery Network Interconnection
(CDNI) Request Routing: Footprint and Capabilities
Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
<https://www.rfc-editor.org/info/rfc8008>.
[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>.
[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>.
[RFC9115] Sheffer, Y., López, D., Pastor Perales, A., and T.
Fossati, "An Automatic Certificate Management Environment
(ACME) Profile for Generating Delegated Certificates",
RFC 9115, DOI 10.17487/RFC9115, September 2021,
<https://www.rfc-editor.org/info/rfc9115>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[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>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/info/rfc9460>.
We would like to thank authors of the [RFC9115], Antonio Augustín Pastor Perales, Diego López, Thomas Fossati, and Yaron Sheffer. Additionally, our gratitude to Thomas Fossati who participated in the drafting, reviewing, and giving his feedback in finalizing this document. We also thank CDNI co-chair Kevin Ma for his continual review and feedback during the development of this document.
[RFC9115]、アントニオ・オーガスティン・ペラレス、ディエゴ・ロペス、トーマス・フォッサティ、ヤロン・シェファーの著者に感謝したいと思います。さらに、このドキュメントの最終化においてドラフト、レビュー、およびフィードバックを提供したトーマス・フォッサティに感謝します。また、CDNIの共同議長であるKevin Maが、この文書の開発中の継続的なレビューとフィードバックについても感謝します。
Frédéric Fieau (editor)
Orange
40-48, avenue de la République
92320 Châtillon
France
Email: frederic.fieau@orange.com
Emile Stephan
Orange
2, avenue Pierre Marzin
22300 Lannion
France
Email: emile.stephan@orange.com
Sanjay Mishra
Verizon
13100 Columbia Pike
Silver Spring, MD 20904
United States of America
Email: sanjay.mishra@verizon.com