ニュースレターNo.31/2005年11月発行

第63回IETF

1. 全体会議報告

2005年7月31日(日)～8月5日(金)、フランスのパリにあるLe Palais des Congress de Paris(パレ会議場)にて、第63回IETFが開催されました。

会場となったLe Palais des Congress de Paris(パレ会議場)

今回のホストはFrance Telecom、協賛はCisco Systems、Juniper Networks、Renatorの3社で、フランスの大手通信企業とネットワーク機器ベンダの大手企業が占めていることになります。

IETF Chairの発表によると今回のIETFの参加登録者数は1,454名でした。前回のIETFまで参加人数が減少傾向にありましたが、今回は大幅に増加しました。近年参加者の間で「IETFの参加者数が減っている」と言われていますが、実際の傾向を見てみるため、ここ2年間の参加登録者数をまとめてみました。以下に示します。

－第63回(2005年7月31日～8月5日): 1,454名 36ヶ国フランス・パリ
－第62回(2005年3月6日～11日): 1,133名 28ヶ国アメリカ・ミネアポリス
－第61回(2004年11月7日～12日): 1,311名 26ヶ国アメリカ・ワシントンD.C.
－第60回(2004年8月1日～6日): 1,460名 40ヶ国アメリカ・サンディエゴ
－第59回(2004年2月29日～3月4日): 1,390名 32ヶ国韓国・ソウル
－第58回(2003年11月9日～14日): 1,233名 29ヶ国アメリカ・ミネアポリス

1,500名を毎回越えていた2000年頃に比べると少ない状況ですが、ここ2年間は1,100名～1,500名の間で推移していることがわかります。減少し続けているわけではないようです。一方、人数が多い回は参加国数も多いことから、多様な国から参加している様子が伺えます。開催地の気候なども関係しているかも知れません。

Past Meetings of the IETF(過去に行われたIETFミーティング): http://www.ietf.org/meetings/past.meetings.html

※参加者数に関するIETFミーティングでの発表と事後の集計結果が異なることがあります。

今回のIETFではチュートリアルを除いて116のセッションが開かれました。このうち、13セッションがBoFでした。BoFはワーキンググループ(以下WG)が結成される前の段階で、新しく活動を始めるための議論を行うセッションです。

一つ目の"Operations and Administration Plenary"は8月3日(水)の夕方に、二つ目の"Technical Plenary"は8月4日(木)の夕方に行われました。

◆Operations and Administration Plenary

Operations and Administration Plenaryは、IETFの活動全体の運営に関する報告と議論を扱う全体会議です。

この会議ではIETFチェアによるIETFミーティングの参加状況などの概況、ホストであるFrance Telecomによるプレゼンテーション、ポステルアワード(Postel Service Award)の発表、IAOCの活動報告、TOOLSチームの活動報告などが行われました。

ポステルアワードはデータ通信のコミュニティで、持続的な技術的貢献をした方や、リーダーシップを発揮した方に送られる賞です。1999年に故JonathanB. Postel氏に対して贈られて以降、毎年一人ずつ選出されてきました。今回はJPNIC理事(前理事長)の村井純に対し、彼のビジョンと先駆者としてのアジア太平洋地域におけるインターネット普及活動の推進をたたえて贈られました。

Postel Awards(ISOCのポステルアワードのWebページ): http://www.isoc.org/awards/
JPNIC News & Views Vol.280: http://www.nic.ad.jp/ja/mailmagazine/backnumber/2005/vol280.html
本誌P52村井純ポステルアワード受賞

IAOC(IETF Administrative Oversight Committee)の活動報告では、メンバー紹介やこれまでに行われたミーティングについて報告されました。IAOCは2004年初頭から行われている、IETFの運営管理体制の再編の活動の一環として作られた委員です。IETFの予算や活動計画、契約などに関するIAD(IETF Administrative Director)の提案に対してレビューを行い、また活動の方向性を示す役割を担っています。

