IDNに関する私見 - Nothing ventured, nothing gained.

IDNの偽装のコメント欄で、暗に私がIDNに関して諸手を上げて賛成しているわけではないことを示唆した。そこでは「私のIDNに対する意見は、数年前に書いたものが、実はインターネット上に載っています。検索すれば、見つかるかもしれません。という言い方から、私の個人的な意見はお察しください。」とコメントした。「ブログで会社をクビになりたくないので、ここでは書けません。」とも書いたが、こんなことでクビにはならないだろう。少し臆病になりすぎたかもしれない。

IDNに関する今までの考え

ここで改めてIDNに対する私の意見を書いておこう。なお、繰り返しになるが、これは私の所属する会社や団体とは一切関係ない。私個人の意見であることを強調しておく。

私はIDNに反対ではない。普及を邪魔する気もない。デジタルデバイド解消のための有力な技術となりうるのならば、積極的にサポートしたいと考えている。

しかし、少なくともちょっと前までは積極的にサポートする気にはなれなかった。自分で使う気にならないからだ。なぜか。自分なりに考えてみた。

正直、日本語ドメイン名でURLを表示しているケースに出会うことはほとんど無い。そうなると、あるサイトにアクセスしようとした場合、たとえば、ほげほげ株式会社というのがあったとして、この会社のサイトのアクセスしようとしたとしよう、http://www.ほげほげ.jp とは入力しない。いきなりブラウザのアドレスフィールド（URLフィールド）にURLを直接入力するよりも、おそらく検索エンジンを使うと思うが、もし直接入力するとしても、日本語ではなくASCIIで入力する（http://www.hogehoge.jp もしくは http://www.hogehoge.co.jp）。

日本語ドメイン名を目にしない理由として、そもそも利用環境が整っていなかったことは確かにあげられるだろう。IEではプラグインを導入しないと使えないし、日本語ドメイン名を登録している企業が少ない。たとえ、プラグインを入れるなりして、日本語名のドメインにアクセスできるようになっていたとしても、そのサイトが日本語ドメイン名を持っている可能性は現時点では非常に少ないので、日本語ドメイン名でのアクセスを試みようとは思わない。

これは「にわたま問題」かもしれない。日本語ドメイン名の利用環境が整っていなかったため、日本語ドメイン名を取ろうとしなかった、もしくは取っていても、実際にDNSに登録をしていなかったということはあるはずだ。

したがって、IE7でIDNが標準サポートされることになり、状況は変わる可能性はある。こう書くと、なんだお前のところが悪いのではないかと言われそうだ。批判は甘んじて受けよう。ただし、われわれが中立的な立場でIDNサポートの検討をさせていただいていた際に、お客様やパートナーの方からの声を聞かせていただいたのだが、そのときは緊急にサポートをしなければいけない状況ではなかった。それだけはここで述べさせていただく。これはJPRSさんの調査とは異なるようであるが、実際そうだったのだ。

IDN偽装への不安

IDNの偽装で書いたように、IDNには新たなフィッシング詐欺の土壌となる可能性はあるが、これは現在のASCIIのみのドメイン名の場合にも起こりうる問題である。実は、前回投稿した後、JDNA（日本語ドメイン名協会）の講演会＆パーティに呼ばれ、JPRSの方とお話させていただく機会があった。そこで「もうすぐJPRSで注意勧告のメッセージを出します」とおっしゃっていたのだが、さっそく出たようだ（ドメイン名登録時は、他人の権利を侵害しないかもう一度チェックを！（JPRSのサイトより））。そこでは次のように書かれている。

登録者Cさんのケース
有名なあのWebサイトのドメイン名ににているドメイン名を登録しようかな。
＜中略＞
このようなドメイン名の登録・使用は、「不正な目的での登録・使用」とみなされる可能性があります。

また、国際化ドメイン名(IDN)のフィッシング詐欺脆弱性について - 既に対策は存在し、.JPはサービス開始当初より対策済み - も次のように更新されている。

