Comments
Description
Transcript
公開鍵証明書発行に関する移行ガイド
2004 情財第 845 号 PKI における UTF8String 問題に関する調査 報告書 Part6: 公開鍵証明書発行に関する移行ガイド 2005 年 3 月 登録商標等について • • • • Microsoft、MS、Windows、Windows 2000、Windows NT、Windows XP、Windows ロゴ、Internet Explorer、Outlook、Outlook Express などは、米国 Microsoft Corporation の米国およびその他の国におけ る登録商標または商標である。 Sun Microsystems、Sun ロゴ、Java コーヒーカップロゴ、Solaris、 Java、JDK などは、米国 Sun Microsystems の米国およびその他の 国における登録商標または商標である。 その他、本文小児記載されている会社名、商品名、製品名などは、一 般に各社の商標または登録商標である。 本書では、™、Ⓒ、Ⓡなどを記載しない 目次 1 背景と問題 ......................................................................................................................... - 1 - 2 移行計画 ............................................................................................................................. - 1 - 3 2.1 移行のマイルストーン ................................................................................................ - 1 - 2.2 移行手段の決定 ........................................................................................................... - 3 - 移行手順の解説 .................................................................................................................. - 5 3.1 3.1.1 移行期限前に CA 証明書を更新するケース ......................................................... - 5 - 3.1.2 移行期限前に CA 証明書を再発行するケース...................................................... - 7 - 3.2 4 移行期限前に移行するケース...................................................................................... - 5 - 移行期限後に移行するケース.................................................................................... - 10 - 3.2.1 移行期限後に CA 証明書を更新するケース ....................................................... - 10 - 3.2.2 移行期限後に CA 証明書を再発行するケース.................................................... - 12 - まとめ............................................................................................................................... - 14 - 参考文献 .................................................................................................................................. - 15 - i 図表番号 表 2-1 語句の定義 ............................................................................................................. - 3 表 2-2 移行時期・移行手段とアプリの対応状況............................................................... - 4 図 2-1 移行のマイルストーン ........................................................................................... - 2 図 3-1 トラストポイントとなる CA 証明書の更新 ........................................................... - 6 図 3-2 トラストポイントを上位に持つ CA 証明書の更新................................................. - 6 図 3-3 移行期限前に CA 証明書を更新 ............................................................................. - 7 図 3-4 自己署名 CA 証明書の再発行................................................................................. - 8 図 3-5 トラストポイントを上位に持つ CA 証明書の再発行 ............................................. - 9 図 3-6 移行期限前に CA 証明書を再発行........................................................................ - 10 図 3-7 移行期限後に CA 証明書を更新 ........................................................................... - 12 図 3-8 移行期限後に CA 証明書を再発行........................................................................ - 14 - ii 1 背景と問題 本報告書 Part1 「UTF8String 問題の解説と提言」(以下、Part1)の 2 章および 4 章で述べてきたように、UTF8String への移行にはいくつかの問題があり、IETF の思ったようには移行が進んでいないのが実情である。 移行に際して直接のアクションを起こすことになるのは UTF8String でエンコ ードされた証明書を発行する CA である。しかし、Part1 の 5 章で述べたように現 状では UTF8String でエンコードされた証明書が正しく検証されない可能性があ ること、移行の具体例がほとんど示されていないこと、既存の運用への影響など を懸念して、実際に移行に踏み切った認証局はそれほど多くない。GPKI など UTF8String を採用している例も一部あるが、これらは既存エンコード方式からの 移行ではなく最初から導入していたものばかりである。 一方、移行の鍵を握るアプリケーションベンダでは、移行時や移行後の文字列 比較の要件が明確になっていないために、移行後を見据えた実装対応がなかなか 進められない、といった問題がある。 これらを整理すると、以下の 3 点にまとめられる。 (イ) UTF8String 環境のアプリケーション要件の曖昧さ (ロ) UTF8String 環境に対応したアプリケーションの不足 (ハ) UTF8String 環境への具体的移行手順に関する情報不足 (イ)については、これまで Part1 の中で解説してきており、解決する必要がある と考えられる部分については、Part1 の 6 章で述べてきた。アプリケーションベン ダはこれらを参考に(ロ)の問題を解決していく必要があるだろう。本書では、残る (ハ)について、Part1 における問題の解説と提言を踏まえて、移行時に CA が具体 的にどのような対応をとるべきか、という論点から「UTF8String 問題に対する CA の移行ガイド」として作成した。 2 移行計画 2.1 移行のマイルストーン 移行の計画を立てるにあたり、各 CA はそれぞれ以下の期日について留意する必 要がある。 • IETF/PKIX WG の定める移行期限 X -1- • 旧来エンコード方式による CA 証明書の有効期限 Y PKIX WG の定める移行期限 X とは、当初 RFC 3280[1] において 2003 年 12 月 31 日と定められていたものである。RFC 3280 の改訂版であるインターネット ドラフト 3280bis[2] では、現時点で公開されている版では移行期限に関する記述 は削除されているが、最終版までに移行期限が規定される可能性も残っている。 そこで本移行ガイドでは、このまま移行期限 X が設定されない場合と、X が設定 された場合とを想定して解説する。 なお、CA はその証明書の有効期限 Y より以前に CA 証明書の更新または再発行 を行う必要があるだろう。この CA 証明書の更新または再発行の期日を Z とする。 PKIX WG が今後 3280bis を改訂していくにあたって移行期限 X を設定した場 合、Z が実施される時機は(1)X 以前、(2)X∼Y の期間のいずれか、に分けて考える ことができる。また、PKIX WG が現状のまま移行期限 X を設定しない場合に Z が実施される時機は、X の時機を考慮しないのと同義となるため(1)と同様とみな してよいだろう。 新CA証明書の 更新または再発行 Z1 移行期限 新CA証明書の 更新または再発行 X Z2 旧CA証明書の有効期間 旧EE証明書の発行可能期間 UTF8証明書の発行期間 UTF8 CA証明書の有効期間 図 2-1 移行のマイルストーン -2- 旧CA証明書の 有効期限 Y なお、図中も含め簡略化のため本書の中では以下のように語句を定義する。 表 2-1 語句の定義 語句 定義 旧 CA 証明書 issuer, subject ともに旧来エンコード方式による CA 証明書 旧 CA 鍵 旧 CA 証明書に関連づけられた CA の鍵ペア 旧 CA 鍵に署名され、issuer, subject ともに旧来エンコード方式によってエン 旧式証明書 コードされた証明書 旧 CA 鍵に署名され、issuer が旧来エンコード方式によってエンコードされた 旧 CRL CRL 新 CA 証明書 issuer, subject ともに UTF8String によってエンコードされた CA 証明書 新 CA 鍵 新 CA 証明書に関連づけられた CA の鍵ペア 新 CRL 新 CA 鍵に署名され、issuer が UTF8String によってエンコードされた CRL UTF8 証明書 subject が UTF8String によってエンコードされた証明書。署名する CA や issuer のエンコード方式についてはここでは定めない。 2.2 移行手段の決定 移行にあたっては、その時期と可能性について検討した上で、移行の手段を決 定する必要がある。 移行時期とは、前述のように CA 証明書の更新または再発行を移行期限前(Z1) に行うか、移行期限後(Z2)に行うか、である。ここでは移行期限 X が設定される ことを考慮して移行期限前・後と表記するが、移行期限 X が設定されない限り、 移行時期は Z1 のみと考えてよい。 移行可能性は、Part1 において UTF8String 環境における比較要件として挙げ てきたコードポイント比較にアプリケーションが対応したかどうかである。 移行の手段とは、CA 証明書を新たに UTF8String でエンコードされたものに切 り換える際に、CA の DN を保持したまま CA 証明書を更新するか、CA の DN を 保持せずに新たに CA 証明書を再発行するか、である。これは CA の発行する証明 書を利用するアプリケーションがコードポイント比較に対応しているかどうか、 に依存するものであることを既に Part1 で述べた。従って、アプリケーションが 既にコードポイント比較に対応していれば更新を、未対応であれば再発行をする ことになる。 以上のことから、移行を検討する CA においては、 • いつ CA 証明書の更新・再発行をやるつもりか? -3- • その時アプリケーションのコードポイント比較の対応状況はどうか? を明確にすることで、移行手段を決めることができる。 表 2-2 移行時期・移行手段とアプリの対応状況 実装状況 コードポイント比較 コードポイント比較 移行時期 対応済 未対応 移行期限以前 ①CA 証明書の更新(Z1) ②CA 証明書の再発行(Z1) ③CA 証明書の更新(Z2) ④CA 証明書の再発行(Z2) 移行期限以後かつ 旧 CA 証明書の 有効期限以前 そこで本ガイドでは、これら 4 種類の手順について、解説をする。 ① 移行期限前に CA 証明書を更新(Z1) ② 移行期限前に CA 証明書を再発行(Z1) ③ 移行期限後かつ旧 CA 証明書の有効期限までに CA 証明書を更新(Z2) ④ 移行期限後かつ旧 CA 証明書の有効期限までに CA 証明書を再発行(Z2) 標準への準拠性、CA としての一意性の確保などを考慮すると①が最も好ましい が、3280bis で移行期限 X が設定されたり、あるいは CA が実際に移行を実施した りする時期が早ければ、アプリケーションベンダにとっては早急に対応する必要 がある。しかしアプリケーションベンダとしてもいずれコードポイント比較には 対応する必要がある以上、移行時期に十分な猶予があれば①を実施することが望 ましく、CA は移行時期について十分アプリケーションベンダと調整した上で、移 行手段を決定すべきである。 加えて CA 証明書は、一般的に 5∼20 年といった長い有効期間を持つ証明書と して発行される。CA 鍵ペアについても同様で、多くの CA は特定の鍵ペアを長期 間使い続けている状態にある。公開鍵証明書は、その性質上、公開鍵が公開され た時刻からの時間の経過に伴って安全性が低下するため、CA 鍵ペアはなるべく新 しく生成されたものを利用することが望ましい。鍵ペアの更新に伴って発生する CA 証明書の更新は運用コストへの影響が大きく、CA にとってなかなか実施しづ らいものであるが、今回のように CA 証明書の切り換えが不可避な状態においては、 むしろ積極的に CA 鍵ペアを更新することが望ましい。 そこで本移行ガイドでは、CA 証明書の移行とともに CA の鍵ペアも更新するこ とを推奨し、これを前提とした移行手順の説明を行うものとする。 -4- 3 移行手順の解説 3.1 移行期限前に移行するケース 今後 3280bis において移行期限 X が定められた場合、一部の CA は移行期限 X 以前に何らかの形で CA 証明書を UTF8String に対応したもの(新 CA 証明書)に更 新または再発行することを望むかも知れない。 また、3280bis において移行期限 X が定められない限り、CA は移行期限 X に関 係なく、いずれその CA 証明書を有効期限までに UTF8String に対応した新 CA 証明書へ更新または再発行する必要が生じる。 本節では、3280bis において • • 移行期限 X が定められた場合に、移行期限 X より以前に新 CA 証明書 へ更新または再発行する CA 移行期限 X を定めない場合に、 (新 CA 証明書へ更新または再発行する) 全ての CA を対象として、移行手順の解説を行う。 3.1.1 移行期限前に CA 証明書を更新するケース (a) コードポイント比較の対応時期 移行期限前に CA 証明書を更新するためには、アプリケーションが少なく とも更新期日までにコードポイント比較に対応していなければならない。CA は、アプリケーションのコードポイント比較に対する対応状況を把握した上 で、更新時期を検討するべきである。 (b) CA 証明書更新の要件 CA は自身の CA 証明書を更新するにあたって、以下の要件を満たす必要が ある。 • • 同一 subject の DN が同一でエンコード方式のみを UTF8String に置 き換えた新 CA 証明書を発行する。この新 CA 証明書に用いる鍵ペア は、既存の旧 CA 鍵ペアとは異なり、新 CA 証明書のために新たに生 成したものでなければならない。 新 CA 証明書発行後、新 CA 鍵ペアを用いて新 CRL を発行し、旧 CRL と同じ配布方法にて配布を行う。このとき失効リストに記載される失 効情報は、新 CA 証明書が発行した証明書のものだけでなく、旧 CA 証明書が発行した証明書に関する失効情報も含まれていなければなら -5- • • • • ない。なお、X.509 の一般的な CRL の考え方にもとづき、有効期限の 切れた証明書に関する失効情報は含めなくともよい。 CA が自己署名証明書の場合には、新 CA と旧 CA のどちらをトラス トポイントにしても検証できるように、新 CA 証明書と旧 CA 証明書 の間で自己発行証明書を発行すべきである。CA が下位 CA の場合に は、新 CA と旧 CA いずれも同じトラストポイントから証明書チェー ンを辿れるよう、新 CA 証明書を発行する上位 CA を選ぶべきである。 新 CA 証明書発行後は、旧式証明書を発行してはならない。 新 CA 証明書発行後は、旧 CRL を発行すべきではない。 新 CA 証明書発行以後に発行する EE 証明書は、新 CA 鍵に署名され た UTF8 証明書でなければならない。 同じDN 異なる鍵ペア 旧CA 旧RPの トラストポイント cn=same CA 旧来エンコード 新CA 自己発行証明書の 発行 Issuer: 旧来エンコード Subject: UTF8String 新RPの トラストポイント cn=same CA UTF8String Issuer: UTF8String Subject: 旧来エンコード 旧CAの リライングパーティ 新CAの リライングパーティ 図 3-1 トラストポイントとなる CA 証明書の更新 旧RPの トラストポイント 旧CAの リライングパーティ 共通の トラストポイント 新RPの トラストポイント 新CAの リライングパーティ 同じDN 異なる鍵ペア 旧CA 新CA cn=same CA 旧来エンコード cn=same CA UTF8String 図 3-2 トラストポイントを上位に持つ CA 証明書の更新 -6- (c) 失効検証に関する注意点 CA 証明書を更新した場合、更新直前に発行した旧式証明書についてはその 後もしばらく有効な期間が存在する。一方、本来旧式証明書の失効検証に必 要な旧 CRL は、置換攻撃を防ぐために発行を停止し、新 CA 鍵による新 CRL のみが発行されている状態となる。従って、新 CRL を用いて旧式証明書の失 効検証ができなければならない。 このために新 CRL では、旧 CRL に記載されていた失効情報を継承する必 要があり、一方でアプリケーションは旧式証明書の issuer と新 CRL の issuer が異なるエンコード方式であるにも関わらず、失効検証に利用できるようコ ードポイント比較に対応している必要がある。 新CA証明書の 更新 Z1 移行期限 X 旧CA証明書の 有効期限 Y 旧CA証明書の有効期間 新CA証明書の有効期間 UTF8証明書の発行期間 旧EE証明書の 発行終了 コードポイント比較 必須期間 旧EE証明書の有効期間 旧EE証明書の発行可能期間 更新後は 新CRLを参照 新CAが発行する UTF8証明書の有効期間 旧CRLを参照 新CRLを参照 旧CRLの発行期間 新CRLの発行期間 失効情報を継承 図 3-3 移行期限前に CA 証明書を更新 3.1.2 移行期限前に CA 証明書を再発行するケース (a) CA 証明書再発行の要件 CA は新たに CA 証明書を再発行するにあたって、以下の要件を満たす必要 がある。 -7- • • • • • 旧 CA とは異なる DN を UTF8String でエンコードした新 CA 証明書 を発行する。この新 CA 証明書に用いる鍵ペアは、既存の旧 CA 鍵ペ アとは異なり、新 CA 証明書のために新たに生成したものでなければ ならない。CA が下位 CA の場合には、新 CA と旧 CA いずれも同じト ラストポイントから証明書チェーンを辿れるよう、新 CA 証明書を発 行する上位 CA を選ぶべきである。CA が自己署名証明書の場合には、 新 CA と旧 CA との間でトラストポイントの移行をスムーズに促すた めに、新 CA 証明書と旧 CA 証明書の間で相互認証証明書を発行すべ きである。 新 CA 証明書発行後、新 CA 鍵ペアを用いて新 CRL を発行する。この とき失効リストに記載される失効情報は、新 CA 証明書が発行した証 明書に関する失効情報だけである。 新 CA 証明書発行後も、旧 CA 鍵を用いて旧 CRL を発行しなければな らない。旧 CRL の発行は、最後の旧式証明書の有効期間が満了する まで(たとえ移行期限 X を超過しても)継続しなければならない。 新 CA 証明書発行後は、旧式証明書を発行すべきではない。 新 CA 証明書発行以後に発行する EE 証明書は、新 CA 鍵に署名され た UTF8 証明書でなければならない。 異なるDN 同じDN 異なる鍵ペア 旧CA 旧RPの トラストポイント cn=old CA 旧来エンコード 新CA 相互認証証明書 の発行 cn=new CA UTF8String 旧CAの リライングパーティ 新RPの トラストポイント 新CAの リライングパーティ 図 3-4 自己署名 CA 証明書の再発行 -8- 旧RPの トラストポイント 旧CAの リライングパーティ 共通の トラストポイント 新RPの トラストポイント 新CAの リライングパーティ 異なるDN 同じDN 異なる鍵ペア 旧CA 新CA cn=old CA 旧来エンコード cn=new CA UTF8String 図 3-5 トラストポイントを上位に持つ CA 証明書の再発行 (b) 失効検証に関する注意点 CA 証明書を再発行した場合、再発行直前に発行した旧式証明書については その後もしばらく有効な期間が存在する。このため旧式証明書の失効検証に 必要な旧 CRL は、CA 証明書再発行後も継続して発行されなければならない。 新 CA と旧 CA では DN が異なるため、失効情報もそれぞれ個別に取り扱 わなければならない。従って、新 CA から発行された証明書の失効検証のた めには新 CRL が、旧 CA から発行された証明書の失効検証のためには旧 CRL が必要である。これはコードポイント比較に対応していないアプリケーショ ンに対して、証明書の issuer と CRL の issuer を同一のエンコード方式に保 持するための要件である。従って、アプリケーションがコードポイント比較 に対応できてない限りは、仮に移行期限 X 以後であっても、旧 CRL は旧 CA 鍵によって署名され、その issuer は旧来のエンコード方式によってエンコー ドされているべきである。 -9- 新CA証明書の 再発行 Z1 旧CA証明書の 有効期限 Y 移行期限 X 旧CA証明書の有効期間 新CA証明書の有効期間 UTF8証明書の発行期間 旧EE証明書の 発行終了 旧EE証明書の発行可能期間 再発行後も 旧CRLを参照 旧EE証明書の有効期間 旧EE証明書の 有効期間満了まで 旧CRL発行 新CAが発行する UTF8証明書の有効期間 旧CRLを参照 旧CRLの発行期間 新CRLの発行期間 新CRLを参照 図 3-6 移行期限前に CA 証明書を再発行 3.2 移行期限後に移行するケース 3280bis において特に移行期限 X を定めない限り、移行する全ての CA は 3.1 節 のいずれかの手段で新 CA 証明書への更新または再発行を行うことになる。しかし 今後 3280bis が何らかの形で移行期限 X を定めた場合、一部の CA では CA 証明 書の更新または再発行を移行期限 X 以後に実施することを望むかも知れない。 例えば当該 CA の発行する証明書を利用するアプリケーションが移行期限 X の 時点でコードポイント比較に対応していなければ、CA 証明書の更新を移行期限 X 以後に実施することは賢明な判断である。 本節では、このような場合に、CA が移行期限 X および CA 証明書の更新または 再発行時においてそれぞれ実施すべき手順について解説する。 3.2.1 移行期限後に CA 証明書を更新するケース (a) 移行期限 X における要件 移行期限 X において、CA は以下の要件を満たす必要がある。 • 移行期限 X 以後、旧式証明書を発行してはならない。 - 10 - • 移行期限 X 以後 CA 証明書を更新するまでの間に発行する EE 証明書 は、旧 CA 鍵から署名された UTF8 証明書として発行されなければな らない。 • 移行期限 X 以後 CA 証明書を更新するまでの間に発行する旧 CRL は 旧 CA 鍵によって署名され、その issuer は旧来エンコード方式によっ てエンコードされなければならない。 移行期限 X においてアプリケーションがコードポイント比較に対応できて ない場合は、仮に移行期限 X 以後であっても、旧 CRL は旧 CA 鍵によって署 名され、その issuer は旧来のエンコード方式によってエンコードされている べきである。 (b) CA 証明書更新の要件 CA は移行期限後、更新期日 Z2 において自身の CA 証明書を更新するにあ たって、以下の要件を満たす必要がある。 • 同一 DN でエンコード方式のみを UTF8String に置き換えた新 CA 証 明書を発行する。この新 CA 証明書に用いる鍵ペアは、既存の旧 CA 鍵ペアとは異なり、新 CA 証明書のために新たに生成したものでなけ ればならない。CA が自己署名証明書の場合には、新 CA と旧 CA の どちらをトラストポイントにしても検証できるように、新 CA 証明書 と旧 CA 証明書の間で自己発行証明書を発行すべきである。CA が下 位 CA の場合には、新 CA と旧 CA いずれも同じトラストポイントか ら証明書チェーンを辿れるよう、新 CA 証明書を発行する上位 CA を • • • • 選ぶべきである。 新 CA 証明書発行後、新 CA 鍵ペアを用いて新 CRL を発行し、旧 CRL と同じ配布方法にて配布を行う。このとき失効リストに記載される失 効情報は、新 CA 証明書が発行した証明書のものだけでなく、旧 CA 証明書が発行した証明書に関する失効情報も含まれていなければなら ない。なお、X.509 の一般的な CRL の考え方にもとづき、有効期限の 切れた証明書に関する失効情報は含めなくともよい。 新 CA 証明書発行後は、旧 CA 鍵による UTF8 証明書を発行してはな らない。 新 CA 証明書発行後は、旧 CRL を発行すべきではない。 新 CA 証明書発行以後に発行する証明書は、新 CA 鍵に署名された UTF8 証明書でなければならない。 (c) 失効検証に関する注意点 CA 証明書を更新した場合、更新直前に発行した旧式証明書についてはその 後もしばらく有効な期間が存在する。一方、本来旧式証明書の失効検証に必 - 11 - 要な旧 CRL は、置換攻撃を防ぐために発行を停止し、新 CA 鍵による新 CRL のみが発行されている状態となる。従って、新 CRL を用いて旧式証明書の失 効検証ができなければならない。 このために新 CRL では、旧 CRL に記載されていた失効情報を継承する必 要があり、一方でアプリケーションは旧式証明書の issuer と新 CRL の issuer が異なるエンコード方式であるにも関わらず、失効検証に利用できるようコ ードポイント比較に対応している必要がある。 新CA証明書の 更新 Z2 移行期限 X 旧CA証明書の 有効期限 Y 旧CA証明書の有効期間 新CA証明書の有効期間 旧EE証明書の 発行終了 旧EE証明書の発行可能期間 UTF8証明書の発行期間 旧EE証明書の 有効期間 コードポイント比較 必須期間 旧CAが発行する UTF8証明書の 発行可能期間 旧CRLを参照 新CAが発行する UTF8証明書の 有効期間 旧CRLを参照 旧CRLの発行期間 更新後は 新CRLを参照 UTF8証明書の 有効期間 新CRLを参照 新CRLの発行期間 失効情報を継承 図 3-7 移行期限後に CA 証明書を更新 3.2.2 移行期限後に CA 証明書を再発行するケース (a) 移行期限 X における要件 移行期限 X において、CA は以下の要件を満たす必要がある。 • • • 移行期限 X 以後、旧式証明書を発行してはならない。 移行期限 X 以後 CA 証明書を再発行するまでの間に発行する証明書は、 旧 CA 鍵から署名された UTF8 証明書として発行されなければならな い。 移行期限 X 以後であっても、旧 CA が発行した最後の証明書の有効期 間が満了するまでは旧 CRL の発行を継続しなければならない。 - 12 - (b) CA 証明書再発行の要件 CA は新たに CA 証明書を再発行するにあたって、以下の要件を満たす必要 がある。 • 旧 CA とは異なる DN を UTF8String でエンコードした新 CA 証明書 を発行する。この新 CA 証明書に用いる鍵ペアは、既存の旧 CA 鍵ペ アとは異なり、新 CA 証明書のために新たに生成したものでなければ ならない。CA が自己署名証明書の場合には、新 CA と旧 CA の関係 を示すために、新 CA 証明書と旧 CA 証明書の間で相互認証証明書を 発行すべきである。CA が下位 CA の場合には、新 CA と旧 CA いずれ も同じトラストポイントから証明書チェーンを辿れるよう、新 CA 証 明書を発行する上位 CA を選ぶべきである。 • 新 CA 証明書発行後、新 CA 鍵ペアを用いて新 CRL を発行する。この とき失効リストに記載される失効情報は、新 CA 証明書が発行した証 明書に関する失効情報だけである。 • 新 CA 証明書発行後も、旧 CA 鍵を用いて旧 CRL を発行しなければな らない。旧 CRL の発行は、旧 CA が発行した最後の UTF8 証明書の 有効期間が満了するまで継続しなければならない。 • 新 CA 証明書発行後は、旧式証明書を発行してはならない。 • 新 CA 証明書発行以後に発行する EE 証明書は、新 CA 鍵に署名され た UTF8 証明書でなければならない。 (c) 失効検証に関する注意点 CA 証明書を再発行した場合、再発行直前に旧 CA が発行した UTF8 証明 書についてはその後もしばらく有効な期間が存在する。このため旧 CA が発 行した UTF8 証明書の失効検証に必要な旧 CRL は、CA 証明書再発行後も継 続して発行されなければならない。 新 CA と旧 CA では DN が異なるため、失効情報もそれぞれ個別に取り扱 わなければならない。従って、新 CA から発行された証明書の失効検証のた めには新 CRL が、旧 CA から発行された証明書の失効検証のためには旧 CRL が必要である。これはコードポイント比較に対応していないアプリケーショ ンに対して、証明書の issuer と CRL の issuer を同一のエンコード方式に保 持するための要件である。従って、アプリケーションがコードポイント比較 に対応できてない限りは、仮に移行期限 X 以後であっても、旧 CRL は旧 CA 鍵によって署名され、その issuer は旧来のエンコード方式によってエンコー ドされているべきである。 - 13 - 新CA証明書の 更新 Z2 移行期限 X 旧CA証明書の 有効期限 Y 旧CA証明書の有効期間 新CA証明書の有効期間 旧EE証明書の 発行終了 旧EE証明書の発行可能期間 UTF8証明書の発行期間 旧EE証明書の 有効期間 旧CAが発行する UTF8証明書の 発行可能期間 再発行後も 旧CRLを参照 UTF8証明書の 有効期間 新CAが発行する UTF8証明書の 有効期間 旧CRLを参照 旧CAが発行する UTF8証明書の 有効期間満了まで 旧CRL発行 旧CRLの発行期間 旧CRLを参照 新CRLの発行期間 新CRLを参照 図 3-8 移行期限後に CA 証明書を再発行 4 まとめ 本移行ガイドでは、アプリケーションのコードポイント比較への対応状況、 IETF/PKIX WG が定めると思われる移行期限をポイントとして、移行の手順を解 説してきた。アプリケーションがコードポイント比較に対応していれば、CA は従 来の DN を保持したまま CA 証明書の更新が可能だが、アプリケーションがコー ドポイント比較に対応できないと、CA はアプリケーション相互運用性のために新 たな DN を持つ CA 証明書を発行する必要があるだろう。 しかし Part1 で述べてきた通り、コードポイント比較は UTF8String 問題だけ に必要な実装ではなく、今後様々な PKI が相互接続していく中で、他の PKI で用 いられてきた異なるエンコード方式を正しく解釈していくためには不可欠なもの である。現時点で公開されている 3280bis では移行期限に関する記述が削除され ているため、一見コードポイント比較が必要なくなるように思われるかも知れな いが、3280bis では逆に UTF8String と PrintableString の混在を明確に許可する ことが記述されたため、むしろ異なるエンコード方式が混在する状況は今後確実 - 14 - にやって来る。このことは、アプリケーションベンダにとってはコードポイント 比較への対応が不可避な事態となった一方で、CA にとっては移行期限の制約が外 されたので、より移行計画を立てやすくなったと言ってよいだろう。 拙速な移行は本来信用されるはずの証明書が信用されなくなるなど、CA の信用 性にも関わるものであるため、アプリケーションの対応状況を十分に把握した上 で移行計画を立てて実施すべきである。 参考文献 [1] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 3280, April 2002 [2] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, W. Ford, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", <draft-ietf-pkix-rfc3280bis-00.txt>, work in progress, 2005 - 15 -