TOOLSチームの活動報告では、これまでに開発されたツールの紹介が行われました。TOOLSチームは2004年の中頃に当時のIETFチェアであるHarald氏などによって提案されたもので、IETFにおけるドキュメント化活動を支援するツールの開発などを行うチームです。開発されたツールは下記のWebページから利用できます。

IETF TOOLS: http://tools.ietf.org/

ドキュメントのステータスやWGのマイルストーンをリアルタイムに表示するツールの他にInternet Draft(以下、I-D)の書式をチェックするツールなどがあり、WGチェアやI-Dの著者の助けになりそうなものが多く見られます。

今後はIETF Last Callとなっている全てのI-Dを表示するツールなどが開発されるようです。このツールができると、次にRFCになるI-Dを比較的簡単に探せるようになります。RFCに則ったプログラムの開発を行っている開発者に役立つツールと言えるでしょう。

◆Technical Plenary

Technical PlenaryはIETFの活動のなかで技術的な議論を扱う全体会議です。前エリア・ディレクターのSteve Bellovin氏によるプレゼンテーションや、IABの活動報告、IRTFの活動報告などが行われました。

Steve Bellovin氏のプレゼンテーションでは、"Application Security: Threats and Architecture"と題して、プロトコルのアーキテクチャ(設計上の考え方)に起因するセキュリティ上の問題点とその仕組みが解説されました。後半ではセキュアなネットワーク・アプリケーションを設計するためのポイントなどが整理して紹介されました。このプレゼンテーション資料は下記のWebページに掲載されています。

"Steven M. Bellovin -- Talks": http://www.cs.columbia.edu/~smb/talks/

IABの報告では、IABで作られているドラフト・ドキュメントの紹介や2005年フォーカスする話題についてプレゼンテーションが行われました。

IABでは、ドメイン名が商標やネットワーク・サービスの存在の推定に使われてしまうことの問題についてまとめたドキュメント(draft-iab-dns-assumptions)や、データリンクの状況がインターネット・アーキテクチャに対して持つ役割に関するドキュメント(draft-iab-link-indications)の編纂(へんさん)が進められています。一方プロトコルのレビューをする立場の人にわかりやすいモデルの記述方法をまとめた"Writing Protocol Models"がRFC4101になりました。このように、IABではIETFにおける仕様策定活動に共通するトピックのドキュメント化活動が行われています。IABのドキュメント活動と現在の活動内容については下記のWebページをご参照下さい。

IAB Documents and Current Activities: http://www.iab.org/documents/

またIABの概要については下記のWebページをご参照下さい。

About the IAB: http://www.iab.org/about/

2005年、IABでは以下の3つにフォーカスして活動するとのことです。

IPv6の利用のため実装上のソリューションに関するドキュメント
インターネット・エンジニアリングの上で共通の知識となるような"原理"に関するドキュメント
望ましくないトラフィックが起こる可能性を減らしたり、悪影響を小さくするためのツールを提供することを想定したプロトコルやインフラに関するドキュメント

IRTF報告では、新しく設置される見込みとなっているResearch Groupの紹介が行われました。その中で新設が検討されているInternet Congestion Control Research Groupとしてフォーカスする技術としてXCP(eXplicit ControlProtocol)が紹介されました。この他のIRTFのResearch Groupについては下記のWebページをご覧下さい。

IRTF Research Groups: http://www.irtf.org/groups/

Technical Plenaryは、最後に"Town Hall Meeting"と呼ばれる参加者同士の自由討論が行われ、会場の都合で19時半という早い時間に終了しました。

(JPNIC 技術部木村泰司)

2. IPv6関連WG報告

本章では、第63回IETFでのIPv6に関連したトピックスとして、IPv6、v6ops、shim6の各WGの動向についてレポートします。

◆IPv6 (IP version 6) WG