同一言語文字集合内における視覚的に似た文字の存在による問題への対処
報道で指摘された問題のように複数の言語間で存在する視覚的に非常に良く似た文字をドメイン名に悪用した不正サイトの問題以外にも、同一言語文字集合内における視覚的に似た文字によって同様の問題が発生する可能性があります。
たとえば、日本語で用いられる文字では次のような似た文字があります。
[へ](平仮名) [ヘ](片仮名)
[ソ](片仮名) [ン](片仮名)
[ロ](片仮名) [口](漢字)
※上記以外にも多数存在します
私たちが日常生活のなかで日本語を使用する際にはこれらの文字はそれぞれ別の文字として扱われており、文章作成時も異なる文字として意識しています。したがって、そこから掛け離れた使用制限や同一視は日本語JPドメイン名としての利便性を大きく損なうこととなってしまいます。
このため、日本語JPドメイン名ではこのような日本語の文字の中で視覚的に似ている文字については登録制限を行っていません。ですが、このような似た文字を悪用して第三者の商標や商号などと誤認させるような不正なドメイン名の登録・使用に対しては、JPドメイン名紛争処理方針(JP-DRP)に則った手続きが提供されており、ドメイン名の取り消しや移転という形で問題の解決に当たることができます。

このように、具体的に紛争処理機関における裁定の可能性とその場合のリスクが書かれており、IDN偽装でドメイン名を取得することを抑止するために努力はされているようだ。

つまり、IDN偽装はサイバースクワッティングやタイポスクワッティングの脅威を増長させる可能性はあるが、本質的にはすでにある問題である。考え方次第ではあるが、IDNの導入により、そのリスクよりも得られるもののほうが大きいと判断されるならば、許容できる範囲なのであろう*1。

残る不安

また、IDNの使われる範囲について私にはまだ若干不安がある。

TLDとSLDによるサポートの違い

現在、われわれはあるサイトにアクセスする際、そのドメイン名がどのTLDに属しているかをあまり意識しない。というよりも、利用者にこれらを意識させてはいけない。現在、TLDごとにIDNを使ったドメイン名の登録ポリシーは異なっており*2、利用者はあるTLDではよりフィッシング詐欺の可能性が高まることを許容しなければいけない状況になっている。

また、JPRSの管理するドメイン名に関しても、汎用JPドメインには日本語ドメイン名が使えるが、CO.JPやNE.JPといった属性型・地域型JPドメインでは日本語ドメイン名は使えない。これも何も知らない利用者には混乱を与える元にならないだろうか。そもそもの属性型・地域型JPドメインと汎用JPドメインとの成り立ちや存在理由を考えると、理解できるのだが、これを一般ユーザーに理解してもらうのはやや難しいのではないか。

アドレスフィールドに表示されるのはどのドメイン？

現在、日本語ドメイン名を持つサイトにアクセスすると、多くの場合、既存のASCIIドメイン名を持つサイトにリダイレクトされる（もしくはCNAMEによりはじめからASCIIドメインにつながるようになっている）。これは何も知らない利用者に対して不安を与える要因にはならないだろうか。たとえば、http://ほげほげ.jp というサイトにアクセスしているつもりなのに、いつのまにか、http://www.microsoft.com/hogehogecampagne/ というページに飛ばされていたら、戸惑わないだろうか。ASCII名でのドメインでもこのようなことはあるが、IDNを用いた場合、この違いはさらに顕著なものとなる。

日本語ドメイン名は期間限定のキャンペーンなどにも使われることが多くなるのではないかと聞いている。ここからは技術というよりも、その活用方法だが、そのような場合、既存ドメインのあるページに飛ばすのではなく、日本語ドメイン名のままキャンペーンのサイトを運営するほうが良いだろう。

また、ブラウザをはじめとするアプリケーション側で、FQDNをあらわす際に、Punycodeでエンコード前のドメイン名を表示するのか、それともエンコード後のドメイン名を表示するのかも課題だ。これは、たとえば日本語でドメイン名を表すのか、それとも呪文のような形ではあるが、"xn--"で始まるASCIIであらわすのかということだ。もちろん、利用者にとっては、日本語で表示されたほうが利便性が高いが、次に示すようなほか標準との兼ね合いもあり、一概にどちらが正しいと今の段階で言うのは難しいだろう。おそらく現時点では、どちらの方法でも表示できるようにするのがベストである。

