🐈

RFC 6487: X.509 PKIXリソース証明書のプロファイル

2024/03/01に公開

Security

rfc

bgp

tech

要旨

本文書は、インターネット番号リソース(INR)の「使用権」主張の検証をサポートする目的で、X.509証明書の標準プロファイルを定義する。このプロファイルに基づいて発行される証明書は、証明書に記載されるINRの「使用権」の現保有者と見なされる対象者に対する発行者の認可(authorization)を伝えるために使用される。本文書は、リソース公開鍵基盤(RPKI)の証明書および証明書失効リスト(CRL)の構文の標準仕様を含む。この文書では、証明書要求形式に関するプロファイルを規定し、リライング・パーティーのRPKI証明書パスの検証手順も規定する。

本文書の位置付け

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

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

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

著作権表示

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

1. はじめに

本文書は、インターネット番号リソース(INR)、つまりIPアドレスと自律システム(AS)番号の証明書という文脈で使用するX.509証明書[X.509]の標準プロファイルを定義する。このような証明書は「リソース証明書」と呼ばれる。リソース証明書とは、PKIXプロファイル[RFC5280]に準拠し、このプロファイルで規定された制約に準拠する証明書である。リソース証明書は、発行者がサブジェクトに対し、IPアドレスおよび/または自律システム番号の「使用権」を付与したことを証明する。

本文書は、「リソース公開鍵基盤(RPKI)の証明書ポリシー (CP)」[RFC6484]のセクション7で引用されている。これは、そのポリシーの不可欠な部分であり、RPKIで使用される証明書および証明書失効リスト(CRL)構文の標準仕様である。本文書では、証明書要求形式のプロファイルと、リライング・パーティー(RP)のRPKI証明書パスの検証手順も規定する。

リソース証明書は、RPKI証明書ポリシー(CP)[RFC6484]に準拠した方法で使用される。RPKIはパブリックINRを割り振りおよび/または割り当てるエンティティによって発行されるため、RPKIはパブリックINRの配布機能と連携する。INRが番号レジストリによってエンティティに割り振られるか、割り当てられる場合、この割り当ては関連するリソース証明書によって記述できる。この証明書は番号レジストリが発行し、証明書サブジェクトの鍵を証明書に列挙されたINRに結び付ける。非常に重要な拡張であるIPアドレス委任拡張やAS識別子委任拡張[RFC3779]は、発行者がサブジェクトに割り振られた、または割り当てられたINRを列挙する。

リソース証明書のリライング・パーティー(RP)検証は、セクション7.1に規定される方法で行われる。この検証手順は、[RFC5280]のセクション6に記載されている手順とは以下の点で異なる。

INR拡張によって課される追加の検証処理が必要である。
CRL発行者とリソース証明書発行者の公開鍵の一致確認が必要である。
リソース証明書はこのプロファイルに準拠することが要求される。

このプロファイルは、リソース証明書に使用されるフィールドのうち、証明書が有効であるために存在しなければならない(MUST)フィールドを定義する。明示的に言及されていない拡張はすべて存在しなければならない(MUST)。RPKIで使用されるCRLについても同様であり、本文書でプロファイルを規定する。RPKI CPに準拠する認証局(CA)は、このプロファイルと一致する証明書とCRLを発行しなければならない(MUST)。

1.1. 用語

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

本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、[RFC2119]の記述にしたがって解釈される。

2. 証明書内のリソースの記述

証明書のサブジェクトと、そのサブジェクトが現在管理しているINRとの関連付けを記述するためのフレームワークは、[RFC3779]に記述されている。このプロファイルはさらに以下のことを必要とする。

すべてのリソース証明書には、IPアドレス委任または自律システム識別子委任拡張のいずれか、あるいは両方を含まなければならない(MUST)。
これらの拡張は重要(critical)としてマークしなければならない(MUST)。
リソース拡張フィールドには、「inherit」構造を使用する場合を除いて、[RFC3779]で定義しているように、最大スパン範囲と最大スパン・プレフィックス・マスクを持つINRを記述するソートされた標準形式を使用しなければならない(MUST)。

リソース証明書を検証する際、RPは、発行者のリソース証明書に記載されているINRが、検証対象のリソース証明書のINRを包含していることを検証しなければならない(MUST)。この文脈において、「包含」(encompass)とは発行者のINRがサブジェクトのINRと同一、あるいはサブジェクトのINRの厳密なスーパーセット(上位集合)であることを考慮に入れる。

3. RPKIにおけるエンド・エンティティ(EE)証明書と署名機能

[RFC6480]に記載されているように、RPKIにおけるエンド・エンティティ(EE)証明書の主な機能は、証明書に記載されているINRの使用に関連する署名済みオブジェクト、例えば、検証経路オリジン認可(ROA)やマニフェストなどの検証である。

EE証明書に関連付けられた秘密鍵は、1つのRPKI署名済みオブジェクトに署名するために使用される。つまり、EE証明書は1つのオブジェクトのみを検証するために使用される。EE証明書は、暗号メッセージ構文(CMS)の署名済みデータ構造[RFC6488]の一部としてオブジェクトに埋め込まれる。EE証明書と署名済みオブジェクトの間には1対1の関係があるため、証明書の失効は対応する署名済みオブジェクトを効果的に失効させることができる。

EE証明書は、一連の署名済みオブジェクトを検証するために使用され、シーケンス内の各署済みオブジェクトは、リポジトリ公開ポイント内の前の署名済みオブジェクトのインスタンスを上書きする。つまり、任意の時点で、リポジトリ公開ポイント内の署名済みオブジェクトは、1つのインスタンスのみが公開される。(例えば、EE証明書は一連のマニフェストを署名するために使用しもよい(MAY)[RFC6486])。このようなEE証明書は、「順次使用」(sequential use) EE証明書と呼ばれる。

署名済みオブジェクトの1つのインスタンスのみを検証するために使用され、それ以降または他の検証という文脈で使用されないEE証明書は、「1回限り使用の」EE証明書と呼ばれる。

4. リソース証明書

リソース証明書とは、PKIXプロファイル[RFC5280]に準拠した有効なX.509公開鍵証明書で、このセクションに列挙されているフィールドが含まれる。[RFC5280]との相違点のみを以下に記載する。

オプション(OPTIONAL)であると特に明記されていない限り、ここに列挙されているフィールドはすべて存在しなければならず(MUST)、他のフィールドは準拠するリソース証明書に現れてはならない(MUST NOT)。ここにフィールド値が指定されている場合、準拠するリソース証明書はこの値を使用しなければならない(MUST)。

4.1. バージョン

リソース証明書はX.509バージョン3の証明書であるため、バージョンは3でなければならない(MUST)(つまり、このフィールドの値は2である)。

RPは、([RFC5280]とは対照的に)バージョン1またはバージョン2の証明書を処理する必要はない。

4.2. シリアル番号

シリアル番号は、特定のCAが発行する証明書ごとにユニークな正の整数値である。

4.3. 署名アルゴリズム

このプロファイルで使用するアルゴリズムは[RFC6485]で規定されている。

4.4. 発行者

このフィールドの値は、有効なX.501識別名である。

