バックナンバー：vol.123

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2012-08-30━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.123 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　　　　　　　　　　第84回IETF Meeting報告（1）
　　　　　　　　　　　～DANEの動向に関する話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

今回で84回目となるIETF Meeting（以下、IETF84）が2012年7月29日から8月3
日にかけて、カナダのバンクーバーで開催されました。FROM JPRSでは今回か
ら2回にわたり、IETF84で報告・議論されたさまざまな話題の中から、ドメイ
ン名／DNSに関する話題を中心にお伝えします。

第1回目となる今回は、ここ数回のIETFにおいて集中的に作業が進められ、
2012年8月に基本プロトコルが標準化されたDANE（*1）の動向について報告し
ます。

（*1）DANEの名称は「DNS-based Authentication of Named Entities」に由来
　　　しています。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

■dane WGの状況

dane（*2）WGでは、DNSを用いたデジタル証明書（以下、証明書）の安全な配
送や、証明書とサーバーの関連付けの正しさを検証できるようにするためのプ
ロトコルの標準化作業を進めています。

（*2）IETFのWG名は小文字で表記されます。

▼DANEの基本仕様の標準化作業が完了

WGで標準化作業を進めていたDANEの基本仕様が、2012年8月にRFC 6698として
発行されました。DANEは、特にWebにおいて広く普及しているTLS/SSL（*3）の
信頼性確保を、既存のDNSインフラによって実現することを目的としています。

（*3）Transport Layer Security/Secure Sockets Layerの略。
　　　安全な通信を行うためのプロトコル。TLSの前身となったSSLは米国ネッ
　　　トスケープコミュニケーションズ社（当時）により開発／実装され、現
　　　在のTLSはIETFにより標準化が進められています。

ここでは、DANEが開発目標としたTLS/SSLにおける証明書の正当性検証の現在
の状況、DANEにより実現される具体的な内容、WGの活動開始に至るまでの経緯
などについて、改めておさらいします。

▽現在のTLS/SSLではX.509による証明書を正当性検証に利用

現在のインターネットではTLS/SSLの信頼性確保において必要となる証明書の
正当性検証に、ITU-T（*4）が定めたX.509で規定された認証局（CA）の階層構
造が広く用いられています。

（*4）国際連合の専門機関の一つである国際電気通信連合（ITU）の部門の一
　　　つで、通信分野における規格の策定を担当しています。

X.509の階層構造ではルート認証局が発行するルート証明書が、全体の信頼性
の根本となっています。ルート認証局は自らの正当性を自分自身が証明するこ
とになるため、ルート認証局を運営する組織はそのシステムの信頼性や生成／
使用する暗号鍵の取り扱いに、細心の注意を払う必要があります。

▽2011年に複数のルート認証局がクラックされる事件が発生、実害も報告

しかし、2011年に複数のルート認証局が外部からの侵入を受け、システムをク
ラックされる事件が相次いで発生しました。そのうち、オランダのDigiNotar
社（現在は破産、業務停止）のルート認証局がクラックされた事件では、実際
に500以上もの偽のサーバー証明書が不正発行され、その一部がTLS/SSL通信の
盗聴に悪用されるなど、インターネットの安全な利用に対する大きな脅威とな
りました。

▽DANEではDNSSECの信頼の連鎖を証明書の正当性検証に利用

一方、2010年7月にルートゾーンにおけるDNSSECの運用が開始され、続く2011
年には.jpや.com/.netなどを含む数多くのTLDにおいてDNSSECの正式運用が開
始されたことにより、利用者がDNSSECを利用可能な環境が整いつつあります。

DNSSECではルートゾーンからの信頼の連鎖により、DNSデータの正当性を検証
します。つまり、

（1）DNSデータとして公開鍵や証明書の情報を格納できるように、プロトコル
　　 を標準化する
（2）それらのDNSデータが格納されているゾーンまでの信頼の連鎖を、DNSSEC
　　 で確立する

ことにより、従来のX.509におけるルート認証局からの階層構造を用いた証明
書の検証をルートゾーンからのドメイン名の階層構造を用いて実現することが、
原理的に可能になります。

このこと自体はDNSSECの開発段階から専門家の間で認識されていましたが、
DNSSEC自体の標準化と実環境への導入の遅れにより、標準化のための本格的な
活動は、これまで積極的に進められていませんでした。

