📑

RFC 9582: 経路オリジン認可(ROA)のプロファイル

2024/05/26に公開

RFC

bgp

rpki

tech

要旨

本文書は、経路オリジン認可(ROA)の標準プロファイルを定義する。ROAは、IPアドレス・ブロックの保有者が自律システム(AS)に対して、アドレス・ブロック内の1つ以上のプレフィックスへの経路発信を認可していることを検証する手段を提供するデジタル署名されたオブジェクトである。本文書はRFC 6482を廃止する。

本文書の位置付け

本文書は、インターネット標準化過程の文書である。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 7841のセクション 2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9582 で入手できる。

著作権表示

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

リソース公開鍵基盤(RPKI)の主な目的は、ルーティングのセキュリティを向上させることである。(詳細は、[RFC6480]を参照のこと。) このシステムの一部として、自律システム(AS)がIPアドレス・ブロック保有者から、そのブロック内の1つ以上のプレフィックスへの経路を広告する認可を与えられたことを関係者が検証できるようにするメカニズムが必要である。経路オリジン認可(ROA)はこの機能を提供する。

ROAは、RPKIデジタル署名オブジェクトのテンプレート[RFC6488]を使用し、RPKI署名済みオブジェクトの一般的な検証手順と、ROAコンテンツの暗号メッセージ構文(CMS)ラッパー[RFC5652]を定義している。したがって、ROAの仕様([RFC6488]のセクション4参照)を完成させるために、本文書で以下を定義する:

署名済みオブジェクトがROAであることを識別するOID。(このOIDは、encapContentInfoオブジェクトのeContentType内、及びsignerInfoオブジェクトのcontent-type signed属性内に表示される。)
ROAのeContentのASN.1構文。(これは、経路の発信が許可されているASと、そのASが経路の発信先となるプレフィックスを指定するペイロードである。) ROAのeContentは、識別符号化規則(DER)[X.690]を使用して ASN.1で符号化される。
ROAを検証するには追加の手順が必要である([RFC6488]で規定されている検証手順に加えて)。

1.1.要件言語

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

1.2. RFC 6482 からの変更点

このセクションは、[RFC6482]と本文書に記載しているプロファイルとの間の重要な変更点を要約する。

IPアドレスとAS識別子のX.509証明書拡張の要件を明確にした。
ASN.1の正式な表記と定義を強化した。
RFC 6482の正誤表を組み込んだ。
ROAのeContentのペイロード例と完全なROA(付録A)を追加した。
ipAddrBlocksの内容の正規化手順を規定した。

2. 関連作業

読者は、「インターネットX.509公開鍵基盤証明書と証明書失効リスト(CRL)プロファイル」[RFC5280]及び「IPアドレスとAS識別子のX.509拡張」[RFC3779]に記載されている用語や概念に精通しているものとする。

さらに、本文書はRPKI署名済みオブジェクト・プロファイル[RFC6488]を利用する。したがって、本文書に精通していることが前提である。RPKI署名済みオブジェクト・プロファイルは、RPKIリソース証明書プロファイル[RFC6487]に準拠する証明書を使用することに留意する。したがって、このプロファイルに精通していることも前提となる。

3. ROAのコンテンツ・タイプ

ROAのcontent-typeはid-ct-routeOriginAuthzとして定義され、数値1.2.840.113549.1.9.16.1.24を持つ。

このOIDは、encapContentInfoオブジェクトのeContentTypeと、signerInfoオブジェクトのcontent-type signed属性の両方に存在しなければならない([RFC6488]を参照)。

4. ROAのeContent

ROAの内容は、経路発信をアドレス空間保有者によって認可された1つのASと、広告される1つ以上のIPアドレス・プレフィックスのリストを識別する。アドレス空間保有者が、複数のASに同じアドレス・プレフィックスを広告することを認可する必要がある場合、保有者はAS番号ごとに1つずつ、複数のROAを発行する。ROAは正式には次のように定義される:

RPKI-ROA-2023
  { iso(1) member-body(2) us(840) rsadsi(113549)
  pkcs(1) pkcs9(9) smime(16) mod(0)
  id-mod-rpkiROA-2023(75) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
  CONTENT-TYPE
  FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;

ct-routeOriginAttestation CONTENT-TYPE ::=
  { TYPE RouteOriginAttestation
    IDENTIFIED BY id-ct-routeOriginAuthz }

id-ct-routeOriginAuthz OBJECT IDENTIFIER ::=
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
    pkcs-9(9) id-smime(16) id-ct(1) routeOriginAuthz(24) }

RouteOriginAttestation ::= SEQUENCE {
  version [0]   INTEGER DEFAULT 0,
  asID          ASID,
  ipAddrBlocks  SEQUENCE (SIZE(1..2)) OF ROAIPAddressFamily }

ASID ::= INTEGER (0..4294967295)

ROAIPAddressFamily ::= SEQUENCE {
  addressFamily ADDRESS-FAMILY.&afi ({AddressFamilySet}),
  addresses     ADDRESS-FAMILY.&Addresses
                               ({AddressFamilySet}{@addressFamily}) }

ADDRESS-FAMILY ::= CLASS {
  &afi          OCTET STRING (SIZE(2)) UNIQUE,
  &Addresses
} WITH SYNTAX { AFI &afi ADDRESSES &Addresses }

AddressFamilySet ADDRESS-FAMILY ::=
  { addressFamilyIPv4 | addressFamilyIPv6 }

addressFamilyIPv4 ADDRESS-FAMILY ::=
  { AFI afi-IPv4 ADDRESSES ROAAddressesIPv4 }
addressFamilyIPv6 ADDRESS-FAMILY ::=
  { AFI afi-IPv6 ADDRESSES ROAAddressesIPv6 }

afi-IPv4 OCTET STRING ::= '0001'H
afi-IPv6 OCTET STRING ::= '0002'H

ROAAddressesIPv4 ::= SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress{ub-IPv4}
ROAAddressesIPv6 ::= SEQUENCE (SIZE(1..MAX)) OF ROAIPAddress{ub-IPv6}

ub-IPv4 INTEGER ::= 32
ub-IPv6 INTEGER ::= 128

ROAIPAddress {INTEGER: ub} ::= SEQUENCE {
  address       BIT STRING (SIZE(0..ub)),
  maxLength     INTEGER (0..ub) OPTIONAL }

END

4.1.バージョン要素

RouteOriginAttestationエントリのバージョン番号は0でなければならない。

4.2. asID要素

asID要素は、指定されたIPアドレス・プレフィックスへの経路発信を認可されているAS番号を含む。

4.3. ipAddrBlocks要素

ipAddrBlocks要素は、ASが経路の発信を認可されているIPアドレス・プレフィックスを符号化する。ここでの構文は、[RFC3779]で定義されているIPアドレス委任拡張で使用されている構文よりも制限が厳しいことに留意する。この拡張は任意のアドレス範囲を表すことができるが、ROAはIPプレフィックスのみを表す必要がある。

4.3.1.タイプROAIPAddressFamily

ROAIPAddressFamily構造内のaddressFamily要素には、IPアドレス・ファミリーのアドレス・ファミリー識別子(AFI)が含まれる。本仕様ではIPv4とIPv6のみをサポートするため、addressFamilyは0001または0002でなければならない。IPv4プレフィックスは、IPv4にマップされたIPv6アドレスとして現れてはならない(MUST NOT)([RFC4291]のセクション2.5.5.2 )。

ROAIPAddressFamily のインスタンスは、ROA内の一意のAFIごとに1つだけ存在しなければならない(MUST)。したがって、ROAIPAddressFamily構造は2 回以上出現してはならない(MUST NOT)。