IPv6基本スペックや、プロトコル自身の挙動に関わる標準を扱っているIPv6WGのミーティングは、8月2日(火)の午前に一コマ、10:30～12:30の2時間枠で実施されました(今回のIETFは、夕食時間などのパリの生活事情にあわせて従来とは時間割が違っており、午前に2コマ、午後3コマが基本になっています)。前回ミネアポリスでは全体参加者が少なかったこともあり、いつもに比べて少々参加者が少なかったのですが、今回はIPv6に関するデプロイメントが盛んな欧州での開催ということもあってか、大きめの部屋にほぼ満員の参加者が集まっていました。

今回の主なトピックスですが、

・既存RFC文書の更改についての議論: - ステートレスアドレス自動設定のプライバシー拡張(現RFC3041)、PPP IPv6(現RFC2472)について、標準段階を進めるために実装レポートの収集
- ICMPv6のノード情報収集機構について
・エンドサイトへのIPv6アドレス割り当て推奨値の変更議論
・ルータ広告のM/Oフラグの扱いについて
・IPv6 WGの今後について

などについて話し合われています。

まずはチェアより、IPv6 WGでの扱い文書の状況について報告がありました。ここ数回、時間短縮のために、あらかじめチェアが用意したWebページにまとめられています。以下のURLを是非ご参照ください。

>http://www.innovationslab.net/~brian/IETF63/IPv6/IPv6DocumentStatus.html

さて、今回ですが、「エンドサイトへのIPv6アドレス割り当て推奨値の変更」についての議論が実施されました。このトピックスに関しては、事前に報告者からIPv6 WGのMLとIPv6のアドレスポリシーを話し合うAPNICのglobal-v6 MLにて議論提起があり、いくつかの意見が寄せられたものです。現在、IPv6アドレスのエンドユーザ割り当てサイズとしては、統一的に/48が推奨されています。この値は、ユーザーごとに約65,000個のサブネットを構築できるものですが、これがSOHOや家庭向けには大きすぎて無駄ではないか、という意見のもと、100以上のサブネットを持つかどうかによって/56、/48を使い分けよう、というものです。基本的には賛成の意見が多かったのですが、そもそもこのような内容はIETFで扱うべきではない、との意見ありました。今後、実際にアドレス割り振りに関する実務を実施しているレジストリでの意見収集が実施される予定です。

その他、大きなトピックスとしては、IPv6 WGの今後についての議論がありました。IPv6 WGは予定では、今年で終了することになっています。IPv6のデプロイメントも進んできたため、現在、IPv4そのものを扱うWGが存在しないように、IPv6 WGも終了し、トピックスごとに適切なWGで標準化を進めて行くべきだ、という意見にも基づいています。このために、基本スペックを標準状態にまで持って行き、WGを終了する方向で、というチェアからの意見提起がありました。これに対し、とはいってもIPv6そのものに関連する話題はいくつか残っており、WGを終了するならそれらをどう扱うか、ということを決めなければならない、といった意見がありました。引き続き、MLで議論を実施することになっています。

このように、IPv6 WGはWGの終了を見据えた動きが始まっています。意見にもありましたが、IPv6 WGで従来扱われていたトピックスが今後どのように扱われるか、注視しておく必要がありそうです。

IPv6 WG: http://www.ietf.org/html.charters/ipv6-charter.html
http://playground.sun.com/pub/ipng/html/ipng-main.html
第63回 IETF IPv6 WG ミーティングのアジェンダ: http://www.ietf.org/ietf/05aug/ipv6.txt

◆v6ops (IPv6 Operations)WG

IPv6のデプロイメントに関する話題を扱うv6ops WGのミーティングは、8月1日(月)の午後、14:00～16:00の2時間枠で開催されました。前回より、トンネル技術などの移行技術をこのWGでの範囲外としています。移行技術や、トンネルでのサービス提供技術などは前回のTunneling Configuration BOF、今回別途開催されたLightweight Reachability softWires BOFにて扱われています。

今回の主なトピックスは、

・既存ドラフトの状況報告: - 企業でのIPv6利用 (draft-ietf-v6ops-ent-analysis-03.txt)
- IPv6ネットワーク防御 (draft-ietf-v6ops-nap-01.txt)
・IPv6ネットワークでのICMPv6のフィルタ手法について
・IPv6ネットワークのリナンバリングについて

