ニュースレターNo.38/2008年3月発行
セキュリティ関連WG報告
第70回IETFでは、セキュリティエリアのWGセッションが14コマ開かれました。一方、セキュリティエリアに属するBoF※1は開かれませんでした。今回はPKIに関連したTLS WGやSIDR WGなどが週の前半に集まっていたため、これらのWGに共通して参加する者にとっては、特に前半が慌ただしいIETFミーティングとなりました。
本稿では、主にPKI（Public-Key Infrastructure）とリソース証明書に関わるWGについて報告いたします。
PKIX WG（Public-Key Infrastructure（X.509））
PKIX WGは、インターネットにおける利用を前提とした、電子証明書に関わるプロトコルの策定に取り組んでいるWGです。今回のミーティングも議論が予定以上に延び、1件のアジェンダを取り消すことになりました。ミーティングは、2日目の2007年12月3日（月）午後に2時間程度行われました。参加者は50名程でした。
PKIX WGにおける主なプロトコルの策定状況（ドキュメントステータス）を以下に示します。
- ○ RFC化が認められたもの
- - SCVP（Server-based Certificate Validation Protocol）
http://tools.ietf.org/id/draft-ietf-pkix-scvp-33.txt
証明書検証の処理をサーバに任せるプロトコルであるSCVP（Server-based Certificate Validation Protocol）は、RFC化が認められ、文書校正を行うRFC editorによる作業待ちの状態になりました。
SCVPは、PKIを利用するアプリケーションの普及を目的として、複雑な証明書検証の処理を、アプリケーションからSCVPサーバと呼ばれるサーバに任せる方法を定めたプロトコルです。OCSP（Online Certificate Status Protocol）と異なり、アプリケーションはSCVPサーバを「信頼」して処理を任せます。
- ○ IESGのレビューを受けているもの
- - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile
http://tools.ietf.org/id/draft-ietf-pkix-rfc3280bis-09.txt
証明書とCRLのプロファイルを定めたRFC3280の後継にあたるドキュメントです。このドキュメントのRFC化が認められると、前身であるRFC3280、CRLの拡張を定めたRFC4325およびRFC4630がobsolete（廃止の状態）となります。
この他に、CMCに関連する三つのドキュメント※2がレビュー中の状態です。証明書とCRLで楕円暗号を扱うための識別子を定めたdraft-ietf-pkix-ecc-pkalgs-03.txtは、有効期限が切れてしまいました。
WGドキュメントに関しては、Subject public key info resolution for ECCのデザインチームの報告と、OCSP Algorithm Agilityの方式提案という、二つの報告が行われました。ECCに関するデザインチームの報告は、証明書でECCを扱う方式についてRFC4055の方式とX9.63の方式とを比較検討した結果、RFC4055の方式にするという内容でした。OCSPのAlgorithm Agilityは、現在はSHA-1しか扱えないOCSPで、他の一方向性ハッシュアルゴリズムを扱うための方式に関する議論です。こちらも二つの選択肢について説明が行われましたが、議論はMLで行われることになりました。
PKIX WGミーティングの後半は、新しいworking itemとITU-Tからの要請に関する議論でした。ここでいうworking itemとは、WGとして取り組むトピックのことを意味しています。
以下の三つについて、新しいworking itemとして採用するかどうかの議論が行われました。当初アジェンダに入っていたCredential selection※3については、時間が取れないためにキャンセルされました。
- - Trust Anchor Management Protocol（TAMP）
- 前回のIETFでBoFとして開かれた、トラストアンカーに関するプロトコルです。MLにてWGのworking itemとして採用するかどうかの議論が行われることになりました。2008年1月現在、TAMPはPKIX WGのworking itemになっており、議論が進められています。
- - Updating ASN.1 modules to 1998 syntax
- 多くのRFCで使われているASN.1モジュールは、1988年版ASN.1に則って記述されています。これを新版の書式に変えていくことについての提案です。TAMPと同様に、2008年1月現在、WGのwokring itemとなっています。
- - Resource Discovery Protocol
- サービス（httpでの接続先など）に必要な証明書を探すプロトコルです。Internet-Draftがまだないことから、MLで議論を進めた後に、提案者が叩き台を出すこととなりました。
ITU-Tからの要請は、DNに含まれるstreetAddressに関する文字列の上限を設けないことに関する検討と、トラストアンカーとなるCAの、名称が重複しないようにする仕組みがあるか、といった確認でした。PKIX WGとしては、前者については証明書を扱うプログラムへの影響を踏まえて、プロトコルの変更に関してはアクションを取らないことを返答することとなりました。また後者については既存の仕組みはなく、PKIX WGとしては、CAの名称が重複しないようなメカニズムを設けることは難しい、という返答がされる模様です。
SIDR WG（Secure Inter-Domain Routing WG）
SIDR WGは2日目の2007年12月3日（月）の午後から、PKIX WGに引き続き行われました。
SIDR WGでは、既存のドラフトドキュメントの更新に関する議論が三つ、新しいトピックに関する議論が二つありました。
既存のドラフトドキュメント更新に関する議論については、以下のものがありました。
- - CP/CPS update
- 特に内容がupdateされたわけではありませんが、インターネットレジストリなど、関係する組織の人はコメントをするように要請がありました。NIRであるJPNICとしてもコメントを求められている様子です。
- - Architecture と Route Originations
- リソース証明書のツリーにおいて末端に位置づけられる、ROA（Route Origination Authorizations）に関する議論です。
- 今回はプライベートアドレスを含むROAの扱いについて議論されました。プライベートアドレスについて、IANAをトラストアンカーとするリソース証明書を発行する必要がないのではないか、各機器がトラストアンカーを定められるような証明書ツリーを構築できるようにすべきでは、という議論です。結局、IANAをトラストアンカーにしなくてもよいが、ドキュメントではIANAについて言及することになりました。
- - 複数の証明書パスでの単一prefix処理
- 経路広告されるprefixとROAに含まれるprefixが異なる場合に、ルータはどのように処理すべきか、という議論です。例えば、複数のprefixについて経路集約を行う場合、インターネットレジストリの構造に合わせて発行されたリソース証明書とprefixが一致しないことが考えられます。正しく発行されたリソース証明書が実際の正しい経路広告をうまく扱えなければなりません。
- 会場ではさらに、複数のインターネットレジストリ、例えば歴史的PIアドレスの経路集約をどう扱うかといった議論になりました。今後、方式に関する選択肢の提示を含め、提案内容を固めてから議論が進められることになりました。
- - リソース証明書に含まれるprefixの処理
- 現行のリソース証明書に関する仕様では、上位CAが階層ごとにIPアドレスとAS番号を内包していく構造になっている必要があります。したがって、リソース証明書を検証する段階で、両方の包含関係が必ず両立する必要があります。
- この仕様を緩め、より上位（すなわち上位の上位など）のCAのリソース証明書が、リソースを包含していればよいことにする提案が、APNICのGeoff Huston氏によって行われました。
- 会場ではパス検証の結果が、ツリーの上から行う場合と下から行う場合とで変わってしまうのは良くない、などの議論が行われましたが、結論は出ず、MLで継続議論される模様です。
- 新しいトピックとしては、以下の二つがありました。各々について、WGのworking itemとして採用するかどうかの問いかけが、WGチェアから行われましたが、いずれもMLで意見収集を行うことになりました。
- - Manifests
- http://www.potaroo.net/drafts/draft-ietf-sidr-rpki-manifests-00.txt
- Manifestとは、リポジトリに入っているオブジェクト一覧に署名をしたもので、CRLより早く、証明書検証者に対してオブジェクトの削除を知らせることを目的としたデータです。
- 会場では、証明書検証に関わるWarning（警告）すべき状態が増えすぎないか、リソース証明書の数は多いためにCRLを含めて、利用可能性について検証する必要がある、といった意見が出されました。WGのworking itemとするかどうかについては、2007年12月24日までにMLで意見収集を行い、決定していくことになりました。
- - Rescerts Provisioning
- http://www.potaroo.net/drafts/draft-ietf-sidr-rescerts-provisioning-00.txt
- リソース証明書を発行するインターネットレジストリと証明書申請者の間で、証明書管理（発行や失効など）のために使われるプロトコルの提案です。これについては、会場での意見は少なく、WGのworking itemとなりました。
- SIDR WGでは、リソース証明書のルータにおける仕様に関して、これまでにあまり多くの議論がなされてきませんでした。今回は、経路集約を踏まえたルータの挙動について議論されており、徐々にではありますが、実用化に向けた動きが見えてきました。しかし、Manifestなどの、新しい処理を要するプロトコルが追加され、リソース証明書を扱うプログラムの全体像に辿り着くには、まだ時間がかかりそうです。
IETFの前日に行われる、IEPG（Internet Engineering and Planning Group）のミーティングで、当センターが実験的に開発した「経路情報の登録認可機構」について、プレゼンテーションを行いました。リソース証明書に関連する議論がありましたので、この場を借りて行われた議論などについて報告いたします。
「経路情報の登録認可機構」は、IRRに登録されるオブジェクトの正当性について、維持と向上を図るシステムです。本機構は、経済産業省からJPNICが受託している受託事業の一環として、2005年度から設計・開発が行われたものです。具体的には、IPアドレス管理指定事業者などの、IPアドレスの割り振り先組織が、IRRにrouteオブジェクトを登録できるメンテナー名を指定し、その指定に則っていないオブジェクトはIRRに登録できないようにする仕組みです。IPアドレスの割り振り先が、経路広告を行う元を指定するという点で、リソース証明書のROAの仕組みに似ていますが、ネットワークオペレーターが運用状況に合わせてprefixやOrigin ASを自由に選択できたり、Webインタフェースで簡単に登録できたりするなど、運用上の自由度を上げています。
プレゼンテーションの結果、APNIC、RIPE NCC、ISCの方などから、encourageする旨のコメントをいただきました。また、リソース証明書との親和性があるかどうか、本機構が扱うデータベースと、IRRに登録されたオブジェクトを同期させる必要性等について、議論を行うことができました。
RIRやIETFにおけるアクティブメンバーと議論する意味で、事前には緊張しましたが、IEPGらしく、IPアドレスの管理とインターネットルーティングに関わる技術者の、両方の立場に立脚した意見交換ができました。
今後、実験運用の結果をコミュニティにフィードバックするなどの活動を通じて、技術と運用が陸続きになるような活動ができればと感じました。
（JPNIC 技術部 木村泰司）
- ※1 IETFにおけるBoF
- Birds of a Featherの略で、WGを作る前にその趣意や、議論を進める意欲のある方が十分に集まる見込みがあること等を確認することを目的としたミーティングのことです。
- ※2 CMCに関連する三つのドキュメント
-
- Certificate Management Messages over CMS
http://tools.ietf.org/id/draft-ietf-pkix-2797-bis-06.txt
CMS（Cryptographic Message Syntax - RFC3852）の書式を使った、 証明書の管理（発行や失効など）手続きに使われるメッセージを定めたドキュメントです。 -
- Certificate Management over CMS （CMC）: Transport Protocols
http://tools.ietf.org/id/draft-ietf-pkix-cmc-trans-07.txt
CMCのメッセージを伝送するトランスポート（伝送路）を指定したドキュメントです。 ファイルの形式やメールメッセージにおける添付の仕方、 HTTPに則った方式などを定めています。 -
- Certificate Management Messages over CMS （CMC）: Compliance Requirements
http://tools.ietf.org/id/draft-ietf-pkix-cmc-compl-05.txt
主に登録局と発行局の間で行われる、 証明書発行手続きのenrollment処理において、 これらのプログラムがCMCのメッセージを使うための要件を集めたものです。 - ※3 Credential Selection Criteria Data Structure
-
http://www.ietf.org/internet-drafts/draft-santesson-credsel-01.txt
認証情報であるクレデンシャルを選択できるようにするための、 汎用的なデータ構造を提案したドキュメントです。 TLS等で使われているセキュリティプロトコルに対して、 汎用の認証情報を定義することが目指されています。
