ニュースレターNo.39/2008年7月発行

セキュリティ関連WG報告

第71回IETFでは、セキュリティ関連のセッションが15行われました。本稿では、PKIXとNEA、TLS、S/MIMEの四つのWGについて報告します。

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

PKIX WGは、インターネットにおける利用を前提とした、電子証明書に関わるプロトコルの策定に取り組んでいるWGです。今回の会合では、初日（3月10日）の9:00～11:30に開催され、参加人数は60名ほどでした。

最初に、Chairの一人であるStefan Santesson氏（Microsoft社）より、WG活動の状況説明がありました。活動状況をまとめると以下の3点となります。

RFC3280bisのRFC化が認められた（2008年5月9日にRFC 5280として発行された）
CMCに関連する三つのI-DがIESGレビュー中
WGが担当する案件が五つとなった

続いて行われた発表の場では、五つのWGアイテムの他に、関連する活動として五つのトピックについて発表がありました。PKIX WGは、活動停止のフェイズに入っているはずなのですが、一向に終わりそうにありません。

［WG担当案件］

1. RFC3279bis/RFC4055bis （ECC（楕円暗号）に関するもの）

前回のIETF（2007年12月にバンクーバーで開催）で、ECCに関するアルゴリズムID/鍵パラメータの扱いが決まり^※1、その決定を受けてデザインチームがECCを用いた証明書の設計を行っています。その結果がRFC3279bis（アルゴリズムID）/RFC4055bis（鍵パラメータ）となります。本案件に関しては、現在のI-Dの状況が報告されました。

RFC3279bisは、多くの細かな修正が行われたとのことです。コメントとして、NISTのTim Polk氏より「NISTにおけるFIPS 180-3の制定が遅れており、RFC化を考えるとFIPS 180-2を参照するようにした方が良い」とのコメントがありました。

RFC4055bisに関しては、作業は順調に進んでおり、内容に関わる修正点は2ヶ所のみであり、残りの修正はつづり間違いの修正などであると報告がありました。

□RFC3279bis: "Elliptic Curve Cryptography Subject Public Key Information": http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-04.txt
□RFC4055bis: "Update for RSAES-OAEP Algorithm Parameters": http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc4055-update-00.txt

2. PKIX用の新ASN.1モジュール（New ASN.1 Modules for PKIX）

前回より新たにWGアイテムに加わったもので、現在旧版のASN.1（1988）文法に則って記述されているPKIX標準を、新版ASN.1（2002）へと変更するという提案です。提案者はPaul Hoffman氏（VPN Consortium）と、Jim Schaad氏（Soaring Hawk Consulting社）です。発表はSchaad氏が行いました（ほぼ同じ内容の発表がS/MIME WGでも行われました）。

提案の目的は、古いASN.1の表記でPKIXは定義されているため、手に入りやすいASN.1コンパイラ（ソースコードジェネレータ）が使えず、普及を阻害する要因の一つとなっている状況を解消したいということです。

この変更により、ソースコードの自動生成、コードの安全性確認の自動化、厳密性を上げたプロトコル設計が可能だとしています。また、この変更はあくまでプロトコルにおける表記上のものであり、実際にネットワーク上に流れるビットイメージ（Bits-on-the-wire）は変更しないため、従来の実装もそのまま利用できるとしています。

ただし、OpenSSL/Crypt APIのような暗号系のAPIを用いる場合、上に書いたような利点を得るためには実装の変更が必要であるとも報告されました。

PKIX関連の新版への変更作業に関しては、Hoffman氏とSchaad氏が行うということで、WGとしては再作業をせずに内容のレビューのみを行うこととなりました。

また、アクションアイテムとしてBits-on-the-wire互換性を検証するために、商用とオープンソースコンパイラの両方を使って、新ASN.1モジュールが扱えるかどうかをテストする必要があることが決まりました。

□New ASN.1 Modules for PKIX: http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-asn1-00.txt

3. Trust Anchor Management Requirements/Trust Anchor Architecture

TAM（Trust Anchor Management）は、第69回IETFミーティングでTAM BoFとして初めて開催されましたが、新規WGとせずPKI WGで扱うことが決まったため、PKIX WGの趣意書にTAMの活動が追加されました。まず、Carl Wallace氏（Orin）により、Trust Anchor Managementの要件に関する発表が行われました。

