メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
===================================
    __
    /P▲         ◆ JPNIC News & Views vol.509【臨時号】2007.12.26 ◆
  _/NIC
===================================
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.509 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

□第70回IETF報告 特集
○[第1弾] 全体会議報告 (vol.505)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol505.html
○[第2弾] DNS関連WG報告 (vol.506)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol506.html
○[第3弾] IPv6関連WG報告 (vol.508)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol508.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第70回IETF報告 [第4弾]  セキュリティ関連WG報告
                                                 JPNIC 技術部 木村泰司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

第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件のアジェンダを取り消すことになりました。ミーティング
は、1日目の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として採用するかどうかの議論が行わ
      れることになりました。

    - Updating ASN.1 modules to 1998 syntax

      多くのRFCで使われているASN.1モジュールは、1988年版ASN.1に則って
      記述されています。これを新版の書式に変えていくことについての提案
      です。

    - Resource Discovery Protocol

      サービス(httpでの接続先など)に必要な証明書を探すプロトコルです。
      Internet-Draftがまだないことから、MLで議論を進めた後に、提案者が
      叩き台を出すこととなりました。

ITU-Tからの要請は、DNに含まれるstreetAddressに関する文字列の上限を設け
ないことに関する検討と、トラストアンカーとなるCAの、名称が重複しないよ
うにする仕組みがあるか、といった確認でした。PKIX WGとしては、前者につ
いては証明書を扱うプログラムへの影響を踏まえて、プロトコルの変更に関し
てはアクションを取らないことを返答することとなりました。また後者につい
ては既存の仕組みはなく、プロトコルの策定を行っているPKIX WGとしては、
それを設けることについて検討できる立場でないことなどが返答される模様で
す。


◆SIDR WG (Secure Inter-Domain Routing WG)

SIDR WGは1日目の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に登録されたオブジェクトの同期の
必要性等について議論を行うことができました。IEPGらしく、IPアドレスの管
理とインターネットルーティングに関わる技術者の、両方の立場に立脚した意
見が寄せられました。

IEPGでプレゼンテーションを行うということは、RIRやIETFにおけるアクティ
ブメンバーと議論することになりますので、事前には緊張いたしました。しか
し、会場からは重要なポイントを押さえたコメントをいただくことができ、事
後には充実した意見交換ができたと感じました。

今後、実験運用の結果をコミュニティにフィードバックするなどの活動を通じ
て、技術と運用が陸続きになるような活動ができればと感じました。


(*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等で使われているセキュリ
    ティプロトコルに対して、汎用の認証情報を定義することが目指されてい
    ます。


     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       わからない用語については、【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.509 【臨時号】

 @ 発行         社団法人 日本ネットワークインフォメーションセンター
                 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), 2007 Japan Network Information Center

このページを評価してください

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2024 Japan Network Information Center. All Rights Reserved.