アドレス・フィールドは、ROAIPAddressタイプのシーケンスとしてIPプレフィックスを含む。

4.3.2.タイプ ROAIPAddress

ROAIPAddress構造体は、BIT STRING型のaddress要素と、オプションでINTEGER 型のmaxLength要素を含むシーケンスである。

4.3.2.1. address要素

address要素はBIT STRING型で、1つのIPアドレス・プレフィックスを表す。このフィールドは、[RFC3779]のセクション2.2.3.8で定義されているIPAddressタイプと同じBIT STRINGとしてのIPアドレス・プレフィックスの表現を使用する。

4.3.2.2. maxLength要素

maxLength要素が存在する場合、ASが広告することを認可されているIPアドレス・プレフィックスの最大長を指定する。最大長がプレフィックス長と等しい場合、maxLength要素は符号化すべきではない(SHOULD NOT)。認証局は、将来のリライング・パーティーが、余分なmaxLength要素の存在を符号化エラーとみなす点で、ますます厳しくなることを予期すべきである(SHOULD)。

maxLength要素が存在する場合、次のようにしなければならない(MUST):

付随するプレフィックスの長さ以上の整数、及び
該当するアドレス・ファミリーのIPアドレスの最大長(ビット単位)以下である: IPv4の場合は32、IPv6の場合は128。

例えば、IPアドレス・プレフィックスが203.0.113.0/24でmaxLengthが26の場合、ASは最大長26のMore Specificプレフィックスを広告することが認可される。この例では、ASは203.0.113.0/24、203.0.113.128/25、または 203.0.113.192/26を広告することが認可されるが、203.0.113.0/27は認可されない。maxLengthの使用の詳細については、[RFC9319]を参照のこと。

maxLength要素が存在しない場合、ASはROAIPAddress構造体のaddress要素で指定された正確なプレフィックスのみを広告することが認可される。

4.3.2.3. 重複または余分な情報の符号化に関する注記

有効なROAには、別のIPアドレス・プレフィックス(別のROAIPAddress要素内)に包含されるIPアドレス・プレフィックス(ROAIPAddress要素内)が含まれる場合があることに留意する。例えば、ROAには、maxLength 26のプレフィックス203.0.113.0/24と、maxLength 28のプレフィックス203.0.113.0/28を含めることができる。このROAは、特定のプレフィックス203.0.113.0/28と同様に、最小長24、最大長26の203.0.113で始まるプレフィックスを広告することを、指定するASに認可する。

さらに、ROAには2つのROAIPAddress要素が含めてもよく(MAY)、どちらの場合でもIPアドレス・プレフィックスは同一である。しかし、このような場合、より短いmaxLengthを持つ ROAIPAddress要素は、指定するASに追加の権限を付与しないため、ROAの意味を変えることなく省略できるため、これは推奨されない(NOT RECOMMENDED)。

4.3.3. ipAddrBlocksの正規形式

ROAのASN.1モジュールによって記述されるデータ構造は、同じIPアドレス情報をさまざまな方法で表現できるため、IPアドレス情報のすべてが一意の表現を持つように標準形式を定義する。この正規形式を生成し、検証するには、このセクションで説明するプロセスを使用して、情報要素が互いに一意であり、昇順にソートされていることを確認する必要がある(SHOULD)。認証局は、将来のリライング・パーティーがipAddrBlocksフィールドがこの正規形式であることを厳格な要件を課すことを予期する必要がある(SHOULD)。この正規化手順は、[RFC3779]のセクション2.2.3.6で規定されている正規化手順に基づいている。

ipAddrBlocksフィールドの内容を意味的に比較、並べ替え、重複排除するために、各 ROAIPAddress要素は4つの整数値で構成される抽象データ要素にマッピングする:

内容	説明
afi	ROAIPAddressFamilyのaddressFamilyフィールドに現れるAFI値を整数で示す。
addr	ROAIPAddressアドレス・フィールドに現れるIPプレフィックスの最初のIPアドレス。32ビット(IPv4)または128ビット(IPv6)の整数値で示す。
plen	ROAIPAddressアドレス・フィールドに現れるIPプレフィックスの長さを整数値で示す。
men	ROAIPAddress要素のmaxLengthフィールドが存在する場合、現れる値。それ以外の場合、上記のプレフィックス長の値。

したがって、2つのROAIPAddress要素の等価性または相対的な順序は、それらの抽象表現を比較することにでテストできる。

4.3.3.1. コンパレータ

ipAddrBlockセットは完全に順序付けされている。2つのipAddrBlockの順序は、以下のリストの最初の不等価比較によって決定される。

低いafi値を持つデータ要素は、高いafi値を持つデータ要素に先行する。
低いaddr値を持つデータ要素は、高いaddr値を持つデータ要素に先行する。
低いplen値を持つデータ要素は、高いplen値を持つデータ要素に先行する。
低いmlen値を持つデータ要素は、高いmlen値を持つデータ要素に先行する。

4つの値がすべて等しいデータ要素は、互いに重複している。

4.3.3.2.実装例

ISO/IEC 9899:1999 (「ANSI C99」)のソート実装[roasort-c]。
Rust 2021 Editionのソート実装[roasort-rs]。

5. ROAの検証

リライング・パーティーは、ROAを使用してルーティング・アナウンスを検証する前に、まずROAを検証しなければならない(MUST)。ROAを検証するには、リライング・パーティーは[RFC6488]で規定されているすべての検証チェックと、以下の追加のROA固有の検証手順を実行しなければならない(MUST):

IPアドレス委任拡張[RFC3779]は、エンドエンティティ(EE)証明書(ROAに含まれる)に存在し、ROAペイロード内のすべてのIPアドレス・プレフィックスは、EE証明書のIPアドレス委任拡張によって指定されるIPアドレスのセットに含まれる。
EE証明書のIPアドレス委任拡張は、[RFC3779]に記載されている「inherit」要素を含んではならない(MUST NOT)。
[RFC3779]に記載されている自律システム識別子委任拡張は、ROAでは使用されず、EE証明書に存在してはならない(MUST NOT)。
ROAの内容は、セクション3及び4で規定されるすべての要件に完全に準拠している。

上記のチェックのいずれかが失敗した場合、ROA全体が無効とみなされなければならず (MUST)、エラーが記録する必要がある(SHOULD)。

6. セキュリティに関する考慮事項

ROAのデータの機密性の前提はない。ROAは、すべてのISP、そしておそらくすべてのインターネット・ユーザがアクセスできるリポジトリに保存されることが予想される。ROAの検証に使用されるPKIは認可を提供するが、認証は提供しないため、ROAに関連する明示的な認証はない。ROAは署名されたアプリケーション層のオブジェクトだが、ROAを介して否認防止を伝える意図はない。

ROAの目的は、ASがROAに含まれるプレフィックスまたはプレフィックスへの経路を発信する認可を伝えることである。したがって、ROAの完全性を確立しなければならない(MUST)。このROA仕様は、RPKI署名済みオブジェクト形式が使用する。したがって、[RFC6488]で議論されているセキュリティに関する考慮事項は、ROAにも適用される。さらに、署名済みオブジェクト・プロファイルは、完全性を保つためにCMS署名済みメッセージ形式を使用する。したがって、ROAはそのデータ構造に関連付けられたすべてのセキュリティ上の考慮事項を継承する。

ROAの署名者が、ターゲットASにプレフィックスへの経路を発信することを認可する権利は、[RFC6480]に記載されているように、アドレス空間とAS番号のPKIを使用することで確立する。具体的には、このPKIに基づいて発行された X.509証明書を使用してROAの署名を検証し、ROAのプレフィックスが証明書のIPアドレス委任拡張の中に含まれていることを確認しなければならない(MUST)。

