Internet Engineering Task Force (IETF) J. Snijders
Request for Comments: 9589 Fastly
Updates: 6488 T. Harrison
Category: Standards Track APNIC
ISSN: 2070-1721 May 2024
In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as Cryptographic Message Syntax (CMS) protected content types. A Signed Object contains a signing-time attribute, representing the purported time at which the object was signed by its issuer. RPKI repositories are accessible using the rsync and RPKI Repository Delta protocols, allowing Relying Parties (RPs) to synchronize a local copy of the RPKI repository used for validation with the remote repositories. This document describes how the CMS signing-time attribute can be used to avoid needless retransfers of data when switching between different synchronization protocols. This document updates RFC 6488 by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute.
リソース公開キーインフラストラクチャ（RPKI）では、署名されたオブジェクトは暗号化メッセージの構文（CMS）保護されたコンテンツタイプとして定義されます。署名されたオブジェクトには、署名時の属性が含まれており、その発行者によってオブジェクトが署名されたとされる時間を表します。RPKIリポジトリは、RSYNCおよびRPKIリポジトリデルタプロトコルを使用してアクセスでき、依存関係者（RPS）がリモートリポジトリでの検証に使用されるRPKIリポジトリのローカルコピーを同期させることができます。このドキュメントでは、異なる同期プロトコルを切り替えるときに、CMSの署名時間属性を使用してデータの不必要な再送信を回避する方法について説明します。このドキュメントは、CMS署名時の属性の存在を義務付け、バイナリ署名時間属性の使用を許可することにより、RFC 6488を更新します。
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/rfc9589.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9589で取得できます。
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. Requirements Language
2. Optimized Switchover from RRDP to rsync
2.1. Guidance for Repository Operators
2.2. Guidance for Relying Parties
3. Presence of the CMS Signing-Time Attribute in Public
Repositories
4. Updates to RFC 6488
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
In the Resource Public Key Infrastructure (RPKI) [RFC6480], Signed Objects are defined as Cryptographic Message Syntax (CMS) [RFC5652] [RFC6268] protected content types by way of a standard template [RFC6488]. That template includes an optional CMS signing-time attribute, representing the time at which the object was signed by its issuer. At the time when the standard template was defined, rsync was the only distribution mechanism for RPKI repositories.
リソース公開キーインフラストラクチャ（RPKI）[RFC6480]では、署名されたオブジェクトは暗号化メッセージ構文（CMS）[RFC5652] [RFC6268]標準テンプレート[RFC6488]によって保護されたコンテンツタイプとして定義されます。そのテンプレートには、オプションのCMS署名時間属性が含まれており、オブジェクトが発行者によって署名された時間を表しています。標準テンプレートが定義された時点で、RSYNCはRPKIリポジトリの唯一の分布メカニズムでした。
Since the publication of the standard template, a new, additional protocol for distribution of RPKI repositories has been developed: the RPKI Repository Delta Protocol (RRDP) [RFC8182]. While RPKI repository operators must provide rsync service, RRDP is typically deployed alongside it as well, and is preferred by default by most Relying Party (RP) implementations. However, RP implementations also support fallback to rsync in the event of problems with the RRDP service. As deployment experience with RRDP has increased, the usefulness of optimizing switchovers by RPs from one mechanism to the other has become apparent.
標準テンプレートの公開以来、RPKIリポジトリの配布のための新しい追加プロトコルが開発されました：RPKIリポジトリデルタプロトコル（RRDP）[RFC8182]。RPKIリポジトリオペレーターはRSYNCサービスを提供する必要がありますが、RRDPは通常、それと同様に展開され、デフォルトではほとんど依存している当事者（RP）の実装が優先されます。ただし、RPの実装は、RRDPサービスの問題が発生した場合のRSYNCへのフォールバックもサポートしています。RRDPでの展開エクスペリエンスが向上するにつれて、RPSによるスイッチオーバーを最適化することの有用性が、あるメカニズムから別のメカニズムへの有用性が明らかになりました。
This document describes how Repository Operators [RFC6481] and RPs can use the CMS signing-time attribute to minimize the burden of switching over from RRDP to rsync. Additionally, this document updates [RFC6488] by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute.
このドキュメントでは、リポジトリオペレーター[RFC6481]とRPSがCMS署名時の属性を使用して、RRDPからRSYNCに切り替える負担を最小限に抑える方法について説明します。さらに、このドキュメントは、CMS署名時の属性の存在を義務付け、バイナリ署名時間属性の使用を許可することにより、[RFC6488]を更新します。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
To avoid needless retransfers of unchanged files in consecutive rsync synchronizations, [RPKI-PUB-SERV] recommends the use of so-called 'deterministic' (normalized) timestamps for files. When the content of a file is unchanged, Repository Operators SHOULD ensure that the last modification timestamp of the file remains unchanged as well.
連続したRSYNC同期での不変のファイルの不必要な再送信を回避するために、[rpki-pub-serv]は、ファイルにいわゆる「決定的」（正規化された）タイムスタンプの使用を推奨します。ファイルのコンテンツが変更されていない場合、リポジトリオペレーターは、ファイルの最後の変更タイムスタンプも変更されていないことを確認する必要があります。
This document advances the aforementioned concept by describing a synchronization strategy through which needless transfers are also avoided upon first use of rsync, by leveraging data previously fetched via RRDP.
このドキュメントは、RRDPを介して以前に取得されたデータを活用することにより、RSYNCの最初の使用時に不必要な転送も回避される同期戦略を説明することにより、前述の概念を進めます。
At the time of writing, all commonly used RP implementations will first attempt synchronization via RRDP, as described in [RPKI-REP-REQS]. If synchronization via RRDP fails for some reason (e.g., malformed XML, expired TLS certificate, HTTP connection timeout), the RP will attempt to synchronize via rsync instead.
執筆時点では、一般的に使用されるすべてのRP実装は、[RPKI-REP-REQS]で説明されているように、最初にRRDPを介した同期を試みます。RRDP経由の同期が何らかの理由で失敗した場合（例：奇形のXML、有効期限が切れたTLS証明書、HTTP接続タイムアウト）、RPは代わりにRSYNCを介して同期しようとします。
In the rsync synchronization protocol, a file's last modification timestamp ('mod-time' from here on) and file size are used to determine whether the general-purpose rsync synchronization algorithm needs to be executed for the file. This is the default mode for both the original rsync implementation [rsync] and the OpenBSD implementation [openrsync]. If the sender's copy of the file and the receiver's copy of the file both have the same mod-time and file size, the files are assumed to contain the same content, and they will be omitted from the list of files to be transferred. Ensuring consistency with respect to mod-time for both senders and receivers helps to reduce the burden of rsync synchronization in terms of network bandwidth, disk I/O operations, and CPU usage.
RSYNC同期プロトコルでは、ファイルの最後の変更タイムスタンプ（ここから「MOD-TIME」）とファイルサイズを使用して、ファイルに対して汎用RSYNC同期アルゴリズムを実行する必要があるかどうかを判断します。これは、元のRSYNC実装[RSYNC]とOpenBSD実装[OpenRSYNC]の両方のデフォルトモードです。ファイルの送信者のコピーとファイルの受信者のコピーの両方が同じMODTIMEとファイルサイズを持っている場合、ファイルは同じコンテンツを含むと想定され、それらは転送されるファイルのリストから省略されます。送信者と受信機の両方のMOD-TIMEに関して一貫性を確保することは、ネットワーク帯域幅、ディスクI/O操作、およびCPU使用の観点からRSYNC同期の負担を軽減するのに役立ちます。
In order to reduce the burden of the rsync synchronization (following an RRDP failure), Repository Operators and RPs SHOULD adhere to the following guidelines.
RSYNC同期（RRDP障害後）の負担を軽減するために、リポジトリオペレーターとRPSは次のガイドラインを順守する必要があります。
When serializing RPKI Signed Objects to a filesystem hierarchy for publication via rsync, the mod-time of the file containing the Signed Object SHOULD be set to the value of the CMS signing-time attribute contained within the Signed Object.
RPKIをシリアル化する場合、RSYNCを介して公開するためのファイルシステム階層にオブジェクトに署名する場合、署名されたオブジェクトを含むファイルのmod-timeは、署名されたオブジェクト内に含まれるCMS署名時間属性の値に設定する必要があります。
When serializing RPKI Signed Objects retrieved via RRDP to a filesystem hierarchy, the mod-time of the file containing the Signed Object SHOULD be set to the value of the CMS signing-time attribute contained within the Signed Object.
RRDPを介してファイルシステム階層に取得されたRPKIのシリアル化署名型オブジェクトは、署名されたオブジェクトを含むファイルのmod-timeを、署名されたオブジェクト内に含まれるCMS署名時間属性の値に設定する必要があります。
If an RP uses RRDP to synthesize a filesystem hierarchy for the repository, then synchronizing to the corresponding directory directly is an option. Alternatively, the RP can synchronize to a new (empty) directory using the --compare-dest=DIR rsync feature, in order to avoid retrieving files that are already available by way of the synthesized filesystem hierarchy stemming from previous RRDP fetches. The DIR component is to be substituted with the name of the directory containing previously fetched and validated RPKI data (in its original DER-encoded form, to ensure the file size parameter matches).
RPがRRDPを使用してリポジトリのファイルシステム階層を合成する場合、対応するディレクトリに直接同期することがオプションです。あるいは、RPは、以前のRRDPフェッチに由来する合成ファイルシステム階層によって既に利用可能なファイルの取得を回避するために、-compare-dest = dir rsync機能を使用して新しい（空の）ディレクトリに同期することができます。dirコンポーネントは、ファイルサイズパラメーターが一致するように、以前に取得および検証されたRPKIデータ（元のderエンコード形式で）を含むディレクトリの名前を置き換えます。
From the [rsync] man page for --compare-dest=DIR:
[rsync] man page for - compare-dest = dir：
This option instructs rsync to use DIR on the destination machine as an additional hierarchy to compare destination files against doing transfers (if the files are missing in the destination directory). If a file is found in DIR that is identical to the sender's file, the file will NOT be transferred to the destination directory. This is useful for creating a sparse backup of just files that have changed from an earlier backup.
このオプションは、RSYNCに、宛先マシン上のDIRを追加の階層として使用するように指示します。宛先ファイルを転送と比較することを指示します（宛先ディレクトリにファイルが欠落している場合）。送信者のファイルと同一のファイルがdirで見つかった場合、ファイルは宛先ディレクトリに転送されません。これは、以前のバックアップから変更されたJust Filesのスパースバックアップを作成するのに役立ちます。
From the [openrsync] man page for --compare-dest=directory:
[compare-dest = directoryの[openrsync] manページから：
Use directory as an alternate base directory to compare files against on the destination machine. If file in directory is found and identical to the sender's file, the file will not be transferred.
ディレクトリを代替ベースディレクトリとして使用して、宛先マシンに対してファイルを比較します。ディレクトリ内のファイルが送信者のファイルと同一である場合、ファイルは転送されません。
Analyzing the [rpkiviews] archives containing millions of RPKI Signed Objects discovered via the five Regional Internet Registry (RIR) Trust Anchors (TAs) from 6 June 2022 to 29 January 2024, each Signed Object contained a CMS signing-time attribute.
2022年6月6日6日から2024年1月29日まで、5つの地域インターネットレジストリ（RIR）トラストアンカー（TA）を介して発見された数百万のRPKI署名されたオブジェクトを含む[RPKIVIEWS]アーカイブを分析すると、それぞれ署名されたオブジェクトにはCMSの署名時間属性が含まれていました。
The above means that all of the commonly used TAs and their subordinate Certification Authorities (CAs) produce Signed Objects that contain a CMS signing-time attribute. This means that making the CMS signing-time attribute mandatory would not cause any existing commonly used TA or CA to become non-compliant.
上記は、一般的に使用されるすべてのTASおよびその下位認定当局（CAS）がCMS署名時の属性を含む署名型オブジェクトを生成することを意味します。これは、CMSの署名時間属性を必須にすることで、既存の一般的に使用されるTAまたはCAが非準拠にならないことを意味します。
As of 29 January 2024, for 83.8% of Signed Objects, the CMS signing-time timestamp matches the file's mod-time observed via rsync. This means that it is already the case that RPs would see a significant reduction in the amount of processing required in rsync if they adopted the strategy outlined in Section 2.2.
2024年1月29日の時点で、署名されたオブジェクトの83.8％の場合、CMS署名時のタイムスタンプは、RSYNCを介して観察されたファイルのmod-timeと一致しています。これは、RPSがセクション2.2で概説されている戦略を採用した場合、RPSがRSYNCで必要な処理量を大幅に減らすことがすでにあることを意味します。
In the above-mentioned period of time, no Signed Objects were discovered with a CMS binary-signing-time [RFC6019] attribute in the specified repositories. Therefore, disallowing the use of the CMS binary-signing-time attribute would not cause any existing commonly used TA or CA to become non-compliant.
上記の期間では、指定されたリポジトリにCMSバイナリ署名時間[RFC6019]属性を使用して署名されたオブジェクトは発見されませんでした。したがって、CMSバイナリ - 署名時間属性の使用を許可しても、既存の一般的に使用されるTAまたはCAが非準拠になることはありません。
This section updates [RFC6488] to make the CMS signing-time attribute mandatory and to disallow the presence of the CMS binary-signing-time attribute.
このセクションは[RFC6488]を更新して、CMSの署名時間属性を必須にし、CMSバイナリ署名時間属性の存在を禁止します。
* In Section 2.1.6.4, this paragraph is replaced as follows.
* セクション2.1.6.4では、この段落は次のように置き換えられます。
OLD
古い
* The signedAttrs element MUST be present and MUST include the content- type and message-digest attributes [RFC5652]. The signer MAY also include the signing-time attribute [RFC5652], the binary-signing-time attribute [RFC6019], or both attributes. Other signed attributes MUST NOT be included.
* SigneDattrs要素が存在する必要があり、コンテンツタイプとメッセージダイジスト属性[RFC5652]を含める必要があります。署名者には、署名時の属性[RFC5652]、バイナリ署名時間属性[RFC6019]、または両方の属性も含まれます。その他の署名された属性を含める必要はありません。
NEW
新しい
* The signedAttrs element MUST be present and MUST include the content-type, message-digest, and signing-time attributes [RFC5652]. Other signed attributes MUST NOT be included.
* SigneDattrs要素が存在する必要があり、コンテンツタイプ、メッセージダイジスト、および署名時の属性[RFC5652]を含める必要があります。その他の署名された属性を含める必要はありません。
* In Section 2.1.6.4.3, the first sentence is replaced as follows.
* セクション2.1.6.4.3では、最初の文は次のように置き換えられます。
OLD
古い
* The signing-time attribute MAY be present.
* 署名時の属性が存在する場合があります。
NEW
新しい
* The signing-time attribute MUST be present.
* 署名時の属性が存在する必要があります。
* In Section 2.1.6.4.3, the sentence "Note that the presence or absence of the signing-time attribute MUST NOT affect the validity of the signed object (as specified in Section 3)." is removed.
* セクション2.1.6.4.3では、「署名時の属性の有無は、署名されたオブジェクトの有効性に影響してはならないことに注意してください（セクション3で指定されている）。削除されます。
* Section 2.1.6.4.4 is removed in its entirety.
* セクション2.1.6.4.4は全体が削除されます。
* In Section 3, item 1.f is replaced as follows.
* セクション3では、項目1が次のように置き換えられます。
OLD
古い
f. The signedAttrs field in the SignerInfo object is present and contains both the content-type attribute (OID 1.2.840.113549.1.9.3) and the message-digest attribute (OID 1.2.840.113549.1.9.4).
f. SignerInfoオブジェクトのSigneDattrsフィールドは存在し、コンテンツタイプの属性（OID 1.2.840.113549.1.9.3）とメッセージダイジスト属性（OID 1.2.840.113549.1.9.4）の両方が含まれています。
NEW
新しい
f. The signedAttrs field in the SignerInfo object is present and contains the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attribute (OID 1.2.840.113549.1.9.4), and the signing-time attribute (1.2.840.113549.1.9.5).
f. SignerInfoオブジェクトのSigneDattrsフィールドは存在し、コンテンツタイプの属性（OID 1.2.840.113549.1.9.3）、メッセージダイジェスト属性（OID 1.2.840.113549.1.9.4）、およびSINGING-TIME属性（1.2.840.113549.1.9.5）。
* In Section 3, item 1.g is replaced as follows.
* セクション3では、項目1.gが次のように置き換えられます。
OLD
古い
g. The signedAttrs field in the SignerInfo object does not contain any attributes other than the following four: the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attribute (OID 1.2.840.113549.1.9.4), the signing-time attribute (OID 1.2.840.113549.1.9.5), and the binary-signing-time attribute (OID 1.2.840.113549.1.9.16.2.46). Note that the signing-time and binary-signing-time attributes MAY be present, but they are not required.
g. SignerINFOオブジェクトのSigneDattrsフィールドには、次の4つ以外の属性は含まれていません。コンテンツタイプの属性（OID 1.2.840.113549.1.9.3）、メッセージダイジェスト属性（OID 1.2.840.113549.1.9.4）、署名時の属性（OID 1.2.840.113549.1.9.5）、およびバイナリシグインタイム属性（OID 1.2.840.113549.1.9.16.2.46）。署名時間およびバイナリシグインタイム属性が存在する場合があるが、それらは必要ないことに注意してください。
NEW
新しい
g. The signedAttrs field in the SignerInfo object does not contain any attributes other than the following three: the content-type attribute (OID 1.2.840.113549.1.9.3), the message-digest attribute (OID 1.2.840.113549.1.9.4), and the signing-time attribute (OID 1.2.840.113549.1.9.5).
g. SignerInfoオブジェクトのSigneDattrsフィールドには、次の3つ以外の属性は含まれていません。コンテンツタイプの属性（OID 1.2.840.113549.1.9.3）、メッセージダイジェスト属性（OID 1.2.840.113549.1.9.4）、署名時の属性（OID 1.2.840.113549.1.9.5）。
* In Section 9 (Informative References), [RFC6019] is removed from the list.
* セクション9（有益な参照）では、[RFC6019]がリストから削除されます。
No requirement is imposed concerning the correctness of the signing time attribute. It does not provide reliable information on the time the signature was produced and it bears no relevance for seamless switchover between RRDP and rsync.
署名時間属性の正確性に関する要件は課されていません。署名が生成された時点に関する信頼できる情報は提供されず、RRDPとRSYNCの間のシームレスなスイッチオーバーには関連性がありません。
Although the Security Considerations in [RFC6019] mandate that the signing-time and binary-signing-time attributes (if both present) MUST provide the same date and time, there is still a chance that an object will have values for these attributes that do not represent the same date and time. Restricting the RPKI Signed Object profile to a single field for storing the signing time removes any potential for ambiguity.
[RFC6019]のセキュリティ上の考慮事項は、署名時とバイナリシグインタイムの属性（両方が存在する場合）が同じ日時を提供しなければならないことを義務付けていますが、オブジェクトがこれらの属性の値を持つ可能性はまだあります。同じ日時を表していません。署名時間を保存するためにRPKI署名されたオブジェクトプロファイルを単一のフィールドに制限すると、あいまいさの可能性が削除されます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[openrsync]
"openrsync", 2023, <https://www.openrsync.org/>.
[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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules
for the Cryptographic Message Syntax (CMS) and the Public
Key Infrastructure Using X.509 (PKIX)", RFC 6268,
DOI 10.17487/RFC6268, July 2011,
<https://www.rfc-editor.org/info/rfc6268>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012,
<https://www.rfc-editor.org/info/rfc6481>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>.
[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>.
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>.
[rsync] "rsync", 2024, <https://rsync.samba.org/>.
[RFC6019] Housley, R., "BinaryTime: An Alternate Format for
Representing Date and Time in ASN.1", RFC 6019,
DOI 10.17487/RFC6019, September 2010,
<https://www.rfc-editor.org/info/rfc6019>.
[RPKI-PUB-SERV]
Bruijnzeels, T., de Kock, T., Hill, F., and T. Harrison,
"RPKI Publication Server Best Current Practices", Work in
Progress, Internet-Draft, draft-timbru-sidrops-
publication-server-bcp-02, 18 January 2024,
<https://datatracker.ietf.org/doc/html/draft-timbru-
sidrops-publication-server-bcp-02>.
[RPKI-REP-REQS]
Bruijnzeels, T., Bush, R., and G. Michaelson, "Resource
Public Key Infrastructure (RPKI) Repository Requirements",
Work in Progress, Internet-Draft, draft-ietf-sidrops-
prefer-rrdp-02, 23 December 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
prefer-rrdp-02>.
[rpkiviews]
"rpkiviews", <https://www.rpkiviews.org/>.
The authors would like to thank Ties de Kock, Niels Bakker, Mikael Abrahamsson, Russ Housley, Zaheduzzaman Sarker, Éric Vyncke, Mahesh Jethanandani, and Roman Danyliw, for their helpful review of this document.
著者は、この文書の有益なレビューについて、Ties de Kock、Niels Bakker、Mikael Abrahamsson、Russ Housley、Zaheduzzaman Sarker、Eric Vyncke、Mahesh Jethanandani、Roman Danyliwに感謝したいと思います。
Job Snijders
Fastly
Amsterdam
The Netherlands
Email: job@fastly.com
Tom Harrison
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Email: tomh@apnic.net