|
ネットワーク WG Request for Comments： 2527 |
S. Chokhani CygnaCom Solutions, Inc. W. Ford VeriSign, Inc. 1999年3月 |
このメモは、インターネットコミュニティに情報提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (1999). All Rights Reserved.
本書は、 CA認証機関やPKI(公開鍵インフラストラクチャ)のための証明書ポリシー、 もしくはCPS (certification practice statements)の執筆者を支援するフレームワークを提供します。 特に、このフレームワークは、 証明書ポリシーもしくはCPSの規定の際に(執筆者の思慮分別において)潜在的に網羅される必要がある論点についての包括的なリストを提供します。
公開鍵証明書(以降、「証明書」)は、 公開鍵の値を主体(個人、組織、アカウント、 サイト等)を識別する情報のセットに結合させます。 この際、対応するプライベート鍵の使用と関連します。 (この主体は、 その証明書の「サブジェクト( subject )」として知られています。 証明書は、 「証明書のユーザ」もしくは使用する必要のある「信頼する主体」によって使用され、 その証明書で配布される公開鍵の正確性に依存します。 (証明書ユーザは典型的には、 証明書のサブジェクト主体からのデジタル署名を検証する主体、もしくは、 対象に暗号化されたデータを送る主体です。) 証明書のユーザが証明書の中に組み込まれた結合を信頼できる度合いは、 いくつかの要素に依存します。 これらの要素には、 サブジェクトを認証(authenticate)する際の認証機関(CA)によって遵守される実践、 そのCAの運用ポリシー、手続き、セキュリティ統制(例えば、 プライベート鍵を防護する際の)サブジェクトの義務、 CAの公式表明された実行や法的な義務(例えば、 責任の保証や制限)が含まれます。
X.509 v3証明書には、ひとつ、もしくは複数の特定の証明書ポリシーが、 その証明書 [ISO1] に適用さることを宣言するフィールドに含まれます。 X.509によれば証明書ポリシーは、 「共通のセキュリティ要件をもつ特定のコミュニティ、かつ／または、 アプリケーションのクラスに対する証明書の適用可能性を示すルールセットです。」 認証ポリシーは、証明書とそれに結合されたものが、 特定のアプリケーションの用途で十分に信頼できるものであるか、 の判断を助けるために、証明書ユーザによって使用されます。 証明書ポリシーのコンセプトは、 PEM (Internet Privacy Enhanced Mail) [PEM1] のために開発されたポリシー表明コンセプトの発展であり、 [BAU1] に基づいて拡張されました。
CAが、証明書を発行または管理する際に従う実践について、 より詳細な記述は、 CAによって発行またはCAによって参照されるCPSに含まれることでしょう。 米国弁護士協会(American Bar Association)デジタル署名ガイドライン(以降「ABAガイドライン」)によれば、 「CPSは、CAが証明書を発行する際に採用する実践を表したものです。」 [ABA1]
本書の目的は、証明書ポリシーとCPSの間の明確な関係を築き、証明書ポリシー、 もしくはCPSの執筆者の仕事を支援するフレームワークを提供することにあります。 特にフレームワークは、証明書ポリシー、 もしくはCPSの公式化の際に考慮される必要がある要素を識別します。 この目的自体は、特定の証明書ポリシー、 もしくはCPSを規定することではありません。
本書の視野は、(X.509で定義されているような)証明書ポリシー、 もしくは(ABAガイドラインで定義されているような)CPSの内容の検討に限定されています。 本書は、特に証明書ポリシー規定、 もしくはCPSに含めることを検討すべき情報の種類を記述します。 提供されるフレームワークは、 一般的に X.509 v3証明書フォーマットの使用を想定しますが、 その題材がその証明書フォーマットの使用に限定されることは意図していません。 むしろ、このフレームワークが将来、 使用されるようになる他の証明書フォーマットにも採用可能であることが意図されています。
視野は、一般に、 証明書ポリシーもしくはCPSと特定の関係があると考えられるポリシーの要素以外のセキュリティポリシー(組織のセキュリティポリシー、 システムセキュリティポリシーもしくはデータラベリングポリシー等)の規定には及びません。
本書は、特定の証明書ポリシー、もしくはCPSを規定するものではありません。
本書では、読者がX.509やABAガイドイラインで使用されているデジタル署名、 証明書、PKIの一般的な概念に慣れ親しんでいることが想定されています。
本書では、下記の定義された用語を使用します。：
この章では、証明書ポリシーとCPSのコンセプトを説明し、 それらの関係を記述します。 他の関連するコンセプトについても記述されています。 この章といくつかの関連する章で網羅する題材には、 X.509 v3として定義された証明書ポリシー拡張に固有なものものがあります。 これらの章以外では、このフレームワークは、将来、 使用される可能性がある他の証明書フォーマットにも採用可能であることを意図しています。
CAが証明書を発行するとき、証明書ユーザ(つまり、 証明書利用者)に対し特定の公開鍵が特定の主体(認証サブジェクト)に関連付けられているという表明が提供されます。 しかし、その証明書ユーザがCAによるその表明に依存すべき程度については、 その証明書ユーザが評価する必要があります。 様々な証明書が異なる実践や手続きに従って発行されており、 おそらく異なるアプリケーション、かつ／または、 目的に適合していることでしょう。
X.509標準は、 証明書ポリシーを「 証明書の適用可能性を特定のコミュニティに示し、 かつ／または、 共通のセキュリティ要件をもったアプリケーションのクラスを示す指定されたルール集」と定義しています。 [ISO1] X.509 v3証明書は、 証明書ユーザによって特定の目的のために証明書を信頼してよいか否かを判断するのに使用される証明書ポリシーの表示を含みます。
証明書ポリシーは、 証明書の発行者とユーザの両方によって理解される必要がありますが、 一意な、登録されたオブジェクト識別子(Object Identifier)によって証明書中に表わされます。 登録手続きは、ISO/IECとITUの標準で仕様化された手続きに従います。 オブジェクト識別子を登録する主体は、また、 テキストによる証明書ポリシーの仕様も、 証明書ユーザによる試験のために発表します。 いかなる証明書も典型的には単一の証明書ポリシーを宣言するか、 もしくはおそらく、少数の異なるポリシーをもって発行されます。
証明書ポリシーはまた、CAの認定(accreditation)のための基礎を構成します。 各CAは実装される際に解釈される、ひとつ、 もしくは複数の証明書ポリシーについて認定されます。 あるCAがCA証明書を他のCAに発行する場合、 その発行CAはどのようなサブジェクトCAを信頼するかについて証明書ポリシー集を調査しなければなりません。 (そのような調査(アセスメント)は、 関連する証明書ポリシーに関する認定(accreditation)に基づいてなされます。) 調査された証明書ポリシー集は、 発行CAによってCA証明書中に表示されるようになります。 X.509認証パス処理ロジックは、これらの証明書ポリシー表示を、 その明確に定義された信頼モデルの中で採用しています。
目的の例として、IATAが、IATAのPKIと航空各社のPKIを組み合わせ、 航空業界全体で使用する何らかの証明書ポリシーの規定を行うものと想定します。
IATA汎用ポリシーとIATA商用グレードポリシーの2つの証明書ポリシーが規定されています。
IATA一般目的ポリシーは、業界の人によるルーチン情報(例、 普段の電子メール)の防護のための使用を意図しており、 ブラウザーからサーバーへの一般的な情報取得目的での接続を本人認証するためのものです。 その鍵ペアは、 商用ブラウザーのような低コストのソフトウェアベースのシステムで生成、 保存され管理されます。 このポリシーのもとで証明書は、 IATAまたはメンバー航空各社の名簿の中にとして掲載されているすべての従業員に対し、 組織内のネットワーク管理者に署名された証明書リクエストを実行したとき、 自動的に発行されます。
IATA商用グレードポリシーは、財務トランザクション、 もしくは航空会社間での契約に関するやり取りを防護するのに使用されます。 このポリシーのもとで、IATAは、認証された鍵ペアは、 認定済みの暗号化ハードウェアトークンによって生成、 保存されることを要求しています。 証明書やトークンは、 支給(disbursement)機関から航空業界の従業員に提供されます。 これらの認可された個人にはトークンや証明書が発行される前に、 会社のセキュリティオフィスに出頭し、正規の識別バッジを見せ、 トークンを防護、 認可された目的にのみ使用することについて署名することが要求されます。
下記のX.509証明書の中の拡張フィールドは、 証明書ポリシーをサポートするのに使用されます。：
証明書ポリシー拡張には、2つの形態があります。 ひとつはノンクリティカルのフラグが立っており、もうひとつは、 クリティカルのフラグが立っています。 このフィールドの目的は、この2つの場合で異なります。
ノンクリティカル証明書ポリシーのフィールドは、 そのCAが適用可能であると宣言した証明書ポリシーを掲載します。 しかし証明書の使用は、 適用可能なポリシーによって示された目的に制限されません。 3.2節で規定したIATA一般目的ポリシーと商用グレードポリシーの例を使用すれば、 通常の航空業界の従業員に発行された証明書は、 一般目的ポリシー用の証明書ポリシーのためのオブジェクト識別子を含みます。 支給機関から従業員に発行された証明書は、一般目的ポリシーと、 商用グレードポリシーの両方のためのオブジェクト識別子を含みます。 また、証明書ポリシーフィールドは、オプションとして、 識別された各ポリシーのための認定子の値を運ぶことがあります。 認定子の使用については3.4節で検討されます。
ノンクリティカル証明書ポリシーフィールドは、 アプリケーションによって下記のように使用されるように設計されました。 各アプリケーションは、どのポリシーを要求するかを知るように、 事前に設定されます。 3.2節にある例を使用するならば、 電子メールアプリケーションやWebサーバーは、 汎用ポリシーを要求するように設定されます。 しかし、航空の財務アプリケーションは、 一定のドル以上の財務トランザクションを認証(validate)するために、 商用グレードポリシーを要求するように設定されます。
認証パスを処理する際に、 証明書を使用するアプリケーションが受付可能な証明書ポリシーは、 パス中のすべての証明書、つまり、 CA証明書からEE(エンドエンティティ)の証明書に至るまで、 その中に現れなければなりません。
証明書ポリシーフィールドにクリティカルのフラグが立っている場合、 上述と同様の目的を果たしますが、追加的な役割も果たします。 証明書の利用は、識別されたポリシーのひとつに制限されることを示します。 つまり、そのCAが、その証明書は、 リストされている証明書ポリシーの中のひとつの規定に従ってのみ使用されなければならないと宣言しているのです。 このフィールドは、 適用可能な証明書ポリシー規定に明文化されているように、 不適切な目的あるいはやり方で証明書を使用した証明書利用者(relying party)による訴えのダメージからそのCAを保護することを意図しています。
例えば、税務署(Internal Revenue Service)は、 納税者に対して納税申告を保護する目的で証明書を発行します。 税務署は、 偶然に不具合のある証明書を発行してしまうリスク(例、 誤って本人認証された人に発行)を理解しており、 適応することができます。 しかし、誰かが、 税務署の納税申告証明書を使って何百万ドルもの秘密財産を暗号化し、 その後、税務署の証明書の発行ミスによって、 それが悪人の手に渡ってしまった、と想定してください。 税務署は、そのような環境下で、 ダメージについての訴えに対して自己防衛することを望むことでしょう。 クリティカルのフラグが立った証明書ポリシー拡張は、そのような状況下で、 その証明書発行者に対するリスクを低減することを意図したものです。
ポリシーマッピング拡張は、CA証明書の中でのみ使用されます。 CAは、このフィールドを使用することで、 自身のドメイン内の特定のポリシーが、 サブジェクトCAのドメイン内の特定の他のポリシーと等価であることを示すことができます。
例えば、ACEコーポレーションがABCコーポレーションと相互にEDI (electronic data interchange)を防護する目的で相互のPKIを相互認証する契約を締結すると想定してください。 さらに両社は、 それぞれace-e-commerceとabc-e-commerceと呼ばれる既存の財務トランザクション防護ポリシーを持っていると想定します。 ここで、単に2つのドメイン間の相互認証証明書を生成することでは、 必要不可欠な相互運用可能性を提供しないことを認識することになります。 それは、この2社のアプリケーションは、 それぞれの証明書ポリシーで設定され、従業員証明書は、 それぞれの証明書ポリシーで登録されているからです。 ひとつの可能な解決策は、両社のポリシーを要求し、 両方のポリシーに基づいてすべての証明書を再発行するように、 すべての財務アプリケーションを再設定することです。 より管理者にとって容易な他の解決策は、 ポリシーマッピングフィールドを使用します。 このフィールドがACEコーポレーションCAによって発行されたABCコーポレーションCAのための相互認証証明書に含まれている場合、 これはABCの財務トランザクション保護ポリシー(つまり、 abc-e-commerce)は、ACEコーポレーションのもの(つまり、 ace-e-commerce)と等価であるとみなせるという表明を提供することができます。
ポリシー制約拡張は、2つのオプションの機能をサポートします。 ひとつめはCAが、 明確な証明書ポリシー表示が認証パス中の以降すべての証明書の中に存在することを要求することができることです。 認証パスの最初の証明書は、証明書ユーザによって、 信頼されたドメインの一部であると考えられます。 つまりCAは、すべての目的のために信頼されているので、 特定の証明書ポリシーは証明書ポリシー拡張の中に必要ではないのです。 そのような証明書は、 明確な証明書ポリシーの表示を含んでいる必要はありません。 しかし、信頼されたドメイン中のCAが外部のドメインを認証する場合には、 認証パス中の以降の証明書の中にある明確な証明書ポリシーを要求するようにすることができます。
他のポリシー制約フィールドの中のオプションの機能は、 CAが認証パス中の以降のCAによるポリシーマッピングを実行不能にすることができることです。 そのドメイン外部を認証する際には、 ポリシーマッピングを実行不能にしておくのが賢明でしょう。 これは、 他に対する信頼に起因するリスクを統制することを支援することができます。 例えば、ドメインAはドメインBを信頼し、 ドメインBはドメインCを信頼しますが、 ドメインAはドメインCを信頼することを強要されることを望みません。
証明書ポリシー拡張フィールドは、各証明書ポリシー識別子とともに、 認定子フィールドの中の追加的なポリシー依存情報を運ぶための規定をもっています。 X.509標準は、このフィールドが使用されるべき目的を強制していませんし、 このフィールドのためのシンタックスを指図してもいません。 ポリシー認定子タイプは、 いかなる組織によっても登録される可能性があります。
下記のポリシー認定子種別がPKIX PartI [PKI1] に定義されています。：
ポリシー認定子は、一般的な、 もしくはパラメータ化された証明書ポリシー規定の規定をサポートするのに使用することができます。 基本CPSが提供された場合には、ポリシー認定子タイプは、 証明書ごとに一般的な規定を埋める追加的な特定のポリシーの詳細を運ぶように定義することができます。
CPSという用語は、ABAガイドラインによって下記のように定義されています。 ：「CAが証明書を発行する際に採用する実践の表明。」 [ABA1] ABAガイドラインの1995年のドラフトの中で、 ABAはこの定義を下記のコメントで拡大しています。：
CPSは、CAによるその信頼に値するシステムと、 その運用と証明書の発行のサポートについて採用している実践の詳細についての宣言の形態をとることがありますし、 あるいは、CAに適用可能で、 同様の課題を網羅する法規または規制であるかもしれません。 これは、CAとその登録者の間の契約の一部でもあります。 CPSはまた、複数の文書、法律の組み合わせ、プライベートな契約、 かつ／または、宣言を包含するものである可能性があります。
CPSを法的に実装する種のフォームは、特定の関係を持つようになります。 例えば、CAと登録者の間の法的な関係が合意されている場合、契約は、 もともとCPSの効果を与える手段となります。 CAの依存する主体に対する義務は一般に、CAの表明に基づき、 これはCPSを含みます。
CPSが依存する人に関連付けられているか否かは、 依存する人がそのCPSの知識を持っているか、 あるいは気付いているかに依存します。 証明書利用者は、 その依存する人によってデジタル署名を検証するために使用される証明書の内容の知識を持っているか、 あるいは少なくとも気付いています。 この際、参考としてその証明書に取り込まれる文書も含まれます。 それゆえ、CPSを参考として証明書に取り込むことが推奨されます。
可能なかぎりCPSは、CAの実践が検証する、 すべての広く理解されている標準を表示する必要があります。 広く理解されている標準への参照は、 他人の目的のCAの実践の適合性とともに、 リポジトリや他のシステム経由でCAによって発行された証明書の潜在的な技術的な互換性を簡潔に表示します。
証明書ポリシーとCPSのコンセプトは、異なる起源を持っており、 異なる理由でつくられてきました。 しかし、両者間の関係は重要です。
CPSは、CAによるその実践に関する詳細化された表明であり、 潜在的に登録者と証明書ユーザ(証明書利用者)によって理解され、 相談される必要があります。 詳細さの程度は、CPSごとに異なるでしょうが、 それらは一般にCPSよりも詳細なものです。 まさにCPSは、提供サービスの詳細、 証明書のライフサイクル管理の詳細な手続きおよび提供サービスの特定の(専用な)実装についてのCPSを結合させる詳細なレベルの記述を提供する、 極めて理解しやすい、しっかりとした文書となることでしょう。
そのような詳細は、適切に開示するために、さらに、 認証(accreditation )もしくは、 他の理解されている品質測定がない場合、 信頼に値するかについての完全なアセスメントを行うために必要不可欠ですが、 詳細化されたCPSは、 異なる組織によって運用されているCA間の相互運用可能性のための適切な基礎を形成するものではありません。 むしろ証明書ポリシーは、せいぜい、業界全体(あるいは、 潜在的にはより広い範囲の)共通相互運用可能性標準や、 共通認証(assurance)クライテリアのベースとなる乗り物として機能するにとどまります。 単一のCPSを持つCAが、複数の証明書ポリシーをサポートすることがあります。 (異なる適用目的のために、かつ／または、 異なる証明書ユーザコミュニティによって使用されます。) また、同一でないCPSをもつ複数の異なるCAが、 同一の証明書ポリシーをサポートすることもあります。
例えば、連邦政府は、 秘密の人材情報を扱うための政府全体の証明書ポリシーを規定するかもしれません。 証明書ポリシー規定は、 その認証ポリシーの一般的な特徴についての広範な表明や、 使用が適切となるアプリケーションのタイプの表示となります。 それぞれのCPSでCAを運用する部門、もしくは機関は、 この証明書ポリシーをサポートすることでしょう。 同時に、そのようなCAは、 他の証明書ポリシーをサポートすることでしょう。
それゆえ証明書ポリシーとCPSの主な違いは、 下記のように要約することができます。：
CAは、 証明書ポリシー識別子をもった証明書ポリシーフィールドを生成することに加えて、 それが発行する証明書の中に、そのCPSへの参照情報を含ませることでしょう。 これを行うために、 証明書ポリシー認定子を使用する基本的なやり方は3.4節に記述されています。
規定集は、実践、かつ／または、ポリシー表明を集めたもので、 このフレームワークの中に記述されたアプローチを採用して証明書ポリシー規定、 もしくはCPSを表明する際に使用するために標準的な論点の範囲に及ぶものです。
証明書ポリシーは、ひとつの規定集として表明することができます。
CPSは各コンポーネントが、ひとつ、 もしくは複数の証明書ポリシーに対応するひとつの規定集として表明することができ、 もしくは代替的に規定集の体系的な集合体として表明することができます。 例えばCPSは下記の組み合わせとして表明することができます。：
b. とc. で提供される表明文は、 適用可能な証明書ポリシー規定の明文を述べ、 もしくは洗練するものですが、 いかなる証明書ポリシー規定の明文ともコンフリクトを生じてはなりません。
このフレームワークは、 規定集の内容を下記のように8つの主要なコンポーネントで概観します。
コンポーネントは、さらにサブコンポーネントに分割することができ、 サブコンポーネントは、複数の要素を包含します。 第4章では、上記のコンポーネントと、 そのサブコンポーネントの内容の詳細を提供します。
この章では、 3.7節で紹介した規定集の内容について掘り下げます。 したがって、この章で識別されている論点は、証明書ポリシー規定、 もしくはCPSに含まれる候補となる論点です。
多くの論点が識別されますが、 すべてのそうのような論点についての具体的な表明を含むことは、 証明書ポリシー、もしくはCPSに必要不可欠なものではありません。 むしろ特定の証明書ポリシー、もしくはCPSは、コンポーネント、 サブコンポーネント、もしくは要素について「明文化せず」と表明し、 これに基づいて特定の証明書ポリシー、 もしくはCPSは、何ら要件を負わせません。 このセンスで、この論点集は、 証明書ポリシーもしくはCPSの執筆者によって考慮されるべき論点のチェックリストとみなすことができます。 たとえ「明文化せず」としていても、 各すべてのコンポーネントとサブコンポーネントが証明書ポリシー、 もしくはCPSに含まれていることが推奨されます。 これは読者に、その論点を含む、あるいは含まないことについて、 意識的な判断がなされたことを示すことになります。 これは、不注意に論点を見落とすことを防ぐ一方、例えば、 ポリシーマッピングの判断をする際に異なる証明書ポリシー、 もしくはCPSの比較を容易にします。
証明書ポリシー規定において、特定のコンポーネント、 サブコンポーネントかつ／または、要素を仕様化しないままにし、 要求される情報は、 ポリシー認定子に表示されることを明文化することがありえます。 そのような証明書ポリシー規定は、 パラメータ化された規定と考えることができます。 規定集は、要求されたポリシー認定子タイプを参照または規定する必要があり、 すべての適用可能なデフォルト値を仕様化する必要があります。
このコンポーネントは、規定集を識別・紹介し、 主体と仕様が目的とするアプリケーションのタイプを表示します。
このコンポーネントは下記のサブコンポーネントを持っています。：
このサブコンポーネントでは、仕様化についての一般的な紹介を提供します。
このサブコンポーネントでは、規定集のために、 ASN.1オブジェクト識別子を含む、すべての適用可能な名前、 もしくは他の識別子を提供します。
このサブコンポーネントは、証明書を発行する、もしくは、 サブジェクトCA (2, 3)として認証された主体のタイプ、 RA機能 ( 4 )を遂行する主体のタイプ、 サブジェクトEE、もしくは登録者(5, 6)として認証された主体のタイプを記述します。
このサブコンポーネントには下記の事項も含まれます。：
このサブコンポーネントは、この証明書ポリシー、もしくはCPSの登録、 維持管理、解釈に責任を負う機関の名前と住所(mailing address)を含みます。 これにはまた、連絡先の担当者の名前、電子メールアドレス 電話番号、 FAX番号が含まれます。
このコンポーネントは、法的論点や一般的な実践の論点の範囲の、 すべての適用可能な前提を仕様化します。
このコンポーネントには下記のサブコンポーネントが含まれています。：
各サブコンポーネントは、CA、リポジトリ、RA、登録者、 証明書利用者といった主体のタイプに応じて別々に規定を表明する必要があります。 (登録者と証明書利用者に関する特定の規定は、 責任(Liability)と義務(Obligations)のサブコンポーネントにおいてのみ、 適用可能です。)
このサブコンポーネントには、各主体タイプについて、 その主体の他の主体に対する義務に関する、 すべての適用可能な規制が含まれます。 そのような規定には下記のものがあります。：
このサブコンポーネントには、 各主体のタイプごとに下記のような依存可能性の分担に関するすべての適用可能な規定が含まれます。：
このサブコンポーネントには CA、リポジトリ、RAについて、 下記のような財務的な責任に関する、 すべての適用可能な規定が含まれます。：
このサブコンポーネントは、 証明書ポリシーもしくはCPSの解釈と執行に関するすべての適用可能な規定を含み、 下記のような論点に対応します。：
このサブコンポーネントは、下記のようなCA、リポジトリ、 もしくはRAによって課せられる料金に関するすべての適用可能な規定を含みます。：
このサブコンポーネントは、以下に関連するすべての規定を含みます。：
このサブコンポーネントは、下記に対応します。：
このサブコンポーネントは、下記に対応します。：
このサブコンポーネントは、証明書の所有権、実践／ポリシーの仕様、 名前、鍵に対応します。
このコンポーネントは、 証明書の発行の前にCAもしくはRAへの証明書の申込者を本人認証するのに使用される手続きを記述します。 これはまた、鍵更新(rekey)もしくは、 失効を要求している主体がどのように本人認証されているか、 についても記述します。 このコンポーネントはまた、名前の所有権の理解と、 名前の争い解決を含む命名実践に対応します。
このコンポーネントは下記のサブコンポーネントを持っています。：
このサブコンポーネントは、主体登録、 もしくは証明書発行における識別と本人認証の手続きに関する下記の要素を含みます。：
このサブコンポーネントは、 各サブジェクトタイプ(CA、RA、 EE)のルーチンの鍵更新のための識別と本人認証の手続きについて記述します。 (13)
このサブコンポーネントは、サブジェクト証明書が失効した後に、 各サブジェクトタイプ(CA、RA、 EE)の鍵更新のための識別と本人認証の手続きを記述します。 (14)
このサブコンポーネントは、各サブジェクトタイプ(CA、RA、 末端主体)による失効要求のための識別と本人認証の手続きを記述します。 (16)
このコンポーネントは、様々な運用的活動に関して、発行CA、 サブジェクトCA、RA、 もしくはEEに負わされる要件を仕様化するのに使用されます。
このコンポーネントは下記のサブコンポーネントから成ります。：
各サブコンポーネントの中において、発行CA、リポジトリ、 サブジェクトCA、RA、EEに対して、 それぞれの考慮がなされる必要があります。
このサブコンポーネントは、サブジェクト登録と、 証明書発行のための要求に関する要件を表明するのに使用されます。
このサブコンポーネントは、証明書の発行と、 そのような発行の申込者への通知に関する要件を表明するのに使用されます。
このサブコンポーネントは、発行された証明書の受容性と、 それによって生ずる証明書の公表に関する要件を表明するのに使用されます。
このサブコンポーネントは下記のものを表明します。：
このサブコンポーネントは、 セキュアな環境を維持するために実装されるイベントロギングと監査システムを記述するのに使用されます。 要素には以下のものがあります。：
このサブコンポーネントは、 一般的なレコードのアーカイブ化(もしくはレコード保持)ポリシーを記述するのに使用され、 下記のものを含みます。：
このサブコンポーネントは、 新しい公開鍵をCAのユーザに提供する手続きを記述します。
このサブコンポーネントは、 改ざんや災害が起きた場合における通知と復旧の手続きに関する要件を記述します。 下記の各状況が別々に対応される必要があります。：
このサブコンポーネントは、 CAもしくはRAの期限と期限の通知のための手続きに関する要件について記述します。 CAとRAのアーカイブ化レコードのカストディアンの識別情報が含まれます。
このコンポーネントは、発行CAによって、セキュアに鍵生成の機能を行う、 サブジェクトの本人認証、証明書発行、証明書失効、監査、 アーカイブ化するために使用される非技術的なセキュリティ統制 (すなわち物理的、手続き的、個人的なセキュリティ統制)を記述します。
このコンポーネントは、リポジトリ、サブジェクトCA、RA、 EEの非技術的なセキュリティ統制を規定するのにも使用することができます。 サブジェクトCA、RA、EEのための非技術的なセキュリティ統制は、 同一である可能性、同様である可能性、 もしくは全く異なる可能性があります。
これらの非技術的なセキュリティ統制は、 証明書を信頼するのに極めて重要です。 それは、セキュリティの欠如はCAの運用を犯し、例えば、 証明書、 もしくはCRLの作成においてエラー情報、もしくは、 CAプライベート鍵の改ざんをともなうことになります。
このコンポーネントは、3つのサブコンポーネントから成ります。：
各サブコンポーネント内において、一般に、各主体のタイプごとに、 それぞれの考慮が必要となります。 つまり、発行CA、リポジトリ、サブジェクトCA、RA、EEです。
このサブコンポーネントにおいては、 主体のシステムを囲うファシリティについての物理的な統制が記述されます。 (21) 対応する論点には以下のものがあります。：
このサブコンポーネントにおいては、 信頼された役割を理解するための要件が、 各役割の義務とともに記述されます。(22)
各役割ことに識別された各業務について、 何人の人員がその業務を遂行するのに必要かについて表明される必要があります。 (n out mルール。) 各役割ごとに、識別と本人認証の要件も規定されます。
このサブコンポーネントは下記のものに対応します。：
このコンポーネントは、発行CAの暗号鍵とアクティヴェーションデータ (例：PIN、パスワード、もしくは相互保有される共有鍵) を防護するために発行CAによって採用されるセキュリティ手段を規定するために使用されます。 このコンポーネントは、リポジトリ、サブジェクトCAとEEが、 それらの暗号鍵と重要なセキュリティパラメータを防護するために制約をかけるためにも使用されます。 すべての秘密・プライベート鍵とアクティヴェーションデータを防護し、 認可された要員だけが使用するには、セキュアな鍵管理は極めて重要です。
このコンポーネントはまた、セキュアに鍵生成の機能、ユーザの本人認証、 証明書登録、証明書失効、監査、 アーカイブ化を遂行するために発行CAによって使用される他の技術的なセキュリティ統制を記述します。 技術的な統制は、 ライフサイクルセキュリティ統制(ソフトウェア開発環境セキュリティ、 信頼されるソフトウェア開発手法を含む)と、 運用面のセキュリティ統制を含みます。
このコンポーネントは、リポジトリ、サブジェクトCA、RA、 EEについての他の技術的なセキュリティ統制を規定するのにも使用することができます。
このコンポーネントは下記のサブコンポーネントをもっています。：
鍵ペア生成とインストールは、発行CA、リポジトリ、サブジェクトCA、RA、 サブジェクトEEについて考慮される必要があります。 これらの主体の各タイプについて、 下記の質問が潜在的に回答される必要があります。：
プライベート鍵の防護についての要件が、発行CA、リポジトリ、 サブジェクトCA、RA、サブジェクト主体について考慮される必要があります。 これらの各タイプの主体について、 下記の質問が潜在的に回答される必要があります。：
鍵管理の他の側面は、発行CA、リポジトリ、サブジェクトCA、RA、 サブジェクトEEについて考慮される必要があります。 これらのタイプの各主体について、 下記の質問が潜在的に回答される必要があります。：
アクティヴェーションデータは、鍵以外のデータ値で、 暗号化モジュールを動かすのに要求され、 防護される必要のあるものをいいます。 (20) アクティヴェーションデータの防護は、潜在的に 発行CA、 サブジェクトCA、RA、EEについて考慮される必要があります。 このような考慮は、 潜在的にアクティヴェーションデータのライフサイクル全体 (生成からアーカイブ化を通じて廃棄されるまで)に対応する必要があります。 各主体のタイプごとに、 (発行CA、リポジトリ、サブジェクトCA、RA、EE) 4.6.1 から 4.6.3 までに列記された質問のすべてが、鍵についてではなく、 むしろアクティヴェーションデータについて、 潜在的に回答される必要が あります。
このサブコンポーネントは、 次のようなコンピュータセキュリティ統制を記述するのに使用されます。： 信頼されたコンピューティング基本コンセプトの使用、 自由裁量的(discretionary)アクセスコントロール、ラベル、 強制的アクセスコントロール、オブジェクト再利用、監査、識別と本人認証、 信頼されたパス、セキュリティテスト、ぺネトレーション(侵入)テスト。 製品認定(assurance)もまた対応されます。
コンピュータシステムについて、 コンピュータセキュリティについての格付け(評価結果の認定)が要求されます。 格付けは、例えば、TCSEC (Trusted System Evaluation Criteria)、 Canadian Trusted Products Evaluation Criteria、 ヨーロッパのITSEC (Information Technology Security Evaluation Criteria)、 もしくはCommon Criteriaに基づくことができます。 このサブコンポーネントは、製品評価分析、テスト、 プロファイリング製品認証、かつ／または、 進行中の製品認定(accreditation)関連活動のための要件にも対応することができます。
このサブコンポーネントは、 システム開発統制およびセキュリティ管理統制に対応します。
システム開発統制は、開発環境のセキュリティ、開発人員セキュリティ、 製品メンテナンスにおける設定管理セキュリティ、 ソフトウェアエンジニアリング実践、ソフトウェア開発手法、モジュール化、 階層化、フェイルセーフ設計と実装のテクニックの使用(例、 防衛的(defensive)プログラミング)と開発ファシリティセキュリティを含みます。
セキュリティ管理統制は、運用システムとネットワークが、 設定されたセキュリティに忠実であることを確保するためのツールの実行と手続きを含みます。 これらのツールと手続きは、セキュリティソフトウェア、ファームウェア、 ハードウェアの正しい運用を確保するために、 インテグリティのチェックを含みます。
このサブコンポーネントは、例えば、TSDM (Trusted Software Development Methodology)レベルIVとV、独立したライフサイクルセキュリティ統制監査、 SEI-CMM (Software Engineering Institute's Capability Maturity Model)ライフサイクル セキュリティ格付けに基づいたものにも対応することができます。
このサブコンポーネントは、 ファイアウォールを含むネットワークセキュリティに関する統制に対応します。
このサブコンポーネントは、暗号モジュールの次の観点について対応します。： 暗号モジュール境界の識別、入力／出力、役割とサービス、制限状態のマシン、 物理的セキュリティ、ソフトウェアセキュリティ、 オペレーティングシステム、アルゴリズム準拠性、 電磁的互換性および自己テスト。 要件は、米国のFIPS 140-1のような標準への参照を通じて表明されます。 (27)
このコンポーネントは、証明書のフォーマットと、 CRLが使用されている場合にはCRLフォーマットを仕様化するのに使用されます。 X.509証明書とCRLフォーマットの使用を想定すれば、 これには使用されるプロファイル、バージョン、 拡張についての情報が含まれます。
このコンポーネントは、2つのサブコンポーネントをもっています。：
このサブコンポーネントは下記のような論点に対応します。 (潜在的にはPKIX Part Iプロファイルのような分離したプロファイル規定への参照によります。)：
このサブコンポーネントは、下記のような論点に対応します。 (潜在的にはPKIX Part Iプロファイルのような分離したプロファイル規定への参照によります。)：
このコンポーネントは、どのようにこの特定の証明書ポリシー規定、 もしくはCPSが維持されるかを仕様化するのに使用されます。
これは下記のサブコンポーネントを含みます。：
しばしば、証明書ポリシーやCPSを変更することが必要となります。 これらの変更には、証明書ポリシー、 もしくはその実装が提供する保障を実質的に減じないものや、 証明書が使用されてきた目的のためのポリシーであって証明書の受容性を変更するものではないとポリシー管理者によって判断されるものがあります。 証明書ポリシーやCPSに対するそのような変更は、 証明書ポリシーオブジェクト識別子、 もしくはそのCPSポインタ(URL)については変更を要求する必要がありません。 他の仕様についての変更は、特定目的のための証明書の受容可能性を変更し、 これらの変更は、証明書ポリシー オブジェクト識別子、 もしくはCPSポインタ(URL)についての変更を要求します。
このサブコンポーネントには、下記の情報が含まれています。：
このサブコンポーネントには、下記の要素が含まれます。：
証明書ポリシーの規定において、このサブコンポーネントは、 証明書ポリシーについての特定のCPSの準拠性は、 どのように判断することができるかを記述します。
この章は、チェックリスト、もしくは(より開発された)証明書ポリシー、 もしくはCPSの執筆者によって使用される標準テンプレートの役割を果たすことを意図された規定集についての目次案を含みます。 そのような共通目次は、下記のことを容易にします。：
CP/CPSフレームワーク(RFC2527)の記述目次
1. はじめに： INTRODUCTION
1.1 概要：Overview
1.2 識別：Identification
1.3 運営体制と適用範囲：Community and Applicability
1.4 連絡先詳細：Contact Details
2. 一般規定： GENERAL PROVISIONS
2.1 義務：Obligations
2.2 責任：Liability
2.3 財務上の責任：Financial responsibility
2.4 解釈と執行：Interpretation and Enforcement
2.5 料金：Fees
2.6 公開とリポジトリ：Publication and Repository
2.7 準拠性監査：Compliance audit
2.8 機密保持：Confidentiality
2.9 知的財産権：Intellectual Property Rights
3. 本人確認と認証： IDENTIFICATION AND AUTHENTICATION
3.1 初期登録：Initial Registration
3.2 証明書の更新：Routine Rekey
3.3 証明書失効後の再発行：Rekey after Revocation
3.4 証明書失効要求：Revocation Request
4. 運用要件： OPERATIONAL REQUIREMENTS
4.1 証明書発行申請：Certificate Application
4.2 証明書発行：Certificate Issuance
4.3 証明書の受領：Certificate Acceptance
4.4 証明書の保留と失効：Certificate Suspension and Revocation
4.5 セキュリティ監査手順：Security Audit Procedures
4.6 記録保存：Records Archival
4.7 鍵更新：Key changeover
4.8 危殆化と災害復旧：Compromise and Disaster Recovery
4.9 認証業務の終了：CA Termination
5. 物理面、手続面及び人事面のセキュリティ管理： PHYSICAL, PROCEDURAL, AND PERSONNEL SECURITY CONTROLS
5.1 物理的管理：Physical Controls
5.2 手続面の管理：Procedural Controls
5.3 人事面の管理：Personnel Controls
6. 技術的管理： TECHNICAL SECURITY CONTROLS
6.1 鍵ペア生成とインストール：Key Pair Generation and Installation
6.2 プライベート鍵保護：Private Key Protection
6.3 その他の鍵管理について：Other Aspects of Key Pair Management
6.4 活性化データ：Activation Data
6.5 コンピュータセキュリティ管理：Computer Security Controls
6.6 システムのライフサイクルの技術的管理：Life Cycle Technical Controls
6.7 ネットワークセキュリティ管理：Network Security Controls
6.8 暗号モジュール技術管理：Cryptographic Module Engineering Controls
7. 証明書とCRLプロファイル： CERTIFICATE AND CRL PROFILES
7.1 証明書プロファイル：Certificate Profile
7.2 CRLプロファイル：CRL Profile
8. 仕様の管理： SPECIFICATION ADMINISTRATION
8.1 仕様の変更手順： Specification change procedures
8.2 公開と通知の規則： Publication and notification policies
8.3 CPS の承認手順：C PS approval procedures
本書の作成は、カナダ政府のPMA (Policy Management Authority)委員会、 NSA (National Security Agency)、NIST (National Institute of Standards and Technology)、ABA (American Bar Association)情報セキュリティ委員会認証(Accreditation)テクニカルワーキンググループによって支援されました。 特別に感謝しなければならないのは、奮起させ、サポートし、 価値ある情報を提供してれたDave Fillingham氏、Jim Brandt氏、Edmond Van Hees氏です。
下記の方々も、レヴューや情報提供してくれたのでクレジットに値します。：
Teresa Acevedo、A&N Associates；
Michael Baum、VeriSign；
Sharon Boeyen、Entrust；
Bob Burger、McCarter & English；
Bill Burr、NIST；
Patrick Cain、BBN；
Michael Harrop、Government of Canada Treasury Board；
Rick Hornbeck、Digital Commerce Services；
Francois Marinier、Domus Software；
John Morris、CygnaCom Solutions；
Tim Moses、Entrust；
Noel Nazario、NIST；
John Nicolletos、A&N Associates；
Jean Petty、CygnaCom Solutions；
Denis Pinkas、Bull；
J.-F. Sauriol、Domus Software；
Robert Shirey、BBN；
Mark Silvern、VeriSign；
David Simonetti、Booz, Allen and Hamilton；
Darryl Stal、Entrust。
Johnny Hsiung氏とChris Miller氏が原稿の準備を支援してくれました。
| [ABA1] | American Bar Association, Digital Signature Guidelines: Legal Infrastructure for Certification Authorities and Electronic Commerce, 1995年. |
| [BAU1] | Michael. S. Baum, Federal Certification Authority Liability and Policy, NIST-GCR- 94-654, 1994年6月. |
| [ISO1] | ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information Technology - Open Systems Interconnection: The Directory: Authentication Framework," 1997年 edition. (Pending publication of 1997年 edition, use 1993年 edition with the following amendment applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 1996年6月.) |
| [PEM1] |
Kent, S., "Privacy Enhancement for Internet Electronic Mail, Part II: Certificate-Based Key Management", RFC 1422, 1993年2月. |
| [PKI1] | Housley, R., Ford, W., Polk, W. and D. Solo, 「インターネットX.509公開鍵インフラストラクチャ(Internet X.509 Public Key Infrastructure, Certificate and CRL Profile)」, RFC 2459, 1999年1月. |
Santosh Chokhani
CygnaCom Solutions, Inc.
Suite 100 West 7927 Jones Branch Drive McLean, VA 22102
電話： (703) 848-0883 Fax: (703) 848-0960
EMail： chokhani＠cygnacom.com
Warwick Ford
VeriSign, Inc.
301 Edgewater Place, Suite 210 Wakefield, MA 01880
電話： (781) 245-6996 x225
Fax： (781) 245-6006
EMail： wford＠verisign.com
宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター
EMail： miyakawa＠ipa.go.jp
| 1 | ABAデジタル署名ガイドラインは、ABAより購入することができます。 注文の詳細については、 http://www.abanet.org をご覧ください。 |
| 2 | サブジェクトCAについての主体のタイプの例は、下位の組織(例、 支部、もしくは部門)、連邦政府機関、もしくは、 州または地方の政府部門です。 |
| 3 | この表明は、大切な示唆を持つ可能性があります。 例えば、 ある銀行がCA証明書をその支店にのみ発行すると主張したとしましょう。 そこで、その銀行によって発行されたCA証明書のユーザは、 証明書の中のサブジェクトCAは、 その銀行の支店であると想像することができます。 |
| 4 | サブジェクトRA主体のタイプの例は、組織の支部と部門です。 |
| 5 | サブジェクトEEのタイプの例は、銀行顧客、電話会社の登録者、 政府部門の従業員です。 |
| 6 | この表明は、大切な示唆を持つ可能性があります。 例えば、政府CAが、 政府従業員のみにのみ証明書を発行すると主張する、と想定します。 そこで、政府CAによって発行された証明書のユーザは、 その証明書のサブジェクトは、 政府従業員であると想像することができます。 |
| 7 | 例は、X.500 DN、インターネット電子メールアドレス、 URLを含みます。 |
| 8 | 「意味を持つ(meaningful)」という用語は、その名前形態が、 個人、かつ／または、組織の識別を判断する、 一般に理解されているセマンティクスを持っている、 ということを意味します。 ディレクトリ名と、RFC822名は、程度の差こそあれ、 意味を持っています。 |
| 9 | 証明(proof)の例は、発行CAが鍵を生成すること、もしくは、 サブジェクトに電子的にサインされた要求を送ること、ないし、 チャレンジにサインすることを要求することを含みます。 |
| 10 | 組織識別の本人認証の例：設立登記、法的にサインされた会社の決議、 社印、正式なものと証明された文書。 |
| 11 | 個人識別の本人認証の例：バイオメトリクス(親指の指紋、 10本指の指紋、顔、手のひら、網膜スキャン)、運転免許証、パスポート、 クレジットカード、社員バッジ、政府バッジ。 |
| 12 | 例は、正式にサインされた認可証、もしくは会社のIDバッジを含みます。 |
| 13 | ルーチン鍵更新のための識別ポリシーは、 同一のサブジェクトが鍵更新を必要としているので、 初期登録についてのものと同一である必要があります。 鍵更新の本人認証は、 初期I&Aのためのまたははデジタル的にサインされた要求を使用して達成されます。 |
| 14 | この識別と認証のポリシーは、 初期登録のためのものと同一である可能性があります。 |
| 15 | このポリシーは、初期登録のためのものと同一である可能性があります。 |
| 16 | 失効要求のための識別ポリシーは、 同一のサブジェクト証明書が失効される必要があるので、 初期登録のためのものと同一である可能性があります。 本人証明書ポリシーは、 サブジェクトによってデジタル的にサインされた失効要求を受容する可能性があります。 初期登録において使用される本人認証情報は、 失効要求について受容可能である可能性があります。 他のより緩やかな本人証明書ポリシーが規定されることがありえます。 |
| 17 | 鍵改ざん通知のための識別ポリシーは、 同一のサブジェクト証明書が失効される必要があるので、 初期登録のためのものと同一である可能性があります。 本人証明書ポリシーは、 サブジェクトによってデジタル的にサインされた失効要求を受容する可能性があります。 初期登録において使用される本人認証情報は、 鍵改ざん通知について受容可能である可能性があります。 他のより緩やかな本人証明書ポリシーが、規定されることがありえます。 |
| 18 | n out of mルールは、鍵がmの部分に分割されることを許容します。 そのmの部分は、mの異なる個人に与えられます。 m個の部分のうちのnの部分は、 その鍵を完全に再編成するのに使用されますが、 いかなるn - 1の部分をもつことは、 その鍵について全く情報を提供しないことになります。 |
| 19 | 鍵は、寄託、バックアップもしくはアーカイブされることがあります。 これらの各機能は、異なる目的を持っています。 それゆえ鍵は、要件に応じて、 これらの機能のすべてのサブジェクトを通過します。 寄託の目的は、(組織、もしくは政府のような)第三者が、法的に、 サブジェクトの協力なしで鍵を取得することを許容することにあります。 バックアップの目的は、サブジェクトが鍵を壊した場合に、 鍵を再編成することを許容することにあります。 アーカイブの目的は、将来において、 その鍵の再使用のために提供することにあり、例えば、 文書の復号にプライベート鍵を使用します。 |
| 20 | アクティベーションデータの例は、PINもしくはパスフレーズです。 |
| 21 | 物理的アクセスコントロールの例： 監視設備、ガード設備、 ロック設備、トークンを使用したアクセスコントロール、 バイオメトリクスを使用したアクセスコントロール、 アクセスリストを通じたアクセス コントロール。 |
| 22 | 役割の例は、システム管理者、システムセキュリティオフィサー、 システム監査人を含みます。 システム管理者の義務は、システムを設定、生成、起動、 運用することです。 システムセキュリティオフィサーの義務は、 アカウントと権限を割り当ることです。 システム監査人の義務は、システム監査プロファイルを用意し、 監査ファイル管理と監査レヴューを行うことです。 |
| 23 | 経歴チェックは、正式承認(clearance)レベル(例：なし、 取り扱い注意(sensitive)、秘密(confidential)、 シークレット、トップシークレット、等)、 正式承認付与機関名を含みます。 規定された正式承認の代わり、もしくは追加として、 経歴チェックは、経歴情報のタイプ(例、名前、出生地、誕生日、 住所、以前の居住地、以前の雇用、 信頼するに値するかを判断するのに役立つすべての他の情報)を含みます。 記述は、どの情報が、どのように検証されたかをも含む必要があります。 |
| 24 | 例えば、その証明書ポリシーは、 CAのネットワークアクセスに責任をもつネットワークシステム管理者に要員セキュリティ要件を負わせます。 |
| 25 | 認可された要員が従業員であるかに関わらず、実践は、 各認可された要員が、 彼の／彼女の行為について説明できる状態にあることを確保するように実装される必要があります。 |
| 26 | 暗号モジュールは、ハードウェア、ソフトウェア／ファームウェア、 もしくは、それらすべての組み合わせです。 |
| 27 | 準拠性の記述は、仕様化され、かつ詳細である必要があります。 例えば、各FIPS 140-1要件について、そのレベルと、そのレベルは、 認定(accredit)されたラボによって認証(certify)されているか否かを記述します。 |
| 28 | 監査イベントの例：証明書を作成する要求、証明書を失効する要求、 鍵改ざん通知、証明書の作成、証明書の失効、証明書の発行、 CRLの発行、鍵改ざんCRLの発行、CAについて信頼された役割の確立、 信頼された要員の行為、CA鍵への変更、等。 |
| 29 | アーカイブイベントの例： 証明書を作成する要求、 証明書を失効する要求、鍵改ざん通知、証明書の作成、証明書の失効、 証明書の発行、CRLの発行、鍵改ざんCRLの発行、CA鍵への変更。 |
| 30 | 親CAは、監査関係の一例です。 |
| 31 | 準拠性監査論点の例：様々なI&Aポリシーの試査、 鍵管理ポリシーについての合理的なチェック、 システムセキュリティ統制についての合理的なチェック、 運用ポリシーについての合理的なチェック、 証明書プロファイルについての合理的なチェック。 |
| 32 | 例は、不備が正されるまでの一時的な運用の留保、 主体証明書の失効、要員についての変更、信頼性ポリシーの実施、 より頻繁な準拠性監査等を含みます。 |
| 33 | 組織は、そのセキュリティ統制、正式な許可(clearance)手続き、 もしくは、 取り扱いに注意を要する性格をもつ他の要素の一部を公にしないことを選択します。 |
| 34 | 下記のアイテムのすべて、あるいはいくつかは、 様々な主体のタイプ、つまり、CA、RA、EEごとに異なります。 |
ABA - American Bar Association
CA - Certification Authority
CPS - Certification Practice Statement
CRL - Certificate Revocation List
DAM - Draft Amendment
FIPS - Federal Information Processing Standard
I&A - Identification and Authentication
IEC - International Electrotechnical Commission
IETF - Internet Engineering Task Force
IP - Internet Protocol
ISO - International Organization for Standardization
ITU - International Telecommunications Union
NIST - National Institute of Standards and Technology
OID - Object Identifier
PIN - Personal Identification Number
PKI - Public Key Infrastructure
PKIX - Public Key Infrastructure (X.509) (IETF Working Group)
RA - Registration Authority
RFC - Request For Comment
URL - Uniform Resource Locator
US - United States
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.