発行者名はCommonName属性のインスタンスを1つ含まれなければならず(MUST)、serialNumber属性のインスタンスを1つ含んでもよい(MAY)。両方の属性が存在する場合は、セットとして表示することが推奨される(RECOMMENDED)。 CommonName属性は、ASN.1のPrintableString型[X.680]で符号化しなければならない(MUST)。発行者名は、発行者の身元を説明するものではない。

RPKIは、セキュリティ上の理由から、発行者名がグローバルにユニークであることに依存しない。ただし、衝突の可能性を最小限に抑える方法で発行者名を生成することが推奨される(RECOMMENDED)。この推奨事項を満たす(非・規範的な)名前生成メカニズムについては、セクション8を参照のこと。

4.5. サブジェクト

このフィールドの値は有効なX.501識別名[RFC4514]であり、発行者名と同じ制約に従う。

RPKIでは、サブジェクト名はサブジェクト(対象者)が決めるものではなく、発行者が決定する[RFC6481]。発行者が認証する個別の下位CAおよびEEは、発行者ごとにユニークなサブジェクト名を使用して識別されなければならない(MUST)。この文脈では、「個別」(distinct)とは、エンティティと特定の公開鍵として定義される。発行者は、サブジェクトの鍵ペアが変更された場合(つまり、CAがサブジェクトの鍵更新の一環として証明書を発行する場合)、別のサブジェクト名を使用する必要がある(SHOULD)。サブジェクト名は、サブジェクトの身元を説明することを意図したものではない。

4.6. 有効期間

証明書の有効期間は、証明書の有効期間が開始日(notBefore)と証明書の有効期間が終了する日付 (notAfter)の2つの日付のSEQUENCEとして表される。

通常、CAは発行された証明書を検証するために使用されるCAの証明書の有効期間よりも長い有効期間を持つ証明書を発行しないよう勧告されるが、このプロファイルの文脈では、CAは、CAの証明書の有効期間を超える有効期間を持つ下位証明書を発行する正当な根拠があっても良い(MAY)。

4.6.1. notBefore

「notBefore」時刻は、証明書の生成時刻よりも前に設定してはならない(SHOULD)。

RPKIでは、このフィールドの値が、上位の証明書の同じフィールド値より前の日付を持っても、証明書としては有効である。リライング・パーティーは、RPによる証明書の有効性の検証範囲は、現在の時点における有効性に特化しているため、この時刻情報から、証明書が過去のある時点で有効であったこと、または将来のある時点で有効であることを推論しようとしてはならない(SHOULD NOT)。

4.6.2. notAfter

「notAfter」時刻は、発行者とサブジェクトの間で現在行われているリソース割り振りまたは割り当ての取り決めの予想される有効期間を表す。

このフィールド値が、上位証明書の同じフィールド値より後の日付を持っても、証明書としては有効である。同じ注意事項が、現時点以外の時刻における証明書の有効性に関するRPの想定(assumptions)にも適用される。

4.7. サブジェクトの公開鍵情報

このプロファイルで使用されるアルゴリズムは、[RFC6485]で規定されている。

4.8. リソース証明書の拡張

準拠するリソース証明書には、特に明記されている場合を除き、以下のX.509 v3拡張が存在しなければならない(MUST)。リソース証明書の各拡張は、重要(critical)または重要でない(non-critical)のいずれかを指定する。証明書を使用するシステムは、認識できない重要な拡張に遭遇した場合、証明書を拒否しなければならない(MUST)。ただし、認識できな重要ではない(non-critical)拡張は無視してもよい(MAY)[RFC5280]。

4.8.1. 基本制約

基本制約(Basic Constraints)拡張フィールドは、リソース証明書プロファイルの重要な拡張であり、サブジェクトがCAである場合には必ず存在しなければならず(MUST)、そうでなければ存在してはならない(MUST NOT)。

発行者は、「cA」ブール値が設定されているかどうかを決定する。

パス長制約(Path Length Constraint)は、RPKI証明書では規定されておらず、存在してはならない(MUST NOT)。

4.8.2. サブジェクト鍵識別子

この拡張は、すべてのリソース証明書に含めなければならない(MUST)。この拡張は重要ではない(non-critical)。

リソース証明書に使用される鍵識別子は、[RFC5280]のセクション4.2.1.2に記載されているように、サブジェクト公開鍵をDERで符号化したASN.1ビット列の値の160ビットSHA-1ハッシュである。

4.8.3. オーソリティ鍵識別子

この拡張は、「自己署名」証明書を発行するCAを除き、すべてのリソース証明書に記載しなければならない(MUST)。自己署名証明書では、CAはこの拡張を含め、サブジェクト鍵識別子と同じ設定をしてもよい(MAY)。authoritativeCertIssuerフィールドとauthoritativeCertSerialNumberフィールドは存在してはならない(MUST NOT)。この拡張は重要ではない(non-critical)。

リソース証明書に使用される鍵識別子は、[RFC5280]のセクション4.2.1.1に記載されているように、発行者の公開鍵をDERで符号化したASN.1ビット列の値の160ビットSHA-1ハッシュである。

4.8.4. 鍵の用途(Key Usage)

この拡張は重要な拡張であり、必ず存在しなければならない(MUST)。

認証局のみに発行される証明書では、keyCertSignビットとCRLSignビットがTRUEに設定され、このビットのみはTRUEに設定しなければならない(MUST)。

EE証明書では、digitalSignatureビットをTRUEに設定しなければならず(MUST)、TRUEに設定する唯一のビットでなければならない(MUST)。

4.8.5. 拡張鍵の使用法

拡張鍵使用法(EKU)拡張は、RPKIのCA証明書も含めてはならない(MUST NOT)。この拡張は、RPKIオブジェクト(ROAやマニフェストなど)を検証するために使用されるEE証明書にも含めてはならない(MUST NOT)。この拡張は重要とマークしてはならない(MUST NOT)。

EKU拡張は、ルータや他のデバイスに発行されるEE証明書に含めても良い(MAY)。EKU OIDの許可される値は、RPKIプロファイルを採用し、そのようなEKUの使用を動機付けるアプリケーション固有の要件を特定する他のIETFワーキング・グループが発行する標準化過程のRFCで規定される。

4.8.6. CRL配布ポイント

この拡張は、「自己署名」証明書を除き、必ず存在しなければならないが(MUST)、重要ではない。自己署名証明書では、この拡張を省略しなければならない(MUST)。

このプロファイルでは、CRLの対象範囲は、このCA発行者が発行したすべての証明書とする。