そして、最近のDNSSECの普及促進と利用環境の整備（＝上記（2）の実現）を
受け、上記（1）を実現するためのプロトコルの標準化を目的としてdane WGが
組織され、標準化作業が進められることとなりました。

▼TLS/SSLのための枠組みとして「TLSAリソースレコード」を新規導入

前述したようにdane WGでは、TLS/SSLにおける証明書の正当性検証に用いるた
めの、DANEの標準化が目的とされました。

DANEでは証明書の検証に利用する証明書そのものや公開鍵を格納するためのリ
ソースレコードとして、TLSAリソースレコードが新たに定義されました。なお、
RFC 6698ではTLSAは何らかの略称ではなくリソースレコードの名称として定義
されており、今回標準化されたプロトコルは「DANE TLSA」と呼ばれることに
なります。

▼IETF84における状況

IETF84では基本プロトコルであるDANE TLSAの標準化完了を受け、secure
SMTP（*5）、S/MIME（*6）、XMPP（*7）に対応するためのプロトコルの標準化
が議論されました。いずれも作業進行中であり、標準化に向けた作業を継続し
ていくこととなりました。

（*5）Simple Mail Transfer Protocolの略称。
　　　電子メールを送信するためのプロトコルです。メールサーバー間での電
　　　子メールのやり取りや、メールソフトなどのクライアントからメール
　　　サーバーに電子メールを送信する際に用いられます。

（*6）Secure Multipurpose Internet Mail Extensionsの略称。
　　　電子メールを暗号化するためのプロトコルの一つです。最初のバージョ
　　　ン米国RSA Data Security社によって提案され、IETFにより標準化され
　　　ました。

（*7）eXtensible Messaging and Presence Protocolの略称。
　　　インスタントメッセンジャー（以下、IM）において、メッセージの交換
　　　やログイン状況の通知などに使われるプロトコルです。米国Jabber社に
　　　よって開発されたIM「Jabber」のプロトコルがもととなっており、
　　　IETFで標準化されました。

最後にdane WGの今後について議論され、DANE TLSAの標準化完了を受け、現在
進行中の標準化作業の完了後、WGを一時休止（hiatus）の状態とすることがほ
ぼ合意されました。なお、従来からWGではDANE TLSAに加え、IPsecにおける証
明書の正当性検証に関する標準化も目的とされていましたが、今回のIETF84に
おいて、IPsecにおける標準化は目的から外されることとなりました（*8）。

（*8）理由の一つとして、IPsecの機能拡張のためのWGとしてipsecme WGが設
　　　立済であることが挙げられました。

■次回の内容について

次回のFROM JPRSでは、IETF84におけるdane以外のDNS関連WG、plenary（全体
会議）におけるトピックスなどについてお伝えします。

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

◎関連URI

　- IETF 84 - Vancouver, BC, Canada
　　http://www.ietf.org/meeting/84/
　　（IETF84ホームページ）

　- IETF 84 Preliminary & Interim Materials
　　https://datatracker.ietf.org/meeting/84/materials.html
　　（IETF84発表資料一覧）

  - DNS-based Authentication of Named Entities (dane)
　　http://datatracker.ietf.org/wg/dane/charter/
　　（dane WGのページ）

  - RFC 6698 - The DNS-Based Authentication of Named Entities (DANE)
　　Transport Layer Security (TLS) Protocol: TLSA
　　http://tools.ietf.org/html/rfc6698
　　（DANE TLSAの基本プロトコル仕様）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━
■会議報告：http://jpinfo.jp/event/
■配信先メールアドレスなどの変更：http://jpinfo.jp/mail/henkou.html
■バックナンバー：http://jpinfo.jp/mail/backnumber/
■ご意見・ご要望：from@jprs.jp

当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、
ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。
また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、
リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに
ご注意ください。
その他、ご利用にあたっての注意事項は読者登録規約にてご確認ください。
http://jpinfo.jp/mail/kiyaku.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集・発行：株式会社日本レジストリサービス（JPRS）
http://jprs.jp/
http://日本レジストリサービス.jp/
Copyright(C), 2012 Japan Registry Services Co., Ltd.