7. IANA に関する考慮事項

7.1. S/MIME CMSコンテンツタイプのSMIセキュリティ(1.2.840.113549.1.9.16.1)

IANAは、「SMI Security for S⁠/MIME CMS Content Type (1.2.840.113549.1.9.16.1)」レジストリのid-ct-routeOriginAuthzエントリを以下のように更新した:

10進数	説明	出典
24	id-ct-routeOriginAuthz	RFC 9582

表1

7.2. RPKI署名済みオブジェクトレジストリ

IANAは、[RFC6488]によって作成された「RPKI Signed Objects」レジストリの Route Origination Authorizationエントリを以下のように更新した。

名前	OID	出典
経路発信の認可	1.2.840.113549.1.9.16.1.24	RFC 9582

表2

7.3.ファイル拡張子

IANAは、[RFC6481]によって作成された「RPKI Repository Name Schemes」レジストリのROAファイル拡張子のエントリを以下のように更新した。

ファイル名の拡張子	RPKIオブジェクト	出典
.roa	経路発信の認可	RFC 9582

表3

7.4. S/MIMEモジュール識別子のSMI セキュリティ(1.2.840.113549.1.9.16.0)

「SMI Security for S⁠/MIME Module Identifier (1.2.840.113549.1.9.16.0)」レジストリに以下のエントリを割り当てた。

10進数	説明	出典
75	id-mod-rpkiROA-2023	RFC 9582

表4

7.5. メディアタイプ

IANAは、「Media Types」レジストリのメディアタイプapplication/rpki-roaを以下のように更新した:

項目	内容
型名	application
サブタイプ名	rpki-roa
必須パラメータ	N/A
オプションのパラメータ	N/A
エンコーディングに関する考慮事項	バイナリ
セキュリティに関する考慮事項	RPKI ROA(RFC 9582)を運ぶ。このメディアタイプにはアクティブなコンテンツを含まない。詳細は、RFC 9582のセクション6を参照のこと。
相互運用性に関する考慮事項	なし
公開仕様	RFC 9582
このメディアタイプを使用するアプリケーション	RPKI運営者
追加情報
コンテンツ	このメディアタイプは、[RFC6488]で定義されている署名済みオブジェクトであり、RFC 9582で定義されているプレフィックスとAS 識別子のリストのペイロードを含む。
マジックナンバー	なし
ファイル拡張子	`.roa`
Macintoshファイルタイプのコード	なし
詳細についての連絡先の担当者と電子メール・アドレス	Job Snijders <job@fastly.com>
使用目的	COMMON
使用上の制限	なし
コントローラの変更	IETF

8.参考文献

8.1.引用規格