CRL配布ポイント(CRLDP)拡張は、この発行者が発行した証明書に関連付けられたCRLの場所を指定する。RPKIは、URI[RFC3986]形式のオブジェクト識別を使用する。推奨されるURIアクセス・メカニズムは、発行者ごとに1つの包括的なCRLを参照する1つのrsync URI (「rsync://」)[RFC5781]である。

このプロファイルでは、証明書発行者はCRL発行者でもあるので、CRLIssuerフィールドは省略しなければならず(MUST)、distributionPointフィールドは存在しなければならない(MUST)。Reasonsフィールドは省略しなければならない(MUST)。

distributionPointはfullNameフィールドを含まなければならず(MUST)、nameRelativeToCRLIssuerを含んではならない(MUST NOT)。generalNameの形式はURI 型でなければならない(MUST)。

distributionPoint値のシーケンスは、1つの DistributionPointのみ含めなければならない(MUST)。DistributionPointには複数のURI値が含んでも良い(MAY)。rsync URI[RFC5781]は DistributionPointに存在しなければならず(MUST)、この発行者のCRLの最新のインスタンスを参照しなければならない(MUST)。rsync URIに加えて、この CRLの代替アクセス・メカニズムを表す他のアクセスフォームURIを使用してもよい(MAY)。

4.8.7. 機関情報アクセス

RPKIの文脈では、この拡張は、拡張が含まれる証明書の発行者の証明書の発行ポイントを識別する。このプロファイルでは、「自己署名」証明書を除き、直属の上位証明書の公開ポイントへの参照が1つ存在しなければならないが(MUST)、この場合、拡張を省略しなければならない(MUST)。この拡張は重要ではない。

このプロファイルは、URI形式のオブジェクト識別を使用する。推奨されるURIアクセス・メカニズムは「rsync」であり、id-ad-caIssuersというaccessMethod値を持つrsync URI[RFC5781]を指定しなければならない(MUST)。このURIは、この発行者をサブジェクトとする証明書の発行ポイント(発行者の直属の上位証明書)を参照しなければならない(MUST)。同じオブジェクトを参照する他の accessMethod URIも、この拡張の値シーケンスに含めても良い(MAY)。

CAは、発行するCA証明書に永続的なURL名スキームを使用しなければならない(MUST) [RFC6481]。これは、再発行された証明書が、公開リポジトリ内で以前に発行された(同じサブジェクトに対する)証明書を上書きすることを意味する。このようにして、再発行された(CA)証明書に従属する証明書は、機関情報アクセス(AIA)拡張ポインタを一定に維持できるため、親証明書が再発行されても再発行する必要はない。

4.8.8. サブジェクト情報アクセス

RPKIの文脈では、このサブジェクト情報アクセス (SIA)拡張は、証明書のサブジェクトが署名したプロダクトの発行ポイントを識別する。

4.8.8.1. CA 証明書のSIA

この拡張は、必ず存在しなければならず(MUST)、重要ではないとマークしなければならない(MUST)。

この拡張は、id-ad-caRepositoryのaccessMethodのインスタンスを持たなければならず(MUST)、URIのaccessLocation形式はrsync URI[RFC5781]を指定しなければならない(MUST)。このURIは、このCAが発行したすべての公開資料、つまり、このCAが発行したすべての有効なCA証明書、公開EE証明書、現在のCRL、マニフェスト、およびEE証明書によって検証された署名済みオブジェクトを含むディレクトリを指す[RFC6481]。id-ad-caRepositoryのaccessMethodを持つ他のaccessDescription要素が存在してもよい(MAY)。そのような場合、accessLocation値は、同じディレクトリに対してサポートされる代替URIアクセス・メカニズムを記述する。このaccessDescriptionシーケンスにおけるURIの順序は、RPが使用するアクセス方法に対するCAの相対的な優先順位を反映しており、シーケンスの最初の要素はCAによって優先付けされる。

この拡張は、id-ad-rpkiManifestのaccessMethodを持つAccessDescriptionのインスタンスと、accessLocationのrsync URI [RFC5781]形式を持つ

id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }

id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 }

を持たなければならない(MUST)。

URIは、オブジェクトURLとしてCAの公開オブジェクトのマニフェスト[RFC6486]を指す。他のaccessDescription要素は、id-ad-rpkiManifest accessMethodのために存在しても良い(MAY)。accessLocation値は、同じマニフェスト・オブジェクトに対する代替アクセス・メカニズムを示す。

4.8.8.2. EE証明書のSIA

この拡張は存在しなければならず(MUST)、重要ではないとマークしなければならない(MUST)。

この拡張には、id-adsignedObjectのaccessMethodのインスタンスと、rsync URI [RFC5781]を含めなければならない(MUST) URIのaccessLocation 形式を持つ

id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 }

を持たなければならない(MUST)。このURIは、このEE証明書[RFC6481]を使用して検証される署名済みオブジェクトを指す。id-ad-signedObject accessMethodには、他のaccessDescription要素が存在する場合がある。accessLocation値は、同じオブジェクトに対する代替URIアクセス・メカニズムを示し、EEがサポートするアクセス・メカニズムに対する相対的な優先順位を示す。

他のAccessMethodをEE証明書のSIAに使用してはならない(MUST NOT)。

4.8.9. 証明書ポリシー

この拡張は存在しなければならず(MUST)、重要とマークされなければならない(MUST)。RPKI CP[RFC6484]で規定されているように、正確に1つのポリシーを含めなければならない(MUST)。

4.8.10. IPリソース

すべてのRPKI証明書には、IPリソース拡張やASリソース拡張のいずれか、またはその両方が存在しなければならず(MUST)、存在する場合は重要とマークしなければならない(MUST)。

この拡張には、[RFC3779]に従ったIPアドレス・リソースのリストが含まれる。この値は、特定のアドレス・ファミリー識別子(AFI)値の「inherit」要素を指定することができる。パブリック・インターネットで使用する公開番号リソースを記述するリソース証明書の文脈では、Subsequent AFI (SAFI)値は使用してはならない(MUST NOT)。

この拡張は、空でないIPアドレス・レコードを指定するか、「inherit」設定を使用して、この証明書のIPアドレス・リソースが証明書の発行者のIPアドレス・リソースを継承していることを示さなければならない(MUST)。

4.8.11. ASリソース

すべてのRPKI証明書には、ASリソース拡張やIPリソース拡張のいずれか、またはその両方が存在しなければならず(MUST)、存在する場合は重要とマークしなければならない(MUST)。

この拡張には、[RFC3779]に従ったAS番号リソースのリストが含まれるか、「inherit」要素を指定することができる。ルーティング・ドメイン識別子(RDI)の値はこのプロファイルではサポートされていないため、使用してはならない(MUST NOT)。

この拡張は、空でないAS番号レコード・セットを指定するか、「inherit」設定を使用して、この証明書の発行者のAS番号リソース・セットが証明書の発行者のAS番号リソース・セットを継承していることを示さなければならない(MUST)。

5. リソース証明書失効リスト

各CAは、[RFC5280]に準拠するバージョン2 CRLを発行しなければならない(MUST)。([RFC5280]とは対照的に) RPはバージョン1 CRLを処理する必要はない。CRLの発行者はCAである。このプロファイルに準拠するCRLは、間接CRLまたはデルタCRLを含めてはならない(MUST NOT)。各CRLの範囲は、このCAが発行したすべての証明書でなければならない(MUST)。

発行者名は、上記セクション4.4と同様である。

同一CAから複数のCRLが発行された場合、「CRL番号」フィールドの値が最も大きいCRLを、このCAが発行した他のすべてのCRLよりも優先する。

このプロファイルに基づいて発行されるCRLで使用されるアルゴリズムは[RFC6485]で規定されている。