以前より提出されていたI-Dである"Trust Anchor Management Problem Statement"へのコメントに従い、管理対象や用語、TA（Trust Anchor）に関連したデータのスコープを広げる提案が行われ承認されました。

また、このドキュメントを要件ドキュメントへと変更するという合意により、要件のリストが抽出されています。

さらに、TrustAnchorInfoデータ構造と、ValidationPolicyとの比較が行われました。Wallace氏からは、両者には共通点が多くあるが、TrustAnchorInfoはTA管理の本質的なデータを含んでおり、TA管理用に必要とされるものを追加データとしてValidationPolicyのデータ構造に載せるという拡張により、複数TAのグループポリシーを可能にする利点が出るとの説明が行われました。それに対し会場からは、そういうことが起きうるのか、またValidationPolicyデータ構造を再利用する試みに十分な根拠があるかに関しては明らかでない、という意見が出ました。

続いて、同じくTAMの話としてStefan Santesson氏（Microsoft）が、TAMのアーキテクチャの一例として、ディレクトリサービスを用いた事例での考察を発表しました。

TA管理としていくつかのシステム（Windowsを含む）では、「既にディレクトリベースでのアプローチが取られている」という事例紹介が行われ、さらにディレクトリベースと要求/応答プロトコルベースの、二つのモデル間の要件には共通部分もあるが、いくつかの要件はディレクトリベースの環境では適用できないことがあり、現状の要件文書I-Dは要求/応答プロトコルベースの指向が強いと指摘しました。そこで、両者のモデルに共通することとして、Trust Anchor情報（公開鍵、名前、パラメータ）が必要であることと、それ以外のものに関しては、ディレクトリベースのソリューションに依存することが発表されました。

これらへの対応として、要件文書には両者のモデルがあることの明記と、プロトコルがどこで/なぜ必要かが書かれるべきだという意見が述べられました。また両モデルのTA情報フォーマットに関しては、別々の作業にした方が良いという提案も行われました。この提案は受け入れられ、ML上でさらに議論を進めることとなりました。

□Trust Anchor Management Problem Statement: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt

4. PKI Resource Query Protocol（PRQP）

Massimiliano Pala氏（Dartmouth大学）が発表を行いました。

PRQPは、PKIの利用に関わるさまざまなネットワーク上のリソースを問い合わせるためのプロトコルであり、2007年12月に、PKIX WGでExperimental RFCとするべく活動をすることに決まりました。

新しい機能として、従来のAIAに相当する機能が提案されました。この提案により、証明書の再発行をせずとも新しいAIA情報を伝播することが可能となります。既にOpenCAでは実装済みとのことです。

また、PKIX WGの範疇ではありませんが、PEACHと呼ばれるP2Pを用いたものの紹介も行われました。

□PKI Resource Query Protocol: http://www.ietf.org/internet-drafts/draft-pala-prqp-01.txt

［関連する案件］

全部で五つの報告がありましたが、この中でみなさんの興味があるであろう事例を取り上げます。

5. Wildcards in DNS Names

Stefan Santesson氏（Microsoft社）が発表を行いました。

Netscapeがきっかけを作ったワイルドカード証明書への対応ですが、IEをはじめとして利用できるプラットホームが増えるとともに、著名なCAサービス（認証局）がワイルドカード証明書を発行するようになっている状況の一方で、ワイルドカード証明書をPKIX標準としては認めていないという現状が報告されました。

このような状況を鑑み、Santesson氏は

Informational RFCを発行する
3280bis（がRFC化された後に修正し）でワイルドカードの存在を認める

のどちらかを行うべきだと提案しました。

この提案に関してさまざまな意見が出ました。主要なものは以下の通りです。

a. NISTのTim Polk氏: RFC 2818（HTTP Over TLS）ではワイルドカードを許可していること、しかもそれはWindowsが行っている方式とは異なっていることを指摘しました。
b. Phillip Hallam-Baker氏: ブラウザがワイルドカードを含んだ名前をどうやって解釈しているかを標準化する助けとなる、 Informational RFCの作成を提案しました。（これはSantesson氏の提案から派生したものです。）
c. 複数の発言から: TLSはさまざまな環境で利用されており、それらの環境はこの問題をそれぞれの文脈で示すように標準を書くことが可能だ、という意見が出ました。
d. PKIX WG ChairのSteve Kent氏（BBN社）: IDN（Internationalized Domain Name）のサポートに関連したあいまいさが残る段階では標準化することに疑問を感じるという意見が出され、 IPアドレス用のRFC3779（X.509 Extensions for IP Addresses and AS Identifiers）にあるアプローチに従うのが良い、との主張です。この議論に関しては、ML上などで継続されることになりました。