などです。既存ドラフトについては、RFC化に向けて進んでいます。

ICMPv6のフィルタ手法についての提案では、IPv6ネットワークにおけるICMPv6のフィルタの仕方についての議論がありました。昨今、セキュリティ上の理由からICMPをフィルタする組織も増えていますが、IPv6ネットワークにおいてはICMPv6が通信上重要な役目を果たすため、すべてをフィルタすることは適切ではありません。IPv6ネットワークであるべきICMPパケットフィルタについての考えは重要であるため、引き続き議論していくことになりました。

ネットワークのリナンバリングに関しては、実際に6NET^※1という実験ネットワークにおいて、サービスプロバイダやユーザを含んだネットワークをリナンバした実例を基に発生した問題点などの報告がなされました。IPネットワークではネットワークのリナンバリングは手間のかかる作業であり、IPv6ネットワークにおいてどのようにリナンバリングを確実、簡素に実施するかは注目すべき話題です。実例ベースで、リナンバリングに利用できるIPv6標準機能の状況などのレポートがあり、ルータリナンバリングプロトコルがうまく動作しない、などが報告されました。

v6ops WG: http://www.ietf.org/html.charters/v6ops-charter.html
http://www.6bone.net/v6ops/
第63回 IETF v6ops WG のアジェンダ: http://www.ietf.org/ietf/05aug/v6ops.txt

◆shim6(Site Multihoming by IPv6 Intermediation )WG

IPv6に特化したマルチホーム手法を検討していたmulti6 WGでの議論を引き継ぎ、実プロトコルの標準化を進めるために今回からshim6 WGが開催されています。shim6 WGは、8月2日(火)午前9:00～10:00と、8月3日(水)午前9:00～10:00の合計2コマ実施されました。

shim6に関しては、grow WG(Global Routing Operations WG)など他のWGでもshim6 WGの紹介が実施されており、shim6への期待の大きさが伺われます。今回は、shim6 WGの方向、shim6の基本アーキテクチャ、及び基本ドラフトの紹介／内容確認に殆どの時間が使われ、具体的な議論はあまりありませんでした。引き続きMLにて議論が実施される予定です。

IPv6の普及が進むにつれ、マルチホーム技術の必要性が高まっており、shim6に関しては今後、早急な標準化とデプロイメントが期待されます。

shim6 WG: http://www.ietf.org/html.charters/shim6-charter.html
第63回 IETF shim6 WGのアジェンダ: http://www.ietf.org/ietf/05aug/shim6.txt

(JPNIC IPアドレス検討委員会メンバー／NTT情報流通プラットフォーム研究所藤崎智宏)

3. DNS関連WG報告

◆dnsop(Domain Name System Operations)WG

今回のdnsop WGミーティングでは、WGドラフトの状況確認を中心に議論が行われました。また、まだWGドラフトとなっていないいくつかの個人ドラフトに関する発表もあり、WGドラフトとして適しているか議論が行われました。

DNSSECに関するものとしては、draft-ietf-dnsop-dnssec-operational-practicesがADも注目している文章であり、早めにIESG^※2reviewに回す方向で更新することが確認されました。また、draft-ietf-dnsop-respsizeはいくつかの修正を経てWG Last Callすることが確認されました。

その他、新たなドラフトである
(1)draft-morishita-dnsop-anycast-node-requirements
(2)draft-kurtis-tld-ops
(3)draft-minda-dnsop-using-in-bailiwick-nameservers
の発表がありました。

(1)draft-morishita-dnsop-anycast-node-requirementsでは、BGP経路制御を用いたDNSエニーキャストサービスを行う場合の必要条件をBCP^※3として発表していました。会場では興味を持つ人が多く、grow(Global Routing Operations)WGでも発表してみたらどうかといった前向きな意見が出ていました。

(2)draft-kurtis-tld-opsは、トップレベルドメイン(TLD) DNSサーバの運用に関するルールを明文化したものであり、会場からは、TLDの運用は多岐にわたっているのでこの文章で定義するのは無理があるのではないか、という意見が出ていました。

