Title: WIDE ROOT 系列 CA鍵対変更実験ノート (Ver 0.4) Author(s): 櫻井 三子(mine@ax.jp.nec.com) Date: 9/1/2004 本ドキュメントは、2000年10月16日に作成され、2004年にWIDEドラフト として改めて登録申請を行なったものです。 概要 現在、商用を含めて多くのCAが運用されているが、CA証明書の有効期限ぎれ等 に際してCA鍵対を変更した例はまだほとんど見られない。この実験では、 あるルートCAとその下のCAの鍵対を全て変更した場合に、既存のアプリケーショ ンにどのような影響が出るかを中心に考察した。その結果、CAの鍵対を変更し たらCAの識別名を一緒に変更しないと、スムーズには移行できない状況である とわかった。そもそも、CAの鍵対を変更したときにCAの識別名を変えるか変え ないかということが、CAの運用ポリシの中でどれほど重要な意味を持つか、議 論されたことはあるだろうか。もしCAの識別名を変えるか変えないかを自由に 決められるなら、既存のアプリケーションは、どちらのケースにも対応する必 要がある。 ご意見等があったら moca-wg@wide.ad.jp 宛てにどうぞ。 1. 背景 WIDEプロジェクトには、WIDE ROOT CAと呼ばれるルートCAと、その下の 2つのCAとがある。 WIDE ROOT CA / \ moCA School of Internet CA(SOI CA) 2つのCAである "moCA" と "School of Internet CA"で発行している証明書 には以下の種類がある。 ・TLS/SSLサーバ用証明書 - Apache_1.3.9_SSL_1.37+openSSL0.9.5a ・TLS/SSLクライアント用証明書 - Netscape Navigator(Version 4.5-4.7) - Internet Explorer(Version 5.00 or higher) (*) ・S/MIME用証明書 - Netscape Messenger(Version 4.5-4.7) - Outlook Express (*) (*) Internet Explorer用証明書については、発行を直接サポートしている わけではないが、Netscape用証明書(と秘密鍵)をPKCS#12形式でInternet Explorerにインポートして利用することができる。(Outlook Expressに ついても同様) これらのCAに関する情報は以下のURLより入手可 http://www.wide.ad.jp/wg/moca/wide_root_ca.html 2. CA鍵対変更実験 WIDEプロジェクトでは、2000年1月、上記1で述べたCA階層にある全てのCA の鍵対を変更し、新しいCA証明書を発行した。鍵対変更の理由は、鍵長を 512bitから2,048bitにすることであった。 WIDE ROOT CA(old) WIDE ROOT CA(new) / \ / \ moCA SOI CA ==> moCA SOI CA (old) (old) (new) (new) この機会を利用して、secure WWW(TLS/SSL)やセキュリティ強化メール (S/MIME)のような既存のアプリケーションがCAの鍵対変更に対処できるか どうかを調査することにした。この機会にともなって、WWWサーバやユーザ などのエンドエンティティの証明書は全て発行しなおしということになる。 一般に、CAの鍵対変更をする場合、エンドエンティティが同時刻に一斉に その鍵対変更に対応するとは考えにくい。新旧の鍵対に切り替えるための 移行期間を設け、その期間内は両方使えるようにする方が混乱が少ない。 移行期間における問題は、自分がCAの鍵対変更に対応しても、通信相手が それに対応しているとは限らないために通信がうまくいかない可能性がある 点である。 あるユーザ証明書の署名検証を行う際に、その証明書を発行したCA証明書が 複数あれば、候補となるCA証明書を1つ1つ検証すればよい。 RFC2459では、この処理を効率的に行うために、subjectKeyIdentifier拡張 フィールドとauthorityKeyIdentifier拡張フィールドを利用して同じCAの 複数の鍵対を区別する方法について述べている。また、RFC2510では、ルー トCAの鍵対変更を扱うために、NewwithOld証明書とOldwithNew証明書を利 用した移行方法について述べている。 以降では特に、WIDE ROOT CAとmoCAに焦点をあて、実験内容について述べる。 以下にこの実験に関する3つの仮定について説明する。 (a) CAの鍵対変更時、CAの新旧証明書はある期間(図中の移行期間、つまり 新CA証明書の期限開始日と旧CA証明書の期限終了日の間)両方とも信頼 できる。 ---------------------------------------------------> time the old CA cert <======================> the new CA cert <==============================> |-------| 移行期間 移行期間中、エンドエンティティ証明書は旧CA秘密鍵で署名されてい る場合もあれば、新CA秘密鍵で署名されている場合もある(そして、 そのどれもが有効)。 (b) 新旧のCAは、識別名(distinguished name)を同じにする。 例: WIDE ROOT CAの識別名は新旧とも、 "CN=ROOT CA, O=WIDE Project, C=JP"。 moCA'の識別名は新旧とも、 "OU=members only CA, O=WIDE Project, C=JP"。 (c) 全ての旧CA証明書には subjectKeyIdentifier拡張フィールド が含まれていない。また、全ての旧エンドエンティティ証明書には authorityKeyIdentifier拡張フィールドが含まれていない。 この実験の目標は、CAの識別名を変えずにCAの鍵対を変更した場合に、 既存のアプリケーションが対応できるかどうかを確認すること、あるい は(対応できなければ)対応できる方法を探すことである。 具体的には、既存アプリケーションについて下記を調査する。 (1) secure WWW(TLS/SSL) Q1 - あるWWWクライアント(ブラウザ)には、新CA証明書が設定されている とする。このWWWクライアントは、TLS/SSLサーバ認証時に、(旧CAの 鍵で署名された)旧WWWサーバ証明書が送られてきても、(新CAの鍵で 署名された)新WWWサーバ証明書が送られてきても、正しく検証でき るか? Q2 - あるWWWサーバ(Apache+openSSLサーバ)には、新CA証明書および新 WWWサーバ証明書が設定されているとする。TLS/SSLクライアント認 証時に、(旧CAの鍵で署名された)旧WWWクライアント証明書が送られ てきても、(新CAの鍵で署名された)新WWWクライアント証明書が送ら れてきても、正しく検証できるか? (2) セキュリティ強化メール (S/MIME) あるユーザ1は、ユーザ1用の証明書データベースに自分の新鍵対 および新CA証明書を設定しているとする。 Q3 - ユーザ1は、ユーザ1の旧公開鍵を使って暗号化されたメールを 復号できるか? Q4 - ユーザ1は、ユーザ2が旧秘密鍵で署名したメールを正しく検証 できるか? Q5 - ユーザ1は、ユーザ2の旧公開鍵を使ってメールを暗号化してユー ザ2に送れるか? Q6 - ユーザ1は、ユーザ1の旧秘密鍵で署名したメールを送れるか? 3. 実験結果 まず、今回実験に使用した全てのアプリケーションは、RFC2510で述べられ ているNewwithOld証明書もOldwithNew証明書も単なる自己署名証明書として 扱われてしまった。したがって、NewwithNew->OldwithNew->User1withOldの ように連携して署名検証することができなかった。 そこで、それ以外の方法を探ることにしたが、2で述べた全ての項目に 対応できる解は得られなかった。 以下では、記録のために各項目に関する実験結果について述べる。 (1) secure WWW(TLS/SSL) Q1に対して: ブラウザによって結果が違う。 まず、Internet Explorer, Netscape Navigatorのどちらでも、証明書デー タベースにある「信頼するCA」に、同じ識別名を持つ新旧CA証明書を格 納することはできた。そこで、新旧のWIDE ROOT CA証明書を証明書デー タベースに格納した。 新旧のmoCA証明書を格納すべきかどうかは、ブラウザの実装に依存 して変わった。 詳細は以下。 Internet Explorer: TLS/SSLのセッション中、新WWWサーバ証明書が送られてきても、旧 WWWサーバ証明書が送られてきても、Internet Explorerには正しく 検証できた。 実験時は、新旧のmoCA証明書をともに証明書データベースに格納し ていた。しかし、片方しか格納していなくても結果は変わらなかっ た。TLS/SSLセッション中、(ルートでない)下位CA証明書はWWWサー バから直接送られており、 Internet Explorerでは送られてきた下 位CA証明書を使って証明書を検証していると推測される。 Netscape Navigator: 以下の条件が全て満たされる時だけ、TLS/SSLのセッション中、新 WWWサーバ証明書が送られてきても、旧WWWサーバ証明書が送られて きても、正しく検証できた。 * 新moCA証明書にはsubjectKeyIdentifier拡張フィールドが 含まれている * 新WWWサーバ証明書にはauthorityKeyIdentifier拡張フィー ルドが含まれている * 証明書データベースに旧moCA証明書は格納されているが、 新moCA証明書は格納されていない これらの条件を満たさない場合は, 新WWWサーバ証明書しか 正しく検証できなかった。したがって、Netscape Navigatorで 旧WWWサーバ証明書を持つWWWサーバにアクセスすると、不正な サーバと判断され、アクセスできなかった。 Q2に対して: ApacheサーバがTLS/SSLクライアント認証を利用する場合は、 新旧クライアント証明書に対応することは不可能であった。 移行期間中、新クライアント証明書に対応したサーバと旧クライアン ト証明書に対応したサーバの2つを用意しなければならない。 Apache+openSSLを利用すると、Apacheの設定ファイル中に指定した CA証明書格納ディレクトリに複数のCA証明書を設定できるが、 同じ識別名を持つ新旧CA証明書を2つとも設定することはできなかっ た。理由は、openSSLの仕様では、証明書検証時にCAの識別名(のハッ シュ値)のみに基づいてCA証明書を検索するため、新旧のどちらか一 方しか一度には使えないためである。 新証明書にsubjectKeyIdentifier拡張フィールドや authorityKeyIdentifier拡張フィールドを入れて再度試したが、結果は 同じであった。 ところで、CA格納ディレクトリにCA証明書を置く時のファイル名は "CA識別名ハッシュ値.インデックス番号"という形式である。 試しにインデックス番号を変えて、新CA証明書を"3bd9f5a.0"、 旧CA証明書を"3bd9fb5a.1"としてみたが効果はなく、"3bd9f5a.0"の 方しか認識されなかった。 (2) security enhanced email (S/MIME) Outlook ExpressとInternet Explorer は証明書データベースを共有 している。また、Netscape MessengerとNetscape Navigatorも証明書 データベースを共有している。(1)より、Internet ExplorerやNetscape Navigatorの証明書データベースに同じ識別名を持つ新旧WIDE ROOT CA 証明書を格納できたということは、Outlook ExpressやNetscape Messengerについても同じことがいえる。 Outlook Express, Netscape Messengerどちらの場合も、新秘密鍵による 署名つきメールを送信したい場合は、新moCA証明書を証明書データベー スに格納しておく必要があるとわかった。したがって、新鍵対に対応する ときには、新旧WIDE ROOT CA 証明書とともに、新旧moCA証明書も証明書 データベースに格納する。 Q3に対して: ユーザ1は、証明書データベースに自分の旧秘密鍵を残していれば、 旧公開鍵で暗号化されたメールを復号して読める。 ユーザへは、自分の新鍵対を設定するときに、証明書データベース から旧証明書を削除しないように(*)アナウンスすべきである。 (*)自分の証明書を削除すると、対応する秘密鍵も一緒に削除される 仕様となっている。 Q4に対して: ツールによって結果が違う。 - Outlook Express 移行期間中、ユーザ2の旧秘密鍵による署名は正しく検証できる。 Outlook Express とInternet Explorerで共有している証明書データ ベースでは新旧CA証明書を扱えるため、Outlook Express はユーザ2 の旧証明書の検証パスを確立できる。 - Netscape Messenger ユーザ2の旧秘密鍵による署名はほとんどの場合、正しく検証でき ない。以下の条件が全て満たされる場合にのみ、正しく検証できた。 * 新下位CA証明書にsubjectKeyIdentifier拡張フィールドが含まれ ている * ユーザ1の新証明書にauthorityKeyIdentifier拡張フィールドが 含まれている * ユーザ1の証明書データベース中に、新WIDE ROOT CA証明書は格納さ れているが、新moCA証明書は格納されていない この結果の意味するところは、ユーザ1は、ユーザ1の新秘密鍵を 使って署名をし始めると、新moCA証明書を格納しなければならなくな るため上記の条件が満たされなくなり、ユーザ2の旧秘密鍵による署名 を正しく検証できなくなるということである。 Q5に対して: ユーザ1は、ユーザ2の旧証明書のみを証明書データベース中に持ってい るときは、ユーザ2の旧公開鍵を使ってメールを暗号化して送れた。 もし、ユーザ2の新旧証明書がユーザ1の証明書データベースに両方入っ ていたらどちらかを選択して使用できるかは十分に試さなかったが、 Netscape Messengerでは新証明書の方しか使えなかった。 Q6に対して: Outlook Expressでは、ユーザ1は、自分の旧秘密鍵を使ってメールに署 名して送れた。 Netscape Messengerでは、ユーザ1は、新moCA証明書を証明書データベー スから削除することによって、自分の旧秘密鍵を使ってメールに署名し て送れたが、そうすると、新秘密鍵を使ってメールに署名することはで きなくなる。 4. まとめ 同じ識別名を持つ新旧CA証明書を扱うための方法は、secure WWWとセキュ リティ強化メール用の実装とで一貫性がなかった。下位CAである moCA は、 secure WWW用とS/MIME用証明書の両方をサポートしているため、両方に対応 できる方法を見つけることができず、結果として移行期間中の旧CA証明書の サポートができなかった。 今回、仮定(b)、つまり新旧CAが同じ識別名を持つということが状況をより 複雑にしたと考えられる。CA鍵対を変える場合には、CAの識別名の一部を 変更した方が、外見上は異なるCAが増えただけという扱いになり、問題は 少ない。CA鍵対を変える場合にCAの識別名を変えるべきかどうかは、ポリシ にも関連してくるが、議論が不足している。しかし、CAを利用するツールに おいて、信頼するルートCAを複数指定できる機能があるならば、同じ識別名 を持つ新旧CAを両方とも信頼できるべきではないだろうか。 今回の実験により、Internet ExplorerとNetscape Navigatorは、 subjectKeyIdentifier拡張フィールドとauthorityKeyIdentifier拡張フィー ルドを解釈できることがわかった。旧CA証明書にsubjectKeyIdentifier拡 張フィールドが含まれていれば、よい解が見つかったかもしれない。 しかし、現状出回っている多くのルートCA証明書ではsubjectKeyIdentifier が含まれていないという現実に気づいているだろうか。途中でCA証明書に subjectKeyIdentifierを含めようとしても、エンドエンティティの証明書に authorityKeyIdentifierを含めて再発行するということは困難である。 逆に言うと、今後CAを新規に立ち上げる場合は、CA証明書に subjectKeyIdentifier拡張フィールドを、そして、エンドエンティティ証明 書にauthorityKeyIdentifier拡張フィールドを含めた方が無難である。 Apache+openSSLは、CA名に加えて、subjectKeyIdentifierと authorityKeyIdentifierを利用して必要なCA証明書にたどりつく実装になっ ていなかった(実験時点では(*))。もしまだなら、対応していただきたいし、 加えて、今回の実験のような状況についても対応できるようにCA名ハッシュ 値の重複を許すように修正していただきたい。 (*)openSSL0.9.6では、subjectKeyIdentifierとauthorityKeyIdentifierを 使って証明書検証できることがわかった。しかし、今回のように旧系列が subjectKeyIdentifierとauthorityKeyIdentifierに対応していない場合に は有効ではないこともわかった。 Copyright Notice Copyright (C) WIDE Project (2000-2004). All Rights Reserved.