ほかインターネット標準との兼ね合い

以前から私が懸念を示していたものの１つが、このほかインターネット標準との関連だ。IETFでは文字列はすべてUTF-8であらわすようにすることを以前すでに決定している。これはRFC2277 IETF Policy on Character Sets and Languagesに示されている。以下はRFC2277の"3.1 What charset to use"からの抜粋だ。

3.1. What charset to use
All protocols MUST identify, for all character data, which charset is in use.
Protocols MUST be able to use the UTF-8 charset, which consists of the ISO 10646 coded character set combined with the UTF-8 character encoding scheme, as defined in [10646] Annex R (published in Amendment 2), for all text.

ほかの多くのインターネット標準はこのRFCにしたがい、UTF-8対応が進められている。しかし、ドメイン名だけPunycodeでエンコードされることになると、そこに不整合が生じる。たとえば、私が一番気になるのは、PKIとの関係だ。

PKIはITUのX.509およびIETFのPKIXにおいて標準化が行われているが、X.509の証明書においてDirectoryNameおよびIssue/SujectでUTF-8が使うことが決められている*3。つまり、SSLやTLSで接続する際に、IDNのドメインであった場合でも、本来ならば、UTF-8でのエンコーディングがPKIの観点からは期待されるのだ。この不整合を解決するためには、証明書の中にはPunycode表記（"xn--"で始まるASCII表記）で記述する必要がある。ここで前に説明した、アプリケーションがIDNのドメインにアクセスした際に、アドレスフィールドに何を表示するかと関係する部分になる。利用者は、SSL/TLSでアクセスした場合、そのサイトが正しい証明書を持っているかを確認することになる。たとえば、https://ほげほげ.jp にアクセスしたとしよう。証明書は、Punycodeによるエンコーディングをサポートしていないので、xn--18ja5jb.jpに対しての証明書となる。ほげほげ.jpにアクセスしたのに、証明書はxn--18ja5jb.jpのもの。これでは何もわからない利用者には真正はサーバーかどうかを確認することはできない。残念ながら、私は最近、PKIにおけるこの動きを追っていないので、現在、どのような状態であり、どのような議論がされているか把握していない。もしどなたかご存知の方がいたら、コメントにでも書き込んでいただけると幸いである。

また、PKI以外にもW3CにおけるURI全体の国際化であるIRI（Internationalized Resource Identifier）やメールアドレスにおける国際化であるIMAA（Internationalizing Mail Address in Applications）の標準化や普及も望まれる。特に、IRIの普及は必須だろう。標準化はRFC3987として進展を見せているが、普及についてはこれからだという認識だ*4。

最後に

繰り返しになるが、私はIDNに反対論者ではない。ただ、まだ運用面でも技術面でも課題があるのは事実だ。利用者の多くはドメイン名に直接入力せずに、検索エンジンに頼るようになってきている現状もある。これはASCIIしか許さないドメイン名の技術的制約が原因だという見方もできるが、必ずしもそれだけではないだろう。このような中で、IDNの利用法、また普及に必要な技術、これらについての継続的な議論が必要だと思う。

以上、靖国参拝をめぐる議論ではないが (^^;;;;、あくまで「私人」としての意見を述べさせてもらった。

*1:ここはあえて、第三者的な書き方をさせていただく。私にはROIを判断できる材料が無い。どっかにIDN導入における経済波及効果などがあるのかもしれないが、残念ながら私は知らない。

*2:ICANNの勧告はあるが、残念ながらすべてのTLDがそれに準じているわけではない。

*3:これについては、IPAから発行されている[http://www.ipa.go.jp/security/fy16/reports/pki-utf8string/documents/PKI-part4.pdf:title=PKI における UTF8String 問題に関する調査報告書]に詳しい。

*4:それにしても、[http://xn--wgv71a119e.jp/access/iri_rfc.html:title=この]書き方はう〜ん… ^^;;;