[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>.

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/info/rfc3779>.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[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>.

[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>.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.

[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>.

[X.690] ITU-T, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, February 2021.

8.2. 参考規格

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.

[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>.

[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>.

[RFC9319] Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B. Maddison, "The Use of maxLength in the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 9319, DOI 10.17487/RFC9319, October 2022, <https://www.rfc-editor.org/info/rfc9319>.

[roasort-c] Snijders, J., "ROA sorter in C", commit 68969ea, July 2023, <https://github.com/job/roasort>.

[roasort-rs] Maddison, B., "ROA sorter in Rust", commit 023e756, August 2023, <https://github.com/benmaddison/roasort>.

付録 A. ROA eContent ペイロードの例

DERで符号化されたROA eContentの例を以下に示す。「#」文字の後に注釈が続く。

$ echo 16i 301802030100003011300F040200023009300703050020010DB8 P \
  | dc | openssl asn1parse -inform DER -i -dump
 0:d=0  hl=2 l=  24 cons: SEQUENCE           # RouteOriginAttestation
 2:d=1  hl=2 l=   3 prim:  INTEGER  :010000  #  asID 65536
 7:d=1  hl=2 l=  17 cons:  SEQUENCE          #  ipAddrBlocks
 9:d=2  hl=2 l=  15 cons:   SEQUENCE         #   ROAIPAddressFamily
11:d=3  hl=2 l=   2 prim:    OCTET STRING    #    addressFamily
   0000 - 00 02                              #     IPv6
15:d=3  hl=2 l=   9 cons:    SEQUENCE        #    addresses
17:d=4  hl=2 l=   7 cons:     SEQUENCE       #     ROAIPAddress
19:d=5  hl=2 l=   5 prim:      BIT STRING    #      2001:db8::/32
    0000 - 00 20 01 0d b8

以下は、[RFC4648]に従ってBase64符号化された完全なRPKI ROA署名済みオブジェクトである。

MIIGgAYJKoZIhvcNAQcCoIIGcTCCBm0CAQMxDTALBglghkgBZQMEAgEwKwYLKoZI
hvcNAQkQARigHAQaMBgCAwEAADARMA8EAgACMAkwBwMFACABDbigggR8MIIEeDCC
A2CgAwIBAgIBAzANBgkqhkiG9w0BAQsFADAvMS0wKwYDVQQDEyQ4NjUyNWNkNS00
NGQ3LTRkZjktODA3OS00YTlkY2RmMjY5NDQwHhcNMjQwNTAxMDAzNDEzWhcNMjUw
NTAxMDAzNDEzWjAvMS0wKwYDVQQDEyRlYjg3NmJmMC1lYTlkLTRiMjItYTExZS0y
YmNhZDA4MzliMTMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsPSYD
JnGOFRSHUZuVxibx2TQfWWoPIHNKgQAwYn1Kz88HaGgVf63G1mJd/cxBNMj5AfNQ
m2zKSAb83UAp97DUXf+lvoKj4F+lxCCjFaBpBeehc7X0XPDpbcbqo1YrzIzxxqou
GijEwZ4k+BaM2avEFYMBszqWA+ZdneBSuZ3YbHPKp2royn4pJ9a1I5fYdqFQi0eo
VZbAc8pZmwRVOuedYYqQiy9CSRGsbiGlB0fKt2m/zSsuvl4Zit7+NyGL3wAZecjZ
XEInsTtQsjQuy5PeJjLDyfWi/ZFi0qPsNlK0M2lMsi5B7QKaagA1RbRVHZyrkWoe
20l5rfk1bIGMv/plAgMBAAGjggGdMIIBmTAOBgNVHQ8BAf8EBAMCB4AwHQYDVR0O
BBYEFN4UWxk/syCyWnRDVSmMi/fCUj0iMB8GA1UdIwQYMBaAFNZyCOpHDp1t1mVA
IvVTrcE4mrQ0MBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIwWgYIKwYBBQUHAQEE
TjBMMEoGCCsGAQUFBzAChj5yc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwby8x
bklJNmtjT25XM1daVUFpOVZPdHdUaWF0RFNnLmNlcjBRBgNVHR8ESjBIMEagRKBC
hkByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwby9BLzFuSUk2a2NPblczV1pV
QWk5Vk90d1RpYXREU2cuY3JsMFwGCCsGAQUFBwELBFAwTjBMBggrBgEFBQcwC4ZA
cnN5bmM6Ly9ycGtpLmV4YW1wbGUubmV0L3JlcG8vQS8zaFJiR1QteklMSmFkRU5W
S1l5TDk4SlNQU0tnLnJvYTAgBggrBgEFBQcBBwEB/wQRMA8wDQQCAAIwBwMFACAB
DbgwDQYJKoZIhvcNAQELBQADggEBAKFoMax1Gdxb9mvSfKE2Jo+DudqCGjWF3mGv
rkhag8CQYi2CBJZLrkpCRha8doBW4PbrL36waWG55A/TdLKvWzAf66/v3iL5QcXo
Krb0+fp1pu/YVK4xFxwYJhbX4OnL4Gqh9+t4fFXhEDj2QemlgjWZyxvgx2Sra/iK
fOt6gxUhie3oIT+FiYjqF//WIUBP/HjTf+E4IRGN8tCr3NDhMZG6c0njq2keW7w4
wnw1+GqSyDhqu0Rsr0m3XUbivkc+h0ZZBBS9SxPM+GfgdzEDV51VcK1SeMa3G3Ca
j0cJA99eTM+j52tkNVupftv1Y+4Wt0XGLKmRNKw26XDaphzw3B8xggGqMIIBpgIB
A4AU3hRbGT+zILJadENVKYyL98JSPSIwCwYJYIZIAWUDBAIBoGswGgYJKoZIhvcN
AQkDMQ0GCyqGSIb3DQEJEAEYMBwGCSqGSIb3DQEJBTEPFw0yNDA1MDEwMDM0MTNa
MC8GCSqGSIb3DQEJBDEiBCBlz4HExs5A69pxkJqTCbUvc2iTS7C4eDd3aJD4hYJS
wjANBgkqhkiG9w0BAQEFAASCAQBa2wmuDHbcvfnMRIaOJ6m30zpCZtJVBLDELoA0
2kLb18TfFbxQhUi/jZ9g0hNYksV0n4vOJnCQ3qP6IIfm0ZsKzRnyzZf3f2xegw2p
Wzi9Z8QYlc//eY3+XA3bQ37h+s0r7OZkQH7+KmIwDOCYaLh/YB37wp/7giC7bpvi
c2Fv2illQmctrK7tYDHsNGq+svULTjemUaklqfcRAAJnQTRzTz8So9wKY9SR2VVZ
68DDItTBUx8jPYeNQtvxxoVA6HuW9wyurlYQ9m/cF8CzlizVmsHgxzjO9ifmYJj9
YZWMLtjF7Xw1fQZLYMrD5DCZzUw3nv4GyyHxckm2kLF38mze

この付録のオブジェクトは以下のプロパティを持つ:

Object size: 1668 octets
Object SHA256 message digest:
     3a39e0b652e79ddf6efdd178ad5e3b29e0121b1e593b89f1e0ac18f3ba60d5e7

CMS signing time: Wed 01 May 2024 00:34:13 +0000

X.509 end-entity certificate
Subject key id: DE145B193FB320B25A744355298C8BF7C2523D22
Authority key id: D67208EA470E9D6DD6654022F553ADC1389AB434
Issuer: CN=86525cd5-44d7-4df9-8079-4a9dcdf26944
Serial: 3
Not before: Wed 01 May 2024 00:34:13 +0000
Not after: Thu 01 May 2025 00:34:13 +0000
IP address delegation: 2001:db8::/32

ROA eContent
asID: 65536
addresses: 2001:db8::/32

謝辞

著者らは、テオ・ビューラー、タイ・デ・コック、マーティン・ホフマン、チャールズ・ガーディナー、ラス・ハウズリー、ジェフリー・ハース、ボブ・ベック、トム・ハリソンの協力と貢献に感謝する。さらに、ジム・フェントン、ヴィジャイ・グルバニ、ハオユー・ソン、ロブ・オーステイン、ロケ・ガリアーノ、ダニー・マクファーソン、サム・ワイラー、ジャスディップ・シン、マレー・S・クシェラウィの丁寧なレビューと有益なコメントに感謝する。

著者のアドレス

ジョブ・スナイデルス
Fastly
アムステルダム
オランダ
メール: job@fastly.com

ベン・マディソン
Workonline
ケープタウン
南アフリカ
メール: benm@workonline.africa

マシュー・レピンスキー
カールトン大学
メール: mlepinski@carleton.edu

デリック・コング
Raytheon
メール: derrick.kong@raytheon.com

スティーブン・ケント
Independent
メール: kent@alum.mit.edu

更新履歴

2024.5.26

GitHubで編集を提案

要旨