まず、証明書発行のすごく基本から説明します。 公開鍵証明書とは、公開鍵暗号の公開鍵に「これはこの人のものですよ」ということをみんなに信頼されている権威のある機関が電子署名をしたものです。この権威機関がCAです。電子署名にはCAの秘密鍵が必要です。
CAには次のものが必要です。
このような証明書発行のやりとりについての標準は、RFC2510 :Internet X.509 Public Key Infrastructure Certificate Management Protocolsに定義されています。
この標準にかなりしっかり準拠したシステムの実装としてOpenCAプロジェクトのものがあります。 このプロジェクトはオープンソースのツールを組み合わせたもので、OpenSSL,OpenLDAP,Apache,mod_SSLなどを使っています。このあたりはCACAnetとほぼ同じです。
ただし、この標準は多くの部分を実際の運用に任せているために、このOpenCAのシステムも肝心の部分が手作業になっていたりします。 CACAnetはこれまでの実験をふまえながら、より実用的な認証モデルそのものを模索しているということもあり、 既存のシステムをそのまま利用するというわけにはいきません。そのために、自分たちで最初からシステムを作ろうとしています。
それでは、まずRFC2510などに現れる主な登場人物を簡単に説明しましょう。
ここで、RAという登場人物が加わりました。RAは、証明書発行のときに実際に本人確認などの窓口業務を行う機関のことです。 実際に証明書の発行を行ってみるとわかることは、この窓口業務がとてもたいへんで時間と人がかかるということです。 電子認証の目的は、「架空の人物」のいない安心できる場所を作ることにありますが、RAの仕事がいい加減だとこの大前提が崩れてしまいます。
RAでは、運転免許証などの公文書を用いた本人確認など、現実の社会で一般に信用されている手段で本人確認を行います。 この手段を具体的に規定するのは、RAのポリシーです。通常はこれを文書化して公開します。 電子署名法の政省令では、認定認証機関としての本人確認の方法が規定されています。
一般的には、PKIを社会基盤として利用するためには大量の証明書発行が必要になりますから、窓口であるRAがたくさんないと処理しきれなくなります。 一つのCAに対して、複数のRAが接続するというのが一般的な姿だと思います。
では、次に、基本的な証明書の発行の手順について説明します。
証明書発行は基本的に次のように行います。
まず最初にやることはsubjectさんの公開鍵と秘密鍵のペアを作ることです。
この鍵生成は、subjectさん自身で行う場合と信頼できる機関が代行する場合があります。
誰かに代行してもらった場合、代行した人がsubjectになりすますことが可能になります。 代行した方も、警察などから「捜査のために鍵を出してくれ」と要請されるかもしれませんし、その鍵が犯罪に使われた場合などにあらぬ疑いをかけられる可能性もあります。
RAやCA側で作成した鍵のペアと完成した証明書をセットにして暗号化したファイルの標準としてPKCS#12があります。 PKCS#12は、NetscapeやIEに組み込むことができます。
鍵生成の機能は、Netscapeには備わっていますしIEでも可能です。 ですから、普通のsubjectさんが自分で鍵を生成することは可能です。
しかし、現在のNetscapeなどを使った鍵生成は、一般ユーザーには操作が難しい部分があります。 特に、例えば学校の学生全員や会社の社員全員に証明書を発行するといった一括処理的な形での証明書発行の場合には、CAやRAが代行する方が運用上は現実的なこともあります。
subjectさんが自分で鍵を生成した場合にさらに問題なのは、鍵を生成した本人と公開鍵の関係が正しいことを証明しなければならないということです。
subjectさんが自宅のパソコンで鍵を生成した場合、RAは、RAの窓口にやってきた人が本当に鍵を生成した本当のsubjectさんなのかどうかチェックできないといけません。
これは POP (Proof of Possession of Private Key) つまり本当にそのsubjectが秘密鍵を持っているのかというチェックを行う何らかのプロトコルが必要になります。
対して、RAやCAが鍵を生成した場合には、RAの窓口で秘密鍵とデジタル証明書のペアを手渡しすることが可能なので、POPのような手順は不要になります。
鍵生成を行った瞬間から、subjectさんは自分の秘密鍵を誰にも渡さないように大切に管理しなければなりません。
鍵生成の理想的な形は、ICカードなどの「耐タンパデバイス」と呼ばれる中身のデーターを取り出すことができない装置の中で行い、暗号化や復号化の処理もその装置の中で行うようにするというものです。
ICカードのような携帯可能な装置で鍵を安全に持ち運ぶことができれば、POPもRAの窓口で簡単に行うことができます。 また、RAがICカードの発行元でもある場合は、RAの窓口で鍵生成を行うかもしれませんが、それでも秘密鍵はICカードの外には取り出せないので、RAに鍵をバックアップされる危険性はなくなります。RAやCAにとっても、その方が責任が軽くなって好都合でしょう。
NetscapeなどのPKIを利用するアプリケーションとICカードなどの装置を扱うための標準的なAPIとしてPKCS#11があります。またマイクロソフトも独自のAPIを提案しています。
また、SSL/TLSの場合はパソコン側でPKI関係の処理を行うローカルプロキシーサーバーを動かしておいて、これでICカードなどを利用するという方法もあります。CAに証明書をリクエストを行うときの形式が決まっています。 公開鍵を含んだ「申請書」のようなものをCAに渡します。
リクエストファイルにはいくつかの標準的なフォーマットがあります。
opensslのreqコマンドなどで生成する形式です。
openssl req -new -keyout (ユーザ証明書の秘密鍵ファイル名) -out (ユーザ証明書 リクエストデータのファイル名) -config (opensslの設定ファイル名) -newkey
主にNetscapeの<keygen>タグで鍵を生成したときに使用されます。
<html> <head> <title>key generation</title> </head> <body bgcolor="white"> <h1>デジタル証明書用暗号鍵の生成</h1> <form action="keygen.rhtml" method=POST name="f"> <h2>生成する暗号鍵の長さ</h2> <p> <keygen name="spkac"> </p> <h2>本人情報</h2> <pre> ローマ字氏名： （姓）<input type="text" name=sname size=14>（例）YAMASAKI （名）<input type="text" name=fname size=14>（例）Shigeichiro 電子メールアドレス： <input type="text" name="Email" size=40> <p> <h2><input type=submit value="個人証明書申請ボタン"></h2> </p> </body> </html>
RAによる本人確認が完了すると、リクエストファイルがCAに渡されます。 CAが自分の署名用の鍵でリクエストファイルに対して電子署名を行いX.509証明書が完成します。
opensslによるユーザ証明書署名コマンド openssl ca -config (opensslの設定ファイル名) -in (ユーザ証明書リクエストデー タのファイル名) -keyfile (CA証明書の秘密鍵ファイル名) -cert (CA証明書ファイ ル名) -out (ユーザ証明書ファイル名)