ニュースレターNo.37/2007年11月発行

セキュリティ関連WG報告

第69回IETFでは、セキュリティエリアのセッションが18開かれました。そのうちの一つはBoFでした。本稿では、PKI（Public-Key Infrastructure）と、リソース証明書に関連するWG、並びにTAM（Trust Anchor Management） BoFについて、お送りいたします。

PKIX WG（Public-Key Infrastructure（X.509））

PKIX WGのミーティングは、5日目の2007年7月26日（木）に行われました。PKIX WGは、電子的な認証基盤の規格であるITU-TのX.509をインターネットに適用して、新たな規格作りを行っているWGです。アジェンダが多くなりがちなPKIX WGにしては1時間と短く、最後に行われたWebDAVを使ったデモは、unofficial PKIX WGという位置付けで、休憩時間を割いて行われました。

最初はドキュメント策定状況の確認です。メッセージの簡略化等を図ったLightweight OCSPと、subjectAltName拡張フィールドにホスト名やプロトコル名等を入れる仕様のService Name SANは、IESGよりRFC化の承認を得ました。現在、RFC Editorの処理待ちです。オンラインの証明書検証プロトコルであるSCVP（Server-based Certificate Validation Protocol）と、RFC3280の改良版（RFC3280bis）、それからCMC（Certificate Management over CMS）に関わる三つのドキュメント（下記）は、IESGのレビューを受けている最中です。

□ Certificate Management Messages over CMS

draft-ietf-pkix-2797-bis-04.txt

□ Certificate Management over CMS（CMC） Transport Protocols

draft-ietf-pkix-cmc-trans-05.txt

□ CMC Complience Document

draft-ietf-pkix-cmc-compl-03.txt

いよいよRFC3280bisがIESGのレビューに入りました。Certification PathBuilding（RFC4158）やAuthority Information Access Certificate Revocation List Extension（RFC4325）など、ドキュメントは別々になっていますが、各々のRFC化が済んでおり、証明書とCRL（Certificate Revocation List）の処理に関する基本的な仕様が、ある程度固まる時期が来つつあるのかも知れません。

SCEP（Simple Certificate Enrollment Protocol）については、会場で若干議論がありました。SCEPは、いくつもの商用のソフトウェア等で利用されている、証明書の申請等のメッセージをやり取りするためのプロトコルですが、これまではWGにおけるRFC化が積極的に進められていませんでした。これはCMCという機能的に似ていながら、異なるデザインのプロトコルがあったためだと考えられますが、SCEPを使ったプログラムが普及しつつあることはRFC化の大きな推進理由となります。結局Informational RFCを目指して進められることになりました。

今回の新たな話題として、PKI Disaster Recovery and Key Rolloverと、WebDAV for certificate publication and revocationの二つをご紹介します。これらはWG後半、Related Specificationsの時間に、プレゼンテーションが行われました。

PKI Disaster Recovery and Key Rolloverは、実は今回新しく提案されたものではなく、2001年の7月に一度作られたことのあるドキュメントです。その時のタイトルは、“PKI Disaster Planning and Recovery”だったそうです。今回Joel Kazin氏によって再編集されたこのドキュメントは、プライベート鍵の危殆化や喪失といった、例外的な状況から正常な運用に復旧する方法が書かれています。主にCPS（Certificate Practice Statement）を記述したり、PKIに関するディザスターリカバリープランを立てるために役立つ、Informational RFCにすることが目指されています。記述されているディザスターリカバリーの対象は、エンドエンティティ、認証局、Revocation Authority、Attribute Authority、タイムスタンプ局（Time-stamp Authority）です。プライベート鍵の危殆化や喪失の他には、CRLのリポジトリに対するDoS（Denial of Services）攻撃や、認証局のキーロールオーバー（鍵の更新）についても言及されています。

クイックに復旧するという言葉から想像されるような、特殊な手法が提案されているわけではありませんが、復旧手段が網羅的にまとめられています。認証局の運用や設計をされる方には、とても参考になるドキュメントになっていくと思われます。