CRLの内容は、CAによって失効された、有効期限が切れていないすべての証明書のリストである。

RPKI CAは、発行するすべてのCRLに、オーソリティ鍵識別子(AKI)とCRL番号という2つの拡張を含めなければならない(MUST)。 RPは、これらの拡張を含むCRLを処理できるように準備しなければならない(MUST)。他のCRL拡張は許可されない。

失効した各リソース証明書について、シリアル番号と失効日の2つのフィールドのみが存在しなければならず(MUST)、他のフィールドはすべて存在してはならない(MUST NOT)。このプロファイルではCRLエントリ拡張はサポートされておらず、CRLエントリ拡張はCRL内に存在してはならない(MUST NOT)。

6. リソース証明書リクエスト

リソース証明書要求は、PKCS#10または証明書要求メッセージ形式(CRMF)のいずれかを使用してもよい(MAY)。CAはPKCS#10での証明書発行をサポートしなければならず (MUST)、CRMFリクエストをサポートしてもよい(MAY)。

このプロファイルでは、証明書応答が定義されていないことに留意する。CA証明書リクエストに対しては、CAは[RFC6484]に従って、リソース証明書をリポジトリに配置する。EE証明書要求に対する応答は定義されていない。

6.1. PCKS#10プロファイル

このプロファイルは、リソース証明書に関連する[RFC2986]の仕様を改良したものである。PKCS#10に従ってフォーマットされた証明書要求メッセージ・オブジェクトは、証明書発行の最初のステップとしCAに渡される。

SubjectPublicKeyinfoとSIA拡張リクエストを除き、CAは証明書を発行する際、リクエストのどのフィールドも変更することが許される。

6.1.1. PKCS#10リソース証明書要求テンプレートのフィールド

このプロファイルは、CertificationRequestInfoに現れても良い(MAY)フィールドに以下の追加要件を適用する。

Version
このフィールドは必須であり、値は0でなければならない(MUST)。

Subject
このフィールドは省略してもよい(MAY)。存在する場合、このフィールドの値は空 (つまり NULL) である必要がある。その場合、CA は、この CA によって発行された証明書のコンテキスト内で一意のサブジェクト名を生成しなければならない(MUST)。このフィールドが空でないことが許可されるのは、鍵再発行/再発行要求の場合にのみであり、また、CAがそのような状況で名前の再利用を許可するポリシー(証明書運用規定(CPS)で)を採用している場合に限られる。

SubjectPublicKeyInfo
このフィールドは、サブジェクトの公開鍵とその鍵が使用するアルゴリズムを指定する。このプロファイルで使用されるアルゴリズムは、[RFC6485]で規定されている。

Attributes (属性)
[RFC2986]は、属性フィールドを、鍵はOIDであり、値の構造は鍵に依存する鍵と値のペアとして定義する。
このプロファイルで使用される唯一の属性は、[RFC2985]で定義されているextensionRequest属性である。この属性には証明書の拡張を含む。証明書リクエストの拡張に関するプロファイルはセクション6.3で規定する。
このプロファイルは、証明書要求メッセージ・オブジェクトに現れても良い(MAY)フィールドに以下の追加制約を適用する。

signatureAlgorithm
SignatureAlgorithm値は[RFC6485]で規定されている。

6.2. CRMFプロファイル

このプロファイルは、[RFC4211]の証明書要求メッセージ・フォーマット(CRMF)仕様を、リソース証明書に関連するものとして改良したものである。CRMFに従ってフォーマットされた証明書要求メッセージ・オブジェクトは、証明書発行の最初のステップとしてCAに渡される。

SubjectPublicKeyinfoとSIA拡張リクエストを除き、CAは証明書の発行時に要求されたフィールドを変更することができる。

6.2.1. CRMFリソース証明書要求テンプレートのフィールド

このプロファイルは、証明書要求テンプレートに現れるフィールドに以下の追加要件を適用する。

version
このフィールドは省略する必要がある(SHOULD)。存在する場合は、バージョン3証明書の要求を指定しなければならない。

serialNumber
このフィールドは省略しなければならない(MUST)。

signingAlgorithm
このフィールドは省略しなければならない(MUST)。

issuer
このプロファイルではこれを省略しなければならない(MUST)。

Validity
このフィールドは省略してもよい(MAY)。省略した場合、CAはCAが決定した有効期限を持つ証明書を発行する。指定された場合、CAは要求された値をCAが決定した日付で上書きしてもよい(MAY)。

Subject
このフィールドは省略してもよい(MAY)。存在する場合、このフィールドの値は空(つまりNULL)である必要がある。その場合、CAは、このCAが発行する証明書の文脈で一意のサブジェクト名を生成しなければならない(MUST)。このフィールドが空ではないことが許されるのは、鍵の再発行/再発行要求の場合のみであり、CAが(そのCPSにおいて)そのような状況で名前の再利用を許可するポリシーを採用している場合に限られる。

PublicKey
このフィールドは存在しなければならない(MUST)。

extensions
証明書リクエストの拡張のプロファイルは、セクション6.3で規定される

6.2.2. リソース証明書リクエスト制御フィールド

このプロファイルでは、以下の制御フィールドがサポートされている。

Authenticator Control
意図されたサブジェクトの認証モデルは「長期」モデルで、[RFC4211]で提示されているガイダンスは、Authenticator Controlフィールドが使われている。

6.3. 証明書要求における証明書拡張属性

次の拡張は、PKCS#10またはCRMF証明書要求に含めることができる。他の拡張は証明書要求に含めてはならない。このプロファイルは、これらの拡張に対し、以下の追加制約を課す。

BasicConstraints(基本制約)
これを省略すると、CAはEE証明書を発行する(したがって、BasicConstraints拡張は含まれない)。
pathLengthConstraintはこのプロファイルではサポートされていないため、このフィールドは省略しなければならない(MUST)。
CAは、TRUE (CA証明書要求)に設定されている場合、cAブール値を尊重しても良い(MAY)。このビットが設定されている場合、サブジェクトが CA証明書を要求していることを示す。
CAは、cAビットがFALSEに設定されている場合(EE証明書要求)、これを尊重しなければならない(MUST)。この場合、対応するEE証明書にはBasicConstraints拡張が含まれない。

KeyUsage(鍵の使用法)
CAは、KeyCertSignおよびcRLSignのKeyUsage拡張が存在する場合、これを尊重してもよい(MAY)。ただし、BasicConstraintsのSubjectTypeサブフィールドが指定されている場合、これと一致していることを条件とする。

ExtendedKeyUsage(拡張鍵の使用法)
CAは、KeyCertSignおよびcRLSignのExtendedKeyUsage拡張が存在する場合、これを尊重してもよい(MAY)。ただし、BasicConstraintsのSubjectTypeサブフィールドが指定されている場合、これと一致していることを条件とする。

SubjectInformationAccess(サブジェクト情報アクセス)
このフィールドは存在しなければならず(MUST)、フィールド値はがセクション4.8.8に規定される要件に適合する場合、 CAはその値を尊重する必要がある(SHOULD)。CAがこのフィールドの要求された値を受け入れることができない場合、CAは証明書要求を拒否しなければならない(MUST)。