(3)最後に、draft-minda-dnsop-using-in-bailiwick-nameserversの発表では、BIND 8をリゾルバサーバとして利用した場合の問題点が指摘されていました。ここ数回のIETFでのdnsop WGは、DNSの挙動を分析したドラフトが増えているように思われます。

◆dnsext (DNS Extensions) WG

dnsext WGのミーティングでは、ここ数回のミーティングでの主な議論となっている、DNSSECに関するドラフトを中心とした議論が行われました。前回のミーティングから引き続いて行われているNSEC3に関する進展の報告や、DNSSECやTSIGにて利用される個々の暗号化アルゴリズムに関するドラフトの報告が行われました。さらに、今回のミーティングの大きな議題として、DNSSECによって署名されたゾーン連鎖の起点となる鍵が、新たに生成もしくは更新された場合に、リゾルバ側にどう伝えるかという問題について述べたドラフトである、draft-ietf-dnsext-trustupdate-timersとdraft-ietf-dnsext-trustupdate-thresholdに関する議論が行われるはずでした。ところが、両方のドラフトを読んで来た人が会場に少なく、trustupdate-thresholdが既にExpireしていたため、次回のミーティングまでに両者の違いをまとめた文章をメーリングリストに流し、それをもとに議論を行うこととなりました。最後に、DNS実装の仕様をテストするためのツールがTAHI Project(http://www.tahi.org)によって開発されるというアナウンスが行われ、会場からは有意義であるという意見が出されていました。dnsext WGは、これからもDNSSECに関する議論が中心となっていきそうです。

(JPNIC DNS運用健全化タスクフォースメンバー／東京大学情報基盤センター関谷勇司)

4. セキュリティ関連WG報告

第63回IETFの中で、セキュリティエリアのセッションは17開かれました。そのうち4セッションが新たに開かれたBoFでした。

今回開かれたBoFは以下の4つです。

　－Hash BoF(One-way Hash Function BoF)
　－ALIEN BoF(Anonymous Identifiers BOF)
　－MASS BoF(Message Authentication Signature Standards BoF)
　－SECMECH BoF(Security Mechanisms BoF)

前回までBoFが開かれていたBTNSはWGになり、初めてのWGセッションとなりました。

本章では、セキュリティエリアのセッションの電子認証に関わるセッションについてご報告致します。

◆One-way Hash Function BoF
(一方向ハッシュ関数の脆弱性に関するBoF)

2005年8月1日(月)18：15よりハッシュ関数の脆弱性に関するBoFが開かれました。このBoFは最近発見されたハッシュ関数の脆弱性に対して、どのように対応していくかを議論するためのBoFです。話題性のある内容だけに、会場には150人程集まり、会場の通路や前方近くに座って参加する人が多数いました。

ここでのハッシュ関数とは、任意の長さのデータに対する演算処理を何度も行い、一定の長さの値を算出する計算処理(関数)のことです。元になるデータが少しでも違うと算出される値が大きく変わる性質を利用して、通信路でデータが改変されていないかどうかを確認するときなどに使われ、X.509の電子証明書などで使われています。

ハッシュ関数に関する研究は長年行われてきており、脆弱性を示唆する現象はこれまでにも指摘されてきました。しかし2004年中頃から2005年にかけて、これまでにないほど影響が大きい研究結果がいくつかの学会で発表されていました。ハッシュ関数の中に、異なるデータから同じ値が算出されるものがあることが立証されたり、同じ値が算出されるようなデータを探す方法で、効率の良いものが発表されたりしたのです。

IETFで仕様が策定されているセキュリティ関連のプロトコルの中には、MD5やSHA-1といった脆弱性が指摘されたハッシュ関数を使っているものが多くあります。これらのハッシュ関数の耐衝突性(異なる二つのデータから同一の値が算出されにくい性質、すなわち同じ値が算出されるような元の値の探索が難しいという性質) は、実は想定よりも弱いことがわかってきました。

このBoFは、ハッシュ関数の脆弱性に関する現状を把握し、IETFのセキュリティエリアとしてどのように対応していくかを議論するために開かれました。BoFの活動趣意やアジェンダについては以下のWebページをご覧下さい。

One-way Hash Function BOF(hash): http://www.ietf.org/ietf/05aug/hash.txt

このBoFでは、はじめに米国NIST(National Institute of Standards and Technology - 米国標準技術研究所)によるワークショップの紹介がありました。このワークショップは2005年の10月31日～11月1日に開催が予定されており、既存のハッシュ関数に代わるSHA-256やSHA-512といったハッシュ関数の紹介や新しいハッシュ関数への移行方法について議論が行われる予定です。詳しくは以下のWebページをご覧下さい。

CRYPTOGRAPHIC HASH WORKSHOP: http://www.csrc.nist.gov/pki/HashWorkshop/index.html

次に、プロトコルの工夫によって脆弱性を回避する方法がいくつか紹介されました。新たなハッシュ関数を開発しその強度を検証するには時間がかかるため、これらの短期的な対策が必要になります。今回プレゼンテーションされたものはいずれも提案の段階で、今後どのような"短期的な対策"と"長期的な対策"が取られていくかは、前述のワークショップでの議論を踏まえて検討されていくと考えられます。BoFで紹介のあったハッシュ関数の現状をまとめたWebページと今後の議論に使われるメーリングリストの加入方法については、以下のWebページをご覧下さい。

Cryptographic Hashes(現状をまとめたページ): http://www.vpnc.org/hash.html
ハッシュ関数の脆弱性に関する議論を行うメーリングリストのWebページ: https://www1.ietf.org/mailman/listinfo/hash/

◆PKIX WG

PKIX WGのセッションは、2005年8月2日(火)14：00から行われました。約60名の参加で、近年のPKIX WGのセッションとしてはまずますの人数です。はじめにドキュメントステータスの報告が行われました。

前回のIETFから今回までの期間に二つのドキュメントがRFCになりました。

－Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (RFC 4055)

－Internet X.509 Public Key Infrastructure Permanent Identifier(RFC 4043)

前者は電子証明書とCRL(失効リスト)で、RSAのアルゴリズムに関連した署名アルゴリズムと鍵共有アルゴリズム、それから一方向性関数の追加について取り決めたものです。後者はSubject欄などではなく、恒久的な識別子を電子証明書に入れるための拡張です。電子証明書の有効期限が切れるなどして、別の電子証明書が発行されたときでも、同一の識別子を入れておくために使われます。

下記の4つがRFC Editorの編集待ちの状態です。これはRFCになることは決定しており、最終的な編集を行っている段階です。

　－Certification Path Building
　　(draft-ietf-pkix-certpathbuild)
　－Warranty Certificate Extension
　　2005年9月1日現在、このドキュメントはRFC 4059になっています。
　－Certificate Management Protocols
　　(draft-ietf-pkix-rfc2510bis)
　－Certificate Request Message Format (CRMF)
　　(draft-ietf-pkix-rfc2511bis)

Certification Path BuildingがRFC Editor queueに入り、証明書の検証に関する再度の仕様検討が徐々に片付きつつあります。あとはRFC3280の後継(通称RFC3280bis)が残っています。こちらはまだ重い課題が残っており、検討が続きそうです。

PKIX WGの議論としては、はじめに"SRV RR"と題してMicrosoftのStefan Santesson氏によるプレゼンテーションがありました。これは_ldap._tcp.domain.comといったDNSのRR(リソースレコード)を使って、電子証明書のデータを格納／取得する方法の提案です。WGとしてのドラフトドキュメントにはなっておらず、個人のドラフト(draft-santesson-pkix-srvrr-00.txt)としてsubmitされています。これに対し会場からは、DNSのゾーン管理がサーバ証明書の利用を許可するようなモデルで問題がないかを確認する必要がある、といった指摘がありました。一方、MLでは入手した電子証明書を検証するための信頼の設定について議論されています。

SCVPについては、処理能力が低いシン・クライアントでの実装上の問題について議論されました。SCVPは電子証明書の検証を、他のサーバに任せて行うためのプロトコルです。今までに上がっている指摘は、複数の認証局証明書を検証するときに、name Constraints等の制約をチェックすることが負荷になる点、検証ポリシーと検証アルゴリズムの二つのOID(Object Identifier)が必要になる点の二つです。後者についてポリシーとアルゴリズムをまとめたポリシーOIDを設ける提案がなされましたが、会場ではまとまらないため、一度個別に議論が行われることになりました。

RFC3280bisは、電子証明書とCRLの基本的な扱いを記述するドキュメントです。様々な論点が残っています。認証局の鍵を変えるための"Root CA key update"は、RFC2510(CMP)で言及されている古い鍵で新しい証明書に署名をする"newwith old"などを組み合わせる手法がありますが、改めて記述するようです。この他にkeyUsageフィールドのnonRepudiationビットの解釈の仕方をはじめ、6つほど大きな論点が残っています。ひとまず今の -01版に対するコメントを反映して修正し-02版でもう一度コメントを募ることになりそうです。

恒例のLiasion Presentationでは、ETSI(European Telecommunications Standards Institute)の立場で、Denis Pinkas氏がCAdES(CMS Advanced Electronic Signature)の紹介を行いました。CAdESはCMS(Cryptographic Message Syntax)を使って長期的に検証可能な電子署名を実現するための書式です。ETSIではXMLを使った電子署名の書式であるXAdES(XML Advanced Electronic Signatures)をETSI TS 101 901と呼ばれるドキュメントにまとめており、これをCMSを使ったものに書き換えるという位置づけのようです。同様のプロトコルにRFC3126があり、これを更新することを目標としているようです。ドラフトドキュメントは以下のURLから入手できます。

CMS Advanced Electronic Signatures (CAdES): http://www.ietf.org/internet-drafts/draft-pinkas-smime-cades-01.txt

◆SAAG (Security Area Advisory Group)

SAAGはIETFのセキュリティエリアの全体会議です。各セッションの報告や最近の話題についてのプレゼンテーションや議論が行われます。今回のIETFでは8月4日(木)の14:00～16:30開催されました。

今回行われたプレゼンテーションは、"ITU-T Recommendation X.805"の紹介と"Unicode Security Considerations"の紹介です。

ITU-T Recommendation X.805 は End-to-Endの通信を構成するシステムのセキュリティの側面を分類し整理したものです。盗聴やなりすまし、使用不能といった脅威をモデルとして、脅威を避けるための技術要素を分類しています。分類はSecurity Dimensions、Security Layers、Security Planesと呼ばれる三つの観点で行われています。

会場からは、三つの観点の関連性はあるのか、ある脅威に対して適した分類がなされているのか、などの内容の正しさに関する指摘が挙がり、果たしてこの文書が"Recommendation"(勧告)の役割を果たすのかという根本的な疑問が呈される場面がありました。

一方、ITU-TのようなIETF以外の会議で、ネットワークのセキュリティがどのように捉えられているのかを知る機会になるという指摘もありました。IETFは、IETFとして議論した結果の"仕様"を決めるミーティングなので、必ずしもIETFにおける視点だけが正しいわけではないという、控えめな見方があります。IETFにおけるWG活動とドキュメント活動は長年のノウハウもあって、とても洗練されていますが、別の技術標準の状況を知ることによって、また新たな視点を取り込むことができると考えることができます。

"Unicode Security Considerations(Unicode Technical Report #36)"では、Unicodeの利用によって起こる問題点の紹介などが行われました。例えば文字の記述方向が異なる言語を組み合わせてIDN(Internationalized Domain Names)を使ってURLを記述すると、URLの途中で右方向に読んだり左方向に読んだりという、使いづらい状況ができてしまいます。このような問題に対して、User Agent(Webブラウザ等)に必要になることなどをまとめたのがUnicode Technical Report #36です。このドキュメントは以下のWebページで読むことができます。