NEA WG

NEA（Network Endpoint Assessment）WGは、ネットワークに接続する種々のもの（Endpoint）の機能が充足しているか、機能不全になっていないか、ウイルスなどに犯されていないかといったことを調査、評価し、ネットワークへの接続を許可するプロトコルを策定するWGです。昨今は、内部統制や情報漏洩対策、ウイルスなどのマルウェアによる業務停止のリスクを避けるための手法として検疫ネットワークが導入される事例が増えていますが、検疫ネットワークをより自由度が高く、オープンな環境にしようとする試みの一つになります。

第67回IETFでBoFとして開催され、Security AreaのWGとして活動しています。Chairは、Steve Hanna氏（Juniper Networks社）とSusan Thomson氏（Cisco Systems社）の2人です。

今回の会合は2日目（3月11日）の9:00～11:30に行われ、参加人数は60名ほどでした。

現在WGで出している唯一のI-D（要求仕様）である"Network Endpoint Assessment（NEA）: Overview and Requirements"に関する状況報告として、IESGからのコメントがあり、第7版を作成中と報告がありました。本I-Dについては、MLにより議論を行う予定とのことです。またマイルストーンに関しては変更が無い旨が報告されました。

2時間半の時間のうち大半は、ChairであるSteve Hanna氏（Juniper Networks社/TCG TNC WG Chair）が、TCG（Trusted Computing Group）の提案しているTNC（Trusted Network Connect）をどうNEAに適応させるかを提案することで終わりました。

NEAの要求仕様I-Dでは、NEAを三つのレイヤで定義しています。

PA（Posture Attribute）
Endpointの種々の属性情報（OSのバージョン、サポートしているプロトコル、パッチの適応状態など）の表現形式を定める
PB（Posture Broker）
PAをEndpointと評価者（Evaluator/Validator）に対して交換する仕様を定める
PT（Posture Transport）
PA/PBの情報を送るためのトランスポートメカニズム

これらのレイヤごとにI-Dを作ることになります。

Hanna氏は、TCGでNEAと同様のことを決めているTNC WGのチェアとして、TNCを使った場合、どのようにNEAを適応すべきかをまとめて報告し、WG DraftとしてI-D化することを提案しました。

今回の発表では、主にPA/PBをどうTNCに適応するか（PA-TNC/PB-TNC）という部分と、PAに対するセキュリティをどうするか（PA-Security）の、三つの部分についてI-Dを書くことを提案していました。

PA-TNC/PB-TNCに関しては、PA/PBの各データ構造をTNCにどう当てはめるかを提案しており、ほぼ提案通りの方式でI-Dを書くことが合意されました。PA-Securityに関しては、Hanna氏はCMS（Cryptographic Message Syntax）を用いてデータ自身を暗号化・電子署名することを提案しましたが、CMSの処理が複雑であること、CMSが複数の暗号化・電子署名のレパートリーを持っておりネゴシエーションに手間がかかること、PTにおいてSSL/TLSの利用が暗黙の前提となっているため、PAにおいて暗号化・改竄検出を厳密に行うことが必要なのか疑問があるなどといった意見が出され、この提案に関しての合意は保留となりました。

□NEA WG: http://www.ietf.org/html.charters/nea-charter.html
□Network Endpoint Assessment（NEA）:Overview and Requirements: http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-06.txt

TLS WG

TLS WGは、TLS（Transport Layer Security）の標準化を行うWGです。ミーティングは、4日目（3月13日）の15:20～17:20に行われ、70人程度が参加しました。

まず、ドキュメントのステータスとして、TLS 1.2がRFC化されることが承認されたことなどが報告されました。

続いて、作業中のアイテムであるTLS拡張の定義について発表が行われました。議論の中心は、証明書が置かれているURLをハッシュ化する必要性についてであり、以下の二つの点で合意がされました。

ハッシュ利用を強制すること（Mandate）
必要ならば新しいコードポイントを定義してHash Agilityを確保すること