□ PKI Disaster Recovery and Key Rollover

draft-pinkas-pkix-pki-dr-kr-00.txt

WebDAV for certificate publication and revocationは、証明書やCRLのリポジトリへのアクセスに、WebDAVを使う手法の提案です。リポジトリにアクセスするためのプロトコルにはLDAP（Lightweight Directory Access Protocol）がありますが、LDAPはファイアウォールで遮断されがちであったり、証明書やCRLの内容を使った、証明書データやCRLデータの検索ができなかったりします。この提案は、HTTPやURIのデザインに影響しているREST（Representational State Transfer）の考え方を取り入れ、WebDAVを使った証明書データやCRLデータの取得や格納、さらに発行や失効手続きとの関連する処理等について提案しています。

□ Representational State Transfer （REST）

「Architectural Styles and the Design of Network-based Software Architectures」の第5章
http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm
この手法を用いると、証明書やCRLのURLは以下のように示されます。
https://dns.name/c=jp/o=NIR%20in%20Japan/cn=Taiji%20Kimura/
サーバdns.nameにあるC=jp, O=NIR in Japan, CN=Taiji KimuraというCNが入った証明書データ
https://dns.name/c=jp/o=NIR%20in%20Japan/cn=CRLs/
サーバdns.nameにあるC=jp, O=NIR in JapanによるCRLの全て（シリアル番号が一つ一つ入った形のCRLが使われる）

会場では、リソース証明書にも適用できるように、名前を示す文字列として鍵のハッシュ値が扱えるようにして欲しい、といった意見交換が行われていました。

今回ご紹介した二つのドキュメントの他にも、PRDP（PKI Resource Discovery Protocol）などの新しい作業項目が加わりました。まだまだPKIX WGの活動は続きそうです。

SIDR WG（Secure Inter-Domain Routing WG）

SIDR WGは5日目の朝、9時から10時45分まで行われました。SIDR WGは、インターネットにおけるドメイン間（AS間）の経路制御を、セキュアに行う仕組みを検討しているWGです。今回のWGでは、主にドキュメントの更新に関する議論が行われました。

現在、SIDR WGで行われている議論は大きく分けて三つあります。一つ目は、RFC3779を使って、セキュアなルーティングを実現するアーキテクチャを、ドキュメント化するための議論です。二つ目は、リソース証明書を発行する認証局のCP（Certificate Policies）とCPSに関する議論で、Stephen Kent氏を中心に議論が進められています。三つ目は、ROA（Route Origination Authorization）の書式と取り扱いに関する議論です。

SIDRのアーキテクチャについては、継続して行われている議論がいくつもあります。まず、経路集約が可能な隣接するIPアドレスのリソース証明書を、どのように扱うかという議論があります。単一のISPに対して、レジストリが複数のIPアドレスブロックを割り当てている場合、ISPは集約（route aggregation）された経路を広告することが考えられます。しかし、リソース証明書は割り振りブロックを含んだ形で発行されるので、広告される経路情報とリソース証明書が一対一に対応しません。すると、集約されたプリフィックスの正しさを検証できないことになってしまいます。この件については会場ではあまり議論されず、MLで継続して議論が行われることになりました。他に「リソース証明書とCRLを示すURLで、rsyncをプロトコルとして使うことが提案されているが、書式上認められるのか」という議論も進行中で、今は作業を担当する人を探している段階です。WGのマイルストーンによると、アーキテクチャは2007年3月にはRFC化が目指される予定でしたが、大幅に遅れてしまっているようです。ちなみに、4バイトAS番号については既に対応済みです。

□ An Infrastructure to Support Secure Internet Routing

draft-ietf-sidr-arch-01.txt

