RFC 8360: リソース公開鍵基盤(RPKI)検証の再考
要旨
本文書は、RFC 6487が規定している証明書検証手順の代替案を規定するもので、必要不可欠なセキュリティ機能を維持しつつ、リソース公開鍵基盤(RPKI)の証明書管理における運用上のフラジリティを軽減するものである。
RFC 6487が規定している手順では、発行元証明書に含まれないリソースを過大申告(オーバークレーム)していることが判明した場合、リソース証明書全体を却下することを要求している。一方、ここで定義している検証プロセスでは、発行元認証局(CA)はリソースと発行証明書が交差する場合、そのリソース証明書の受け入れを伝えることができる。
ここで定義する検証プロセスでは、単一のトラストアンカー(TA)下での検証のみを考慮していることに留意する必要がある。特に、複数のTAが設定された重複するリソースを申告する場合の過大申告に関する懸念は、本文書の範囲外と見なす。
この選択は、「IPアドレスとAS識別子のX.509拡張」(RFC 3779)及び「リソース公開鍵基盤(RPKI)の証明書ポリシー(CP)」(RFC 6484)に基づく、一連の代替オブジェクト識別子(OID)によって通知する。これらのOIDがトラストアンカーの下でどの証明書にも使用されない場合、ここで定義された検証手順はRFC 6487で定義された手順と同じ結果になることに留意する必要がある。
さらに、本文書は、経路オリジン認可(ROA)(RFC 6482)およびBGPsecルータ証明書(BGPsec PKIプロファイル -- 公開要求)の検証の代替手段を提供する。
⚠️ RFC 8360について
RFC 8360が策定された理由は、要旨/概要にもあるように、証明書と下位証明書プロダクト間に不整合があった場合、その下位証明書のツリー全体を無効にするというRFC 6487の規定だった。そこで、RFC 8360はRPKI証明書とその下位プロダクトのリソースセット間の不一致に寛容なRPKI検証スキームの変更点を提案した。しかし、当時、IETFのX.509フォークが下した指示は、このような証明書の検証アルゴリズムを変更するには、RPKI証明書のオブジェクト識別子(OID)値を変更する必要があるというものだった。クライアントが使用したい検証方法を決定できないことは、X.509証明書使用の「適切な範囲」から外れていると考えられた(同じクライアントが、検証のために独自のトラストアンカーを自由に選択できるにもかかわらず)。あるアルゴリズムから別のアルゴリズムに移行する間、2つのRPKI証明書階層を並行して運用するという暗黙の要件は、一般にナンセンスと考えられ、変更した検証アルゴリズムの概念全体はお蔵入りになった。
ジョブ・スナイデルスとベン・マディソンは、RFC 8360アルゴリズムの復活を望んでいる。彼らが提案する今後の方向性は、RFC 8360のOID割り当てを非推奨とし、代わりにRFC 6482とRFC 6487を改訂した検証アルゴリズムで更新することである。つまり、検証アルゴリズムの定義の標準プロファイルを変更し、RPKI証明書のOID値を一定に保つやり方である。現在、IETF SIDROPSで議論が進められている(<https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-validation-update/>)。
参考:
<https://ripe88.ripe.net/presentations/66-RIPE88_validation_re_reconsidered_Snijders.pdf>
本文書の位置付け
本文書はインターネット標準化過程の文書である。
本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。
文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、<http://www.rfc-editor.org/info/rfc8360>で入手できる。
著作権表示
Copyright (c) 2018 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。
本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(<https://trustee.ietf.org/license-info>)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。
1. 概要
本文書は、RFC 6487で規定されている証明書検証手順の代替案を規定する。RFC 6487で規定されている手順では、発行証明書に含まれないリソースを過大申告していることが判明した場合、リソース証明書を完全に拒否することが求められるが、本文書で定義された手順では、リソース証明書は、そのリソースと発行証明書の交差部分に対してのみ受理される。
過大申告が発生しない限り、両手順の結果は同じである。さらに、新しい手順では、証明書発行のパス上で、有効に保持されていないリソースが受理されることはない。
しかし、ここで定義される手順は、これらのリソースのみを参照する経路オリジン認可[RFC6482]など、これらのリソースのみを参照する証明書発行パスにおいて、リソースが有効に保持されなくなった場合の影響を限定する。
1.1. 要件表記
この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。
2. RPKIにおける証明書の検証
現在、[RFC6487]のセクション7.2で定義されているように、RPKIプロファイルに準拠するPKIX証明書の検証は、検証パスの各証明書が証明書検証基準を満たすことが要求されるパス検証プロセスの使用に依存している。
これらの基準は、特に、検証パスの各証明書のインターネット番号リソース(INR)が、発行する証明書のINRに「包含される(encompassed)」ことを要求する。パスの最初の証明書はトラストアンカーであることが求められ、そのリソースは定義上有効と見なされる。
例えば、以下のような順序である。
証明書1 (トラストアンカー)
発行者TA,
サブジェクトTA,
リソース 192.0.2.0/24, 198.51.100.0/24,
2001:db8/32, AS64496-AS64500
証明書2:
発行者TA,
サブジェクトCA1,
リソース 192.0.2.0/24, 198.51.100.0/24, 2001:db8/32
証明書3:
発行者CA1,
サブジェクトCA2,
リソース 192.0.2.0/24, 198.51.100.0/24, 2001:db8/32
ROA 1:
組み込み証明書4 (EE証明書):
発行者CA2,
サブジェクトR1,
リソース 192.0.2.0/24
プレフィックス 192.0.2.0/24, Max Length 24, ASN 64496
各証明書のINRは、発行する証明書のINRに包含されるため、本シナリオのすべての証明書は有効とみなされる。ROA 1は、[RFC6482]が要求するとおり、指定されたプレフィックスが組み込みエンド・エンティティ(EE)証明書に包含されるため、有効である。
3. 運用上の考慮事項
RPKIに記録される割り当ては、リソース移転の結果で変更される。例えば、移転に関与するCAは、一部の証明書が一時的に「過大申告」となるような順序で、CA証明書変更を選択する可能性がある。証明書は、問題となっている証明書を発行したCAのINRに包含されないINRを含んでいる場合、その証明書は「過大申告」と言われる。
⚠️ 過大申告について
また、親CAによってリソースの移転または再申告が行われる際に、子CAが縮小したリソース証明書を自発的に要求しないこともある。さらに、RPKIデータベースの管理中に発生する操作上のエラーによって、一時的に下位証明書のINRをすべて包含しないCA証明書が作成されることもある。
次のシーケンスを考えるてみる:
証明書1(トラストアンカー):
発行者TA,
サブジェクトTA,
リソース 192.0.2.0/24, 198.51.100.0/24, 2001:db8/32, AS64496-AS64500
証明書2:
発行者TA,
サブジェクトCA1,
リソース 192.0.2.0/24, 2001:db8/32
証明書3 (無効):
発行者CA1,
サブジェクトCA2,
リソース 192.0.2.0/24, 198.51.100.0/24, 2001:db8/32
ROA 1 (無効):
組み込み証明書4 (EE証明書, 無効):
発行者CA2,
サブジェクトR1,
リソース 192.0.2.0/24
プレフィックス 192.0.2.0/24, Max Length 24, ASN 64496
ここで、前の例の証明書2がTAによってCA1に再発行され、その際、プレフィックス198.51.100.0/24が削除されている。しかも、CA1はCA2に対する新しい証明書3を再発行に失敗する。その結果、証明書3は過大申告となり、無効とみなされる。再帰により、ROA1に使用する組み込み証明書4も無効となる。また、ROA1は、[RFC6482]が要求しているように、ROAに含まれる指定されたプレフィックスが有効な組み込みEE証明書に包含されなくなったため、無効である。
ただし、ROA1はCA1の証明書から削除されたアドレス・リソースを一切使用していないことに留意する必要がある。したがって、ROA 1が依然として有効であると見なすことができれば望ましい。技術的には、CA1は、198.51.100.0/24なしでCA2に証明書3を再発行すべきで、そうすれば、ROA1は[RFC6482]に従って有効になる。しかし、CA1がこのアクションを取らない限り、ROA1は無効のままである。ROA1が有効であるとみなされることが望ましい。なぜなら、ROA1が行うアサーションは、CA1の証明書のスコープ縮小の影響を受けないからである。
4. 修正されたRPKI認証の検証プロセス
4.1. 検証済みのリソースセット
上記の問題は、現在では確率が低い問題と考えられる。しかし、RPKI階層の頂点付近で過大申告が発生した場合、このポイントより下にあるサブツリー全体が無効になってしまうため、ルーティング・セキュリティに与える潜在的な影響は大きい。
[RFC6487]の検証手順に対してここで指定される変更は、この問題の発生確率を変更するものではないが、影響を過大申告されたリソースだけに限定するものである。この改訂された検証アルゴリズムは、過大申告の結果としてCA証明書が完全に無効なものとして扱われるのを回避することを目的としている。ただし、これらの変更は、RPKIが提供するセキュリティを低下させないように設計されている。具体的には、ROA及びルータ証明書は、その中に含まれるすべてのリソースが、トラストアンカーへのパスに沿ったすべての上位証明書に包含されている場合に限り、有効なものとして扱われる。
これを概念的に実現する方法は、証明書内のリソース拡張[RFC3779]にあるINRとは別に、証明書ごとに検証済みリソースセット(VRS)を保持することである。
4.2. 既存規格との相違点
4.2.1. RPKIにおける再検証とともに使用する証明書ポリシー(CP)
[RFC6484]のセクション1.2では、以下のOIDを使用して「リソースPKI (RPKI)の証明書ポリシー(CP)」が定義されていることに留意する:
id-cp-ipAddr-asNumber OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) cp(14) 2 }
本文書に従って、代替の「リソースPKI (RPKI)で再考された検証とともに使用する証明書ポリシー(CP)」の新しいOIDは以下のように割り当てらる:
id-cp-ipAddr-asNumber-v2 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) cp(14) 3 }
この代替証明書ポリシーは、セクション4.2.4.4に記載されている検証手順のステップ8における判断を行うために使用される点を除き、[RFC6484]に記載される証明書ポリシーと同じである。
4.2.2. IPアドレスとAS識別子のためのX.509拡張(RFC 3779)の代替
本文書は、[RFC3779]の代替案を定義する。[RFC3779]に記述されているすべての仕様と手順が適用されるが、以下のサブセクションで説明する顕著な例外がある。
4.2.2.1. id-pe-ipAddrBlocks-v2のOID
本文書では、拡張子id-pe-ipAddrBlocks-v2 (id-pe 28)にOIDが割り当てられている。このOIDは、セクション4.2.1で定義する代替証明書ポリシーOIDとの組み合わせのみで使用しなければならない(MUST)。
以下は、[RFC3779]のセクション2.2.1の仕様の代替として使用するための修正された仕様である。
この拡張のOIDはid-pe-ipAddrBlocks-v2である。
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
ここで、[RFC5280]は以下のように定義している。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
4.2.2.2. id-pe-ipAddrBlocks-v2の構文
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & optional SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
上記の構文で参照するオブジェクトの記述は、[RFC3779]のセクション2.2.3.1から2.2.3.9で定義されていることに留意する。
4.2.2.3. id-pe-autonomousSysIds-v2のOID
本文書では、拡張子id-pe-autonomousSysIds-v2 (id-pe 29)にOIDが割り当てられている。このOIDは、セクション4.2.1に定義されている代替証明書ポリシーOIDとの組み合わせのみで使用しなければならない(MUST)。
以下は、[RFC3779]のセクション3.2.1の仕様の代替として使用するために修正された仕様である。
この拡張のOIDは id-pe-autonomousSysIds-v2である。
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
ここで、[RFC5280]は以下のように定義している。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-pe OBJECT IDENTIFIER ::= { id-pkix 1 }
4.2.2.4. id-pe-autonomousSysIds-v2の構文
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- inherit from issuer --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
4.2.2.5. 修正されたIPアドレス委任拡張認証パス検証
証明書パスの検証は、セクション4.2.4.4の規定に従って実行する。
4.2.2.6. 修正された自律システム識別子委任拡張認証パス検証
証明書パスの検証は、セクション4.2.4.4の規定に従って実行する。
4.2.2.7. 修正されたASN.1モジュール
本文書では、id-mod-ip-addr-and-as-ident-v2対して以下のようなOIDが割り当てられている。
IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-v2(90) }
以下は、[RFC3779]の付録Aの仕様の代替として使用する修正仕様である。
この規範となる付録は、準拠するPKIコンポーネントがASN.1構文で使用するIPアドレスおよびAS識別子の委任拡張について記述している。
IPAddrAndASCertExtn-v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-v2(90) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
-- PKIX specific OIDs and arcs --
id-pe FROM PKIX1Explicit88 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) }
-- IP Address Block and AS Identifiers Syntax --
IPAddrBlocks, ASIdentifiers FROM IPAddrAndASCertExtn { iso(1)
identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) mod(0) id-mod-ip-addr-and-as-ident(30) }
;
-- Validation Reconsidered IP Address Delegation Extension OID --
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
-- Validation Reconsidered IP Address Delegation Extension Syntax --
-- Syntax is imported from RFC 3779 --
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension OID --
id-pe-autonomousSysIds-v2 OBJECT IDENTIFIER ::= { id-pe 29 }
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension Syntax --
-- Syntax is imported from RFC 3779 --
END
4.2.3. RFC 6268への補遺
本文書では、id-mod-ip-addr-and-as-ident-2v2に対して以下のようなOIDが割り当てられている。
IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-2v2(91) }
[RFC6268]は、いくつかの補助的なASN.1モジュールをASN.1の2008年バージョンに準拠するように更新した情報RFCである。セクション4.2.2.7の1988年バージョンのASN.1モジュールは標準バージョンのままである。
以下は、セクション4.2.2.1と4.2.2.3で定義された拡張とともに使用する、ASN.1の2008年バージョンに準拠した追加モジュールである。
the extensions defined in Sections 4.2.2.1 and 4.2.2.3.
IPAddrAndASCertExtn-2010v2 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-2v2(91) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
EXPORTS ALL;
IMPORTS
-- PKIX specific OIDs and arcs --
id-pe
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51)}
EXTENSION
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57)}
-- IP Address Block and AS Identifiers Syntax --
IPAddrBlocks, ASIdentifiers
FROM IPAddrAndASCertExtn-2010
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) mod(0)
id-mod-ip-addr-and-as-ident-2(72) }
;
--
-- Extensions contain the set of extensions defined in this module
--
-- These are intended to be placed in public key certificates and thus should be added to the CertExtensions extension set in PKIXImplicit-2009 defined for RFC 5280
--
Extensions EXTENSION ::= {
ext-pe-ipAddrBlocks-v2 | ext-pe-autonomousSysIds-v2
}
-- Validation Reconsidered IP Address Delegation Extension OID --
ext-pe-ipAddrBlocks-v2 EXTENSION ::= {
SYNTAX IPAddrBlocks
IDENTIFIED BY id-pe-ipAddrBlocks-v2
}
id-pe-ipAddrBlocks-v2 OBJECT IDENTIFIER ::= { id-pe 28 }
-- Validation Reconsidered IP Address Delegation --
-- Extension Syntax --
-- Syntax is imported from RFC 6268 --
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension OID --
ext-pe-autonomousSysIds-v2 EXTENSION ::= {
SYNTAX ASIdentifiers
IDENTIFIED BY id-pe-autonomousSysIds-v2
}
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 29 }
-- Validation Reconsidered Autonomous System Identifier --
-- Delegation Extension Syntax --
-- Syntax is imported from RFC 6268 --
END
4.2.4. X.509 PKIXリソース証明書の代替プロファイル
本文書は、X.509 PKIXリソース証明書の代替プロファイルを定義する。このプロファイルは、以下の顕著な例外を除き、[RFC6487]に記載されているすべての定義と手順に従う。
4.2.4.1. 修正された証明書ポリシー
以下は、[RFC6487]のセクション4.8.9の代わりに、このプロファイルで使用するために修正された仕様である。
この拡張は必ず存在しなければならず(MUST)、重要(critical)とマークしなければならない(MUST)。セクション4.2.1の更新されたRPKI CPで規定されているように、id-cp-ipAddr-asNumber-v2タイプのポリシーを正確に1つだけ含まなければならない(MUST)。
4.2.4.2. 修正されたIPリソース
以下は、[RFC6487]のセクション4.8.10の代わりに、本プロファイルで使用する修正後の仕様である。
IPリソース拡張またはASリソース拡張のいずれか、あるいはその両方がすべてのRPKI証明書に存在しなければならず(MUST)、重要とマークしなければならない(MUST)。
この拡張には、セクション4.2.2.1に従って、IPアドレス・リソースのリストが含まれる。この値は、特定のアドレス・ファミリ識別子(AFI)値の「inherit」要素を指定することができる。パブリック・インターネットで使用する公開番号リソースを記述するリソース証明書の文脈では、Subsequent AFI (SAFI)値を使用してはならない(MUST NOT)。
この拡張は、空でないIPアドレス・レコードのセットを指定するか、「inherit」設定を使用して、この証明書のIPアドレス・リソース・セットが証明書の発行者のIPアドレス・リソース・セットから継承していることを示さなければならない(MUST)。
4.2.4.3. 修正されたASリソース
以下は、[RFC6487]のセクション4.8.11の代わりに、本プロファイルで使用される修正後の仕様である。
ASリソース拡張またはIPリソース拡張のいずれか、あるいはその両方が、すべてのRPKI証明書に存在しなければならず(MUST)、重要とマークしなければならない(MUST)。
この拡張には、セクション4.2.2.3に従ってAS番号リソースのリストを含めるか、「inherit」要素を指定することができる。ルーティング・ドメイン識別子(RDI)値は、本プロファイルではサポートされず、使用してはならない(MUST NOT)。
この拡張は、空でないAS番号レコード・セットを指定するか、「inherit」設定を使用して、この証明書のAS番号リソース・セットが証明書の発行者のAS番号リソース・セットから継承されていることを示さなければならない(MUST)。
4.2.4.4. 修正されたリソース証明書パス検証
以下は、[RFC6487]のセクション7.2の代わりに使用されるパス検証の修正仕様であり、[RFC6487]で定義されたプロファイルに従う証明書と、上記のプロファイルに従う証明書の両方を検証できるようにするものである。
以下のアルゴリズムは、CA及びEEリソース証明書を検証するために採用する。これは[RFC5280]のパス検証アルゴリズムに基づいてモデル化されているが、[RFC3779]のIPアドレス委任及びAS識別子委任拡張を利用するように修正している。
検証アルゴリズムには2つの入力がある:
- トラストアンカー
- 検証対象の証明書
アルゴリズムは、RPKIで使用する2つの新しい変数、Verified Resource Set-IP (VRS-IP)とVerified Resource Set-AS (VRS-AS)を使用して初期化する。これらのセットは、各CA証明書に対して有効とみなされるINR(IPアドレス空間とAS番号)セットを追跡するために使用する。VRS-IPセットとVRS-ASセットは、検証の実行に使用されるトラストアンカーのIPアドレス委任値とAS識別子委任値にそれぞれ初期設定する。
このパス検証アルゴリズムは、特に、予想される証明書パス(n個の証明書のシーケンス)が次の条件を満たすことを検証する。
ａ. 「1, ..., n-1」内のすべての「x」について、証明書「x」のサブジェクトが証明書の発行者(「x」 + 1)である。
b. 証明書「1」はトラストアンカーが発行する。
c. 証明書「n」は検証対象の証明書である。そして
d. 「1, ..., n」のすべての「x」について、証明書「x」は有効である。
証明書の検証では、[RFC5280]のセクション6で規定されている証明書パスの検証基準に加えて、以下の条件がすべて満たすことを検証する必要がある。
-
証明書x (x>1)の署名は、発行者の証明書(x-1)の公開鍵を使用し、その公開鍵(証明書x-1内)に指定された署名アルゴリズムを用いて検証する。
-
現在時刻は、証明書xのValidityフィールドのNotBefore値とNotAfter値で定義された範囲内にある。
-
証明書xのバージョン、発行者、Subjectフィールドは、RFC 6487のセクション4.1から4.7で確立された制約を満たす。
-
証明書xが[RFC6487]のセクション4.8.9で定義された証明書ポリシーを使用する場合、証明書には、[RFC6487]のセクション4.8で定義され、存在しなければならないすべての拡張を含まなければならない(MUST)。これらの各拡張の値は、それぞれのセクションで各拡張に確立された制約を満たさなければならない(MUST)。このように識別されない拡張は、証明書xに含めてはならない(MUST NOT)。
-
証明書xがセクション4.2.4.1で定義する証明書ポリシーを使用する場合、セクション4.8.9、4.8.10、4.8.11を除く、[RFC6487]のセクション4.8で定義されたすべての拡張が存在しなければならない(MUST)。証明書は、セクション4.2.4.2または4.2.4.3、またはその両方で定義される拡張が含まれていなければならない(MUST)。これらの各拡張の値は、それぞれのセクションで各拡張に対して確立された制約を満たさなければならない(MUST)。このように識別されない拡張は、証明書xに含めてはならない(MUST NOT)。
-
証明書xは、失効してはならない(MUST NOT)。つまり、証明書x-1で表されるCAが発行する証明書失効リスト(CRL)に載せてはならない。
-
以下に示すように、VRS-IPとVRS-ASの設定値を計算する:
-
証明書xにIPアドレス委任拡張が存在し、x=1の場合、VRS-IPをこの拡張に含まれるリソースを設定する。
-
証明書xにIPアドレス委任拡張が存在し、x>1の場合、VRS-IPをこの拡張と証明書x-1について計算されたVRS-IPの値との間のリソースの交点に設定する。
-
証明書xにIPアドレス委任拡張が存在しない場合、VRS-IPをNULLに設定する。
-
証明書xに
IPアドレス委任拡張が存在し、x=1の場合、VRS-IPをこの拡張に含まれるリソースを設定する。 -
証明書xにAS識別子委任拡張が存在し、x>1の場合、VRS-ASに、この拡張と証明書x-1について計算されたVRS-ASの値の間のリソースの交点に設定する。
-
証明書xにAS識別子委任拡張が存在しない場合、VRS-ASをNULLに設定する。
-
-
証明書xのVRS-IPとIPアドレス委任拡張、または証明書xのVRS-ASとAS識別子委任拡張のリソースに差異がある場合、以下のようになる:
- 証明書xがセクション4.2.4.1で定義された証明書ポリシーを使用している場合、証明書xのリソースの過大申告をリストした警告を発行する必要がある(SHOULD)。
- 証明書xが[RFC6487]のセクション4.8.9で定義されている証明書ポリシーを使用している場合、証明書xは拒否しなければならない(MUST)。
これらのルールにより、トラストアンカーからCA証明書までのパスにある(すべての)証明書に存在しないリソースをCA証明書に含めることができる。CA証明書内のリソースがパス上のすべての証明書に存在しない場合、下位証明書は有効ではない。ただし、これは一時的な状態である可能性があるため、証明書はすぐには拒否されない。関連するVRSセットは、問題の証明書に有効に関連付けられているリソースを正確に反映するため、証明書をすぐに拒否しなくてもセキュリティ上の問題は生じない。
4.2.5. 代替のROA検証
現在、[RFC6482]のセクション4には、ROA上のリソースの検証に関する次の文章が記載されている。
IPアドレス委任拡張 [RFC3779]はエンド・エンティティ(EE) 証明書 (ROA内に含まれる)に存在し、ROAに含まれる各IPアドレス・プレフィックスがEE証明書の IPアドレス委任拡張で指定されたIPアドレスの集合が含まれる。
エンド・エンティティ証明書がセクション4.2.4.1で定義された証明書ポリシーを使用する場合、代わりに以下のアプローチを使用しなければならない。
セクション4.2.4.2に記載される修正されたIPアドレス委任拡張が、(ROAに含まれる)エンド・エンティティ(EE)証明書に存在し、ROAに含まれる各IPアドレス・プレフィックスは、セクション4.2.4.4に記載されているEE証明書の検証結果として指定されるVRS-IPセットに含まれる。
これにより、ROAに含まれるすべてのIPアドレス・プレフィックスが、検証に使用されるトラストアンカーへのパスに沿ったすべての証明書のVRS-IPに含まれる場合にのみ、ROAが有効であることが保証されることに留意する。
事業者は、トラストアンカーへのパスに沿った証明書のVRS-IPから1つ以上のIPアドレス・プレフィックスが失われても、他のIPアドレス・プレフィックスに対する認証が無効にならないように、IPアドレス・プレフィックスごとに個別のROAを発行してもよい(MAY)。
4.2.6. BGPsecルータ証明書検証の代替手段
BGPsecルータ証明書[RFC8209]がセクション4.2.4.1で定義された証明書ポリシーを使用する場合、[RFC8209]のセクション3.3で定義されたBGPsecルータ証明書の検証に加えて、以下の制約を満たさなければならない(MUST)。
- BGPsecルータ証明書のVRS-ASは、ASリソース識別子委任拡張のすべての自律システム番号(ASN)を包含しなければならない(MUST)。
事業者は、トラストアンカーへのパスに沿った証明書のVRS-ASからASNを喪失しても、他のASNのルータ・キーが無効にならないように、異なるASNに対して個別のBGPsecルータ証明書を発行してもよい(MAY)。
5. 検証例
このセクションでは、セクション4.2.4.4、4.2.5、4.2.6で説明したアルゴリズムと手順を使用して実行されたRPKI検証結果を、以下の3つの展開シナリオで示す:
- 古いOIDのみを使用する証明書で構成されるRPKI ツリー
- 新しいOIDのみを使用する証明書で構成されるRPKI ツリー
- 古いOIDまたは新しいOIDのいずれかを使用する証明書の混在で構成されるRPKIツリー
この状況では、証明書が[RFC6484]のセクション1.2、[RFC3779]のセクション2.2.1、および/または[RFC3779]のセクション3.2.1に定義されるOIDの組み合わせを使用する場合、「古い」OID を使用する証明書と呼ぶ。セクション 4.2.4.1、4.2.2.1、および/またはセクション4.2.2.3で定義されるOIDの組み合わせを使用する証明書を、「新しい」OIDを使用する証明書と呼ぶ。
5.1. 例1 ─ 古いOIDのみを使用するRPKIツリー
次の例を考えてみる:
証明書 1 (トラストアンカー):
Issuer: TA,
Subject: TA,
OIDs: OLD,
Resources: 0/0, ::0, AS0-4294967295 (all resources)
Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
Warnings: none
証明書 2:
Issuer: TA,
Subject: CA1,
OIDs: OLD,
Resources: 192.0.2.0/24, 2001:db8::/32, AS64496
Verified Resource Set: 192.0.2.0/24,
2001:db8::/32, AS64496
Warnings: none
証明書 3 (無効):
Issuer: CA1,
Subject: CA2,
OIDs: OLD,
Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496
Verified Resource Set: 192.0.2.0/24, AS64496
証明書3は、リソースに198.51.100.0/24が含まれているため無効とみなされる。これは、検証済みリソース・セットに含まれていない。
ROA 1 (無効):
Embedded Certificate 4 (EE certificate invalid):
Issuer: CA2,
Subject: R1,
OIDs: OLD,
Resources: 192.0.2.0/24
Prefix 192.0.2.0/24, Max Length 24, ASN 64496
証明書3が無効であるため、ROA 1は無効とみなされる。
ROA 2 (無効):
Embedded Certificate 5 (EE certificate invalid):
Issuer: CA2,
Subject: R2,
OIDs: OLD,
Resources: 198.51.100.0/24
Prefix 198.51.100.0/24, Max Length 24, ASN 64496
証明書3が無効であるため、ROA 2は無効とみなされる。
BGPsec証明書1 (無効):
Issuer: CA2,
Subject: ROUTER-64496,
OIDs: NEW,
Resources: AS64496
証明書3が無効であるため、BGPsec証明書1は無効とみなされる。
BGPsec証明書2 (無効):
Issuer: CA2,
Subject: ALL-ROUTERS,
OIDs: NEW,
Resources: AS64496-AS64497
証明書3が無効であるため、BGPsec証明書2は無効とみなされる。
5.2. 例2 ─ 新しいOIDのみを使用したRPKIツリー
修正されたアプローチにおける以下の例を考えてみる:
証明書 1 (トラストアンカー):
Issuer: TA,
Subject: TA,
OIDs: NEW,
Resources: 0/0, ::0, AS0-4294967295 (all resources)
Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
Warnings: none
証明書 2:
Issuer: TA,
Subject: CA1,
OIDs: NEW,
Resources: 192.0.2.0/24, 2001:db8::/32, AS64496
Verified Resource Set: 192.0.2.0/24,
2001:db8::/32, AS64496
Warnings: none
証明書 3:
Issuer: CA1,
Subject: CA2,
OIDs: NEW,
Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496
Verified Resource Set: 192.0.2.0/24, AS64496
Warnings: overclaim for 198.51.100.0/24
ROA 1 (有効):
組み込み証明書 4 (EE証明書):
Issuer: CA2,
Subject: R1,
OIDs: NEW,
Resources: 192.0.2.0/24
Prefix 192.0.2.0/24, Max Length 24, ASN 64496
Verified Resource Set: 192.0.2.0/24
Warnings: none
ROA 1は、プレフィックスが埋め込みEE証明書の検証済みリソース・セットと一致するため、有効であるとみなされる。
ROA 2 (invalid):
組み込み証明書 5 (EE証明書 無効):
Issuer: CA2,
Subject: R2,
OIDs: NEW,
Resources: 198.51.100.0/24
Prefix 198.51.100.0/24, Max Length 24, ASN 64496
Verified Resource Set: none (empty set)
Warnings: 198.51.100.0/24
ROAプレフィックス198.51.100.0/24が検証済みリソース・セットに含まれていないため、ROA2は無効とみなされる。
BGPsec証明書1 (有効):
Issuer: CA2,
Subject: ROUTER-64496,
OIDs: NEW,
Resources: AS64496
Verified Resource Set: AS64496
Warnings: none
BGPsec証明書2 (無効):
Issuer: CA2,
Subject: ALL-ROUTERS,
OIDs: NEW,
Resources: AS64496-AS64497
Verified Resource Set: AS64496
BGPsec証明書2は、そのリソースの一部が検証済みリソース・セットに含まれていないため、無効である。
この問題は、AS番号ごとに個別の証明書を発行することで軽減できることに留意する。
5.3. 例3 ─ 新旧のOIDを混合して使用するRPKIツリー
以下の例では、発行CAが過大申告の発生を予期し、その影響を問題の過大申告されたリソースのみに限定したいCA証明書に対してのみ、新しいOIDを使用する:
証明書1 (trust anchor):
Issuer: TA,
Subject: TA,
OIDs: OLD,
Resources: 0/0, ::0, AS0-4294967295 (all resources)
Verified Resource Set: 0/0, ::0, AS0-4294967295 (all resources)
Warnings: none
トラストアンカー証明書は、過大申告を発見できないことに留意する。したがって、ここで新しいOIDを使用しても、この証明書の有効性に関しては何も変わらない。
証明書2:
Issuer: TA,
Subject: CA1,
OIDs: OLD,
Resources: 192.0.2.0/24, 2001:db8::/32, AS64496
Verified Resource Set: 192.0.2.0/24,
2001:db8::/32, AS64496
Warnings: none
TA証明書はすべてのリソースを申告するため、その下位の証明書を発行することは不可能であり、過大申告であると判断される可能性があることに留意する。したがって、証明書2に新しいOIDを使用するメリットはない。
証明書3:
Issuer: CA1,
Subject: CA2,
OIDs: NEW,
Resources: 192.0.2.0/24, 198.51.100.0/24, AS64496
Verified Resource Set: 192.0.2.0/24, AS64496
Warnings: overclaim for 198.51.100.0/24
CA1は、証明書2の独自リソースが変更され、証明書3で古いOIDが使用されていた場合、CA2に発行された証明書3が無効になる可能性を予期していた。
ROA 1 (有効):
埋め込み証明書 4 (EE certificate):
Issuer: CA2,
Subject: R1,
OIDs: OLD,
Resources: 192.0.2.0/24
Prefix 192.0.2.0/24, Max Length 24, ASN 64496
Verified Resource Set: 192.0.2.0/24
Warnings: none
ROA1は、プレフィックスが埋め込みEE証明書の検証済みリソース・セットと一致するため、有効とみなされる。
ROA 2 (無効):
埋め込み証明書 5 (EE certificate invalid):
Issuer: CA2,
Subject: R2,
OIDs: OLD,
Resources: 198.51.100.0/24
Prefix 198.51.100.0/24, Max Length 24, ASN 64496
Verified Resource Set: none (empty set)
ROA2は、EE証明書のリソースに198.51.100.0/24が含まれ、検証済みリソース・セットに含まれていないため、無効とみなされる。
ここで(例 2 のように)新しいOIDを使用した場合 、プレフィックスが検証済みリソース・セットに含まれていないため、ROA 2は無効であるとみなされることに留意する。
つまり、有効性の結果に違いがない場合、ROAプレフィックスの過大申告は無効とみなされなければならないため(セクション4.2.5で説明)、ここで古いOIDを使用することが最も明確であると主張することができる。
BGPsec証明書1 (有効):
Issuer: CA2,
Subject: ROUTER-64496,
OIDs: OLD,
Resources: AS64496
Verified Resource Set: AS64496
Warnings: none
BGPsec証明書2 (無効):
Issuer: CA2,
Subject: ALL-ROUTERS,
OIDs: OLD,
Resources: AS64496-AS64497
Verified Resource Set: AS64496
BGPsec 証明書2は、リソースが検証済みリソース・セットに含まれていなAS64497を含むため、無効とみなされる。
ここで新しいOIDが(例2のように)使用された場合 、BGPsec 証明書 2はプレフィックスが検証済みリソース・セットに含まれていないため、無効とみなされることに留意する。
したがって、有効性の結果に違いがない場合、この証明書に対する過大申告があれば無効とみなされなければならないため(セクション4.2.6で説明)、ここで古いOIDを使用することが最も明確であると主張することができる。
また、例2のように、各AS番号に対して個別の証明書を発行することで、この問題を軽減できることにも留意する。
6. 導入に関する考慮事項
本文書では、代替のRPKI検証アルゴリズムを定義するが、このアルゴリズムの展開方法を規定するものではない。これは別の取り組みとして議論する必要がある。とはいえ、以下の考えは、この議論に役立つかもしれない。
本文書は[RFC6487]に記載されているX.509 PKIXリソース証明書のプロファイルに代わる新しいOIDと代替プロファイルを導入するため、グローバルRPKIでこのような証明書を使用すると、本文書に記載されている代替プロファイルを(まだ)実装していないリライング・パーティー・ツールは、この証明書を拒否することになる。
そのため、認証局がこの仕様を使い始める前に、ツールを更新することが重要である。
ただし、OIDは各RPKI証明書で定義されているため、すべての証明機関、または認証局が発行するすべての証明書について、同時に新しいOIDに移行することを厳密に要求するものではない。セクション5.3の例は、偶発的な過大申告が発生する可能性のあるCA証明書でのみ新しいOIDが使用される可能性のある展開を示している。
7. セキュリティに関する考慮事項
著者らは、改訂された検証アルゴリズムは、RPKIに新たなセキュリティ脆弱性を導入しないと考えている。なぜなら、ROA証明書及び/またはルータ証明書に、発行者が保持していないリソースが含まれている場合、それが受け入れられる可能性がないためである。
8. IANAに関する考慮事項
IANAは、「SMI Security for PKIX Certificate Policies」レジストリに以下を追加した。
| 10進法 | 説明 | 参照先 |
|---|---|---|
| 3 | id-cp-ipAddr-asNumber-v2 | セクション4.2.1 |
IANA は、「SMI Security for PKIX Certificate Extension」レジストリに以下を追加した。
| 10進法 | 説明 | 参照先 |
|---|---|---|
| 28 | id-pe-ipAddrBlocks-v2 | セクション4.2.2.1 |
| 29 | id-pe-autonomousSysIds-v2 | セクション4.2.2.3 |
IANAは、「SMI Security for PKIX Module Identifier」レジストリに以下を追加した。
| 10進法 | 説明 | 参照先 |
|---|---|---|
| 90 | id-mod-ip-addr-and-as-ident-v2 | セクション4.2.2.7 |
| 91 | id-mod-ip-addr-and-as-ident-2v2 | セクション4.2.3 |
9. 参考文献
9.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>.
[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>.
[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>.
[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012, <https://www.rfc-editor.org/info/rfc6484>.
[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>.
[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>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
9.2. 参考規格
[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>.
謝辞
著者らは、本文書をレビューし貢献してくれたスティーブン・ケントに感謝の意を表す。私たちは、証明書利用者ツールの動作を決定論的にするために個別のOIDを使用する必要があると提案してくれたロブ・オースティンに感謝する。また、OIDとASN.1の更新に関して貢献してくれたラス・ハウズリー、ショーン・ターナー、トム・ペッチに感謝する。最後に、この文書の全般的なレビューをしてくれたトム・ハリソンに感謝する。
著者のアドレス
ジェフ・ヒューストン
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane, QLD 4101
オーストラリア
電話: +61 7 3858 3100
メール: gih@apnic.net
ジョージ・マイケルソン
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane, QLD 4101
オーストラリア
電話: +61 7 3858 3100
メール: ggm@apnic.net
カルロス・M・マルティネス
Latin American and Caribbean Internet Address Registry
Rambla Mexico 6125
Montevideo 11400
ウルグアイ
電話: +598 2604 2222
メール: carlos@lacnic.net
ティム・ブルインジールス
RIPE Network Coordination Centre
Singel 258
Amsterdam 1016 AB
オランダ
メール: tim@ripe.net
アンドリュー・リー・ニュートン
American Registry for Internet Numbers
3635 Concorde Parkway
Chantilly, VA 20151
アメリカ合衆国
メール: andy@arin.net
ダニエル・ショー
African Network Information Centre (AFRINIC)
11th Floor, Standard Chartered Tower
サイバーシティ、エベネ
モーリシャス
電話: +230 403 51 00
メール: daniel@afrinic.net
更新履歴
- 2024.6.21
Discussion