また、TLSで利用される暗号スイートについて、以下3件の発表がありました。

DES/IDEA
ESDHE PSK
Camellia

ESDHE PSK暗号スイートに関しては、I-Dの十分なレビューがまだされていないことを受けて、Joe Salowey氏とPaul Hoffman氏が今月中にコメントすることとなりました。

次に、DESとIDEAの暗号スイートに関する発表は、DESは強度上の問題があること、IDEAは利用がほとんどされていないことから、TLSのCipherリストから外す提案がされ、会場からは賛成の意見が多く聞かれました。

また、NTTソフトウェアの加藤氏よりCamelliaの暗号スイートについて発表がありました。

Cameliaの暗号スイートは、2005年にRFC4132としてRFC化され、OpenSSLやGnuTLS、Firefoxの次期バージョンなどで適用されるようになってきました。今回の発表では、既に定義されているスイート群に、SHA-256などを加える提案がされました。

写真:Pasi Eronen氏とEric Rescorla氏 — TLS WGのチェアであるPasi Eronen氏（左）とEric Rescorla氏（右）

S/MIME WG

S/MIME WGは電子メールの暗号化や電子署名に関する標準化を行うWGです。ミーティングは4日目（3月13日）の16:00～17:00に行われ、30人程度が参加しました。

ドキュメントのステータス報告が簡単にされ、続いて進行中のI-Dについての発表がありました。

まず、S/MIMEにおける証明書の処理に関する発表では、これまで鍵長の下限が512ビットだったものを1024ビットに引き上げる提案がされました。同じくメッセージ仕様も、ユーザーエージェント鍵長の下限を1024ビットに引き上げる提案がされました。メッセージ仕様では、鍵長についてこれまでが「512ビット未満の鍵生成をしてはならない（MUST NOT）、768ビット以上の鍵生成をすべき（SHOULD）」であったのを「1024ビット未満の鍵生成をしてはならない（MUST NOT）、1024ビット以上の鍵生成をすべき（SHOULD）」と変更する提案でした。

会場からは特に異論は出なかったものの、その後のメーリングリストの議論では、ユーザーエージェントの鍵長について「MUST NOT」とすべきではないという意見が複数出ており、議論が続きそうです。

また、CMSでの楕円曲線暗号（ECC）利用についての発表では、SHA2ファミリへ対応するような提案がされました。こちらについては特に異論は出ていませんでした。

さらにASN.1モジュールの発表として、現在旧版のASN.1（1988）モジュールに則って記述されている標準を、新版（2002）へと変更するという提案がされました。内容としてはPKIX WGで発表されたものと同じであるため、PKIXの資料を参考するよう依頼がありました。

最後に、PECに関する発表が行われました。PECはイタリア語のPosta Elettronica Certificataの略で、英語ではCertified Electronic Mailの意味となるようです。

イタリアでは、2008年末までに行政機関間の文書交換を電子化することが求められており、それに向けたS/MIMEを応用した電子メールシステムの案として発表されたものでした。会場内からはS/MIMEの範疇ではないのではという意見が出され、また、もし標準化を望むのであれば、まずI-Dを提出すべきだなどの意見が上がりました。

写真:Philadelphia Marriott Downtown — 第71回IETFの会場となったPhiladelphia Marriott Downtown

その他

今回のIETFにおいて、3月12日の17:00～19:30に開催された全体会合（Plenary）で、IESGのセキュリティエリアのディレクタであるSam Hartman氏（MIT）が退き、後任としてPasi Eronen氏（NOKIA社、TLS-WGのチェアの一人）が着任することになりました。

Hartman氏は、SASLの提案を行い、セキュリティエリアで多くの貢献をした方です。一方、新任のEronen氏はTLSの標準化における中心的な人物で、昨今では、多くのTLS（SSL）の実装状況を調査・比較するなど、プロトコルの配備に関して広い視野を持った方です。セキュリティをどう守り、どう広めていくかに関しての視点を持つディレクタとして活躍されるのではないでしょうか。

また、全体会合だけでなく、セキュリティエリア会議（SAAG）でも、Hartman氏が退任の挨拶をするとともに、Eronen氏からは就任の挨拶が行われました。

（富士ゼロックス株式会社稲田龍/筑波大学金岡晃）