[要約] RFC 9255は、RPKIがインターネットナンバーリソース（INR）の実世界の所有者の身元と関連付けられるという誤った考えを否定し、INRの保持者と関連付けないことを明確にします。
Internet Engineering Task Force (IETF) R. Bush
Request for Comments: 9255 Arrcus & IIJ Research
Category: Standards Track R. Housley
ISSN: 2070-1721 Vigil Security
June 2022
The 'I' in RPKI Does Not Stand for Identity
rpkiの「私」はアイデンティティを表していません
Abstract
概要
There is a false notion that Internet Number Resources (INRs) in the RPKI can be associated with the real-world identity of the 'holder' of an INR. This document specifies that RPKI does not associate to the INR holder.
RPKIのインターネット番号リソース（INR）は、INRの「ホルダー」の実際のアイデンティティに関連付けられる可能性があるという誤った概念があります。このドキュメントは、RPKIがINRホルダーに関連付けられていないことを指定しています。
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/rfc9255.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9255で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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ライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. The RPKI is for Authorization
3. Discussion
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
The Resource Public Key Infrastructure (RPKI), see [RFC6480], "represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers," which are collectively known as Internet Number Resources (INRs). Since initial deployment, the RPKI has grown to include other similar resource and routing data, e.g., Router Keying for BGPsec [RFC8635].
リソースの公開キーインフラストラクチャ（RPKI）、[RFC6480]を参照してください。「IPアドレススペースと自律システム（AS）数の割り当て階層（AS）を表します。初期展開以来、RPKIは他の同様のリソースおよびルーティングデータ、たとえばBGPSECのキーイング[RFC8635]を含めるように成長しました。
In security terms, the phrase "Public Key" implies there is also a corresponding private key [RFC5280]. The RPKI provides strong authority to the current holder of INRs; however, some people have a desire to use RPKI private keys to sign arbitrary documents as the INR 'holder' of those resources with the inappropriate expectation that the signature will be considered an attestation to the authenticity of the document content. But, in reality, the RPKI certificate is only an authorization to speak for the explicitly identified INRs; it is explicitly not intended for authentication of the 'holders' of the INRs. This situation is emphasized in Section 2.1 of [RFC6480].
セキュリティ用語では、「公開鍵」というフレーズは、対応する秘密鍵もあることを意味します[RFC5280]。RPKIは、現在のINRの保有者に強力な権限を提供します。ただし、一部の人々は、RPKIプライベートキーを使用して、署名がドキュメントコンテンツの信頼性の認証と見なされるという不適切な期待を抱いて、それらのリソースの任意のドキュメントとして署名することを望んでいます。しかし、実際には、RPKI証明書は、明示的に特定されたINRを代表する許可にすぎません。INRの「保有者」の認証を明示的に意図していません。この状況は、[RFC6480]のセクション2.1で強調されています。
It has been suggested that one could authenticate real-world business transactions with the signatures of INR holders. For example, Bill's Bait and Sushi (BB&S) could use the private key attesting to that they are the holder of their AS in the RPKI to sign a Letter of Authorization (LOA) for some other party to rack and stack hardware owned by BB&S. Unfortunately, while this may be technically possible, it is neither appropriate nor meaningful.
INR所有者の署名で実際のビジネストランザクションを認証できることが示唆されています。たとえば、ビルの餌と寿司（BB＆S）は、RPKIの所有者であることを証明する秘密キーを使用して、BB＆Sが所有するハードウェアをラックしてスタックするために、他の当事者に認可書（LOA）に署名することができます。残念ながら、これは技術的には可能かもしれませんが、それは適切でも意味がありません。
The 'I' in RPKI actually stands for "Infrastructure," as in Resource Public Key Infrastructure, not for "Identity". In fact, the RPKI does not provide any association between INRs and the real-world holder(s) of those INRs. The RPKI provides authorization to make assertions only regarding Internet Number Resources, such as IP prefixes or AS numbers, and data such as Autonomous System Provider Authorization (ASPA) records [ASPA-PROFILE].
RPKIの「I」は、実際には「インフラストラクチャ」を表しています。これは、「ID」ではなく、リソース公開キーインフラストラクチャのように。実際、RPKIは、INRとそれらのINRの実世界の所有者との間に関連性を提供しません。RPKIは、IPプレフィックスなどのインターネット番号リソースや数字としてのみ、および自律システムプロバイダー認証（ASPA）レコード[ASPAプロファイル]などのデータに関する主張を行う許可を提供します。
In short, avoid the desire to use RPKI certificates for any purpose other than the verification of authorizations associated with the delegation of INRs or attestations related to INRs. Instead, recognize that these authorizations and attestations take place irrespective of the identity of an RPKI private key holder.
要するに、INRの委任またはINRに関連する証明に関連する承認の検証以外の目的でRPKI証明書を使用したいという欲求を避けてください。代わりに、RPKI秘密キーホルダーの身元に関係なく、これらの承認と証明が行われることを認識してください。
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 RPKI was designed and specified to sign certificates for use within the RPKI itself and to generate Route Origin Authorizations (ROAs) [RFC6480] for use in routing. Its design intentionally precluded use for attesting to real-world identity as, among other issues, it would expose the Certification Authority (CA) to liability.
RPKIは、RPKI自体内で使用する証明書に署名し、ルーティングで使用するためにルートオリジン認証（ROA）[RFC6480]を生成するように設計および指定されました。その設計は、他の問題の中でも、認証機関（CA）を責任を暴露するため、実際のアイデンティティを証明するための使用を意図的に排除しました。
That the RPKI does not authenticate real-world identity is by design. If it tried to do so, aside from the liability, it would end in a world of complexity with no proof of termination.
RPKIが実際のアイデンティティを認証しないことは設計によるものです。責任を除いて、そうしようとした場合、それは終了の証拠なしに複雑さの世界で終わります。
Registries such as the Regional Internet Registries (RIRs) provide INR to real-world identity mapping through WHOIS [RFC3912] and similar services. They claim to be authoritative, at least for the INRs that they allocate.
Regional Internet Registries（RIRS）などのレジストリは、WHOIS [RFC3912]および同様のサービスを通じて、実際のアイデンティティマッピングにINRを提供します。彼らは、少なくとも彼らが割り当てるINRのために、権威あると主張しています。
That is, RPKI-based credentials of INRs MUST NOT be used to authenticate real-world documents or transactions. That might be done with some formal external authentication of authority allowing an otherwise anonymous INR holder to authenticate the particular document or transaction. Given such external, i.e. non-RPKI, verification of authority, the use of RPKI-based credentials adds no authenticity.
つまり、RPKIベースのINRの資格情報を使用して、実際のドキュメントやトランザクションを認証するために使用してはなりません。それは、特定のドキュメントまたはトランザクションを認証できる匿名のINR保有者を許可する権限の正式な外部認証で行われる可能性があります。そのような外部、つまり非RPKIの権限の検証を考えると、RPKIベースの資格情報の使用は信頼性を追加しません。
Section 2.1 of the RPKI base document [RFC6480] says explicitly "An important property of this PKI is that certificates do not attest to the identity of the subject."
RPKIベースドキュメント[RFC6480]のセクション2.1は、「このPKIの重要な特性は、証明書が被験者の身元を証明していないことです」と明示的に述べています。
Section 3.1 of "Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)" [RFC7382] states that the Subject name in each certificate SHOULD NOT be meaningful and goes on to explain this at some length.
「リソースPKI（RPKI）の認証慣行声明（CPS）のテンプレート（CPS）」[RFC7382]のセクション3.1は、各証明書の件名名は意味がないことを示しており、これをある程度説明し続けています。
Normally, the INR holder does not hold the private key attesting to their resources; the CA does. The INR holder has a real-world business relationship with the CA for which they have likely signed real-world documents.
通常、INR保有者は、リソースを証明する秘密鍵を保持していません。CAはそうします。INR所有者は、実世界のドキュメントに署名した可能性が高いCAとの現実世界のビジネス関係を持っています。
As the INR holder does not have the keying material, they rely on the CA, to which they presumably present credentials, to manipulate their INRs. These credentials may be user ID and password (with two-factor authentication one hopes), a hardware token, client browser certificates, etc.
INRホルダーにはキーイング素材がないため、INRを操作するために、おそらく資格を提示するCAに依存しています。これらの資格情報は、ユーザーIDとパスワード（2要素認証が期待される）、ハードウェアトークン、クライアントブラウザ証明書などです。
Hence schemes such as Resource Tagged Attestations [RPKI-RTA] and Signed Checklists [RPKI-RSC] must go to great lengths to extract the supposedly relevant keys from the CA.
したがって、リソースにタグ付けされた証明[RPKI-RTA]や署名されたチェックリスト[RPKI-RSC]などのスキームは、CAから関連するキーを抽出するために非常に長く進む必要があります。
For some particular INR, say, Bill's Bait and Sushi's Autonomous System (AS) number, someone out on the net probably has the credentials to the CA account in which BB&S's INRs are registered. That could be the owner of BB&S, Randy's Taco Stand, an IT vendor, or the Government of Elbonia. One simply can not know.
たとえば、ビルの餌と寿司の自律システム（AS）番号など、いくつかの特定のINRの場合、ネット上の誰かがおそらくBB＆SのINRが登録されているCAアカウントの資格情報を持っています。それは、BB＆S、ランディのタコススタンド、ITベンダー、またはエルボニア政府の所有者である可能性があります。単に知ることができません。
In large organizations, INR management is often compartmentalized with no authority over anything beyond dealing with INR registration. The INR manager for Bill's Bait and Sushi is unlikely to be authorized to conduct bank transactions for BB&S, or even to authorize access to BB&S's servers in some colocation facility.
大規模な組織では、INR管理は多くの場合、INR登録に対処する以上の権限を持たずに区画化されています。Bill's BaitとSushiのINRマネージャーは、BB＆Sの銀行取引を実施したり、いくつかのコロケーション施設でBB＆Sのサーバーへのアクセスを許可することを許可される可能性は低いです。
Then there is the temporal issue. The holder of that AS may be BB&S today when some document was signed, and could be the Government of Elbonia tomorrow. Or the resource could have been administratively moved from one CA to another, likely requiring a change of keys. If so, how does one determine if the signature on the real-world document is still valid?
次に、一時的な問題があります。今日のBB＆Sの保持者は、いくつかの文書が署名されたときに、明日エルボニア政府になる可能性があります。または、リソースをあるCAから別のCAに管理上移動した可能性があり、おそらくキーの変更が必要です。もしそうなら、実際のドキュメントの署名がまだ有効かどうかをどのように判断しますか？
While Ghostbuster Records [RFC6493] may seem to identify real-world entities, their semantic content is completely arbitrary and does not attest to holding of any INRs. They are merely clues for operational support contact in case of technical RPKI problems.
Ghostbuster Records [RFC6493]は実際のエンティティを特定しているように見えるかもしれませんが、セマンティックコンテンツは完全にarbitrary意的であり、INRの保持を証明していません。それらは、技術的なRPKIの問題が発生した場合の運用サポート接触の単なる手がかりです。
Usually, before registering INRs, CAs require proof of an INR holding via external documentation and authorities. It is somewhat droll that the CPS Template [RFC7382] does not mention any diligence the CA must, or even might, conduct to assure the INRs are in fact owned by a registrant.
通常、INRSを登録する前に、CASは外部文書と当局を介したINR保持の証明を必要とします。CPSテンプレート[RFC7382]が、CAが実際に登録者が所有するINRが所有されていることを保証するためにCAが必要とする勤勉ささえ言及していないことを幾分ドロールしています。
That someone can provide 'proof of possession' of the private key signing over a particular INR should not be taken to imply that they are a valid legal representative of the organization in possession of that INR. They could be in an INR administrative role, and not be a formal representative of the organization.
誰かが特定のINRに署名する秘密鍵の「所有証明」を提供できることは、彼らがそのINRを所有する組織の有効な法定代理人であることを暗示するべきではありません。彼らはINR管理の役割にある可能性があり、組織の正式な代表者ではありません。
Autonomous System Numbers do not identify real-world entities. They are identifiers some network operators 'own' and are only used for loop detection in routing. They have no inherent semantics other than uniqueness.
自律システム番号は、実際のエンティティを識別しません。それらは、いくつかのネットワークオペレーターの独自の識別子であり、ルーティングでのループ検出にのみ使用されます。彼らは一意性以外の固有のセマンティクスを持っていません。
Attempts to use RPKI data to authenticate real-world documents or other artifacts requiring identity, while possibly cryptographically valid within the RPKI, are misleading as to any authenticity.
RPKIデータを使用して、RPKI内で暗号化的に有効なものであるが、アイデンティティを必要とする実世界のドキュメントまたはその他のアーティファクトを認証しようとする試みは、あらゆる信頼性について誤解を招くものです。
When a document is signed with the private key associated with an RPKI certificate, the signer is speaking for the INRs (the IP address space and AS numbers) in the certificate. This is not an identity; this is an authorization. In schemes such as Resource Tagged Attestations [RPKI-RTA] and Signed Checklists [RPKI-RSC], the signed message further narrows this scope of INRs. The INRs in the message are a subset of the INRs in the certificate. If the signature is valid, the message content comes from a party that is authorized to speak for that subset of INRs.
RPKI証明書に関連付けられた秘密鍵でドキュメントが署名されると、署名者は証明書のINRS（IPアドレススペースおよび数字）について話しています。これはアイデンティティではありません。これは許可です。リソースタグ付きの証明[RPKI-RTA]や署名されたチェックリスト[RPKI-RSC]などのスキームでは、署名されたメッセージがこのINRの範囲をさらに狭めます。メッセージのINRは、証明書のINRSのサブセットです。署名が有効な場合、メッセージコンテンツは、INRのサブセットについて話すことが許可された当事者からのものです。
Control of INRs for an entity could be used to falsely authorize transactions or documents for which the INR manager has no authority.
エンティティのINRの制御を使用して、INRマネージャーが権限を持たない取引または文書を誤って許可することができます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[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 Public Key Infrastructure Certificate and Certificate Recocation List（CRL）プロファイル"、RFC 5280、DOI 10.17487/RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[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>.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、DOI 10.17487/RFC6480、2012年2月、<https://www.rfc-editor.org/info/rfc6480>。
[RFC7382] Kent, S., Kong, D., and K. Seo, "Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)", BCP 173, RFC 7382, DOI 10.17487/RFC7382, April 2015, <https://www.rfc-editor.org/info/rfc7382>.
[RFC7382] Kent、S.、Kong、D。、およびK. Seo、「リソースPKI（RPKI）の認証慣行声明（CPS）のテンプレート」、BCP 173、RFC 7382、DOI 10.17487/RFC7382、2015年4月、<https://www.rfc-editor.org/info/rfc7382>。
[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>。
[RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, <https://www.rfc-editor.org/info/rfc8635>.
[RFC8635] Bush、R.、Turner、S。、およびK. Patel、「BGPSECのルーターキーイング」、RFC 8635、DOI 10.17487/RFC8635、2019年8月、<https://www.rfc-editor.org/info/rfc8635>。
[ASPA-PROFILE] Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., and R. Housley, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-profile-07, 31 January 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-07>.
[Aspa-Profile] Azimov、A.、Uskov、E.、Bush、R.、Patel、K.、Snijders、J。、およびR. Housley、「自律システムプロバイダー認証のプロファイル」、進行中の作業、インターネット-draft、Draft-iitf-sidrops-aspa-profile-07、2022年1月31日、<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-07>。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>.
[RFC3912] Daigle、L。、「Whois Protocol Specification」、RFC 3912、DOI 10.17487/RFC3912、2004年9月、<https://www.rfc-editor.org/info/rfc3912>。
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RFC6493] Bush、R。、「リソース公開キーインフラストラクチャ（RPKI）Ghostbusters Record」、RFC 6493、DOI 10.17487/RFC6493、2012年2月、<https://www.rfc-editor.org/info/rfc6493>。
[RPKI-RSC] Snijders, J., Harrison, T., and B. Maddison, "A profile for Resource Public Key Infrastructure (RPKI) Signed Checklists (RSC)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-rsc-08, 26 May 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-08>.
[RPKI-RSC] Snijders、J.、Harrison、T。、およびB. Maddison、「リソース公開キーインフラストラクチャ（RPKI）署名チェックリスト（RSC）のプロファイル」Sidrops-RPKI-RSC-08、2022年5月26日、<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-08>。
[RPKI-RTA] Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., and M. Hoffmann, "A profile for Resource Tagged Attestations (RTAs)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-rta-00, 21 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00>.
[RPKI-RTA] Michaelson、G.、Huston、G.、Harrison、T.、Bruijnzeels、T.、およびM. Hoffmann、「リソースタグ付き証明（RTA）のプロファイル」、進行中の作業、インターネットドラフト、ドラフト-ITETF-SIDROPS-RPKI-RTA-00、2021年1月21日、<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00>。
Acknowledgments
謝辞
The authors thank George Michaelson and Job Snijders for lively discussion, Geoff Huston for some more formal text, Ties de Kock for useful suggestions, many directorate and IESG reviewers, and last but not least, Biff for the loan of Bill's Bait and Sushi.
著者は、ジョージ・マイケルソンとジョブ・スナイダーズが活発な議論をしてくれたことに感謝します。
Authors' Addresses
著者のアドレス
Randy Bush Arrcus & Internet Initiative Japan Research 5147 Crystal Springs Bainbridge Island, WA 98110 United States of America Email: randy@psg.com
ランディブッシュアルカス＆インターネットイニシアチブジャパンリサーチ5147クリスタルスプリングスベインブリッジ島、ワシントン州アメリカ合衆国電子メール：randy@psg.com
Russ Housley Vigil Security, LLC 516 Dranesville Road Herndon, VA 20170 United States of America Email: housley@vigilsec.com
Russ Housley Vigil Security、LLC 516 Dranesville Road Herndon、バージニア州20170アメリカ合衆国電子メール：housley@vigilsec.com