7. リソース証明書の検証

このセクションでは、リソース証明書の検証手順について説明する。これは、[RFC5280]のセクション6に記載されている一般的な手順を改良したものである。

7.1. リソース拡張の検証

IPリソース拡張とASリソース拡張[RFC3779]は、INRのための重要な拡張を定義する。これらは、IPv4およびIPv6アドレス範囲とAS番号セットのASN.1符号化表現である。

有効なリソース証明書は、有効なIPアドレスおよび/またはAS番号リソース拡張を持たなければならない(MUST)。リソース証明書を検証するには、リソース拡張も検証しなければならない(MUST)。この検証プロセスは、リソースセットの比較定義に依存する:

more specific
連続する2つのIPアドレス範囲または連続する2つのAS番号範囲AとBがある場合、範囲Bに範囲Aで記述されるすべてのIPアドレスまたはAS番号を含み、範囲Bが範囲Aより大きい場合、AはBよりも「more specific」となる。

equal(等しい)
2つの連続するIPアドレス範囲または2つの連続するAS番号範囲AとBが与えられたとき、範囲Aが範囲Bによって記述されるIPアドレスまたはAS番号の同じコレクションを正確に記述する場合、AはBと「等しい」。[RFC3779]は「継承」(inheritance)の定義は、この「等しい」(equality)比較に等価である。

encompass (包含)
2つのIPアドレスとAS番号の集合XとYが与えられたとき、集合Y内のIPアドレスまたはAS番号要素の連続するすべての範囲について、その範囲要素が集合X内の連続する範囲要素よりも「more specific」であるか、「equal」のいずれかの場合、XはYを「encompasses」(包含)する。

証明書パスの文脈における証明書のリソース拡張の検証(セクション7.2参照)には、証明書パス内の隣接する証明書のペア(証明書「x」および「x+1」)ごとに、以下のことが含まれる。証明書「x」に記載される番号リソースは、証明書「x+1」に記載される番号リソースを「包含」し、トラストアンカー情報に記載されるリソースは、証明書パスの最初の証明書に記載されるリソースを「包含」する。

7.2. リソース証明書パスの検証

対象リソース証明書を使用した署名済みリソース・データの検証は、対象リソース証明書の公開鍵を使用して、署名済みリソース・データのデジタル署名が有効であることを検証することと、パス検証プロセスを使用して、RPKIの文脈でのリソース証明書を検証することから構成される。このパス検証プロセスは、特に、見込み(prospective)証明書パス(n個の一連の証明書)が以下の条件を満たすことを検証する。

{1, ..., n-1}内のすべての「x」に対して、証明書「x」のサブジェクトは証明書(「x」+1)の発行者である。
証明書「1」はトラストアンカーによって発行されている。
証明書「n」は検証される証明書である。そして、
{1, ..., n}のすべての「x」に対して、証明書「x」は有効である。

証明書の検証では、[RFC5280]のセクション6で規定されている証明書パスの検証基準に加えて、以下の条件がすべて満たされていることを検証する必要がある。

証明書は発行者の公開鍵と署名アルゴリズムを使用して検証できる。
現在時刻が証明書の有効期間の開始値と終了値の範囲内にある。
証明書には、この仕様で定義されるとおり、存在しなければならない(MUST)フィールドがすべてて含まれ、この仕様で許容値として定義される選択されたフィールドの値が含まれている。
この仕様で存在してはならない(MUST NOT)と定義されているフィールドまたはフィールド値は、証明書では使用できない。
発行者が証明書を失効していない。失効した証明書は、証明書のシリアル番号が発行者の現在のCRLに記載することで、証明書のCRLDPで識別される。そして、CRL自体が有効であり、CRL上の署名の検証に使用される公開鍵が、証明書自体を検証するために使用された公開鍵と同じである。
リソース拡張データが、この発行者をサブジェクトとする有効な証明書(証明書パスで定義された順序シーケンスの文脈における前の証明書)に含まれるリソース拡張データによって「包含」されている。
証明書パスはトラストアンカーによって発行された証明書から始まり、証明書パス内の証明書「x」のサブジェクトが証明書パスの証明書「x+1」の発行者と一致し、証明書「x」の公開鍵が証明書「x+1」の署名値を検証できるような、証明書パス全体にまたがる署名チェーンが存在する。

証明書検証アルゴリズムは、これらのテストを任意の順序で実行してもよい(MAY)。

このプロセスで使用される証明書とCRLは、定期的な分散公開リポジトリ構造[RFC6481]全体の同期によって維持され、ローカルに維持されるキャッシュで見つけても良い(MAY)。

RPに対する潜在的なサービス拒否(DOS)攻撃を引き起こす手段として、恣意的に長い証明書パスにしたり、ループを含むパスを生成しようと試みる可能性がある。この手順を実行するRPは、そのような不正な証明書パス構造を検証する試みに関連する問題を回避するために、さらに証明書パス検証プロセスを停止に誘導するヒューリスティックを適用しても良い(MAY)。リソース証明書検証の実装は、証明書パスの長さがローカルに定義された設定パラメータを超える場合、検証失敗で停止してもよい(MAY)。

8. デザインノート

次の注記は、証明書プロファイルの設計において行われたいくつかの設計上の選択の背後にある考慮事項について、補足的な解説を提供する。これらの注記は、非・規範的なものである。つまり、本文書のこのセクションは、プロファイル仕様の正式な一部を構成するものではなく、RFC 2119で定義されているキーワードの解釈は、本文書のこのセクションには適用されない。

証明書拡張:
このプロファイルは、他の重要な拡張または重要ではない拡張の使用を許可しない。この制限の根拠は、リソース証明書プロファイルが特定の定義された用途を目的としているためである。この文脈において、RPがその拡張を理解せずに有効な証明書とみなす可能性がある重要ではない拡張を追加した証明書を持つことは不適切である。なぜなら、RPが拡張を理解する立場にあった場合、何らかの形でこの有効性の最初の判断と矛盾したり、資格を与えることになるからである。このプロファイルは、拡張よりもミニマリズムの立場をとる。関連するRPKIの具体的な目標は、INR配布階層内の割り当てとその前後関係を記述する調整された証明書構造を通じて、INR割り当て構造を正確に一致させることにある。このプロファイルは、これらの要件を満たすように構造化されたリソース証明書を定義する。

認証局と鍵の値:
このプロファイルは、名前付きエンティティと鍵ペアの組み合わせとして、CAのインスタンスの定義を使用する。この定義では、CAのインスタンスは鍵ペアをロールオーバーできない。しかし、エンティティは新しいインスタンスを生成できる。新しい鍵ペアを持つCAを作成し、署名済みのすべての下位プロダクトを新しいCAにロールオーバーする[RFC6489]。
これは、サブジェクト名の管理、CRLのスコープ、リポジトリ公開ポイント管理という点で多くの意味を持つ。

