1.2 システム構成
+------+ +--------------+ SSL(c),S/MIME(es) +--------+
| CA |SSL(c)| RA server |<----------------->| RA |
| +<---->+ | +--------+
| | | | SSL(s),S/MIME(s) +--------+
+------+ | |<----------------->| subject|
| | +--------+
|+------------+| SSL(c) +--------+
||RA server DB||<----------------->| RAA |
|+------------+| +--------+
| | S/MIME(s) +--------+
| |------------------>| Board |
+--------------+ +--------+
SSL(c): SSLのクライアント認証付きhttpセッション
SSL(s): SSLのサーバー認証のみhttpセッション
S/MIME(es): S/MIMEの暗号化と署名付きメール
S/MIME(s): S/MIMEの署名付きメール
4. 個人証明書発行手続き
次の図は、証明書発行手続きの概要である。
RA server RA Subject
+---------------+ +--------------+
| 事前作業 <--> 事前作業 |
+-------+-------+ +--------------+
S | out of band
|------------------------+ |
| RAによるsubjectの登録 |<-----------+
|------------------------+ SSL(c)
|
+------------------------+ +---------------+
| RAに秘密情報 を |--->| 秘密情報 入手|
| 暗号メールで送信 | +-------+-------+
+------------------------+S/MIME(es) | +---------------+
| +-------->| 秘密情報 入手 |
+------------------------+ out of band +---------------+
| SubjectにセッションIDを| +------------------+
| 署名付きメールで送信 |--------------------->| セッションID入手 |
+------------------------+ S/MIME(s) +-------+----------+
E |
|
S |
+------------------------+ |
| Subjectが秘密情報 と |<-----------------------------+
|セッションIDを入力する | SSL(s)
+------------------------+
| +-----------------+
+---+-|秘密情報確認成功 | RA server DBで確認
|if/ +-----------------+
+-+
| +-+then
| |
| +----------------------+
| |証明書発行に必要となる| SSL(s) +--------------+
| |Subjecの個人情報を入力|<---------------------+個人情報を入力|
| +----------------------+ +--------------+
| |
| |
| +----------------------+ S/MIME(es)
| | RAに個人情報の確認を +-------------+
| | 暗号メールで送信 | S |
| +----------------------+ +-------v--------+
| | | 個人情報を入手 |
| +-+else +----------------+
| | | +----------+
| +----------------------+ +---+-| 確認 |
| | 秘密情報エラーを表示 | |if/ +----------+
| +----------------------+ +-+
+ | |
E | +-+then
| |
S SSL(c) | +--------------+
+ +--------------------+ 承認する |
| | | +--------------+
+-----------v---------+ | |
|RAからの承認を受ける | | +-+else
+---------------------+ | |
| | +--------------+
| | | 承認しない |
| + +--------------+
| E
+---------------------+ S/MIME(s)
| RAの承認を通知する +---------------------------------+
+---------------------+ |
| |
E S |
+ |
+-------v-------+
| RA承認の受信 |
+---------------+
S |
+ SSL(s) +---------------+
| <---------------------------------------------+ URLへアクセス |
| +---------------+
| |
+------------------------+ +---------------+
| Subjectが秘密情報 と |<---------------------+秘密情報の入力 |
| セッションIDを入力する | SSL(s) +---------------+
+------------------------+ |
| +-----------------+ |
+---+-|秘密情報確認成功 | RA server DBで確認 |
|if/ +-----------------+ |
+-+ |
| +-+then +----------------+
| +--------------------------+ |証明書発行方法を|
| | 証明書発行方法を受付 |<-----------------+選択 |
| +--------------------------+ +----------------+
| | |
| | +------------------+ +
| +-----+-+ p12で証明書発行 | 続く
| |case/ +------------------+
| +-+-+ p12で証明書発行の場合
| | | +
| | |------------------------+ |
| | | P12ファイル用 | SSL(s) +---------------+
| | | パスワード入力 |<-----------------+ パスワード入力|
| | |------------------------+ +---------------+
| | | |
| | +------------------------+ |
| | |鍵生成、request file作成| |
| | +------------------------+ |
| | | |
| | +------------------------+ |
| | |証明書作成 （CAを利用） | |
| | +------------------------+ |
| | | |
| | +------------------------+ |
| | | p12ファイル作成 | |
| | +------------------------+ |
| | | +----------------+
| | +------------------------+ SSL(s) | p12ファイルを |
| | | Subjectにp12ファイルの +----------------->| 受け取る |
| | | URLを通知 | +----------------+
| | +------------------------+ |
| | +----------------+
| | | p12ファイルを |
| | | 組み込む |
| | +----------------+
| | +
| | E
| |
| | +------------------+
| +-----+-+keygenで証明書発行|
| |case/ +------------------+ keygenで証明書発行の場合
| +-+-+ +
| | | +----------------+
| | | SSL(s) | 鍵生成ページに |
| | +------------------------+<-----------------+ アクセス |
| | |鍵生成ページを表示 | SSL(s) +----------------+
| | +------------------------+----------------> |
| | | +----------------+
| | | SSL(s) |keygen formで |
| | +------------------------+<-----------------+鍵生成 |
| | |SPKACのリクエストを受信 | +----------------+
| | +------------------------+ |
| | | |
| | +------------------------+ |
| | | 証明書発行（CAを利用） | |
| | +------------------------+ |
| | | |
| | +------------------------+ |
| | |Subjectにcertファイルの | +----------------+
| | |URLを通知 +----------------->|certファイルを |
| | +------------------------+ |組み込む |
| | +----------------+
| +------------------------+ |
| | 証明書リポジトリへ登録 | +
| +------------------------+ E
| |
| +------------------------+
| | クランベクターへ登録 |
| +------------------------+
| |
| +- else
| |
| +------------------------+
| | 秘密情報エラーを表示 |
| +------------------------+
|
|
+
E
★以下の説明文は、単純に秘密情報1をセッションIDに変更しただけなので、少しお
かしくなっています。セッション管理DBでセッションIDをキーにして秘密情報のMD5
ハッシュを取り出すという仕様が現状のものです。
RAはout of bandな方法によるsubjectの意志確認を行います。 通常は、「証明書発行申請書」みたいな書類を書いてもらうことになるでしょう。
RAが事前に確認すべき情報 *subjectの氏名 *subjectの連絡用メールアドレス （但し、証明書発行に使用するアドレスはsubjectが自分で指定できるようにする）
CACAnetのCAが発行したデジタル証明書は、CACAnetのCAの証明書が無ければ検証することができません。 そこで、まず、新しいsubjectさんに、CACAnetのCAの証明書を自分のブラウザや電子メールソフトに組み込んでいただく必要があります。
このあたりの作業を楽にするためには、CACAnetのページに手順のマニュアルを整備する必要がありますが、RAさんにも、親切に教えてあげるという忍耐力が要求されます。
こういう説明と同時に、CAの証明書の意味の説明なども必要となりますので、教育コストがかかるのは覚悟してコストに予め含めておく必要があります。
同じRAAの配下で他のRAが当該subjectにすでに証明書を発行している可能性があります。
本システムでは、同一のDNによる証明書の多重発行は認めていません。 同一DNによる証明書の多重発行を事前に防止するために、RAさんは RA server DBを使って多重登録のチェックを行わないといけません。RA が RA server のクライアント認証付きSSLでアクセスするページで、subjectの登録を行います。
このページへのアクセス制御では、CACAnetの会員証明書によるクライアント認証だけでなく、RA権限があることを確認する必要があります。
この権限の検証には、RA server DBを利用します。
RAは、この登録ページで事前に入手したsubjectの情報を登録する。 登録する情報は次の二つである。
*本人の氏名 *本人の連絡用メールアドレス
また、RAが後述する秘密情報をSubjectに通知するための手段もここで入力する。 手段としては、直接対面、電話、郵送などが考えられる。
★注意：電子メールは盗聴の危険性が高いので、秘密情報の通知手段として電子メー ルを使用してはならない。
このRAによる登録操作によって、証明書発行システムのセッションが開始される。 セッションの状態は、RA server DBによってセッションIDに基づいて管理される。
Subjectの本人確認を行うための秘密情報を生成する。 秘密情報を使ってSubjectの本人確認を行ううえで、次のような問題がある。
指定されたメールアドレスに認証用の秘密情報を送信し、その秘密情報を要求する ことによって本人確認はできるが、メールを盗聴することによって秘密情報を第３者 が知ることが可能なのでなりすましが可能である。
RAに秘密情報を渡すことにした場合、Subjectの代わりにRAが自分で他人の証明書 を取得するという不正が簡単に行えるようになる。
以上のような問題に対処するために、秘密情報を秘密情報 とセッションIDの二つに 分割し、そのうち秘密情報 はRAを経由してSunjectに渡され、セッションIDは本人に 直接渡されるようにすることによりメールの盗聴によるなりすましとRAによる不正が簡単に行えるという問題を解決する。
RAによるメール盗聴による不正の危険は残るが、Subjectにも通知メールがあること とRAとの接触があるために、RAが盗聴した情報を使ってSubjectになりすますことは 困難であると考えられる。
しかし、Subjectが通知メールを無視して登録を放置した場合にはなりすましの危険 性が高まるので、一定の期間登録を行わなかった場合は、登録処理をキャンセルすべ きである。
RA serverは、メールの盗聴者が存在しても秘密情報が漏洩しないようにRAに秘密情 報 を暗号メールで送信する。 RAへ暗号化メールができるように RA serverには、RAの証明書を登録しておく必要が ある。
RA serverは、Subjectに秘密情報を署名付きメールで送信を送信する。 使用する署名は、CACAnet事務局のものとする。 署名付きメールを送信できるように、RA serverは、CACAnet事務局の秘密鍵を持つ必 要がある。
Subjectに通知されるメールには、セッションIDが入っているだけでなく、RAから秘 密情報 を入手する手段についても記述されているものとする。
直接対面、電話、郵送などの安全な方法でSubjectからRAに秘密情報 を通知する。
SubjectがRA serverのSSLサーバー認証ページアクセスして、秘密情報 とセッショ ンIDを入力する。
RA server は、RA server DBに登録されている秘密情報 とセッションIDを合成した データーのハッシュ値と比較を行い、Subject が正しい秘密情報を入力したことを確 認する。
この確認が成功したときにのみ、正常に処理が進められる。
この確認が失敗した場合、「秘密情報エラーを」表示し、再度の秘密情報の入力画面 になる。
Subjectは、証明書発行に必要となる自分の情報を入力を入力する。
★入力情報：
証明書の記載内容を決定するための情報をRA serverのデーターベースに登録する。
*電子メールアドレス（暗号メールや署名メールに使用するアドレスであること） *ローマ字の氏名
RAのポリシーを参照して、オプションとして次のような情報の入力を要求する （RAが本人確認を行うためのその他の情報） これらの個人情報はRA server のデーターベスには登録されない。
*住所 *生年月日 *性別 *電話番号 *所属 *所属電話番号 *組織内役職 *その他の情報 *本人確認のための想定質問（母親の旧姓など） *本人確認のための想定質問への応答
これらのオプション情報はRAのポリシーに依存する。 RA server のデータベースにはこれらのオプションの個人情報は格納せず、直接暗号 メールでRAに通知する。その後の個人情報の管理責任もRAにあるものとする。
この管理ポリシーについては個人情報管理ポリシーとして Subjectに明示する。
RA serverは、Subjectから入力された情報をRAに暗号メールで通知し、確認を行う。 これは、Subjectが事前にRAに申請していたものと異なる情報を入れていないか、特 に、他人になりすますための証明書発行要求をしていないことを確認するために必要 となる。
RAは、RA serverからの暗号、署名付きメールでSubjectの登録内容を確認する。 これの確認が成功すると、メールの中に記載されたURLにアクセスして「承認」を行 う。このセッションはクライアント認証付きのSSLセッションで行う。
確認の結果、RAが登録内容を承認できない場合、処理を遂行することができなくなり ます。
この場合、この後のRAによる処置として次のようなものが考えられる。
*入力ミスと考えられる場合：Subjectにミスの件を通知し、再度入力を依頼する。 *明かな不正である場合、運営委員会に通知し、セッションを中止する。
RA serverから署名付きS/MIMEメールでsubjectにRAからの承認の通知が送信される。 このメールには、証明書発行ページのURLが記載される。
このときに、再び秘密情報 とセッションIDの入力を行い、本人確認を行う。
証明書発行処理には、RA server側で秘密鍵の生成まで行い、PKCS#12形式でSubject に証明書と秘密鍵の対を返す方法と、Subjectのブラウザ（Netscapeに限定）側で鍵 生成を行い、公開鍵のみをRA serverに送る方法とをサポートする。
subject が証明書発行方法を選択する。 操作方法や方式の特徴については説明を用意する。
ポイントは
*p12方式 利点：ブラウザを選ばないこと。エクスポートしなくても証明書を複数のアプリケー ションで利用できること。 欠点：秘密鍵をRA server側で生成するので、秘密鍵がRA serverから漏洩する疑い を完全に消すことができない。
*keygen方式 利点：subject側で鍵生成を行うので、秘密鍵の漏洩の心配がない。 JAVA ringなどでも鍵が生成でき、安全性が高い。 欠点：Netscapeだけしか利用できない。 他のアプリケーションで利用するには鍵をNetscapeからエクスポートしない といけない。
subjectは、p12ファイルの秘密鍵を保護するためのパスワードを入力する。 このパスワードはデーターベースなどには格納しない。 ユーザーには、本システムではパスワードの管理を行わないことを表示する。
RA server は、登録されたSubjectの情報を元に、鍵生成、リクエストファイルの生 成を行う。
さらに、リクエストファイルをCAに送付し、CAによる署名を行って完成した証明書を 得る。
このCAとRA serverとのセッションは、クライアント認証付きのSSLで行う。
証明書が完成すると、秘密鍵とともにp12ファイルを作成する。 このp12ファイルは、Subjectが事前に入力したパスワードを使って暗号化する。
RA serverは完成したp12ファイルのURLをSSLで通知する。
<keygen> タグを<form>の中に持つページにアクセスする。 subjectのnetscape で鍵生成を行う。
鍵生成の結果は、formを通じてRA server に送られる。 この形式は、SPKAC になっている。
SPKAC形式のリクエストファイルとsubjectの登録情報を元にCAを使って証明書を作成 する。
完成した証明書が格納されているURLをsubjectにSSLで通知する。 MIME type の指定によって、Netscapeが証明書を組み込む。
完成した証明書を証明書リポジトリに格納する。
生成された証明書の情報をクランベクターに登録する。