Network Working Group C. Lynn
Request for Comments: 3779 S. Kent
Category: Standards Track K. Seo
BBN Technologies
June 2004
IPアドレスおよびAS識別子のためのX.509の拡張
本文書の位置づけ
本文書はインターネットコミュニティのためのインターネット標準化過程
プロトコルを定義し、改良のための議論と提案を求めている。本プロトコ
ルの標準化の段階および状態については「Internet Official プロトコル
Standard」(STD 1)の最新版を参照してほしい。本文書の配布は制限されな
い。
著作権表示
Copyright (C) Internet Society (2004).
要約
本文書は、2つのX.509 v3 証明書拡張を定義する。最初のものはIPアドレ
スブロックのリスト、またはプレフィックスを証明書のサブジェクトに結
合するものである。2番目のものは、自律システム識別子のリストを証明書
のサブジェクトに結合するものである。これらの拡張は、拡張領域内に含
まれるIPアドレスおよび自律システム識別子をサブジェクトが使用するこ
とを認証するために使用することができる。
目次
1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
1.1. 用語. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2. IPアドレス委任拡張領域. . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
2.1. コンテキスト. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
2.1.1. IPアドレスまたはプレフィックスのエンコーディング. . . . . . . . . . . 5
2.1.2. IPアドレスの範囲のエンコーディング. . . . . . . . . . . . . . . . . . .7
2.2. 仕様. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
2.2.2. クリティカリティ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
2.2.3. 文法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3.1. タイプIPAddrBlocks. . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3.2. タイプIPAddressFamily . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3.3. 要素addressFamily. . . . . . . . . . . . . . . . . . . . . . . . . .10
2.2.3.4. 要素ipAddressChoiceおよびタイプIPAddressChoice . . . . . . . . . . . .10
Lynn, et al. Standards Track [Page 1]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
2.2.3.5. 要素inherit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
2.2.3.6. 要素addressesOrRanges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
2.2.3.7. タイプIPAddressOrRange. . . . . . . . . . . . . . . . . . . . . . . .11
2.2.3.8. 要素addressPrefixおよびタイプIPAddress. . . . . . . . . . . . . . . 11
2.2.3.9. 要素addressRangeおよびタイプIPAddressRange . . . . . . . . . . . . 12
2.3. IPアドレス委任拡張領域証明書パス検証 . . . . . . . . . . . . . . . . . . 12
3. 自律システム識別子委任拡張領域. . . . . . . . . . . . . . . . . . . . . . .13
3.1. コンテキスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
3.2. 仕様. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
3.2.1. OID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13
3.2.2. クリティカリティ. . . . . . . . . . . . . . . . . . . . . . . . . . .14
3.2.3. 文法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14
3.2.3.1. タイプASIdentifiers . . . . . . . . . . . . . . . . . . . . . . . . . .14
3.2.3.2. 要素asnum、rdi、およびタイプASIdentifierChoice . . . . . . . . . . . .14
3.2.3.3. 要素inherit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
3.2.3.4. 要素asIdsOrRanges. . . . . . . . . . . . . . . . . . . . . . . . . . .15
3.2.3.5. タイプASIdOrRange . . . . . . . . . . . . . . . . . . . . . . . . . . .15
3.2.3.6. 要素id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
3.2.3.7. 要素range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
3.2.3.8. タイプASRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
3.2.3.9. 要素min and max . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
3.2.3.10. タイプASId. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
3.3. 自律システム識別子委任拡張領域証明書パス検証. . . . . . . . . . . . . . . .16
4. セキュリティ上の配慮. . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
5. 謝辞. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16
付録A -- ASN.1 モジュール . . . . . . . . . . . . . . . . . . . . . . . . . . .17
付録B -- IPアドレス委任拡張領域の例 . . . . . . . . . . . . . . . . . . . . . . .18
付録C -- AS識別子委任拡張領域の例 . . . . . . . . . . . . . . . . . . . . . . . .21
付録D -- X.509 属性証明書の使用. . . . . . . . . . . . . . . . . . . . . . . . .21
参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
引用規格 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
参考情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
執筆者の連絡先. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Lynn, et al. Standards Track [Page 2]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
1. はじめに
本文書は、一連のIPアドレスおよび自律システム識別子の使用権の、IANA
から地域インターネットレジストリ(RIR)を通じてインターネットサービス
プロバイダ(ISP)およびユーザ組織への以上を認証する、2つのX.509 v3証
明書拡張を定義する。最初のものは、IPアドレスブロック(しばしばIPアド
レスプレフィックスと表される)を、証明書のサブジェクト(秘密鍵の保有
者)に結合するものである。2番目のものは、自律システム(AS)識別子のリ
ストを証明書のサブジェクト(秘密鍵の保有者)に結合するものである。証
明書の発行者は、一連のIPアドレスブロックおよびAS識別子の管理権を証
明書のサブジェクトに移譲する(「割り振る」)権威を持つエンティティ(た
とえばIANA、地域インターネットレジストリ、またはISP) である。これら
の証明書は、一連のIPアドレスプレフィックスおよびAS識別子の使用権を
確認する、スケーラブルな手段を提供する。これらは、Secure BGP
[S-BGP]などのルーティングプロトコルがルーティング情報の正当性や正確
さを確認したり、インターネットルーティングレジストリが受信するデー
タを確認したりするために使用することができる。
セクション2および3は、この使用で定義され、従わなければならない
(MUST)拡張領域のエンコーディングに関するいくつかの規則を指定する。
これらのエンコーディング規則は、以下の目的で使用される。最初に、こ
れらは拡張領域の値の固有のエンコーディングに帰着する。2つの拡張領域
のインスタンスは、オクテットごとに等しいかどうかを比較することがで
きる。第2に、これらは、情報を最小サイズでエンコーディングすることが
できる。第3に、これらの規則によって、依存者が証明書パス検証を行うと
きに、ワンパスアルゴリズムを使うことができる。特に、依存者は複数の
境界の場合(隣接、重複、または包含)を扱うために、情報をソートしたり
サブセットチェックアルゴリズムの中に余分なコードを実装したりする必
要がない。
1.1. 用語
読者は「インターネットX.509 公開鍵基盤 証明書と証明書失効リスト
(CRL)のプロファイル」[RFC3280]、「インターネットプロトコル」
[RFC791]、「インターネットプロトコルバージョン6(IPv6)のアドレス体系」
[RFC3513]、「インターネットレジストリにおけるIP割り振りのガイドライ
ン」[RFC2050]、および関係する地域インターネットレジストリアドレス管
理ポリシードキュメントに記載されている用語および概念を熟知している
ものとみなされる。重要な用語には、以下のものが含まれる。
割り振り - リソースの管理権の、中間組織への移譲([RFC2050]参照)。
割り当て - リソースの管理権の、エンドユーザ組織への移譲管理権
([RFC2050]参照)。
Lynn, et al. Standards Track [Page 3]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
自律システム (AS) - 1つの管理ポリシーで単独の技術的管理下にあり、1つま
たは複数の内部ゲートウェイプロトコルとメトリックを使用して自律システム
内のパケットのルーティングの方法を決定し、外部ゲートウェイプロトコルを
使用して他の自律システムへのパケットのルーティングの方法を決定する、ルー
ターの集合。
自律システム番号 - 自律システムを識別する32ビットの数字。
委任- IPアドレスブロックまたはAS識別子の管理権(すなわち使用権)を、証明
書をエンティティに発行することによって委任すること。
第1オクテット- DER エンコードされたビット文字列の値の最初のオクテット
[X.690]。
IP v4アドレス- 「.」で区切られた4個の0～255の範囲の十進数としてあらわ
される32ビットの識別子。10.5.0.5はIPv4アドレスの例である。
IP v6アドレス- 「:」で区切られた8個の0～ffffの範囲の16進数として表され
る128ビットの識別子。2001:0:200:3:0:0:0:1はIPv6アドレスの例である。:0:
フィールドの文字列は「::」に置き換えてもよいため、2001:0:200:3::1は直
前の例と同じアドレスを表す([RFC3513]参照)。
プレフィックス- あるアドレスの初期ビットのいくつかで構成されるビット文
字列。アドレスの後ろに「/」および初期ビットの個数が続くものとしてあら
わされる。10.5.0.0/16および2001:0:200:3:0:0:0:0/64(または
2001:0:200:3::/64)プレフィックスの例である。プレフィックスは、下位のゼ
ロフィールドを省略することによって短縮されることが多いが、示された数の
イニシャルビットを含むのに十分なフィールドがあるべきである。10.5/16お
よび2001:0:200:3/64は、短縮されたプレフィックスの例である。
地域インターネットレジストリ (RIR) - IPアドレスおよびAS識別子の管理を
地域内で行うことをIANAに承認された団体。本文書の作成の時点では、
AfriNIC、APNIC、ARIN、LACNIC、およびRIPE NCCなどがある。
使用権 - IPアドレスプレフィックスに関しては、インターネット全体でプレ
フィックスの通知を発信することができるASを指定することを承認されている
こと。自律システム識別子に関しては、その自律システム識別子を使って他の
ネットワークオペレータに自分自身を特定するネットワークを運営することを
承認されていること。
Lynn, et al. Standards Track [Page 4]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
後続オクテット - DER エンコードされたビット文字列の値の2番目から最後ま
でのオクテット[X.690]。
トラストアンカー - 証明書パス検証を行うときに信頼する証明書([RFC3280]
参照)。
本文書中の「MUST（しなければならない）」「MUST NOT（してはならない）」
「REQUIRED（要求される）」「SHALL（すべきである）」「SHALL NOT（す
べきでない）」「SHOULD（したほうがよい）」「SHOULD NOT（しないほう
がよい）」「RECOMMENDED（推奨される）」「MAY（してもよい）」
「OPTIONAL（選択できる）」というキーワード群は、[RFC2119]での記述の
とおりに解釈される。
2. IPアドレス委任拡張領域
この拡張は、IPアドレスをエンディディに属する公開鍵に結合することに
よって、それらのアドレスの割り振りをおこなう。
2.1. コンテキスト
IPアドレス空間は現在、名目上IANAをルートとするがRIRによって管理され
る階層によって管理されている。IANAはIPアドレス空間をRIRに割り振り、
RIRは次にIPアドレス空間をインターネットサービスプロバイダ(ISP)に割
り振り、ISPはIPアドレス空間を下流のプロバイダ、顧客などに割り振る。
RIRはまた、エンドエンティティである組織、すなわち他の組織に空間を移
譲しない組織にIPアドレス空間を割り当てることもできる。(割り振りおよ
び割り当てのプロセスについては、[RFC2050]および関連するRIRポリシー
ドキュメントを参照。)
IPアドレス委任拡張は、IPアドレスブロックが適切に委任されること、す
なわちエンティティがIPアドレス空間を使用または再割り振りすることを
承認することを検証できるようにすることを目的とする。したがって、IP
アドレス空間を割り振るための既存の管理の枠組みの固有の権威性を利用
することは意味がある。上記のセクション1で説明したように、これはこの
セクションで説明する拡張領域を持つ証明書を発行することによって達成
される。この拡張領域内の情報を使用する1方法の例としては、ある組織が
特定のIPアドレスブロックへの経路を通知するBGP UPDATEを発信すること
を承認されていることを確認するために、あるエンティティがこの情報を
使用するというものがある。[RFC1771]、[S-BGP]などを参照。
2.1.1. IPアドレスまたはプレフィックスのエンコーディング
IPアドレスには、IPv4およびIPv6の2つの系統がある。
IPv4アドレスとは、「.」で区切られた4個の0～255の範囲の十進数として
あらわされる32ビットの数字である。10.5.0.5はIPv4アドレスの例である。
Lynn, et al. Standards Track [Page 5]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
IPv6アドレスとは、「:」で区切られた8個の0～ffffの範囲の16進数として
表される128ビットの数字。2001:0:200:3:0:0:0:1はIPv6アドレスの例であ
る。IPv6アドレスはしばしば、値が0である隣接するフィールドを持つ。こ
のような0フィールドのグループは、2個のセミコロン("::")によって短縮
することができる。したがって前の例は、2001:0:200:3::1と表すことがで
きる。
アドレスプレフィックスとは、最上ビットが同じである2^k個の連続したア
ドレスの集合である。たとえば、10.5.0.0～10.5.1.255の512個のIPv4アド
レスの集合は、上位23ビットがすべて同じである。このアドレスの集合は、
スラッシュ("/")と定数であるビットの数を集合内の最下位アドレスに付加
することによって表される。例の集合のプレフィックスは10.5.0.0/23で、
2^(32-23) = 2^9 個のアドレスが含まれる。2001:0:200:0:0:0:0:0～
2001:0:3ff:ffff:ffff:ffff:ffff:ffff(2^89個のアドレス)の集合は、
2001:0:200:0:0:0:0:0/39または同等に2001:0:200::/39とあらわされる。
プレフィックスは、最下位のゼロフィールドを省略することによって短縮
してもよいが、示された 数の定数ビットを含むのに十分なフィールドがあ
るべきである。例のIPv4プレフィックスを省略した形式は、10.5.0/23であ
り、IPv6プレフィックスのものは2001:0:200/39である。
IPアドレスまたはプレフィックスは、IPアドレス委任拡張領域内では、定
数最上位ビットを含むDERエンコードされたASN.1ビット文字列としてエン
コードされる。ビット文字列のDERエンコーディングはビット文字列タイプ
(0x03)、それに続く値オクテットの数(のエンコード）、それに続く値で構
成される[X.690] を思い出すこと。値は、最後の値オクテット内で未使用
のビット数を指定する「第1オクテット」と、それに続くビット文字列を含
む「後続オクテット」で構成される。(IPアドレスについては、長さのエン
コーディングは単に長さである。)
単独のアドレスの場合は、すべてのビットは定数であるため、IPv4アドレ
スのビット文字列には32ビットある。アドレス10.5.0.4のDERエンコーディ
ング内の後続オクテットは0x0a 0x05 0x00 0x04である。最終オクテットの
すべてのビットが使用されるため、第1オクテットは0x00である。したがっ
て、DERエンコードされたビット文字列内のオクテットは以下のとおりであ
る。
タイプ 長さ 未使用ビット ...
0x03 0x05 0x00 0x0a 0x05 0x00 0x04
同様に、プレフィックス10.5.0/23のDERエンコーディングは以下のとおり
である。
タイプ 長さ 未使用ビット ...
0x03 0x04 0x01 0x0a 0x05 0x00
Lynn, et al. Standards Track [Page 6]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
この場合、3個の後続オクテットには24ビットが含まれるが、プレフィッ
クスは23個しか使用していないため、最終オクテット内に未使用のビット
が1つある。したがって、第1オクテットは1である(DERでは、すべての未
使用ビットがゼロビットにセットされなければならない(MUST))。
IPv6アドレス2001:0:200:3:0:0:0:1のDERエンコーディングは以下のとおり。
タイプ 長さ 未使用ビット ...
0x03 0x11 0x00 0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01
プレフィックス2001:0:200/39は最終オクテットに未使用ビットを1つ含む
が、そのDERエンコーディングは以下のとおり。
タイプ 長さ 未使用ビット ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
2.1.2. IPアドレスの範囲のエンコーディング
任意の隣接するIPアドレス範囲は隣接するプレフィックスの集合で表現で
きるが、最下位アドレスと最上位アドレスを含むシーケンスとして範囲を
エンコードすることによって、より簡潔な表現が得られる。ここで各アド
レスはビット文字列としてエンコードされる。シーケンス内では、範囲内
の最下位アドレスを表すビット文字列は、アドレスからすべての最下位ゼ
ロビットを取り除くことで形成され、範囲内の最上位アドレスを表すビッ
ト文字列は、すべての最下位1ビットを取り除くことで形成される。DERビッ
ト文字列エンコーディングでは、最終オクテット内のすべての未使用ビッ
トがゼロビットにセットされなければならない(MUST)。プレフィックスは、
常に範囲として表現することができるが、範囲は常にプレフィックスとし
て表現することはできないことに注意。
プレフィックス10.5.0/23で表現されるアドレスは、10.5.0.0～10.5.1.255
である。最下位アドレスは16個のゼロビットで終わるが取り除かれている。
結果の16ビット文字列のDERエンコーディングは以下のとおり。
タイプ 長さ 未使用ビット ...
0x03 0x03 0x00 0x0a 0x05
最上位アドレスは9個の1ビットで終わるが取り除かれている。結果の23ビッ
ト文字列のDERエンコーディングは以下のとおり。
タイプ 長さ 未使用ビット ...
0x03 0x04 0x01 0x0a 0x05 0x00
Lynn, et al. Standards Track [Page 7]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
プレフィックス2001:0:200/39は、最下位アドレス(2001:0:200::)のDER-エ
ンコーディングが以下のとおりであるような範囲としてエンコードできる。
タイプ 長さ 未使用ビット ...
0x03 0x06 0x01 0x20 0x01 0x00 0x00 0x02
最上位アドレス(2001:0:3ff:ffff:ffff:ffff:ffff:ffff)は、90個の最下位
1ビットを取り除くと38ビット文字列となり、以下のようにエンコードされ
る。
タイプ 長さ 未使用ビット ...
0x03 0x06 0x02 0x20 0x01 0x00 0x00 0x00
特殊な場合として、すべてのIPアドレスブロック、すなわちすべてゼロビッ
トのプレフィックスは、長さオクテットが1、第1オクテットがゼロ、後続
オクテットなしでDERエンコードしなければならない(MUST)。
タイプ 長さ 未使用ビット ...
0x03 0x01 0x00
IPアドレスに関しては、一連のゼロビットは意味を持つことに注意。たと
えば、以下の10.64/12のDERエンコーディング。
タイプ 長さ 未使用ビット ...
0x03 0x03 0x04 0x0a 0x40
は、10.64.0/20のDERエンコーディングとは異なる。
タイプ 長さ 未使用ビット ...
0x03 0x04 0x04 0x0a 0x40 0x00
2.2. 仕様
2.2.1. OID
この拡張のOIDは、id-pe-ipAddrBlocksである。
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
ここで [RFC3280] は以下のように定義する。
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 }
Lynn, et al. Standards Track [Page 8]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
2.2.2. クリティカリティ
この拡張は、クリティカルであるものとする(SHOULD)。この拡張の目的と
する用途は、拡張領域で指定されるIPアドレスのブロックの使用権を暗示
することである。CAは拡張をクリティカルとマークして、証明書が発行さ
れた目的のために依存者が証明書を利用するためには、拡張領域の意味を
理解しなければならない(MUST)という注意を伝える。個の拡張領域を含む
証明書を使用する、新規作成されたアプリケーションは、この拡張を認識
するものと期待される。
2.2.3. 文法
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFI & オプション SAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- 発行者から継承 --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
2.2.3.1. タイプ IPAddrBlocks
IPAddrBlocks タイプは、IPIPAddressFamily タイプのシーケンスである。
2.2.3.2. タイプ IPAddressFamily
IPAddressFamily タイプは、addressFamilyおよびipAddressChoice要素を
含むシーケンスである。
Lynn, et al. Standards Track [Page 9]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
2.2.3.3. 要素 addressFamily
addressFamily要素は、2オクテットのアドレスファミリ識別子(AFI)をネッ
トワークバイトオーダーで含み、オプションで1オクテットの後続アドレス
ファミリ識別子(SAFI)がそれに続くオクテット文字列である。AFIおよび
SAFIはそれぞれ[IANA-AFI]および[IANA-SAFI]で指定される。
特定のAFIとオプションのSAFIに対して、承認が与えられていない場合は、
IPAddrBlocks シーケンス内のAFI/SAFIに対して、IPAddressFamily メンバー
があってはならない(MUST NOT)。
AFIとSAFIの固有の組み合わせに対して、IPAddressFamily シーケンスは1
だけでなくてはならない(MUST)。各シーケンスは、addressFamilyの値で昇
順に並んでいなくてはならない(MUST) (オクテットは符号なしの量として
扱う)。 SAFIのないaddressFamilyは、SAFIを含むものより前に置かなけれ
ばならない(MUST)。IPv4とIPv6の両方のアドレスが指定された場合は、
IPv4アドレスをIPv6アドレスより前に置かなければならない(MUST)(IPv4
AFIの0001はIPv6 AFIの0002より小さいため)。
2.2.3.4. 要素ipAddressChoiceおよびタイプIPAddressChoice
ipAddressChoice要素のタイプはIPAddressChoiceである。IpAddressChoice
タイプはinheritまたはaddressesOrRanges要素のいずれかのCHOICEである。
2.2.3.5. 要素inherit
IPAddressChoice CHOICE にinherit要素が含まれている場合は、指定され
たAFIおよびオプションのSAFIに対する承認されたIPアドレスの集合が、
addressesOrRanges要素を含むIPAddressChoiceを含む証明書が見つかるま
で、再帰的に発行者の証明書、または発行者の発行者の証明書からとられ
る。
2.2.3.6. 要素addressesOrRanges
addressesOrRanges要素はIPAddressOrRangeタイプのシーケンスである。
addressPrefixおよびaddressRange要素は、以下のバイナリ表現を用いてソー
トしなければならない(MUST)。
<範囲内の最下位IPアドレス> | <プレフィックスの長さ>
ここで"|" は連結を表す。この表現内のオクテット(a.b.c.d | IPv4の長さ
またはs:t:u:v:w:x:y:z | IPv6の長さ)は、DERエンコードされたビット文
字列値のオクテットではないことに注意。たとえば、以下の2つの
addressPrefixがあるとする。
Lynn, et al. Standards Track [Page 10]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
IPアドレス| 長さ DER エンコーディング
---------------- ------------------------
タイプ 長さ 未使用ビット...
10.32.0.0 | 12 03 03 04 0a 20
10.64.0.0 | 16 03 03 00 0a 40
32は64より小さいため、プレフィックス10.32.0.0/12は、プレフィックス
10.64.0.0/16より前にこなければならない(MUST)。一方、DER ビット文字
列でソートされるとすると、未使用ビットオクテットは逆の順序でソート
されるため、順序は逆になる。拡張領域内のIPAddressOrRange choiceのペ
アは、重複してはならない(MUST NOT)。隣接するアドレスプレフィックス
または範囲は単独の範囲または、可能であれば常に、単独のプレフィック
スに組み合わせなければならない(MUST)。
2.2.3.7. タイプIPAddressOrRange
IPAddressOrRangeタイプは、addressPrefix(IPプレフィックスまたはアド
レス)またはaddressRange (IPアドレス範囲)要素のCHOICEである。
この仕様では、プレフィックスとしてエンコードできるアドレス範囲は、
IPAddress要素(ビット文字列)を用いてエンコードしなければならず(MUST)、
プレフィックスとしてエンコードできない範囲はIPAddressRange(2つのビッ
ト文字列を含むシーケンス)を用いてエンコードしなければならない(MUST)。
以下の擬似コードは、所定のアドレス範囲のエンコードを選択する方法を
説明するものである。
LET N = 範囲の最下位および最上位アドレス内の、一致する最上位ビットの数
IF 最下位アドレスに残っているすべてのビットがゼロビット
AND 最上位アドレスに残っているすべてのビットが1ビット
THEN 範囲はNビットIPアドレスとしてエンコードしなければならない(MUST)
ELSE 範囲IPAddressRangeとしてエンコードしなければならない(MUST)
2.2.3.8. 要素addressPrefixおよびタイプIPAddress
addressPrefix要素はIPAddressタイプである。IPAddressタイプはアドレス
の最上位(左側の)Nビットが定数であり、残りのビット(IPv4では32-Nビッ
ト、IPv6では128-Nビット)がゼロまたは1のいずれかであるようなIPアドレ
スの範囲を定義する。たとえば、IPv4プレフィックス10.64/12はアドレス
10.64.0.0～10.79.255.255に対応し、10.64/11は10.64.0.0～
10.95.255.255に対応する。IPv6プレフィックス2001:0:2/48はアドレス
2001:0:2::～2001:0:2:ffff:ffff:ffff:ffff:ffffを表す。
IPアドレスプレフィックスは、ビット文字列としてエンコードされる。ビッ
ト文字列のDERエンコーディングは、文字列の第1オクテットを使って、最
終後続オクテットのうちのいくつが未使用であるかを指定する。
Lynn, et al. Standards Track [Page 11]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
DERエンコーディングでは、これらの未使用ビットがゼロビットにセットさ
れなければならない(MUST)と指定している。
例:
128.0.0.0 = 1000 0000.0000 0000.0000 0000.0000 0000
～ 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111
エンコードするビット文字列 = 1000
タイプ 長さ 未使用ビット...
エンコーディング = 0x03 0x02 0x04 0x80
2.2.3.9. 要素addressRangeおよびタイプIPAddressRange
addressRange要素はタイプIPAddressRangeである。IPAddressRangeタイプ
は、最小(要素min)と最大(要素max)のIPアドレスを含むシーケンスで構成
される。各IPアドレスはビット文字列としてエンコードされる。
IPAddressRange内の最小アドレスの意味論的解釈は、指定されていないす
べてのビット(完全な長さのIPアドレスに関して)がゼロビットであるとい
うことである。IPAddressRange内の最大アドレスの意味論的解釈は、指定
されていないすべてのビット(完全な長さのIPアドレスに関して)が1ビット
であるということである。最小アドレスのビット文字列は、最小アドレス
からすべての最下位ゼロビットを取り除くことで得られる。最大アドレス
のビット文字列は、最大アドレスからすべての最下位1ビットを取り除くこ
とで得られる。
例:
129.64.0.0 = 1000 0001.0100 0000.0000 0000.0000 0000
to 143.255.255.255 = 1000 1111.1111 1111.1111 1111.1111 1111
最小ビット文字列 = 1000 0001.01
最大ビット文字列 = 1000
エンコーディング = シーケンス {
タイプ 長さ 未使用ビット ...
min 0x03 0x03 0x06 0x81 0x40
max 0x03 0x02 0x04 0x80
}
証明書パス検証を行うときにIPアドレスブロックの比較を簡素化するため
に、最大IPアドレスは値が1であるビットを少なくとも1つ含んでいなけれ
ばならない(MUST)。すなわち、後続オクテットは省略されたりすべてゼロ
であったりしてはならない。
2.3. IPアドレス委任拡張領域証明書パス検証
IPアドレス委任拡張領域を含む証明書の証明書パス検証には、追加の処理
が必要である。パス内の各証明書が検証されるときに、その証明書のIPア
ドレス委任拡張領域内のIPアドレスが発行者の証明書のIPアドレス委任拡
張領域内のIPアドレスに含まれていなければならない(MUST)。そうなって
いない場合は、検証は失敗しなければならない(MUST)。
Lynn, et al. Standards Track [Page 12]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
証明書パス検証のトラストアンカーである証明書またはIPアドレス委任拡
張領域を含む証明書、およびパス上のすべての証明書は、それぞれIPアド
レス委任拡張領域を含まなければならない(MUST)。許されるアドレス範囲
の初期集合は、トラストアンカー証明書からとられる。
3. 自律システム識別子委任拡張領域
この拡張領域は、自律システム(AS)識別子をエンティティに属する公開鍵
に結合することによって、そのAS識別子のエンティティへの割り振りを行
う。
3.1. コンテキスト
AS識別子委任は現在、名目上IANAをルートとするがRIRによって管理される
階層によって管理されている。IANAはAS識別子をRIRに割り振り、RIRは次
にAS識別子をエンドエンティティである組織、すなわち他の組織にAS識別
子を移譲しない組織にAS識別子を割り当てる。AS識別子委任拡張領域は、
AS識別子が適切に委任されること、すなわちエンティティがこれらのAS識
別子を使用することを承認することを検証できるようにすることを目的と
する。したがって、AS識別子を管理するため既存の枠組みの固有の権威性
を利用することは意味がある。上記のセクション1で説明したように、これ
はこのセクションで説明する拡張領域を持つ証明書を発行することによっ
て達成される。この拡張領域内の情報を使用する1方法の例としては、ある
エンティティが、ある組織がAS識別子で指定されるASを管理する承認を得
ているかどうかを確認するために、この領域を使用することがある。AS識
別子の割り振りを表すためにこの拡張領域を使用することは、AS識別子が
管理される手続きや、ASがいつ使われるべきかを変更することを意図する
ものではない。[RFC1930]参照。
3.2. 仕様
3.2.1. OID
この拡張のOIDは、id-pe-autonomousSysIdsである。
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
ここで [RFC3280] は以下のように定義する。
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 }
Lynn, et al. Standards Track [Page 13]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
3.2.2. クリティカリティ
この拡張は、クリティカルであるものとする(SHOULD)。この拡張の目的と
する用途は、拡張領域内のAS識別子の使用権を暗示することである。CAは
拡張をクリティカルとマークして、証明書が発行された目的のために依存
者が証明書を利用するためには、拡張領域の意味を理解しなければならな
い(MUST)という注意を伝える。個の拡張領域を含む証明書を使用する、新
規作成されたアプリケーションは、この拡張を認識するものと期待される。
3.2.3. 文法
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
ASIdentifiers ::= SEQUENCE {
asnum [0] EXPLICIT ASIdentifierChoice OPTIONAL,
rdi [1] EXPLICIT ASIdentifierChoice OPTIONAL}
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- 発行者から継承 --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
3.2.3.1. タイプASIdentifiers
ASIdentifiers タイプは1つまたはそれ以上の形式の自律システム識別子
(AS番号(asnum要素内)またはルーティングドメイン識別子(rdi要素内)）を
含むシーケンスである。ASIdentifiersタイプに複数の形式の識別子が含ま
れている場合は、asnumエントリはrdiエントリより前に置かれなければな
らない(MUST)。AS番号はBGPによって使用され、ルーティングドメイン識別
子はIDRPないに指定される[RFC1142]。
3.2.3.2. 要素asnum、rdi、およびタイプASIdentifierChoice
asnumおよびrdi要素は、どちらもタイプASIdentifierChoiceである。
ASIdentifierChoiceタイプはinheritまたはasIdsOrRanges要素のCHOICEで
ある。
Lynn, et al. Standards Track [Page 14]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
3.2.3.3. 要素inherit
ASIdentifierChoiceにinherit要素が含まれている場合、承認された識別子
の集合は、asIdsOrRanges要素を含むASIdentifierChoiceを含む証明書が見
つかるまで、再帰的に発行者の証明書、または発行者の発行者の証明書か
らとられる。特定の形式のAS識別子に対して承認が与えられていない場合
は、対応するasnum/rdiメンバーがASIdentifiersシーケンスないにあって
はならない(MUST NOT)。
3.2.3.4. 要素asIdsOrRanges
asIdsOrRanges要素は、ASIdOrRangeタイプのシーケンスである。
asIdsOrRangesシーケンス内の項目のペアは、重複してはならない(MUST
NOT)。任意の隣接する一連のAS識別子は、可能であれば常に単独の範囲に
組み合わせなければならない(MUST)。asIdsOrRanges要素内のAS識別子は、
数値の増える順にソートされなければならない(MUST)。
3.2.3.5. タイプASIdOrRange
ASIdOrRangeタイプは単独の整数(ASId)または単独のシーケンス(ASRange)
のCHOICEである。
3.2.3.6. 要素id
id要素はタイプASIdを持つ。
3.2.3.7. 要素range
range要素はタイプASRangeを持つ。
3.2.3.8. タイプASRange
ASRangeタイプはminおよびmax要素からなるシーケンスで、AS識別子の値の
範囲を指定するために使用される。
3.2.3.9. 要素minおよびmax
minおよびmax要素はタイプASIdを持つ。min要素は、範囲内の最小のAS識別
子を指定するために使用され、max要素は範囲内の最大のAS識別子の値を指
定する。
3.2.3.10. タイプASId
ASIdタイプはINTEGERである。
Lynn, et al. Standards Track [Page 15]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
3.3. 自律システム識別子委任拡張領域証明書パス検証
自律システム識別子委任拡張領域を含む証明書の証明書パス検証には、追
加の処理が必要である。パス内の各証明書が検証されるときに、その証明
書の自律システム識別子委任拡張領域内のAS識別子が発行者の証明書の自
律システム識別子委任拡張領域に含まれていなければならない(MUST)。 そ
うなっていない場合は、検証は失敗しなければならない(MUST)。自律シス
テム識別子委任拡張領域を含む証明書の証明書パス検証のトラストアンカー
である証明書および、パス上のすべての証明書は、それぞれ自律システム
識別子委任拡張領域を含まなければならない(MUST)。許されるAS識別子の
初期集合は、トラストアンカー証明書からとられる。
4. セキュリティ上の配慮
本仕様は2つのX.509拡張を説明する。X.509証明書はデジタル署名されるた
め、追加のインテグリティサービスは不要である。これらの拡張領域を持
つ証明書は、秘密にする必要はなく、これらの証明書に対する無制限の匿
名によるアクセスは、セキュリティ上の問題を生じない。
しかし、本仕様の範囲外のセキュリティ要素が証明書ユーザに提供される
保証に影響する。このセクションは、実装者、管理者、およびユーザが考
慮すべき重要な問題を強調する。
これらの拡張は承認情報、すなわちIPアドレスまたはAS識別子の使用権を
表す。これらは、BGPのセキュアバージョン[S-BGP]をサポートするために
開発されたが、他のコンテキストで利用することもできる。セキュアBGPの
コンテキストでは、これらの拡張領域を含む証明書は可能性として機能す
る。証明書は、秘密鍵の保有者(サブジェクト)が拡張領域に現されるIPア
ドレスまたはAS識別子を使用することを承認されていることを主張する。
この機能モデルの結果として、一般的なPKIの慣習とは異なり、サブジェク
トフィールドは概してセキュリティ目的とは関係ない。
5. 謝辞
著者は、Charles Gardiner、Russ Housley、James Manger、およびJim
Schaadの本仕様への貢献に対し感謝の意を表します。
Lynn, et al. Standards Track [Page 16]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
付録A -- ASN.1 モジュール
この標準的付録は、準拠PKIコンポーネントによって使用されるIPアドレス
およびAS識別子拡張領域についてASN.1文法で説明する。
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) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- Copyright (C) インターネットソサエティ (2004)--
-- 本ASN.1モジュールの本バージョンは、RFC 3779の一部である。 --
-- 完全な法律上の表示については、RFC自身を参照のこと。 --
-- すべてエキスポート --
IMPORTS
-- PKIX固有のOIDおよびアーク --
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アドレス委任拡張領域OID --
id-pe-ipAddrBlocks OBJECT IDENTIFIER ::= { id-pe 7 }
-- IPアドレス委任拡張領域文法 --
IPAddrBlocks ::= SEQUENCE OF IPAddressFamily
IPAddressFamily ::= SEQUENCE { -- AFIとオプションのSAFI --
addressFamily OCTET STRING (SIZE (2..3)),
ipAddressChoice IPAddressChoice }
IPAddressChoice ::= CHOICE {
inherit NULL, -- 発行者から継承 --
addressesOrRanges SEQUENCE OF IPAddressOrRange }
IPAddressOrRange ::= CHOICE {
addressPrefix IPAddress,
addressRange IPAddressRange }
IPAddressRange ::= SEQUENCE {
min IPAddress,
max IPAddress }
IPAddress ::= BIT STRING
Lynn, et al. Standards Track [Page 17]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
-- 自律システム識別子委任拡張領域OID --
id-pe-autonomousSysIds OBJECT IDENTIFIER ::= { id-pe 8 }
-- 自律システム識別子委任拡張領域文法 --
ASIdentifiers ::= SEQUENCE {
asnum [0] ASIdentifierChoice OPTIONAL,
rdi [1] ASIdentifierChoice OPTIONAL }
ASIdentifierChoice ::= CHOICE {
inherit NULL, -- 発行者から継承 --
asIdsOrRanges SEQUENCE OF ASIdOrRange }
ASIdOrRange ::= CHOICE {
id ASId,
range ASRange }
ASRange ::= SEQUENCE {
min ASId,
max ASId }
ASId ::= INTEGER
END
付録B -- IPアドレス委任拡張領域の例
以下のIPv4ユニキャストアドレスプレフィックスを指定する、重要なX.509
v3 証明書拡張
1) 10.0.32/20 すなわち 10.0.32.0～10.0.47.255
2) 10.0.64/24 すなわち 10.0.64.0～10.0.64.255
3) 10.1/16 すなわち 10.1.0.0 ～10.1.255.255
4) 10.2.48/20 すなわち 10.2.48.0～10.2.63.255
5) 10.2.64/24 すなわち 10.2.64.0～10.2.64.255
6) 10.3/16 すなわち 10.3.0.0 ～10.3.255.255、および
7) 発行者の証明書からすべてのIPv6アドレスを継承
は、以下のとおり(16進):
30 46 Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 37 extnValue {
30 35 IPAddrBlocks {
30 2b IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
ipAddressChoice
30 24 addressesOrRanges {
Lynn, et al. Standards Track [Page 18]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
IPAddressOrRange
03 04 04 0a0020 addressPrefix10.0.32/20
IPAddressOrRange
03 04 00 0a0040 addressPrefix10.0.64/24
IPAddressOrRange
03 03 00 0a01 addressPrefix 10.1/16
IPAddressOrRange
30 0c addressRange {
03 04 04 0a0230 min 10.2.48.0
03 04 00 0a0240 max 10.2.64.255
} --addressRange
IPAddressOrRange
03 03 00 0a03 addressPrefix 10.3/16
} -- addressesOrRanges
} -- IPAddressFamily
30 06 IPAddressFamily {
04 02 0002 addressFamily: IPv6
ipAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
この例は、プレフィックスと範囲がどのようにソートされるかを示す。
+ プレフィックス1の未使用ビット(4)がプレフィックス2の未使用ビット(0)よ
り大きくても、プレフィックス1はプレフィックス2より前に置かれなければな
らない(MUST)。
+ プレフィックス2のビット文字列エンコーディングのオクテット数(4)がプレ
フィックス3のビット文字列エンコーディングのオクテット数(3)より大きくて
も、プレフィックス2はプレフィックス3より前に置かれなければならない
(MUST)。
+ プレフィックス4と5は隣接している(アドレスの範囲10.2.48.0～
10.2.64.255を表す)ので、1つの範囲に組み合わせなければならない(MUST)(範
囲は単独のプレフィックスによってエンコードできないため)。
+ 範囲のmax要素内6個の連続するゼロビットが、値の意味論的解釈にとって重
要であることに注意(すべての未使用ビットは、ゼロでなく1と解釈されるため)。
min要素内の4個の連続するゼロビット(したがって、min要素のエンコーディン
グ内の(4)個の未使用ビット)は重要ではなく、取り除かなくてはならない
(MUST)。(DERエンコーディングでは、最後の後続オクテット内の未使用ビット
はすべてゼロにセットしなくてはならない(MUST))。
Lynn, et al. Standards Track [Page 19]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
+ プレフィックス4と5で形成される範囲は、範囲のSEQUENCEタグ(30)がプレ
フィックス6のエンコードに使用されるビット文字列(03)のタグより大きくて
も、プレフィックス6より前に置かれなければならない(MUST)。
+ IPv4のアドレスファミリ識別子(0001)はIPv6の識別子(0002)より小さいので、
IPv4情報はIPv6情報より前に置かれなければならない(MUST)。
IPv6プレフィックス2001:0:2/48およびIPv4プレフィックス10/8と172.16/12を
指定し、すべてのIPv4マルチキャストアドレスを発行者の証明書から継承する
拡張領域は、以下のとおり(16進):
30 3d Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 2e extnValue {
30 2c IPAddrBlocks {
30 10 IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
ipAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 02 00 0a addressPrefix 10/8
IPAddressOrRange
03 03 04 b010 addressPrefix 172.16/12
} -- addressesOrRanges
} -- IPAddressFamily
30 07 IPAddressFamily {
04 03 0001 02 addressFamily: IPv4 Multicast
ipAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
ipAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 07 00 200100000002 addressPrefix 2001:0:2/47
} -- addressesOrRanges
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
Lynn, et al. Standards Track [Page 20]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
付録C -- AS識別子委任拡張領域の例
AS番号135、3000～3999、5001を指定し、すべてのルーティングドメイン識
別子を発行者の証明書から継承する拡張領域は以下のとおり(16進)
30 2b Extension {
06 08 2b06010505070108 extnID 1.3.6.1.5.5.7.1.8
01 01 ff critical
04 1c extnValue {
30 1a ASIdentifiers {
a0 14 asnum
ASIdentifierChoice
30 12 asIdsOrRanges {
ASIdOrRange
02 02 0087 ASId
ASIdOrRange
30 08 ASRange {
02 02 0bb8 min
02 02 0f9f max
} -- ASRange
ASIdOrRange
02 02 1389 ASId
} -- asIdsOrRanges
} -- asnum
a1 02 rdi {
ASIdentifierChoice
05 00 inherit from issuer
} -- rdi
} -- ASIdentifiers
} -- extnValue
} -- Extension
付録D -- X.509 属性証明書の使用
この付録では、属性証明書 ([RFC3281]で指定されるように、AC) を、地域
インターネットレジストリ(RIR)からエンドユーザ組織へIPアドレスブロッ
クまたはAS識別子の使用権を伝えるために使用するという提案に起因する
問題について議論する。
AS識別子とIPアドレスブロックの2つのリソースは、現在異なる方法で管理
されている。AS識別子の使用権を持つすべての組織は、その承認をRIRから
直接受ける。IPアドレスブロックの使用権を持つ組織は、その承認を直接
RIRから、または間接的にたとえば下流のサービスプロバイダから受け、そ
の下流のサービスプロバイダは別のサービスプロバイダから承認をうけ、
サービスプロバイダはRIRから承認を受ける。
Lynn, et al. Standards Track [Page 21]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
将来AS識別子が再割り振りされるかもしれないので、メカニズムは3レベル
の階層に依存すべきではないことに注意。
RFC 3281のセクション1で、承認情報を伝える拡張領域を持つ公開鍵証明書
(PKC)を使用するよりもACを使用するほうが望ましい理由が2つ述べられて
いる。
「承認情報は、PKC 拡張領域におくことも、別の属性証明書(AC)におく
こともできる。承認情報をPKCに置くことは、通常2つの理由で望ましく
ない。第1に、承認情報は、アイデンティティと公開鍵の結合とは異な
る寿命を持つことがよくある。商人情報がPKC拡張領域におかれると、
一般的な結果としてPKCの使用可能な寿命が短縮される。第2に、PKCの
発行者は通常、承認情報に関する権威を持たない。この結果、PKCの発
行者は権威をもつものから承認情報を得るという余分のステップを踏ま
なければならない。」
「これらの理由により、承認情報はPKCとは独立させるほうがよいこと
が多い。しかし、承認情報はアイデンティティに結合する必要もある。
ACはこの結合を提供する。それは単に、デジタル署名(または保証)され
たアイデンティティと属性の集合である。」
IPアドレスとAS識別子の承認の場合、これらの理由は当てはまらない。第1
に、公開鍵証明書は承認のためだけに発行されるので、証明書の寿命は承
認の寿命に正確に対応し、それは発行者と承認を受けるエンティティとの
間の契約関係に結びついていることが多い。サブジェクト名と発行者名は
証明書パス検証の間に連鎖のために使用されるだけであり、物理的なエン
ティティに対応する必要はない。PKC内のサブジェクト名は、実際に発行CA
によってランダムに割り当てられ、リソースの保有者に制限つきの匿名性
を与えてもよい。第2に、証明書の階層は、証明書の発行者が承認情報に関
する権威を持つように構築されている。
したがって、上に引用した最初の段落はAS番号とIPアドレスブロックの割
り振りの場合には当てはまらない。リソースはアイデンティティではなく
PKC内の公開鍵に対応する秘密鍵の保有者に結合されているため、2番目に
引用した段落の要点は当てはまらない。
Lynn, et al. Standards Track [Page 22]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
RFC 3281は、それに準拠する属性証明書が満たさなければならないいくつ
かの要件を指定している。S-BGPに関係して、より重要な要件は以下のとお
りである。
1 セクション1から: 「本仕様では、AC連鎖の使用は推奨されない(NOT
RECOMMEND)。その他の(将来的な)仕様は、AC連鎖の仕様を扱うかもしれない。」
IANAからRIRへ、RIRからISPへ、ISPからDSPへの割り振りおよびエンド
組織への割り当てには、少なくともIPアドレスブロックに関しては連鎖
の仕様が必要である。上位者のACをどのように見つけ、それをどのよう
に処理するかについての説明が提供されなければならない。本文書の読
者は、連鎖を避けることができるような方法を提案することを奨励され
る。
2 セクション4.2.9から: 「セクション4.3はこのプロファイルとともに用
いてもよい(MAY)拡張領域および、それらがクリティカルとマーク付けされ
るかどうかを定義する。他のクリティカルな拡張領域が使用される場合、
ACはこのプロファイルに準拠しない。しかし、他のクリティカルでない拡
張領域が使用される場合、ACはこのプロファイルに準拠する。」
これは、本仕様で定義される委任拡張領域(クリティカルである)が、単
純にACにおくことはできないということを意味する。クリティカルとマー
ク付けされていなければ使用できるが、意図される用途では、思いもよ
らぬアプリケーションによって拡張領域を含む証明書がアイデンティティ
証明書として使用されることがないように、クリティカルであることが
必要である。
3 セクション4.5から: 「ACの発行者は、PKCの発行者でもあることはでき
ない(MUST NOT)。つまり、ACの発行者は同時にCAでもあることはできない。」
これは、各ACの発行者が、AC保有者の公開鍵を含むPKCを発行するため
に、独立したCAを必要とすることを意味する。ACの発行者は保有者の
PKCを発行することができず、PKCの発行者はACに署名することができな
い。したがって、PKI内の各エンティティは、CAのほかにAC発行者を運
営する必要がある。PKCが使用された場合に比べて、属性証明書のサポー
トを処理するために、2倍の数の証明書発行者とCRLが必要になる。単独
の目的で証明書を発行する発行者が2つあると、不整合が生じる可能性
もある。
RFC 3281のACモデルは、AC保有者属性または承認を実証したいときに、
保有者がACをAC検証者に提示するということを含意する。本文書で定義
される拡張領域の意図する用途では、AC検証者(NOC)とACの発行者(すべ
てのRIRおよびNOC)との間の直接の相互作用はない。
Lynn, et al. Standards Track [Page 23]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
主張される使用権の対象への署名があれば、「AC検証者」はACの保有者
のPKCを見つけることができるが、サブジェクトのACを見つける直接的
な方法はない。
4 セクション5から: 「4. AC の発行者は、(設定またはその他の方法によっ
て)ACの発行者として直接信用されなければならない(MUST) 。」
これは、IPアドレスブロックの使用権の場合には事実ではない。IPアド
レスブロックは階層を通じて割り振られる。ACの証明書パス検証には、
委任階層を上って連鎖をたどる必要がある。各依存者(NOC)が他のすべ
てのNOCを「信用」するように設定しなければならないことは適切では
なく、このような「信用」は、提案されたセキュリティメカニズムが回
避するように設計されている失敗に帰する。何千もの個々の信用される
ISPごとのACの発行者ではなく、信頼されるルートを持つ単独のPKIが使
用される。
ACを適切に検証するために必要な作業の量は、本文書で定義される証明
書拡張領域をPKCに置くメカニズムの場合よりも多い。ACに加えて、検
証されるべき証明書は2倍になる。ACをサポートするために必要な管理
負荷が著しく増加する可能性がある。
参考文献
引用規格
[IANA-AFI] http://www.iana.org/assignments/address-family-numbers.
[IANA-SAFI] http://www.iana.org/assignments/safi-namespace.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[X.690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
"Information Technology - ASN.1 Encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)".
Lynn, et al. Standards Track [Page 24]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
参考情報
[RFC791] Postel, J., "Internet Protocol -- DARPA Internet Program
Protocol Specification", RFC 791, September 1981.
[RFC1142] D. Oran, Ed., "OSI IS-IS Intra-domain Routing Protocol",
RFC 1142, February 1990.
[RFC1771] Rekhter, Y. and T. Li, Eds., "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System
(AS)", BCP 6, RFC 1930, March 1996.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and
J. Postel, "Internet Registry IP Allocation Guidelines",
BCP 12, RFC 2050, November 1996.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
Protocol (S-BGP)," IEEE JSAC Special Issue on Network
Security, April 2000.
Lynn, et al. Standards Track [Page 25]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
執筆者の連絡先
Charles Lynn
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3367
EMail: CLynn@BBN.Com
Stephen Kent
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3988
EMail: Kent@BBN.Com
Karen Seo
BBN Technologies
10 Moulton St.
Cambridge, MA 02138
USA
Phone: +1 (617) 873-3152
EMail: KSeo@BBN.Com
Lynn, et al. Standards Track [Page 26]
RFC 3779 X.509 Extensions for IP Addr and AS ID June 2004
完全な著作権表示
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2004). 本文書は、BCP 78に含まれ
る権利、ライセンス、および制約を前提とし、ここに述べられない限り、
著者はすべての権利を保有する。
本文書およびここに含まれる情報は「無保証(AS IS)」で提供され、寄稿者、
寄稿者が代表するまたは後援を受ける組織(もしあれば)、インターネット
ソサエティ、およびIETFはこの情報がいかなる権利も侵害していないとい
う保証、商用利用および特定目的への適合性への保証を含め、また、これ
らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行
われない。
知的所有権
IETFは、本文書で説明される技術の実装または使用に関連すると主張する
知的財産権またはその他の権利の正当性または範囲または、そのような権
利に基づくライセンスが利用できるまたはできない範囲に関して、特定の
立場をとらない。また、IETFはそのような権利を特定するための独立した
努力を行ったと主張するものでもない。RFC文書内の権利に関する手続きに
ついての情報は、BCP 78およびBCP 79に見られる。
IETF事務局に行われたIPR開示、利用可能になったライセンスの保証、また
はこのような所有権の一般的ライセンスまたは使用許可を得るために、本
仕様の実施者またはユーザによって試みられた結果は、IETFオンラインIPR
レポジトリ http://www.ietf.org/ipr で入手することができます。
IETFは、本標準を実装するために必要になるかもしれない技術をカバーす
る可能性のある著作権、特許または特許申請、またはその他の所有権を、
利害関係者が知らせることを推奨する。情報はIETF ietf-ipr@ietf.org に
送信してください。
謝辞
RFCエディターの職務に関する財政援助は現在インターネットソサエティに
よって提供されている。
Lynn, et al. Standards Track [Page 27]
JPNICはインターネットの円滑な運営を支えるための組織です
- JPNIC
-
IPアドレス・AS番号
指定事業者向け各種申請手続/お知らせ
一般ユーザーの方
-
JPNIC会員
会員向け情報/各種変更手続
入会のご案内