CRLスコープと鍵の値:
CRLスコープについて、このプロファイルは、CAが一度に1つのCRLを発行し、そのCRLのスコープがこのCAが発行するすべての証明書であることを規定する。CAインスタンスは1つの鍵ペアに結び付けられるため、これはCAの公開鍵、CAのCRLの検証に使用される鍵、およびそのCRLによって失効された証明書を検証するために使用される鍵がすべて同じ鍵値であることを意味する。

リポジトリ公開ポイント:
CAの定義は、リポジトリ公開システムの設計に影響する。鍵ロールオーバー・イベントにおける強制的な証明書の更新量を最小限に抑えるため、同じエンティティを参照するが異なる鍵値を持つすべてのCAインスタンスに同じリポジトリ公開ポイントを使用するリポジトリ公開体制は、証明書の再生成の範囲を、直下の証明書のみに最小限に抑えられる。これについては、[RFC6489]に記載されている。

サブジェクト名:
このプロファイルは、サブジェクト名が発行者ごとに一意でなければならないことを規定しており、サブジェクト名が(一意性の保証という点で)グローバルに一意でなければならないとは規定していない。これは、PKIが分散型RPKIであるという性質によるもので、認証局が追加の重要な外部依存関係に頼ることなく、単純な RPKI全体の一意の名前空間を調整する準備ができていないことを意味する。CAは、名前の衝突の可能性を最小限に抑えるサブジェクト名生成手順を使用するよう勧める。
これを実現する1つの方法として、CAは、識別名のCommonNameコンポーネントを、CAが発行する証明書のサブジェクトである任意のエンティティの定数値として使用し、DistinguishedNameのserialNumberコンポーネントをサブジェクト公開鍵値のハッシュから得られる値に設定するサブジェクト名プラクティスを使用する。
CAがDistinguishedNameのserialNumberコンポーネントを使用しないことを選択した場合、CAが名前に40ビット以上のエントロピーを含むランダムなコンポーネントを持つCommonNameを生成することは有益だと考えられる。これを実現するための非・規範的な推奨事項には以下のようなものがある。

