＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲         ◆ JPNIC News & Views vol.536【臨時号】2008.4.9 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.536 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では、vol.532、vol.534、vol.535に続き、第71回IETFのレポート[第4弾]
として、セキュリティ関連WGの動向についてお届けします。

□第71回IETF報告 特集
○[第1弾] 全体会議報告 (vol.532)
  http://www.nic.ad.jp/ja/mailmagazine/backnumber/2008/vol532.html
○[第2弾] DNS関連WG報告 (vol.534)
  http://www.nic.ad.jp/ja/mailmagazine/backnumber/2008/vol534.html
○[第3弾] IPv6関連WG報告 (vol.535)
  http://www.nic.ad.jp/ja/mailmagazine/backnumber/2008/vol535.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第71回IETF報告 [第4弾]  セキュリティ関連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点となります。

1. RFC3280bisのRFC化が認められた
2. CMCに関連する三つのI-DがIESGレビュー中
3. WGが担当する案件が五つとなった

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

[WG担当案件]

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

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

(*) JPNIC News & Views vol.509
    第70回IETF報告 [第4弾] セキュリティ関連WG報告
    http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol509.html

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

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

RFC 3279bis: "Elliptic Curve Cryptography Subject Public Key Information"
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ecc-subpubkeyinfo-04.txt

RFC 4055bis: " 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氏は

  i.  Informational RFCを発行する
  ii. 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を三つのレイヤで定義しています。

1. PA(Posture Attribute)
   Endpointの種々の属性情報(OSのバージョン、サポートしているプロトコ
   ル、パッチの適応状態など)の表現形式を定める

2. PB(Posture Broker)
   PAをEndpointと評価者(Evaluator/Validator)に対して交換する仕様を定め
   る

3. 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をハッシュ化する必要性につい
てであり、以下の二つの点で合意がされました。

1. ハッシュ利用を強制すること(Mandate)
2. 必要ならば新しいコードポイントを定義して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などを加える提
案がされました。


◆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を提出すべきだなどの
意見が上がりました。


◆その他

今回の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氏からは就任の挨拶が行われました。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
            http://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  :::::  http://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト ::::  http://www.nic.ad.jp/member/(PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
 JPNIC News & Views vol.536 【臨時号】

 ＠ 発行         社団法人 日本ネットワークインフォメーションセンター
                 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F
 ＠ 問い合わせ先   jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
           本メールを転載・複製・再配布・引用される際には
       http://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   http://www.nic.ad.jp/ja/mailmagazine/


■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  http://www.nic.ad.jp/
■■

Copyright(C), 2008 Japan Network Information Center