(57)【特許請求の範囲】
【請求項１】
第１の管理サーバが上位ドメイン、第２の管理サーバが下位ドメインに関して、それぞれのホスト名およびドメイン名を管理するネットワークにおいて、
前記第２の管理サーバによって作成された公開鍵と秘密鍵のペアにおける該公開鍵が前記第１の管理サーバに送信され、
受信した公開鍵に対応する秘密鍵が前記送信を行った第２の管理サーバにより所有されていることが検証された場合に、該公開鍵のハッシュ値を基に作成された自己認証ドメイン名をドメイン名として付与され、該第２の管理サーバによって管理される自己認証ドメインを、前記送信にかかる第１の管理サーバが管理するドメインの下位に生成する
ことを特徴とするドメイン管理方法。
【請求項２】
前記第２の管理サーバによって作成された公開鍵のハッシュ値を基に作成された自己認証ドメイン名が、さらに前記第１の管理サーバに送信され、
前記検証と併せて、前記受信した公開鍵から計算したハッシュ値と前記受信した自己認証ドメイン名に対応するハッシュ値とが一致することが検証された場合に、前記自己認証ドメインを生成する
ことを特徴とする請求項１に記載のドメイン管理方法。
【請求項３】
前記自己認証ドメインに設けられたホストに関する所定のホスト情報が、ハッシュ関数によって該自己認証ドメインと対応付けられた公開鍵とペアになる秘密鍵を用いて署名を施された上で、該ホストのホスト名とともに前記第１の管理サーバに送信され、
受信したホスト情報に施された署名が前記受信した公開鍵によって検証された場合に、該ホスト情報とホスト名を前記第１の管理サーバに登録する
ことを特徴とする請求項１または請求項２に記載のドメイン管理方法。
【請求項４】
前記ホスト情報は、少なくとも、前記ホストのアドレスと、該ホストが属する自己認証ドメインを管理する第２の管理サーバによって発行され、該ホスト自身の公開鍵を証明する公開鍵証明書とを含んでいる
ことを特徴とする請求項３に記載のドメイン管理方法。
【請求項５】
前記登録されたホスト情報に対する参照要求を受けた第１の管理サーバが、該要求元に対し、該ホスト情報と、該ホスト情報にかかるホストが属する自己認証ドメインと対応付けられた公開鍵とを送付し、
前記送付された公開鍵は、前記要求元によって、そのハッシュ値が計算され前記自己認証ドメインのドメイン名に対応するハッシュ値と照合されることで該公開鍵自身が検証された上で、前記送付されたホスト情報に施された署名を検証するために用いられる
ことを特徴とする請求項３または請求項４に記載のドメイン管理方法。
【請求項６】
第三者機関が割り当てた、前記第２の管理サーバの管理者に固有のＩＤを、前記自己認証ドメイン名の別名として付与する
ことを特徴とする請求項１から請求項５のいずれかの項に記載のドメイン管理方法。
【請求項７】
前記ＩＤは電子メールアドレスであり、
前記管理者の電子メールアドレスと自己認証ドメイン名との対応関係を宣言するメッセージと、電子メール用の秘密鍵を用いて該メッセージに施された署名と、認証局によって発行され、該秘密鍵とペアになる公開鍵を証明する電子メール用公開鍵証明書とが、該管理者にかかる自己認証ドメインを生成した第１の管理サーバに送信され、
前記電子メール用公開鍵証明書が前記認証局のルートＣＡ公開鍵によって検証され、且つ、受信したメッセージに施された署名が、前記検証された電子メール用公開鍵証明書にかかる公開鍵によって検証された場合に、該電子メールアドレスを前記自己認証ドメインの別名として付与する
ことを特徴とする請求項６に記載のドメイン管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークのドメイン管理方法にかかり、特に、ドメイン名の競合を防止してその一意性を保証するための、信頼できる第三者機関を必要とせずに新たに下位ドメインを作成することが可能なドメイン管理方法に関する。
【背景技術】
【０００２】
ネットワークにおいて安全な一対一通信を実現するためには、通信相手を一意に識別する仕組みと、通信相手の認証情報を取得して、その相手が本当に自分が通信しようとしている相手であることの確認や、暗号化を施した通信を行うことのできる仕組みとが必要である。このような仕組みとして、例えばインターネットにおいては、ＩＰアドレスやＤＮＳ（Domain Name System）、公開鍵証明書などが利用されている（例えば、非特許文献１参照）。
すなわち、インターネットに接続されたコンピュータ１台１台に割り振られた識別番号であるＩＰアドレスや、各コンピュータに名付けられた名前であるホスト名を指定することによって、通信相手となるコンピュータが一意に識別される。また、ＩＰアドレスとホスト名との対応付けは、ＤＮＳによって世界中のコンピュータについてデータベース化されており、このＤＮＳを参照してホスト名からＩＰアドレス（またはその逆）を求めることで、目的とする通信相手の検索が行われる。さらに、各コンピュータの公開鍵が真正であることを証明する公開鍵証明書が信頼できる認証局（ＣＡ；Certificate Authority）によって発行され、実際の通信では上記証明された公開鍵が利用されることで、セキュリティの確保が図られている。
【非特許文献１】“基本的なＤＮＳの仕様  ＲＦＣ１０３４「ドメイン名−概念と機能」”、［ｏｎｌｉｎｅ］、［平成１７年８月４日検索］、インターネット、〈URL: http://www5d.biglobe.ne.jp/~stssk/dns.html〉
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、サーバやパーソナルコンピュータだけでなく、家電製品やセンサなど、さまざまなものがインターネットに接続されるようになるユビキタス社会においては、それらの通信ノードの名前やアドレス、公開鍵等の情報を、各ノードの管理者が自由に登録することができ、また誰でもがそれらノードを参照して安全にアクセスできる環境が整備されることが望ましいと考えられる。
【０００４】
しかしながら、現状インターネットの運用においては、ホスト名はＩＣＡＮＮ（The Internet Corporation for Assigned Names and Numbers）や各国のＮＩＣ（Network Information Center）、ならびにその配下のレジストラと呼ばれる機関が管理を行っているため、ホスト名を登録するにはそれら各機関に申請を行なって認可を受けなければならず、こうした認可なしに誰でも自由にホスト名の登録をするということが認められていない。
また、公開鍵証明書の発行についても、認証局によって所定の認証手続きを経ることが必要とされている。
【０００５】
本発明は上記の点に鑑みてなされたものであり、その目的は、ＩＣＡＮＮや認証局などの第三者機関による認可・認証を必要とすることなく、誰もが名前の一意性を保証された自分専用のドメインを取得して当該ドメインに自由に通信ノードのホスト名やアドレス、公開鍵などの情報を登録でき、その上でそれらの情報を改竄の有無を検証しつつ参照できるドメイン管理方法を提供することにある。
【課題を解決するための手段】
【０００６】
本発明は上記の課題を解決するためになされたものであり、請求項１に記載の発明は、第１の管理サーバが上位ドメイン、第２の管理サーバが下位ドメインに関して、それぞれのホスト名およびドメイン名を管理するネットワークにおいて、前記第２の管理サーバによって作成された公開鍵と秘密鍵のペアにおける該公開鍵が前記第１の管理サーバに送信され、受信した公開鍵に対応する秘密鍵が前記送信を行った第２の管理サーバにより所有されていることが検証された場合に、該公開鍵のハッシュ値を基に作成された自己認証ドメイン名をドメイン名として付与され、該第２の管理サーバによって管理される自己認証ドメインを、前記送信にかかる第１の管理サーバが管理するドメインの下位に生成することを特徴とするドメイン管理方法である。
【０００７】
また、請求項２に記載の発明は、請求項１に記載のドメイン管理方法において、前記第２の管理サーバによって作成された公開鍵のハッシュ値を基に作成された自己認証ドメイン名が、さらに前記第１の管理サーバに送信され、前記検証と併せて、前記受信した公開鍵から計算したハッシュ値と前記受信した自己認証ドメイン名に対応するハッシュ値とが一致することが検証された場合に、前記自己認証ドメインを生成することを特徴とする。
【０００８】
また、請求項３に記載の発明は、請求項１または請求項２に記載のドメイン管理方法において、前記自己認証ドメインに設けられたホストに関する所定のホスト情報が、ハッシュ関数によって該自己認証ドメインと対応付けられた公開鍵とペアになる秘密鍵を用いて署名を施された上で、該ホストのホスト名とともに前記第１の管理サーバに送信され、受信したホスト情報に施された署名が前記受信した公開鍵によって検証された場合に、該ホスト情報とホスト名を前記第１の管理サーバに登録することを特徴とする。
【０００９】
また、請求項４に記載の発明は、請求項３に記載のドメイン管理方法において、前記ホスト情報は、少なくとも、前記ホストのアドレスと、該ホストが属する自己認証ドメインを管理する第２の管理サーバによって発行され、該ホスト自身の公開鍵を証明する公開鍵証明書とを含んでいることを特徴とする。
【００１０】
また、請求項５に記載の発明は、請求項３または請求項４に記載のドメイン管理方法において、前記登録されたホスト情報に対する参照要求を受けた第１の管理サーバが、該要求元に対し、該ホスト情報と、該ホスト情報にかかるホストが属する自己認証ドメインと対応付けられた公開鍵とを送付し、前記送付された公開鍵は、前記要求元によって、そのハッシュ値が計算され前記自己認証ドメインのドメイン名に対応するハッシュ値と照合されることで該公開鍵自身が検証された上で、前記送付されたホスト情報に施された署名を検証するために用いられることを特徴とする。
【００１１】
また、請求項６に記載の発明は、請求項１から請求項５のいずれかの項に記載のドメイン管理方法において、第三者機関が割り当てた、前記第２の管理サーバの管理者に固有のＩＤを、前記自己認証ドメイン名の別名として付与することを特徴とする。
【００１２】
また、請求項７に記載の発明は、請求項６に記載のドメイン管理方法において、前記ＩＤは電子メールアドレスであり、前記管理者の電子メールアドレスと自己認証ドメイン名との対応関係を宣言するメッセージと、電子メール用の秘密鍵を用いて該メッセージに施された署名と、認証局によって発行され、該秘密鍵とペアになる公開鍵を証明する電子メール用公開鍵証明書とが、該管理者にかかる自己認証ドメインを生成した第１の管理サーバに送信され、前記電子メール用公開鍵証明書が前記認証局のルートＣＡ公開鍵によって検証され、且つ、受信したメッセージに施された署名が、前記検証された電子メール用公開鍵証明書にかかる公開鍵によって検証された場合に、該電子メールアドレスを前記自己認証ドメインの別名として付与することを特徴とする。
【発明の効果】
【００１３】
本発明によれば、利用者（第２の管理サーバ）の公開鍵のハッシュ値を基にして新たなドメイン（自己認証ドメイン）のドメイン名（自己認証ドメイン名）が付与されるので、ハッシュ関数の性質により当該自己認証ドメイン名の一意性を保証することができる。すなわち、本アルゴリズムにしたがって生成されたドメイン名は重複することがなく、ドメイン管理を行うための基本的特性を満足するものである。
また、新たな自己認証ドメインが生成されるためには、ハッシュ値をドメイン管理サービス提供者（第１の管理サーバ）側で再計算するとともに、ドメインの生成を要求した利用者が対応する秘密鍵を持っていることを確認するという条件が課されているので、自己認証ドメインと利用者が作成した公開鍵・秘密鍵のペアとの対応関係が正しいものであることを保証することができる。すなわち、ハッシュ値の再計算により自己認証ドメイン名に間違いがないことが検証され、秘密鍵の確認により自己認証ドメインに対する正当な権限を持った利用者からの要求であることが検証される。
【００１４】
このようにして、本発明により、公開鍵と秘密鍵のペアを作成することで利用者が自分専用のドメインを取得でき、ドメイン名のグローバルな一意性を保証するためにドメインの認可や管理権限の委譲を司る第三者機関（ＩＣＡＮＮ等）の存在を必要としないドメイン管理方法を実現することが可能である。
【００１５】
また、請求項３および請求項４に記載の発明によれば、利用者が自己認証ドメインの下にホストコンピュータを設置して、署名付きのホスト情報をサービス提供者のサーバに登録する際に、当該署名は自己認証ドメイン名の基礎となった公開鍵に対応する秘密鍵によりなされたものであり、そのことがドメイン生成時に用いた公開鍵によって検証されるので、自己認証ドメインの所有者だけがホスト情報の登録を行うことを許可される。したがって、不正な登録がなされることを防止して、真の利用者にのみ、自己認証ドメインの管理権限を与えることが可能である。
【００１６】
また、請求項５に記載の発明によれば、自己認証ドメインの下に設置されたホストコンピュータのホスト情報を参照しようとする者に対して、当該ホスト情報とドメインの生成に用いた公開鍵とが送られて、当該公開鍵と当該ホスト情報の内容が検証されるので、その参照者は所望のホスト情報を改竄のおそれなく取得することが可能である。すなわち、当該公開鍵（利用者が所有）は、ハッシュ値を再計算することで参照しようとしている自己認証ドメインと正しく対応するものであることが確認されるため、第三者機関（ＣＡ）に依存することなく、利用者（第２の管理サーバ）は正しい公開鍵を参照者に配布することが可能であり、この公開鍵を使って上記ホスト情報の署名を検証すれば、参照者は参照先の正しいアドレスと公開鍵証明書を取得することが可能である。なお、取得した参照先の公開鍵証明書は、利用者によって発行されたものである。すなわち、ホストコンピュータの公開鍵証明書についても、第三者機関（ＣＡ）による認証なしに発行することが可能となっている。
【００１７】
また、請求項６および請求項７に記載の発明によれば、生成された自己認証ドメインに対して、ハッシュ値に基づく意味のない文字の羅列である自己認証ドメイン名を、利用者（第２の管理サーバの管理者）が既に所有している固有ＩＤ（電子メールアドレスや電話番号等、意味のある文字列）で置き換えることによって、ホストコンピュータの参照方法を簡便化することができる。
【発明を実施するための最良の形態】
【００１８】
以下、図面を参照しながら本発明の実施形態について詳しく説明する。
≪第１の実施形態≫
図１は、本発明の一実施形態によるドメイン管理方法にしたがって管理されるネットワークとその構成要素の一例を示した図である。同図において、サービス提供者ＳＰが運用している管理サーバ１０により管理される上位ドメイン“.selfauthdomain.net”に、利用者Ｕが下位ドメイン“.e7de0088726d91aefeb60885452453f1.selfauthdomain.net”を作成してこれを管理サーバ２０により管理する。利用者Ｕは、ホストサーバ２１ａ〜２１ｄを設置してそれぞれにホスト名“www”、“dvr”、“mp3”、“webcam”を付与し、当該ドメインにおいてこれらホストを稼動させる。各ホストサーバ２１ａ〜２１ｄのホスト情報は、サービス提供者ＳＰの管理サーバ１０に登録され、利用者Ｒのユーザ端末３０によって参照される。
【００１９】
ここで、サービス提供者ＳＰは、さらに上位のドメイン“.net”を管理するＩＣＡＮＮからドメイン“.selfauthdomain.net”に関する管理権限の委譲を受けており、当該ドメインにホスト（例えばwww.selfauthdomain.net）を登録したり、下位ドメインの作成や下位ドメインの管理権限の他者への委譲を行ったりする権限を有しているものとする。また、利用者Ｕは、管理サーバ２０とホストサーバ２１ａ〜２１ｄとからなる家庭内ネットワークを構築しているものとする。なお、上記管理サーバ１０等はインターネット６０に接続され相互にアクセス可能となっている。
【００２０】
図２は、上記のネットワークのドメイン構成を示した図である。ルートドメインの下に“.net”、“.org”、“.com”などのｇＴＬＤ（generic Top Level Domain）、“.jp”などのｃｃＴＬＤ（country code Top Level Domain）が設けられ、それぞれサブドメインを有している。サービス提供者ＳＰが管理するドメイン“.selfauthdomain.net”（サービス用ドメイン４０）は“.net”のサブドメインであり、サービス提供者ＳＰは、サービス用ドメイン４０の下に各利用者専用のサブドメイン（自己認証ドメイン５０ａ、５０ｂ、…）を作成して管理するサービスを提供している。
【００２１】
自己認証ドメイン５０ａ“.e7de0088726d91aefeb60885452453f1.selfauthdomain.net”は利用者Ｕが取得したサブドメインである。ホスト“www.〜”、“dvr.〜”、“mp3.〜”、“webcam.〜”は自己認証ドメイン５０ａに属している。自己認証ドメイン５０ａのドメイン名を構成している文字列「e7de0088726d91aefeb60885452453f1」は、利用者Ｕの公開鍵ｐｋから得られる２進数表記のハッシュ値Ｈ（ｐｋ）を１６進数表記に変換したものである（詳細は後述）。
【００２２】
次に、本実施形態によるドメイン管理方法を、（１）自己認証ドメインの生成、（２）ホスト情報の登録、（３）ホスト情報の参照の３つの段階に分け、図３に示す概念図と図４に示すフローチャートを参照し説明する。
【００２３】
（１）自己認証ドメインの生成
まず、利用者Ｕの管理サーバ２０が公開鍵ｐｋと秘密鍵ｓｋのペアを１つ作成し（ステップＳ１１）、作成した公開鍵ｐｋを所定のハッシュ関数に入力してハッシュ値Ｈ（ｐｋ）を計算する。ハッシュ関数は、与えられた入力に対し固定長の文字列を出力する関数であり、ここではＭＤ５（Message Digest 5）を使用することとする。ハッシュ関数ＭＤ５により得られるハッシュ値は２進数表記された１２８ビットの文字列であるが、管理サーバ２０は、これを１６進数で表記した文字列に変換することによって自己認証ドメイン名を生成する。生成された自己認証ドメイン名は「e7de0088726d91aefeb60885452453f1」（１６進数表記で３２桁）のようであったとする（ステップＳ１２）。
【００２４】
次に、管理サーバ２０は、上記公開鍵と生成した自己認証ドメイン名とをサービス提供者の管理サーバ１０に送信することによって、サービス用ドメイン４０のドメイン名に自己認証ドメイン名を付した“.e7de0088726d91aefeb60885452453f1.selfauthdomain.net”を、利用者Ｕ専用の自己認証ドメイン５０ａとして生成するよう要求を行う（ステップＳ１３）。
【００２５】
要求を受けた管理サーバ１０は、送られた公開鍵ｐｋのハッシュ値Ｈ（ｐｋ）を計算して自己認証ドメイン名と照合することにより、要求された自己認証ドメイン名が公開鍵と正しく対応していることを検証する（ステップＳ１４）。
そしてさらに、管理サーバ１０は、ステップＳ１３の送信を行ったのが利用者Ｕ本人であることを確認するために、送られてきた公開鍵ｐｋに対応する秘密鍵ｓｋを利用者Ｕの管理サーバ２０が所有していること（ＰＯＰ；Proof of Possession）の検証を行う（ステップＳ１５）。具体的には、管理サーバ１０は、乱数を作成してチャレンジメッセージとして管理サーバ２０へ送り、そのメッセージに対して管理サーバ２０に秘密鍵ｓｋで署名Ｓｉｇｓｋを施させた上で返送させる。返送されたメッセージの署名を上記の公開鍵ｐｋを使って検証できれば、ＰＯＰが確認されることになる。
【００２６】
上記の検証に成功すると、管理サーバ１０は、ステップＳ１３の要求にかかる自己認証ドメイン５０ａをサービス用ドメイン４０の下位に生成する（ステップＳ１６）。このようにして、利用者Ｕ（管理サーバ２０）は自分専用のドメインをサービス提供者ＳＰとのやりとりだけで（つまりＩＣＡＮＮ等を介在させることなく）取得することになる。
【００２７】
（２）ホスト情報の登録
次に、生成された自己認証ドメイン５０ａの下に利用者Ｕがホストサーバ２１ｄ（ホスト名“webcam”）のホスト情報を登録する処理について説明する。ここで、ホストサーバ１１ｄは、ＩＰアドレス「12.34.56.78」と自身の公開鍵ｐｋｗｅｂｃａｍとを有しているものとする。なお、公開鍵ｐｋｗｅｂｃａｍは、利用者Ｒのユーザ端末３０とホストサーバ１１ｄとの間で行われる、一般的な公開鍵方式による暗号化通信や認証に利用されるものであって、ここでの目的は、ホストサーバ１１ｄのホスト情報であるこの公開鍵ｐｋｗｅｂｃａｍをユーザ端末３０が正しく参照できるようにすることである。
【００２８】
自己認証ドメイン５０ａを取得した利用者Ｕの管理サーバ２０は、まず、ｐｋｗｅｂｃａｍがホストサーバ１１ｄの公開鍵であることを証明する、秘密鍵ｓｋで署名Ｓｉｇｓｋを施した公開鍵証明書Ｃｅｒｔｓｋ（ｐｋｗｅｂｃａｍ）を作成する。この公開鍵証明書とＩＰアドレスが登録すべきホスト情報である。
【００２９】
管理サーバ２０は次に、上記ホスト情報に秘密鍵ｓｋで署名Ｓｉｇｓｋを施したものを、登録するホスト名“webcam.e7de0088726d91aefeb60885452453f1.selfauthdomain.net”とともに管理サーバ１０へ送信する（ステップＳ２１）。
そして、管理サーバ１０は上記のステップＳ１３で入手済みの公開鍵ｐｋを使って、送られたホスト情報の署名を検証し（ステップＳ２２）、検証に成功したら上記ホスト名と署名付きホスト情報の登録を行う（ステップＳ２３）。なお、ここで署名に使用する秘密鍵として、自己認証ドメインを生成する時に利用した公開鍵ｐｋと対応する秘密鍵ｓｋを使用するようにしたことから、上記の登録を行えるのは秘密鍵ｓｋの真の保有者、すなわち利用者Ｕに限られることとなる。
【００３０】
（３）ホスト情報の参照
上記のようにしてホスト“webcam”のホスト情報の登録が完了すると、利用者Ｒが当該ホスト情報を参照することができる状態となる。その参照方法は次の通りである。
まず利用者Ｒのユーザ端末３０が、ホスト情報を参照しようとしているホストサーバ２１ｄのホスト名“webcam.e7de0088726d91aefeb60885452453f1.selfauthdomain.net”をサービス提供者の管理サーバ１０に送信することによって、ホスト情報の参照要求を行う（ステップＳ３１）。そして管理サーバ１０は、受信したホスト名に対応する上記ステップＳ２３で登録済みのホスト情報、および当該登録の際使用した管理サーバ２０の公開鍵ｐｋを要求元のユーザ端末３０に回答する（ステップＳ３２）。
【００３１】
するとユーザ端末３０は、まず送られた公開鍵ｐｋが管理サーバ２０の正規の公開鍵であることを検証するために、当該取得した公開鍵ｐｋのハッシュ値を計算して、上記要求したホスト名に含まれる自己認証ドメイン名「e7de0088726d91aefeb60885452453f1」と照合する（ステップＳ３３）。そしてその公開鍵ｐｋが正しければ、送られた上記のホスト情報に施されている署名を当該公開鍵ｐｋで検証して（ステップＳ３４）、目的のホストサーバ１１ｄの正しいＩＰアドレス「12.34.56.78」と管理サーバ２０が発行した公開鍵証明書Ｃｅｒｔｓｋ（ｐｋｗｅｂｃａｍ）を取得する（ステップＳ３５）。
ユーザ端末３０は、こうして得られたＩＰアドレスと公開鍵証明書を使って、以降ホスト“webcam”に対するアクセスを行う。
【００３２】
このように、本実施形態によれば、利用者Ｕの管理サーバ２０が作成した公開鍵ｐｋに対してハッシュ値が計算され、このハッシュ値を基にしたドメイン名（自己認証ドメイン名）が新たなドメイン（自己認証ドメイン）に付与される。そして、サービス提供者ＳＰの管理サーバ１０において、ハッシュ値の再計算による自己認証ドメイン名の正しさの検証と、利用者Ｕが公開鍵ｐｋに対応する秘密鍵ｓｋの正当な保有者であることの検証がなされた場合に、管理サーバ１０が管理権限を有するドメインの下位に自己認証ドメインが生成されて、利用者Ｕにその管理権限が委譲される。これにより、第三者機関に認可を受けることなく、利用者専用のドメインを作成することが可能である。
【００３３】
また、ホスト情報を登録する際、自己認証ドメインと対応する秘密鍵ｓｋで当該ホスト情報に署名を行い、対応する公開鍵ｐｋでその検証が行われる。これにより、自己認証ドメインの正当な所有者だけにその管理権限を与えることが可能となっている。
さらにまた、ホスト情報を参照する際、利用者Ｒ（参照者）のユーザ端末３０において公開鍵ｐｋのハッシュ値が再計算されて当該公開鍵の正しさが検証され、その公開鍵を使ってホスト情報の署名が検証される。これにより、第三者機関に依存しないでホスト情報を改竄のおそれなく利用者に配布することが可能である。
【００３４】
≪第２の実施形態≫
次に、本発明による第２の実施形態について図５に示す概念図を用いて説明する。本実施形態は、前述のハッシュ値に基づく自己認証ドメイン名の代わりに電子メールアドレスをドメイン名に利用することで、利用者Ｒがホストの参照を簡便に行えるようにするものである。
まず第１の実施形態と同じ方法で、（１）自己認証ドメインの生成と（２）ホスト情報の登録を行う。
【００３５】
ここで、上記自己認証ドメインを取得した利用者Ｕは、任意のインターネットサービスプロバイダによって割り当てられた電子メールアドレス「ccc@aaa.com」と、当該電子メールアドレスから発信する電子メールに署名をするための電子メール用秘密鍵ｓｋｃｃｃ＠ａａａ．ｃｏｍおよびそれに対応する公開鍵ｐｋｃｃｃ＠ａａａ．ｃｏｍを持っているとする。また、当該公開鍵に対する公開鍵証明書ＣｅｒｔＣＡ（ｐｋｃｃｃ＠ａａａ．ｃｏｍ）が、ルートＣＡと呼ばれる第三者機関によって発行されているものとする。この公開鍵証明書は、誰でも入手可能且つその正当性が保証されているルートＣＡの公開鍵ｐｋＣＡを使うことで、検証することができるものである。
【００３６】
さて、上記（１）、（２）の後、利用者Ｕの管理サーバ２０は、登録された自己認証ドメイン名「e7de0088726d91aefeb60885452453f1」と電子メールアドレス「ccc@aaa.com」との対応付けを宣言する電子メールを、電子メール用秘密鍵ｓｋｃｃｃ＠ａａａ．ｃｏｍで署名Ｓｉｇｓｋ（ｃｃｃ＠ａａａ．ｃｏｍ）を付した上でサービス提供者ＳＰの管理サーバ１０へ送信して、上記自己認証ドメイン名への別名付与を要求する。また、公開鍵証明書ＣｅｒｔＣＡ（ｐｋｃｃｃ＠ａａａ．ｃｏｍ）と管理サーバ２０自身の公開鍵ｐｋ（自己認証ドメイン生成時に使われたもの）も管理サーバ１０へ送られる。
【００３７】
管理サーバ１０は、上記要求に対して、まず送られた公開鍵ｐｋと自己認証ドメイン名「e7de0088726d91aefeb60885452453f1」との対応の検証、および管理サーバ２０のＰＯＰの確認を行う。これは前述した第１の実施形態におけるステップＳ１４およびステップＳ１５の処理と同じである。
次に、管理サーバ１０は、あらかじめ入手しておいたルートＣＡの公開鍵ｐｋＣＡを用いて、送られてきた公開鍵証明書ＣｅｒｔＣＡ（ｐｋｃｃｃ＠ａａａ．ｃｏｍ）を検証して公開鍵ｐｋｃｃｃ＠ａａａ．ｃｏｍを取り出す。そしてその公開鍵により、受信した上記の電子メールの署名を検証し、正しい電子メールの内容を取得する。
【００３８】
こうして自己認証ドメイン名「e7de0088726d91aefeb60885452453f1」と電子メールアドレス「ccc@aaa.com」とが確かに対応していることが確認されると、管理サーバ１０は登録済みのホスト名“webcam.e7de0088726d91aefeb60885452453f1.selfauthdomain.net”の中の自己認証ドメイン名の部分を電子メールアドレスで置き換え、ホスト名、電子メールアドレスのユーザ名、電子メールアドレスのドメイン名を“.-.”で区切った新しいホスト名を“webcam.-.ccc.-.aaa.com.selfauthdomain.net”として登録する。
【００３９】
次に、利用者Ｒが上記の新しいホスト名が登録されたホストサーバ１１ｄのホスト情報を参照する方法は以下のようになる。
ユーザ端末３０が新たなホスト名“webcam.-.ccc.-.aaa.com.selfauthdomain.net”（公開されているのはこのホスト名のみであるものとする）を管理サーバ１０に送信してホスト情報の参照要求を行うと、管理サーバ１０は、第１の実施形態におけるステップＳ３２と同様に、要求されたホスト名に対応する登録済みのホスト情報および管理サーバ２０の公開鍵ｐｋをユーザ端末３０に回答する。また、新しいホスト名を登録する際に使用した電子メール（自己認証ドメイン名と電子メールアドレスとの対応が記述された電子メールで、電子メール用秘密鍵ｓｋｃｃｃ＠ａａａ．ｃｏｍで署名されている）と、公開鍵証明書ＣｅｒｔＣＡ（ｐｋｃｃｃ＠ａａａ．ｃｏｍ）もユーザ端末３０に送信される。
【００４０】
ユーザ端末３０は、送られたこれらの各データに対して順次以下の検証を行っていき、最終的に第１の実施形態の場合と同じく正しく検証されたＩＰアドレス「12.34.56.78」と公開鍵証明書Ｃｅｒｔｓｋ（ｐｋｗｅｂｃａｍ）を取得する。
まず、前述の管理サーバ１０と同様、あらかじめ入手したルートＣＡの公開鍵ｐｋＣＡにより公開鍵証明書ＣｅｒｔＣＡ（ｐｋｃｃｃ＠ａａａ．ｃｏｍ）を検証して公開鍵ｐｋｃｃｃ＠ａａａ．ｃｏｍを取り出し、その公開鍵により上記電子メールの署名を検証して、公開されている上記のホスト名に対応する自己認証ドメイン名「e7de0088726d91aefeb60885452453f1」を取得する。
【００４１】
そして、以降、第１の実施形態におけるステップＳ３３〜ステップＳ３５と同様に、上記得られた自己認証ドメイン名と送られた公開鍵ｐｋとからハッシュ値の計算と照合を行い、当該公開鍵ｐｋが管理サーバ２０の正規の公開鍵であることを検証する。検証に成功したら、上記送信されたホスト情報を当該公開鍵ｐｋで検証することにより、目的とするホストの正しいＩＰアドレス「12.34.56.78」および公開鍵証明書Ｃｅｒｔｓｋ（ｐｋｗｅｂｃａｍ）が得られる。
【００４２】
このように、本実施形態によれば、電子メールアドレスと自己認証ドメイン名との対応付けを行い、その検証を電子メール用秘密鍵による署名を利用して行っている。これにより、自己認証ドメインの簡便な参照が可能となる。
【００４３】
以上、図面を参照してこの発明の一実施形態について詳しく説明してきたが、具体的な構成は上述のものに限られることはなく、この発明の要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。
例えば、利用可能なハッシュ関数は上述したＭＤ５に限定されず、ＳＨＡ−１等他のアルゴリズムによるものであっても構わない。
また、上述の説明ではホスト情報に関わる名前解決システムとしてＤＮＳを前提としたが、他の方式の名前解決システムであってもよい。
【００４４】
また、上述した第２の実施形態では自己認証ドメイン名の別名として電子メールアドレスを利用する場合について説明したが、これは１つの具体例であり、他のＩＤを利用することもできる。すなわち、信頼できる第三者機関によって一意性を保証されて割り当てられたＩＤであって、当該ＩＤと、当該ＩＤの割り当てを受けた者の公開鍵との対応を証明する公開鍵証明書が信頼できる第三者機関によって発行されるのであれば、電子メールアドレス以外にも、電話番号やその他何らかのサービスに係る加入者ＩＤのようなものであってもよい。
さらにまた、別名としての新しいホスト名に挿入された“.-.”は、置き換えられた電子メールアドレスの部分を識別するためのものであって、ホスト名に利用可能な他の文字にすることもできる。
【産業上の利用可能性】
【００４５】
この発明は、ネットワークのドメイン管理システムに用いて好適である。
【図面の簡単な説明】
【００４６】
【図１】本発明の一実施形態によるドメイン管理方法にしたがって管理されるネットワークとその構成要素の一例を示した図である。
【図２】図１のネットワークのドメイン構成および自己認証ドメインの概念を示した図である。
【図３】第１の実施形態におけるホスト情報の登録と参照の方法を示した概念図である。
【図４】第１の実施形態におけるドメイン管理方法を示すフローチャートである。
【図５】第２の実施形態におけるホスト情報の登録と参照の方法を示した概念図である。
【符号の説明】
【００４７】
１０…管理サーバ  ２０…管理サーバ  ２１ａ〜２１ｄ…ホストサーバ  ３０…ユーザ端末  ４０…サービス用ドメイン  ５０ａ、５０ｂ…自己認証ドメイン  ６０…インターネット
【図１】
0004490354.tif 000002
【図２】
0004490354.tif 000003
【図３】
0004490354.tif 000004
【図４】
0004490354.tif 000005
【図５】
0004490354.tif 000006