サブジェクトの公開鍵のハッシュ (ASCII HEXで符号化)。
例: cn="999d99d564de366a29cd8468c45ede1848e2cc14"
Universally Unique IDentifier (UUID)[RFC4122]
例: cn="6437d442-6fb5-49ba-bbdb-19c260652098"
ランダムに生成された長さ20以上のASCII HEX符号化文字列:
例: cn="0f8fcc28e3be4869bc5f8fa114db05e1">
(20個のASCII HEX数字の文字列には80ビットのエントロピーがある)
内部データベース鍵または加入者IDと上記のいずれか1つを組み合わせたもの
例: cn="<DBkey1> (6437d442-6fb5-49ba-bbdb-19c2606520980)"
(発行CAは、commonNameからデータベース鍵または加入者IDを抽出できることを望む場合がある。発行CAだけがcommonName、データベース鍵、エントロピーのソース(UUIDなど)を解析できればよいため、 PrintableStringの規則に準拠している限り、CAが望む任意の方法で区切ることができる。区切り文字としては、スペース文字、括弧、ハイフン、スラッシュ、疑問符などが使用できる。

9. プロファイルのアジリティに関する運用上の考慮事項

本プロファイルは、リライング・パーティーがプロファイルに準拠しない証明書またはCRLを拒否することを要求する。(このセクションの残りの部分では、「証明書」(certificate)という用語は、証明書とCRLの両方を指すものとして使用する。) これには、[RFC5280]に従って、禁止されているがそれ以外は有効である拡張を含む証明書も含まれる。これは、RPKIで使用される証明書のプロファイル(拡張、許可された属性またはオプション・フィールド、フィールドのエンコーディングなど)の変更は、下位互換性がなくなることを意味する。一般的なPKIの文脈では、おそらくこの制約が深刻な問題を引き起こす可能性がある。RPKIでは、いくつかの要因によって、この種の変更を行うことの難しさを最小限に抑えている。

RPKIは、すべてのリライング・パーティー(RP)がこのシステム内のCAが発行したすべての証明書にアクセスする必要があるという点でユニークであることに留意されたい。RPKI で使用される証明書の重要な更新は、RPKIデータのビューがRP間で異なることのないように、システム内のすべてのCAおよびRPがサポートしなければならない。したがって、段階的な変更には非常に慎重な調整が必要である。セキュリティに関連する目的のために、断片的に新しい拡張を導入したり、既存の標準拡張の使用を部分的に許可することは適切ではない。

X.509証明書拡張の「重要」(critical)フラグを使用することで、この問題を改善できるのではないかと考える人がいるかもしれない。しかし、この解決策は包括的ではなく、セキュリティ上重要な拡張を新たに追加するという問題には対処していない。(というのも、そのような拡張は、すべてのCAおよびRPが普遍的にサポートする必要があるためである。) また、標準的な拡張の中には、発行者の裁量によって、重要または重要でない(non-critical)のいずれかにマーク付けできるが、すべてがこの特性を持つわけではない。つまり、一部の標準拡張は常に重要ではない。さらに、名前内の属性やフィールドや拡張内のオプション・フィールドには、重要という概念はない。したがって、重要フラグはこの問題の解決策にはならない。

一般的なPKIの展開では、CAの数はほとんどなく、RPが多数存在する。ただし、RPKIでは、基本的にRPKI内のすべてのCAもRPでもある。したがって、新しい形式で証明書を発行するために変更する必要があるエンティティ・セットは、これらの新しい証明書を受け入れるために変更する必要があるエンティティ・セットと同じである。これが文字通り真実である限りにおいて、変更のためのCA/RPの調整は、いずれにせよ緊密に連携している。実際には、この一般的な観察には重要な例外がある。小規模なISPやプロバイダに依存しない割り当ての保有者は、地域インターネット・レジストリ(RIR)や、ホールセールのインターネット・サービス・プロバイダ(ISP)が提供する可能性のあるマネージドCAサービスを利用することが予想される。これにより、必要とされる個別のCAの実装数が減少し、証明書発行のための変更が容易になる。また、これらのエンティティは、マネージドCAサービス・プロバイダが提供するRPソフトウェアを利用する可能性が非常に高いと思われる。これにより、個別のRPソフトウェアの実装数を減らすことができる。また、多くの小規模ISP(およびプロバイダに依存しない割り当ての保持者)は、デフォルト経路を採用しているため、RPによるRPKIデータの検証は不要であり、これらのエンティティはRPとして排除されることに留意する。

広く利用可能なPKI RPソフトウェアは、RPKIに不可欠な戦略である大量の証明書をキャッシュしない。また、RPKIリポジトリ・システムの必須要素であるマニフェストまたはROAデータ構造は処理しない。経験上、このようなソフトウェアは失効ステータス・データの処理が不十分であることが分かっている。したがって、既存のRPソフトウェアはRPKIには適切ではないが、いくつかのオープンソース・ツール(例えば、OpenSSLやcryptlibなど)を、RPKI RP実装のための構成要素として使用できる。したがって、RPは、RPKI環境専用に設計され、限られた数のオープンソースから入手可能なソフトウェアを使用することが予想される。現在、複数のRIRと2社がこのようなソフトウェアを提供している。したがって、少数の開発者/保守者の間で、このソフトウェアの変更を調整することは可能である。

将来、リソース証明書プロファイルが変更される場合、例えば、新しい拡張の追加や、許可される名前属性のセットの変更、またはこれらの属性のエンコードの変更など、RPKIでの展開を有効にするために以下の手順が採用される。このモデルは[RPKI-ALG]で説明されているモデルと似ている、より単純である。

この RFCの更新として、新しい文書を発行する。RPKI[RFC6484]のCPは、新しい証明書プロファイルを参照するように更新する。新しいCPは、新しい証明書プロファイルに基づいて発行される証明書の新しいポリシーOIDを定義する。更新された CPでは、新しい証明書(CRL)形式への移行のタイムラインも定義する。このタイムラインは、3つのフェーズと関連する日付が定義する。

フェーズ1が終了した時点で、すべてのRPKI CAは、サブジェクトからの要求があれば、新しいプロファイルに基づく証明書を発行できるようになっていなければならない(MUST)。新しい形式に基づいて発行された証明書には、新しいポリシーOIDが含まれる。
フェーズ2において、CAは新しいプロファイルに基づき証明書を発行しなければならず(MUST)、これらの証明書は旧形式に基づき発行された証明書と共存しなければならない(MUST)。(CAは、新旧の証明書も引き続き発行する。) 新旧の証明書は、ポリシーOIDおよび新しい拡張、エンコーディングなどを除き、同一でなければならない(MUST)。新しい証明書および関連する署名済みオブジェクトは、 RPKI[RPKI-ALG]のアルゴリズム移行で要求されるものと同様に、このフェーズの間、RPKIリポジトリ・システムで共存する。リライング・パーティーは、RPKIリポジトリ・システムから取得した署名済みオブジェクトを処理する際に、新旧の証明書形式を使用してもよい(MAY)。このフェーズの間、両方の形式を処理することを選択したリライング・パーティーは、新旧の形式間で重複するすべての証明書フィールドに対して同じ値を取得する。したがって、いずれかの証明書形式が検証可能であれば、リライング・パーティーはその証明書のデータを受け入れる。これにより、CAはすべてのリライング・パーティーが新しい形式の証明書を処理する準備が整う前に、新しい形式の証明書を発行することができる。
フェーズ3の開始時に、すべてのリライング・パーティーは、新しい形式の証明書を処理できなければならない(MUST)。このフェーズの間、CAは新しい形式でのみ新しい証明書を発行する。古いOIDで発行された証明書は、新しいポリシーOIDを含む証明書に置き換えられるる。リポジトリ・システムは、異なる形式に基づく新旧の証明書を照合する必要がなくなる。

フェーズ3の終了時点で、古いOIDに基づくすべての証明書は置き換えられる。リソース証明書プロファイルRFCは、古い証明書形式のサポートを削除するために置き換えられ、CPは、古いポリシーOIDおよび古いリソース証明書プロファイルRFCへの参照を削除するために置き換えられる。システムは新しい定常状態に戻る。

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

リソース証明書には[RFC5280]と[RFC3779]のセキュリティに関する考慮事項が適用される。[RFC2986]および[RFC4211]のセキュリティに関する考慮事項は、リソース証明書の認証要求に適用される。

リソース証明書PKIは、それ自体、2つ以上の有効な証明書が同じリソースを包含する場合、使用権の主張の一意性に関連するいかなる形の曖昧さも解決することはできない。リソース証明書の発行が、リソースの割り振りと割り当てのステータスと一致する場合、証明書に記載される情報は、割り振りと割り当てデータベースの情報と変わらない。

このプロファイルは、発行された証明書に署名するために使用される鍵が、証明書を失効させることができるCRLの署名に使用される鍵と同じであることを要求し、すなわち証明書の署名を検証するために使用される証明書パスが、証明書を失効させることができるCRLの署名の検証に使用される証明書パスと同じであることを意味する。これは、X.509 PKIで要求されるよりも厳しい制約であり、証明書と対応するCRLに別個の検証パスを使用できるパス検証実装を使用することにリスクがある可能性があることに留意する。サブジェクト名を構成する際に十分なエントロピーを確保することに関して、CAがこのガイドラインに従わなかった結果、RPKI内でサブジェクト名の衝突が発生し、RPが本RPKIプロファイルに準拠しない検証パス構築の実装を使用している状況と組み合わさった場合、サブジェクト名の衝突によって、RPは有効な証明書が失効したと判断する可能性がある。

11. 謝辞

著者らは、本文書をレビューし、文書に組み込まれた文章の多数のセクションを提案してくれたスティーブン・ケントの貴重な貢献に特に感謝する。著者らはまた、この文書の作成とその後のレビューにおける、サンディ・マーフィー、ロバート・キステレキ、ランディ・ブッシュ、ラス・ハウズリー、リカルド・パタラ、ロブ・アウスタインの貢献を認める。本文書には、ロケ・ガリアーノ、ショーン・ターナー、デビッド・クーパーから受け取ったレビュー・コメントも反映されている。

12. 参考文献

12.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.

[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.

[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, May 2008.

[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, February 2010.

[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, February 2012.

[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.

[X.509] ITU-T, "Recommendation X.509: The Directory - Authentication Framework", 2000.

[X.680] ITU-T, "Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", 2002.

12.2. 参考規格

[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.

[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.

[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.

[RPKI-ALG] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for RPKI", Work in Progress, November 2011.

付録A. リソース証明書の例

以下はリソース証明書の例である。

Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer

Data:
  Version: 3 (0x2)
  Serial: 1500 (0x5dc)
  Signature Algorithm: SHA256WithRSAEncryption
  Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s
  Validity
   Not Before: Oct 25 12:50:00 2008 GMT
    Not After : Jan 31 00:00:00 2010 GMT
  Subject: CN=A91872ED
  Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (2048 bit)
    Modulus (2048 bit):
      00:bb:fb:4a:af:a4:b9:dc:d0:fa:6f:67:cc:27:39:
      34:d1:80:40:37:de:88:d1:64:a2:f1:b3:fa:c6:7f:
      bb:51:df:e1:c7:13:92:c3:c8:a2:aa:8c:d1:11:b3:
      aa:99:c0:ac:54:d3:65:83:c6:13:bf:0d:9f:33:2d:
      39:9f:ab:5f:cd:a3:e9:a1:fb:80:7d:1d:d0:2b:48:
      a5:55:e6:24:1f:06:41:35:1d:00:da:1f:99:85:13:
      26:39:24:c5:9a:81:15:98:fb:5f:f9:84:38:e5:d6:
      70:ce:5a:02:ca:dd:61:85:b3:43:2d:0b:35:d5:91:
      98:9d:da:1e:0f:c2:f6:97:b7:97:3e:e6:fc:c1:c4:
      3f:30:c4:81:03:25:99:09:4c:e2:4a:85:e7:46:4b:
      60:63:02:43:46:51:4d:ed:fd:a1:06:84:f1:4e:98:
      32:da:27:ee:80:82:d4:6b:cf:31:ea:21:af:6f:bd:
      70:34:e9:3f:d7:e4:24:cd:b8:e0:0f:8e:80:eb:11:
      1f:bc:c5:7e:05:8e:5c:7b:96:26:f8:2c:17:30:7d:
      08:9e:a4:72:66:f5:ca:23:2b:f2:ce:54:ec:4d:d9:
      d9:81:72:80:19:95:57:da:91:00:d9:b1:e8:8c:33:
      4a:9d:3c:4a:94:bf:74:4c:30:72:9b:1e:f5:8b:00:
      4d:e3
    Exponent: 65537 (0x10001)
  X509v3 extensions:
    X509v3 Subject Key Identifier:
      F4:97:E0:00:47:2A:ED:0F:B8:EC:8C:0C:0B:90:89:
      20:9A:FA:10:9B

    X509v3 Authority Key Identifier:
      keyid:09:53:D0:4A:05:24:2F:2E:E9:39:77:4D:79:
      55:86:BE:71:57:FF:4B

    X509v3 Key Usage: critical
      Certificate Sign, CRL Sign

    X509v3 Basic Constraints: critical
      CA:TRUE

    X509v3 CRL Distribution Points:
      URI:rsync://rpki.apnic.net/repository/A3C38A24
          D60311DCAB08F31979BDBE39/CVPQSgUkLy7pOXdNe
          VWGvnFX_0s.crl

    Authority Information Access:
       CA Issuers - URI:rsync://rpki.apnic.net/repos
          itory/8BDFC7DED5FD11DCB14CF4B1A703F9B7/CVP
          QSgUkLy7pOXdNeVWGvnFX_0s.cer

    X509v3 Certificate Policies: critical
       Policy: 1.3.6.1.5.5.7.14.2

    Subject Information Access:
       CA Repository - URI:rsync://rpki.apnic.net/mem
           ber_repository/A91872ED/06A83982887911DD81
           3F432B2086D636/
       Manifest - URI:rsync://rpki.apnic.net/member_r
           epository/A91872ED/06A83982887911DD813F432
           B2086D636/9JfgAEcq7Q-47IwMC5CJIJr6EJs.mft

     sbgp-autonomousSysNum: critical
       Autonomous System Numbers:
         24021
         38610
         131072
         131074

     sbgp-ipAddrBlock: critical
       IPv4:
         203.133.248.0/22
         203.147.108.0/23

Signature Algorithm: sha256WithRSAEncryption
    51:4c:77:e4:21:64:80:e9:35:30:20:9f:d8:4b:88:60:b8:1f:
    73:24:9d:b5:17:60:65:6a:28:cc:43:4b:68:97:ca:76:07:eb:
    dc:bd:a2:08:3c:8c:56:38:c6:0a:1e:a8:af:f5:b9:42:02:6b:
    77:e0:b1:1c:4a:88:e6:6f:b6:17:d3:59:41:d7:a0:62:86:59:
    29:79:26:76:34:d1:16:2d:75:05:cb:b2:99:bf:ca:c6:68:1b:
    b6:a9:b0:f4:43:2e:df:e3:7f:3c:b3:72:1a:99:fa:5d:94:a1:
    eb:57:9c:9a:2c:87:d6:40:32:c9:ff:a6:54:b8:91:87:fd:90:
    55:ef:12:3e:1e:2e:cf:c5:ea:c3:4c:09:62:4f:88:00:a0:7f:
    cd:67:83:bc:27:e1:74:2c:18:4e:3f:12:1d:ef:29:0f:e3:27:
    00:ce:14:eb:f0:01:f0:36:25:a2:33:a8:c6:2f:31:18:22:30:
    cf:ca:97:43:ed:84:75:53:ab:b7:6c:75:f7:2f:55:5c:2e:82:
    0a:be:91:59:bf:c9:06:ef:bb:b4:a2:71:9e:03:b1:25:8e:29:
    7a:30:88:66:b4:f2:16:6e:df:ad:78:ff:d3:b2:9c:29:48:e3:
    be:87:5c:fc:20:2b:df:da:ca:30:58:c3:04:c9:63:72:48:8c:
    0a:5f:97:71

付録B. 証明書失効リストの例

以下は証明書失効リストの例である。

CRL Name: q66IrWSGuBE7jqx8PAUHAlHCqRw.crl
Data:
  Version: 2
  Signature Algorithm:
    Hash: SHA256, Encryption: RSA
  Issuer: CN=Demo Production APNIC CA - Not for real use,
    E=ca@apnic.net
  This Update: Thu Jul 27 06:30:34 2006 GMT
  Next Update: Fri Jul 28 06:30:34 2006 GMT
  Authority Key Identifier: Key Identifier:
    ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05:
    07:02:51:c2:a9:1c
  CRLNumber: 4
  Revoked Certificates: 1
    Serial Number: 1
    Revocation Date: Mon Jul 17 05:10:19 2006 GMT
    Serial Number: 2
    Revocation Date: Mon Jul 17 05:12:25 2006 GMT
    Serial Number: 4
    Revocation Date: Mon Jul 17 05:40:39 2006 GMT
  Signature:
    b2:5a:e8:7c:bd:a8:00:0f:03:1a:17:fd:40:2c:46:
    0e:d5:64:87:e7:e7:bc:10:7d:b6:3e:39:21:a9:12:
    f4:5a:d8:b8:d4:bd:57:1a:7d:2f:7c:0d:c6:4f:27:
    17:c8:0e:ae:8c:89:ff:00:f7:81:97:c3:a1:6a:0a:
    f7:d2:46:06:9a:d1:d5:4d:78:e1:b7:b0:58:4d:09:
    d6:7c:1e:a0:40:af:86:5d:8c:c9:48:f6:e6:20:2e:
    b9:b6:81:03:0b:51:ac:23:db:9f:c1:8e:d6:94:54:
    66:a5:68:52:ee:dd:0f:10:5d:21:b8:b8:19:ff:29:
    6f:51:2e:c8:74:5c:2a:d2:c5:fa:99:eb:c5:c2:a2:
    d0:96:fc:54:b3:ba:80:4b:92:7f:85:54:76:c9:12:
    cb:32:ea:1d:12:7b:f8:f9:a2:5c:a1:b1:06:8e:d8:
    c5:42:61:00:8c:f6:33:11:29:df:6e:b2:cc:c3:7c:
    d3:f3:0c:8d:5c:49:a5:fb:49:fd:e7:c4:73:68:0a:
    09:0e:6d:68:a9:06:52:3a:36:4f:19:47:83:59:da:
    02:5b:2a:d0:8a:7a:33:0a:d5:ce:be:b5:a2:7d:8d:
    59:a1:9d:ee:60:ce:77:3d:e1:86:9a:84:93:90:9f:
    34:a7:02:40:59:3a:a5:d1:18:fb:6f:fc:af:d4:02:
    d9

著者のアドレス

ジェフ・ヒューストン
アプニック
電子メール: gih@apnic.net
URI: http://www.apnic.net

ジョージ・マイケルソン
アプニック
電子メール: ggm@apnic.net
URI: http://www.apnic.net

ロバート・ルーマンズ
アプニック
電子メール: robertl@apnic.net
URI: http://www.apnic.net

変更履歴

2024.3.1
2024.4.12: AIA=機関情報アクセス

GitHubで編集を提案