この文書では、CACAnetの証明書発行システムの認証モデルについて説明します。
まず、登場人物の紹介からはじめます。 CACAnet証明書発行システムは次のような主体およびシステムから構成されます。このシステムによって証明書の発行を受ける本人のことです。
X.500 標準に基づくDNによって識別され、DNが異なるものは別のSubjectとして扱われるものとします。
subjectさんをどういう基準で本人確認するのか？ 同一人物に複数の証明書を発行できるようにするか？ といった問題は、「ポリシー」つまり運用規定の問題になります。
CACAnetの証明書発行モデルでは、CAとRAの両方がポリシを持つもものとしています。 特に、本人確認はRAのポリシに準拠することになります。
Subjectは、SSL対応のwebブラウザとS/MIME対応の電子メールクライアントが使用できることを前提とします。
Subjectに対して証明書発行および廃棄を実際に行う窓口になる人およびそのシステム。
RAは、自分の証明書のSubjectとしての名前以外にRAとしての識別名を持つものとします。 RA名の名前空間は、RAA（後述）によって管理されるものとします。
RAは、SSL対応のwebブラウザとS/MIME対応の電子メールクライアントが使用できることを前提とする。
将来的には、耐タンパデバイスの所持を義務づけたい。
この証明書発行システムから発行される証明書の署名鍵を管理し証明書発行を行う主体およびシステム。
CAシステムには人間は介入せず、RAからの証明書発行要求によって自動的に証明書の 発行を行う。
普通、「相互認証」という用語はCAそのものが複数存在するときに、各CAの配下にあるsubjectさんたちがお互いにどうやって相手を確認するかという方法を考えるときに使われます。
しかし、CACAnetでは、まず、一つのCAの配下にたくさんのRAがある場合にそれぞれのRAが認証したsubjectさんたちをどのように信用するのかという話についても「相互認証」という用語を用います。
CACAnetの「相互認証」は、CAが一つしかありませんから、通常の「相互認証」よりもずっと話が簡単です。技術的にも運用面からも実現できる可能性が高いと思われます。 しかし、相互認証は、このように話を単純化してもなお難しいものであるということも注意をお願いします。
このRAAというのは、CACAnetオリジナルの概念です。
すでに証明書を所持しているCACAnet会員を「あなたをRAにします」と宣言してRAにしてしまえる人およびその人の権限を指します。
CACAnetの団体会員になると、CACAnetはその団体の代表者にこのRAAの権限を与えます。 この最初のRAAさんは、CACAnetが直接認証した方になります。 また、RAAの権限だけではその団体のメンバーに証明書を発行できないので、RAの権限も与えます。
RAA は、組織ごとに一つ（一人）を原則とするが、RAAの不慮の事故などに備えてバッ クアップを持つことができるものとする。 具体的な方式は検討課題。
RAAは、SSL対応のwebブラウザとS/MIME対応の電子メールクライアントが使用できることを前 提とする。
将来的には耐タンパデバイスの使用を必須にしたいです。
CACAnetの運営委員会（現在のＭＬ）は、証明書発行システムの最終的なチェックを行う権威機関になります。
すべてのRAAに対して任命と解任の権限を持つものとします。 任命や解任の承認は通常の「承認」手続きで行います。
CACAnet運営委員会はすべてのRAAのRAへのRA権の操作を監視します。
CACAnet運営委員の各メンバーは、署名付きメールの検証が可能な電子メールソフトを持つことを前提とする。
RAからの要求に基づいて証明書発行を行うセッションを管理するサーバーシステムです。 証明書発行システムの中核となるシステムで、これから作成する証明書発行システムの中心です。
clan vector は、CACAnetのオリジナルの概念です。 発行された証明書がそれぞれどのRAから発行されたのかという発行関係の連鎖情報を管理するためのデータベースです。
発行者RAの証明書のシリアル番号とsubject の証明書のシリアル番号の対および信用 情報から構成されています。
clan vector は、乱数で作られたシリアル番号の対なので、それ自体を見ても、それぞれが誰の証明書であるかということをすぐに知ることはできませんが、ある起点にある証明書から発行された証明書群を調べることや一括して廃棄すること、評判情報などの集積が可能になります。
CACAnetの証明書発行システムは、CACAnetの個人会員および団体会員間の相互的な信用を使った信用モデルを提案しています。
まず、個人会員への個人証明書の発行はどのようにして信用を保証するかという話からです。
証明書発行には、もう一つ、スケーラビリティの問題もあります。 CACAnetの個人会員が何千人という規模になってきたときに、どうやって窓口をやるのか？ 事務コストはどうするのか？という問題も合わせて考える必要があります。
CACAnetの会員間の連鎖的な信頼関係を利用して、証明書の発行審査や廃棄窓口業務の負荷分散を図ることを想定しています。
ただし、RAになる権限は RAA によって厳重に管理されます。
「どろぼうはダメです」という法律があるからと言ってどろぼうが世の中に一人も存在しないわけではありません。
「RAは不正をしてはダメです」「法律で罰せられます」などと書いても、問題は必ず起こるでしょう。システムとしては、そのような問題が起きたときに、全ての証明書の信用が一気に崩壊しないようにする必要があります。
RAによる不正な証明書発行が発生した場合に追求を可能にするために、証明書発行の連鎖はclan vector によって管理されます。
RAによる証明書発行は、すべてCACAnet運営委員によってもモニターされます。 運営委員会ＭＬに流れるこれらの登録情報はタイムスタンプ付きで署名されて配布され、RAの不正を立証するための証拠としても利用される。
RAA: CACAnet運営委員会が認定したCACAnet会員
RA: RAAが定義した会員
RA名は、"CACAnet Class A members RA"
Subject
|<-------------------------------+
RA +-> Subject |
+-> Subject |
+-> Subject |
|<----------------------+-RAA
RA +-> Subject |
+-> Subject |
+-> Subject |
|<-------------+
RA +-> Subject
+-> Subject
+-> Subject
CACAnetは団体会員に、RAA権を譲渡する。 団体会員は、その団体の構成員に対してRA権を定義し証明書発行を行う。
たとえば、大学のような大きな組織では、学部や学科や研究室などの単位でRAを定義 することによって証明書発行や廃棄の受付などの運用のコストを分散させることがで きる。
RAA
|
+---------------+---------------+
| | |
v v v
RA +-> Subject RA +-> Subject RA +-> Subject
+-> Subject +-> Subject +-> Subject
+-> Subject +-> Subject +-> Subject
ただし団体会員の場合も個人会員のときと同様に、RAになる権限は RAA によって厳 重に管理されるとともに、RAによる不正な証明書発行が発生した場合に追求を可能に するために、証明書発行の連鎖はclan vector によって管理される。
RAによる証明書発行は、すべてCACAnet運営委員によってもモニターされる。 これらの情報はタイムスタンプ付きで署名されて配布され、RAの不正を立証するため の証拠としても利用される。
CPSは、RAAごとに定義されるものとします。 また、共通のRAAから認定されたRAの運用は共通のCPSで運営されるものとします。
RAAが定めるCPSは、CACAnetのCAのCPSと整合性を持ち、CACAnetとの契約による合意 が成立しているものとします。
また、発行される証明書の CertificatePolicy フィールドに記述されるオブジェク ト識別子やCPS文書実体へのURLなどはRAAごとに定義されなければならないものとします(MUST)。
CACAnet自体も個人会員向けのRAAを持ちます。 CACAnetのRAAも基本的に一つです。したがって、CACAnet会員の個人証明書のCertificatePolicy フィールドの値は、RAに関わらずすべて共通になります。