CPとCPSについては、本ドキュメントの策定における、時間的な制約に関する議論が行われました。提案者であるStephen Kent氏によると、本ドキュメントは、リソース証明書を発行する認証局が構築され始める頃には必ず必要になりますが、Internet-Draftの有効期限は6ヶ月であり、この期限内で有意義な議論を進めることができるかという疑問が、Stephen Kent氏自身にもあるそうです。議論の結果、今後、ドキュメントの位置付けを明確化することが課題になりました。

ROAについては、ROAに含まれるprefixと、検証の対象であるBGP Updateに含まれる、NLRIとの比較ルールについて議論が行われました。前回のSIDR WGでは、ROAに内包されるprefixが、NLRIに含まれるのであればよい、という方向になっていましたが、前述の経路集約の問題があり、ROAとして比較ルールを定めることは難しいことがわかってきました。ひとまずROAのドキュメントでは比較ルールを記述しないことになりました。

□ A Profile for Route Origin Authorizations （ROAs）

draft-ietf-sidr-res-certs-08.txt

最後に、“Private AS space”というタイトルで、チェアのSandra Murphy氏よりプレゼンテーションがありました。これは、AS内のプライベートな経路制御のためにユニークローカルアドレス（RFC4193）を使う場合、リソース証明書をどこが発行すればよいのか、という疑問の投げかけです。これは、リソース証明書のトラストアンカー（trust anchor - 信頼点）として何を想定すべきか、という議論に発展しました。IANAをトラストアンカーとして想定すると、RIRへの追加割り振りがあった場合に、ユーザー環境のトラストアンカー証明書を入れ替える必要がなく、手続きは簡単です。また、本来、トラストアンカーはRP（Relying Party - 証明書検証者）によって選ばれることが望ましくもあります。しかし、現在のIANAが果たすとされている機能の中に、認証局が定義されておらず、RIRの認証局で対応せざるを得ないのが現状であるようです。

TAM BoF（Trust Anchor Management BoF）

電子証明書がVPNの機器等で使われるようになるにつれ、証明書検証で使われるトラストアンカーとなる認証局証明書を管理することの重要性は、一層増してきています。TAMは、Webブラウザや電子証明書の技術を使うVPN機器等にある、トラストアンカー証明書を格納する領域をモデル化して「トラストアンカーストア」と呼び、トラストアンカーの取り扱いが標準化されていない状況を改善する目的で開かれました。TAMは第69回IETFの最終日である7月27日（金）の午前に行われたにも関わらず、70名以上の参加者がありました。

はじめに、トラストアンカーに関する課題点をまとめたCarl Wallace氏から、課題点と解決策のあり方に関するプレゼンテーションが行われました。

目標

• トラストアンカーストアを管理するプロトコルを標準化する（トラストアンカー証明書の追加／削除／検索）
• out-of-bandの信頼メカニズムへの依存を減らす機能要件
• トランスポート（伝送路）との独立
• トラストアンカーをユーザーが意識しない、または意識させないデバイスなどをサポート

など

Carl Wallace氏がまとめたドキュメントを以下に示します。

□ Trust Anchor Management Problem Statement

draft-wallace-ta-mgmt-problem-statement-01

会場では、Webブラウザをこの議論に含めるべきかどうかについて、意見交換が行われました。また、リソース証明書における、この議論の重要性に関する指摘もありました。しかし、このBoFをWGにするかどうかは決まらず、MLを通じてこの議論の目的と意義を議論することになりました。その後、状況に応じて趣意書を作ることになりそうです。

IETFチェアにRuss Housley氏が、そしてセキュリティエリアのエリアディレクターにTim Polk氏が就任し、PKIX WGでお会いしていた方々が、IETF全体で活躍されるようになりました。また、IABチェアには、RIPEミーティングでいつもユーモラスなプレゼンテーションをされていた、Olaf Kolkman氏が就任されました。

私にはIETFが少し身近に感じられる一方、彼らが発言の度に慎重に言葉を選び、そしてミーティング中も忙しそうにされている様子が、少し気の毒に思えます。今の私には、体調を崩されないよう応援する以外にできることが少なそうです。

（JPNIC 技術部 木村泰司）