(57)【要約】【課題】電子メール送信装置及び電子メール受信装置間で公開鍵暗号化方式により電子メールを転送する方法及び装置に関し、既存の認証局による公開鍵証明書を利用せず、その代わりにＩＳＰのサーバを利用することにより簡易に電子メールの送受信を可能にする。【解決手段】ユーザ認証データと公開鍵１αが付加されたトリガメッセージ３を送信側クライアント１Ａから受信し、トリガメッセージ３中のユーザ認証データが認証されたとき、トリガメッセージ３中の公開鍵１αに信頼性を付与して受信側クライアントに送信し、これに応答して、ユーザ認証データと公開鍵１γが付加されたレスポンスメッセージ４を受信側クライアント１Ｂから受信し、レスポンスメッセージ４中のユーザ認証データが認証されたとき、レスポンスメッセージ４中の公開鍵１γに信頼性を付与して送信側クライアント１Ａに送信する。【選択図】図１
2006260490.tif 000002
【特許請求の範囲】
【請求項１】
公開鍵暗号化方式により電子メールを転送するための電子メール転送方法であって、
ユーザ認証データと公開鍵が付加されたトリガメッセージを受信するトリガメッセージ受信ステップと、
該ユーザ認証データを認証するユーザ認証ステップと、
該ユーザ認証ステップにより該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して送信するトリガメッセージ信頼性付与ステップと、
ユーザ認証データと公開鍵が付加されたレスポンスメッセージを受信するレスポンスメッセージ受信ステップと、
該ユーザ認証ステップにより該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して送信するレスポンスメッセージ信頼性付与ステップと、
を有することを特徴とした電子メール転送方法。
【請求項２】
電子メール送信装置及び電子メール受信装置間で公開鍵暗号化方式により電子メールを転送するための電子メール転送装置であって、
ユーザ認証データと公開鍵が付加されたトリガメッセージを該電子メール送信装置から受信するトリガメッセージ受信手段と、
該ユーザ認証データを認証するユーザ認証手段と、
該ユーザ認証手段により該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して該電子メール受信装置に送信するトリガメッセージ信頼性付与手段と、
ユーザ認証データと公開鍵が付加されたレスポンスメッセージを該電子メール受信装置から受信するレスポンスメッセージ受信手段と、
該ユーザ認証手段により該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して該電子メール送信装置に送信するレスポンスメッセージ信頼性付与手段と、
を有することを特徴とした電子メール転送装置。
【請求項３】
請求項２において、
該電子メール送信装置が、
該トリガメッセージを該電子メール転送装置に送信するトリガメッセージ送信手段と、
該電子メール受信装置からのレスポンスメッセージを該電子メール転送装置から取得するレスポンスメッセージ取得手段と、
該レスポンスメッセージ中の公開鍵に信頼性が付与されているか否かを検証するレスポンスメッセージ信頼性付与検証手段と、
該レスポンスメッセージ信頼性付与検証手段が該レスポンスメッセージ中の公開鍵に該信頼性が付与されていることを検証した場合、該電子メール送信装置の私有鍵で電子署名され、該信頼性が付与された該電子メール受信装置の公開鍵により暗号化された電子メールを該電子メール受信装置に送信するメール送信手段と、
を有することを特徴とした電子メール転送装置。
【請求項４】
請求項２において、
該電子メール受信装置が、
該電子メール転送装置から該トリガメッセージを取得するトリガメッセージ取得手段と、
該トリガメッセージ中の公開鍵に信頼性が付与されているか否かを検証するトリガメッセージ信頼性付与検証手段と、
トリガメッセージ信頼性付与検証手段が該トリガメッセージ中の公開鍵に信頼性が付与されていることを検証した場合、該レスポンスメッセージを該電子メール転送装置に送信するレスポンスメッセージ送信手段と、
該電子メール送信装置からの電子メールを、自己の私有鍵で復号化し、さらに該電子署名を該電子メール送信装置の公開鍵で復号化するメール受信手段と、
を有することを特徴とした電子メール転送装置。
【請求項５】
請求項２において、
該トリガメッセージ信頼性付与手段は、該トリガメッセージ中の空欄となっている公開鍵証明書部分に該電子メール送信装置の公開鍵に対する自己の電子署名を付加すると共に、該レスポンスメッセージ中の空欄となっている公開鍵証明書部分に該電子メール受信装置の公開鍵に対する自己の電子署名を付加することを特徴とした電子メール転送装置。
【請求項６】
請求項２において、
該電子メール送信装置及び電子メール受信装置が、各メッセージに同一かつネットワーク内でユニークなメッセージ識別子を付与することを特徴とした電子メール転送装置。
【請求項７】
請求項２において、
該トリガメッセージ信頼性付与手段が、該トリガメッセージのヘッダ部に信頼性付与識別子を付与すると共に、該レスポンスメッセージ信頼性付与手段が該レスポンスメッセージのヘッダ部に信頼性付与識別子を付与することを特徴とした電子メール転送装置。
【請求項８】
請求項２において、
該電子メール送信装置から、その公開鍵と該電子メール受信装置に対し暗号化及び電子署名付きメールの送信を要求する平文とを含むトリガメッセージを受信したとき、該トリガメッセージの公開鍵に信頼性を付与して該電子メール受信装置に送信し、該電子メール受信装置から、その公開鍵と暗号化及び電子署名付きメッセージを含むレスポンスメッセージを受信したとき、該レスポンスメッセージに信頼性を付与して該電子メール送信装置に送信することを特徴とした電子メール転送装置。
【請求項９】
請求項２において、
該電子メール送信装置及び該電子メール受信装置は、それぞれ、相手側の公開鍵をその識別子と共に保管する保管手段と、該保管手段に保管した後、各メッセージを送信するとき、該識別子を該公開鍵の代わりに用いる手段とを有することを特徴とした電子メール転送装置。
【請求項１０】
請求項３又は４において、
電子メール送信装置及び電子メール受信装置が、メッセージを指定するためのメッセージ作成画面を有するメッセージ作成ユーザインタフェース、又はメッセージ状態を表示するためのメッセージ状態表示画面を有するメッセージ管理インタフェースを備えたことを特徴とした電子メール転送装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子メール転送方法及び装置に関し、特に、電子メール送信装置及び電子メール受信装置間で公開鍵暗号化方式により電子メールを転送するための電子メール転送方法及び装置に関する。
【背景技術】
【０００２】
従来、インターネット上で電子メールの平文を暗号化する方式として、暗号化と復号化に共通の鍵を使用する共通鍵暗号化方式と、暗号化と復号化にそれぞれ違う鍵を使用する公開鍵暗号化方式が知られている。ここで、平文とは、電子メールの暗号化される前のメッセージをいう。
【０００３】
上記共通鍵暗号化方式では、電子メール送信装置(以下、メール送信ユーザ又はクライアントと称することがある。)と電子メール受信装置(以下、メール受信ユーザ又はクライアントと称することがある。)とが共通鍵を予め所有して、メール送信ユーザは平文を共通鍵で暗号化した暗号文をメール受信ユーザに送信し、メール受信ユーザは暗号文を共通鍵で復号化する。これにより、メール送信ユーザからメール受信ユーザへの送信過程での「情報漏洩」を防止する。しかしながら、不正な第三者による「なりすまし」や、「改竄」を防ぐための電子署名が困難であり、共通鍵の安全な配送が必要となる。
【０００４】
上記問題に対処するため、公開鍵暗号化方式は、異なる2つのペアとなる鍵を作成し、暗号化と復号化とで異なる鍵を使用する。そして、一方の鍵を送信相手に公開する公開鍵、他方の鍵を自分だけが手元で保管する私有鍵(秘密鍵とも言う。)とする。公開鍵で暗号化された暗号文は、ペアとなる私有鍵でしか復号化できず、私有鍵で暗号化した暗号文はペアとなる公開鍵でしか復号化できない。また、上記公開鍵と私有鍵は、一方の鍵の情報から、他方の鍵を作成することは、数学的に困難であって事実上不可能となっている。
【０００５】
例えば、公開鍵暗号化方式による暗号化電子メールをメール送信ユーザがメール受信ユーザに対して送信する際には、メール送信ユーザはメール受信ユーザの公開鍵で平文を暗号文に暗号化し、メール受信ユーザに電子メールを送信する。電子メールを受信したメール受信ユーザは自分の私有鍵で暗号文を復号化して元の平文を得ることができる。このため、電子メールの送信過程で、不正な第三者が電子メールを盗聴したとしても、復号化するための私有鍵を有していなければ、平文を得ることができないので、不正な第三者に電子メールのメッセージの漏洩が防止される。
【０００６】
また、公開鍵暗号化方式による電子署名付きメールをメール送信ユーザがメール受信ユーザに対して送信する際には、メール送信ユーザが、平文を或るハッシュ関数に掛けてハッシュ値(以下、ダイジェストと言う。)を作成し、該ダイジェストをメール送信ユーザの私有鍵で暗号化して電子署名にし、この電子署名を平文に付加してメール受信ユーザに電子メールを送信する。この電子署名付きメールを受信したメール受信ユーザは、メール送信ユーザの公開鍵で電子署名を復号化し、これとは別に平文から作成したダイジェストと一致するか否かを確認する。
【０００７】
なお、上述したように、平文からダイジェストを作成した場合、理論的に二つの異なる平文から同一のダイジェストが得られる可能性があるが、実際には二つの平文が偶然同一のダイジェストとなる確率は極めて低く、また、或るダイジェストから平文の作成は不可能であり、また、メール送信ユーザの公開鍵で復号化できるダイジェストを作成できるのは、唯一、該メール送信ユーザの私有鍵だけである。
【０００８】
したがって、上述のダイジェストの比較結果が一致した場合、電子メールを受信したメール受信ユーザは、不正な第三者がなりすまして発信したものではなく、メール送信ユーザが間違いなく発信した電子メールであり、更にメール送信の過程で内容が改竄されていないことが分かる。
【０００９】
このため、公開鍵暗号化方式による暗号化及び電子署名付き(以下、「暗号化・電子署名付」と称することがある。)メールでは、セキュリティ上の脅威(「なりすまし」、「情報漏洩」、「改竄」)を防止して、通信相手と安全に電子メールを送受信できる。
【００１０】
ここで、公開鍵暗号化方式による暗号化・電子署名付メールを送受信する手順について図19を参照して詳しく説明する(インターネット・セキュリティ教科書<上>; 出版社: IDGジャパン ; ISBN:4872804759 の217ページを参照。)。
【００１１】
クライアント（メール送信ユーザ)91Aからクライアント（メール受信ユーザ）91Bに対して、暗号化・電子署名付メールを送る際には、メール送信ユーザ91Aが、平文92ａをメッセージ・ダイジェスト関数92ｂに掛けてダイジェスト(メッセージ・ダイジェスト)92ｃを作成する(ステップS91)。メール送信ユーザ91Aは自分の私有鍵91βでダイジェスト92ｃを暗号化して電子署名92ｄにする(ステップS92)。
【００１２】
メール送信ユーザ91Aは、さらに、平文(メッセージ)92ａと電子署名92ｄを共通鍵91εで暗号化して暗号文92ｅを作成し(ステップS93)、かつ、メール受信ユーザ91Bの公開鍵91γで共通鍵91εを暗号化して共通鍵91ζを作成する(ステップS94)。
【００１３】
そして、メール送信ユーザ91Aは暗号文92ｅに共通鍵91ζを付加して電子メール92ｇを作成し(ステップS95)、この電子メール92ｇをメール受信ユーザ91Bに送信する。
【００１４】
一方、電子メール92ｇを受信したメール受信ユーザ91Bは、自分の私有鍵92δで暗号化された共通鍵91ζを共通鍵91εに復号化し(ステップS96)、この共通鍵91εにより暗号文92ｅを平文92ａと電子署名92ｄに復号化する(ステップS97)。
【００１５】
メール受信ユーザ91Bは、平文92ａを上記メッセージ・ダイジェスト関数92ｂに掛けてダイジェスト92ｃ1を作成し(ステップS98)、このダイジェスト92ｃ1と、これとは別に、メール送信ユーザ91Aの公開鍵91αにより電子署名92ｄをダイジェスト92ｃ2に復号化し(ステップS99)、復号化したダイジェスト92ｃ2と比較して同じものか否かを検証する(ステップS100)。
【００１６】
なお、上述した説明では、メール送信ユーザ91Aは、平文92ａをメール受信ユーザ91Bの公開鍵91γで直接暗号化するのではなく、この電子メールの送信のために一時的な共通鍵91εを作成し、この共通鍵91εで平文を暗号化すると共に、メール受信ユーザ91Bの公開鍵で暗号化した共通鍵91εを電子メールへ埋め込んでメール受信ユーザ91Bに送信するようにしている。
【００１７】
これは、公開鍵暗号化方式による暗号化/復号化は、共通鍵暗号化方式に比べて処理が重く時間がかかるので、長い平文全体を公開鍵暗号化方式で暗号化せずに、上記の共通鍵91εをメール受信ユーザ91Bの公開鍵91γで暗号化して、処理の高速化を図っている。本質的には、メール受信ユーザ91Bの公開鍵91γで暗号化を行っていることと変わらない。
【００１８】
なお、上述した暗号化・電子署名付メールは、平文の暗号化と電子署名付加とを組み合わせて、例えば、平文に電子署名を付加したものを暗号化して作成する。したがって、暗号化電子メール、又は、電子署名付きメールは、暗号化・電子署名付メールのサブセットとして作成できる。
【００１９】
ところで、メール送受信ユーザが公開鍵暗号化方式により暗号化・電子署名付メールを作成するためには、メール送受信ユーザはお互いの相手の公開鍵を予め取得して、取得した公開鍵とその所有者の真正性を確認する必要がある。
【００２０】
しかしながら、公開鍵と私有鍵のペア自体はだれでも作成可能であり、不正な第三者が正当なメール送受信ユーザになりすまして公開鍵を公開する虞がある。これに対処するため、信頼できる第三者機関として中立的な立場から電子取引等で使用される公開鍵の管理を行ったり、要求された公開鍵に認証局自身の署名を付けた証明書を発行し、公開鍵とその所有者の真正性を保証する認証局が必要となる。
【００２１】
これにより、メール送受信ユーザは公開鍵を登録して、認証局からメール送受信ユーザの公開鍵と各種属性(名前や所属組織や電子メールアドレス等)が記載された公開鍵証明書を発行してもらうことができる。そして、メール送受信ユーザは認証局から発行された公開鍵証明書により、確かに相手の正当な公開鍵及び公開鍵証明書であることを確認できる。
【００２２】
なお、この認証局、公開鍵暗号化技術、公開鍵証明書、およびそれらが実現している機能、等を含めたインフラストラクチャ全般を指してPKI(Public Key Infrastructure; 公開鍵基盤)という。
【００２３】
上述したことをまとめると、メール送受信ユーザが暗号化・電子署名付メールを送受信するためには、事前に、メール送受信ユーザが認証局から各々の公開鍵証明書を取得することと、メール送受信ユーザが相手の公開鍵証明書を取得することが必要になる。
【００２４】
そして、電子メールの送受信時に、メール送受信ユーザが自分の私有鍵と相手の公開鍵を使用して、電子メールを暗号化及び電子署名した暗号化・電子署名付メールを送受信することが必要になる。
【００２５】
尚、メール送受信ユーザが暗号化メールを送受信する場合は、事前に、メール受信ユーザが、認証局から公開鍵証明書を取得し、メール送信ユーザが該公開鍵証明書を得ればよい。また、メール送受信ユーザが電子署名付きメールを送受信する場合は、事前に、メール送信ユーザが、認証局から公開鍵証明書を取得し、メール受信ユーザが、該公開鍵証明書を得ればよい。
【００２６】
このような認証局、公開鍵証明書及び証明書失効リストについて図20及び図21を参照して以下に具体的に説明する。
【００２７】
図20は認証局(CA)93が公開鍵証明書を発行して、メール送受信ユーザが暗号化・電子署名付メールを送受信するまでの過程を示している。図21は公開鍵証明書フォーマット97Ｆ及び証明書失効リスト(Certificate Revocation List)フォーマット99Fを示す。これは、ITU(International Telecommunications Union：国際電気通信連合電気通信標準化部門)が定めたフォーマット(X.509Version3)で、一般的によく使用されている。尚、証明書失効リストについては後述する。
【００２８】
図20において、認証局93は公開鍵証明書97の発行を受ける人又は組織（クライアント９１C）の要請に応じて公開鍵証明書97を発行する。認証局93は公開鍵証明書97を公開するためのサーバ(リポジトリという。)94を有している。認証局93と認証局95とは相互認証の関係になっている。認証局93の公開鍵証明書97の発行を受ける人又は組織が申請すると(ステップS101)、認証局93は申請に応じて公開鍵証明書97を発行する(ステップS102)。
【００２９】
認証局93はリポジトリ94で発行公開鍵証明書97を不特定多数に公開する(ステップS103)。
【００３０】
このようにして、認証局93からメール送信ユーザ(クライアント)91A及びメール受信ユーザ(クライアント)91Bに公開鍵証明書９７がそれぞれ発行されると、メール送信ユーザ91A及びメール受信ユーザ91Bは、それぞれの相手の公開鍵91γ及び公開鍵91αを取得する。例えば、メール送信ユーザ91Aはメール受信ユーザ91Bのユーザ名でリポジトリ94を検索して取得する(ステップS105)。または、メール送信ユーザ91Aはメール受信ユーザ91Bから取得する(矢印Y)。同様に、メール受信ユーザ91Bはメール送信ユーザ91Aのユーザ名でリポジトリ94を検索して取得する(ステップS106)。または、メール受信ユーザ91Bはメール送信ユーザ91Aから取得する(矢印X)。
【００３１】
次に、メール送受信ユーザ91A,91Bが相手の公開鍵をそれぞれ取得すると、メール送信ユーザ91Aはメール受信ユーザ91Bに公開鍵暗号化方式により暗号化及び電子署名した電子メールを送信することができる。
【００３２】
なお、認証局93は公開鍵証明書97の申請受け付けを公開鍵証明書97の信頼性のレベルに応じて電子受付、郵送、申請者が出向くことを必要とすると共に、住民票、登記簿謄本、 印鑑証明の他の証明書の添付も必要となる。
【００３３】
例えば、多額の金銭の授受が伴うような企業間の電子商取引等で公開鍵証明書97を使用する場合には、より高いレベルの信頼性を有する公開鍵証明書97が必要となる。
【００３４】
そして、認証局93は申請者の申請を審査し、そのレベルに応じて公開鍵証明書97を発行するとともに、発行された公開鍵証明書97を管理する。
【００３５】
また、認証局93は、リポジトリ94で発行公開鍵証明書97を不特定多数に公開すると同時に証明書失効リストやルート証明書(後述)も公開している。なお、図20中のLDAP(Lightweight Directory Access Protocol)は、リポジトリ94へアクセスするために一般的に最もよく使用されているプロトコルである。
【００３６】
また、認証局93が他の認証局95と相互認証の関係になっている場合、一つの認証局93に公開鍵証明書97を登録した送受信ユーザは認証局93,95間で暗号化・電子署名付メールを送受信できるようになっている。
【００３７】
認証局93の機能をまとめると以下となる。
認証局の機能定義
(1)公開鍵証明書申請受付け
証明書の信頼性のレベルに応じた電子受付け、 郵送、申請者が出向く、 他の証明書の添付(住民票、 登記簿謄本、 印鑑証明)
証明書の信頼性のレベルに応じた審査機能
(2)公開鍵証明書の発行
(3)公開鍵証明書の管理
(4)公開鍵証明書の公開
リポジトリ(PKIに関する必要な情報(証明書,CRL,ルート証明書)を公開するサーバ)94の管理(LDAP)
公開鍵証明書97の公開、証明書失効リスト99の公開
(5)公開鍵証明書失効受付け
公開鍵証明書97には有効期間97bが記載されているが、それとは別に公開鍵証明書97が無効になったこと(盗難、対象ユーザの信頼性低下等)を知らせる方法。(証明書失効リスト; CRL) 
(6)他の認証局93との相互認証
認証局93と認証局95が相互認証の関係にある。
【００３８】
次に、公開鍵証明書97について詳しく説明する。
【００３９】
図21(a)において、公開鍵証明書フォーマット97Fはバージョン971から暗号文987までのフィールドを備えている。認証局93は公開鍵証明書97の最後の署名97ｄに電子署名を付加しているので、不正な第三者が「なりすまし」や「改竄」ができないようになっている。認証局93の電子署名は、公開鍵証明書97のバージョン971から拡張984までのフィールド値をハッシュ関数101に掛け、その結果を認証局93の私有鍵93κで暗号化して暗号文103を作成して電子署名としている。
【００４０】
認証局93は電子署名97dを付加した公開鍵証明書97をメール送受信ユーザ91A,91Bに発行する。
【００４１】
メール送受信ユーザ91A,91Bは認証局９３または通信相手から公開鍵証明書９７を取得すると、取得した通信相手の公開鍵証明書97に付加されている電子署名が正当か否かを検証する必要がある。そのため、メール送受信ユーザ91A,91Bは、「認証局自身の公開鍵証明書」(以下、ルート証明書と言う。)を予め入手する必要がある。
【００４２】
尚、予め取得したルート証明書も、そのフィンガープリント(拇印; 証明書をハッシュ関数に通した短い固定長の数値)と、Webサイト等で公開されているフィンガープリントとを、例えば、目視で一致を検証(図20の署名検証)する必要がある。上述した２つのフィンガープリントが一致した場合、メール送受信ユーザ91A,91Bはルート証明書を信頼性することができる。
【００４３】
また、有名な認証局93のルート証明書は、ソフトウェア(メールクライアントソフトウェア等)にバンドルされているので、メール送受信ユーザが該ルート証明書をわざわざ別途取得する必要はない。
【００４４】
次に、証明書失効リスト99について詳しく説明する。
【００４５】
証明書失効リスト99とは、公開鍵証明書97に記載されている有効期間以外の何らかの理由(例えば、盗難,対象ユーザの信頼性低下等)により、公開鍵証明書97が無効になった場合、そのことを広く知らせるリストである。
【００４６】
図21(b)において、証明書失効リストフォーマット99Fは、アルゴリズム991から暗号文1000までのフィールドを備えており、フォーマット99Fの最後に、公開鍵証明書フォーマット97Fと同様に、認証局93の電子署名が付加されている。
証明書失効リスト99には、無効化された証明書の通し番号996のリストが記載されている。
【００４７】
以下に図21(a)及び(b)にそれぞれ示す公開鍵証明書97と証明書失効リスト99の各フィールドを詳述する。
X.509 Ver3公開鍵証明書97
(1)バージョン(Version)971
(2)証明書通し番号(SerialNumber)972
発行認証局93毎に一意の整数値。証明書と1対1に対応。
(3)署名アルゴリズム識別子(Signature algorithm identifier)97ａ
本公開鍵証明書97の最後へ付加されている認証局93の署名97ｄのアルゴリズム973の識別子とその関連パラメータ974。後述の署名フィールド97ｄ内のアルゴリズム985とパラメータ986と同じ値。
(4)発行者名(Issuer name)975
この公開鍵証明書97を作り署名した認証局93の名前(X.500名)。X.500名とは、ツリー構造を有するデータベースであるX.500ディレクトリ上のオブジェクトを一意に識別する名前。例えば、{C=jp,O=組織名, CN=認証局93の名前}のようになる。C: Country; 国／O: Organization;組織／CN: Common Name; 一般名。
(5)有効期間(Period of validity)97ｂ
公開鍵証明書97の有効期間の始まりと終わり。
(6)ユーザ名(Subject name)978
ユーザのX.500名。例えば、{C=jp,O=組織名, CN=ユーザ名, E=ユーザの電子メールアドレス}のようになる。E: E-mail address。
(7)ユーザ公開鍵情報(Subject’s public-key information)97ｃ
ユーザの公開鍵981、及びこの鍵981が解くアルゴリズム979の識別子とその関連パラメータ980。
(8)発行者一意識別子(Issuer Unique Identifier)982
同じX.500名が異なる組織に再利用された場合に、発行認証局93を一意に識別するのに用いる。この識別子の使用はまれである。
(9)ユーザ一意識別子(Subject Unique Identifier)983
選択フィールド。X.500名が異なるユーザに再利用された場合に、ユーザを一意に識別するのに用いる。この識別子の使用はまれである。
(10)拡張984
各種拡張フィールド
(11)署名97ｄ
本公開鍵証明書97の認証局93による署名。署名のアルゴリズム985の識別子とその関連パラメータ986は、上述の署名アルゴリズム識別子97ａと同じ値。
証明書失効リスト99
(1)署名アルゴリズム識別子99ａ
本証明書失効リスト99の最後に付加されている認証局93の署名99ｃのアルゴリズム991の識別子とその関連パラメータ992。後述の署名99ｃフィールド内のアルゴリズム998とパラメータ999と同じ値。
(2)発行者名993
この証明書失効リスト99を作り署名した認証局93の名前(X.500名)。
(3)更新日994，995
この更新日994は、本証明書失効リスト99の発行日時。次の更新日995は、次の証明書失効リスト99の発行予定日。
(4)無効化された署名99ｂ
無効化されたユーザの公開鍵証明書97の通し番号996と無効化の日付997。通し番号996によって、一意に公開鍵証明書97を識別可能。
(5)署名99c
本証明書失効リスト99の認証局93による署名99ｃ。署名99ｃのアルゴリズム998の識別子とその関連パラメータ999は、上述の署名アルゴリズム識別子99ａと同じ値。
【００４８】
なお、認証代行サーバは、サービス提供時、所望のサービスに対応したサービスプロバイダの暗号用公開鍵をクライアントへ配送し、クライアントから受け取った暗号化された情報をプロバイダへ転送し、クライアントは、プロバイダへ送信すべき情報を認証代行サーバから受け取った暗号用公開鍵を用いて暗号化し、この暗号化された情報を認証代行サーバへ送信し、プロバイダは、認証代行サーバから受け取った暗号化された情報を暗号用秘密鍵を用いて復号化する認証代行方法がある(例えば、特許文献1参照。)。
【特許文献１】特開2001−134534号公報
【発明の開示】
【発明が解決しようとする課題】
【００４９】
しかしながら、図２０に示した従来技術の場合には、PKIは企業間の電子商取引等のために活用されていても、ISP(インターネット・サービス・プロバイダ)のメール送受信ユーザ（以下、単にユーザと言うことがある。）91A,91Bが暗号化及び電子署名付メールを気軽に知り合いに送受信するためには以下のような問題がある。
【００５０】
第１に、ISPにすでに加入しているユーザ91A,91Bは、認証局93の公開鍵証明書97を必要とするため、ユーザ91A,91Bの双方が公開鍵証明書97の信頼性のレベルに応じた作業手間及び発行手数料が掛かる。したがって、ユーザ91A,91Bが自分の都合で暗号化・電子署名付メールを送信したい場合でも、相手ユーザ91A,91Bにも認証局93の公開鍵証明書97の発行コスト等を負担してもらわなければならない。
【００５１】
第2に、認証局93は公開鍵証明書97を管理しているため、公開鍵証明書97の管理コストが掛かる。すなわち、認証局93は公開鍵証明書97をリポジトリ94に公開すると共に、任意の人物に対する検索サービスを提供しており、認証局93では公開鍵証明書97の管理及び検索サービスのコストが発生する。したがって、認証局93はユーザ91A,91Bに手数料を請求することになる。
【００５２】
第3に、ISPのユーザ91A,91Bは個人情報を多数の場所に分散化するリスクを負うことになる。ユーザ91A,91Bは認証局93に公開鍵を登録すると、公開鍵が不特定多数に公開される。このため、ユーザ91A,91Bは個人情報が漏洩する危惧からISPと別の組織に自分の個人情報を預けることを躊躇する傾向がある。
【００５３】
また、PKＩは証明書失効に関して以下の問題がある
第1に、認証局93はユーザ91A,91Bの申告に基づいて公開する証明書失効リスト99により該当する公開鍵証明書97を失効させるが、該証明書失効リスト99は公開鍵取得済みユーザ91A,91Bに必ずしもリアルタイムに反映される保証がない。
【００５４】
第2に、上述とは逆に、証明書失効リスト99は、不特定多数のユーザに広く公開されており、ユーザ91A,91Bは、自分の信用が低下したことが、自分と何ら全く関係がない他者(公開鍵取得済みユーザでも何でもない。)にも公開されてしまうというプライバシー上の問題もある。
【００５５】
上述した証明書失効の問題点は、認証局93が公開鍵証明書97を管理していても、ユーザ91A,91Bが誰に公開鍵証明書97を公開すれば良いか、あるいは、公開鍵証明書97を誰が取得したのか、にまで認証局93が管理できないために発生する問題である。認証局93が管理できない理由は、管理コスト上、又は、技術上の問題(標準化がされていないことも含めて)が考えられる。
【００５６】
ところで、ISP(Internet Service Provider)は、ユーザ91A,91Bに対してインターネットへの接続環境を提供し、電子メール及びこの電子メールを一時的に保管するメールボックスを提供する。上記ISPは、ユーザ91A,91Bのサービス加入の手続きの過程において、ユーザ91A,91Bの住所を郵送によって確認したり、ユーザ91A,91Bの与信情報をクレジットカード番号によって確認したりする。また、上述の過程で、ISPは、ユーザ91A,91Bがネットワークに接続するためのパスワードや、メールボックスを提供するメールサーバに接続するためのパスワードをユーザ91A,91Bに送付する。
【００５７】
ここで、ISPのユーザ認証とは、上述したユーザの確認された個人情報に基づいて、ISPが発行したユーザIDとパスワードを利用した認証機構を指す。
【００５８】
上述したISPのユーザ認証は、ISPのユーザ91A,91Bがインターネットにより電子メールを送受信するとき、ISPのサーバがユーザ認証データ（ユーザIDとパスワード）により行われており普及している。
【００５９】
そこで、本発明は、電子メール送信装置及び電子メール受信装置間で公開鍵暗号化方式により電子メールを転送するための電子メール転送方法及び装置において、既存の認証局による公開鍵証明書を利用せず、その代わりにISPのサーバを利用することにより簡易に電子メールの送受信を可能にすることを課題とする。
【課題を解決するための手段】
【００６０】
解決方針
第１に、図19に示す従来の技術と同様にISPのサーバも含めてユーザ91A,91B以外のネットワーク系路上は全ての範囲に渡り暗号化されていること。
【００６１】
第2に、ユーザ91A,91Bは、ISPに新たな個人情報を預ける必要がないこと。すなわち、ユーザ91A,91Bが認証局93へ自分の公開鍵証明書97を証明してもらう手間と同じことが発生しないようにする。
【００６２】
第3に、ISPは、ユーザ91A,91Bの公開鍵を管理しないこと。すなわち、既に有しているユーザ91A,91Bの認証データ以外に新たなデータベースを設置することによるISPのコスト増を抑える。認証局93の公開鍵証明書97の管理コストと同様のコストがISPに発生しないようにする。また、ユーザ91A,91Bが新たな個人情報をISPへ預けないで済むようにする。
【００６３】
第4に、ISPのユーザ認証失効と同時に公開鍵も失効すること。すなわち、ISPは、ユーザ91A,91Bの公開鍵を管理せず、メール送受信の度に認証するので、リアルタイムにユーザ91A,91Bが信頼できるかどうかを他のユーザ91A,91Bへ反映することができる。また、ユーザ91A,91B間のメール送受信の意図をトリガとしてユーザ認証するので、ユーザ91A,91Bと全く関係がない他者へ広くユーザ91A,91Bの信頼性が公開されることはない。
【００６４】
第5に、ユーザ91A,91Bは従来の公開鍵暗号化方式と同様の手順でメール送受信できること。すなわち、ユーザ91A,91Bが認証局93へ自分の公開鍵証明書97を証明してもらう手間が発生しない代わりに、他の手間が増加することを抑える。
(1)上記の課題を解決するため、このような解決方針に基づき、本発明に係る電子メール転送方法は、公開鍵暗号化方式により電子メールを転送するための電子メール転送方法であって、ユーザ認証データと公開鍵が付加されたトリガメッセージを受信するトリガメッセージ受信ステップと、該ユーザ認証データを認証するユーザ認証ステップと、該ユーザ認証ステップにより該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して送信するトリガメッセージ信頼性付与ステップと、ユーザ認証データと公開鍵が付加されたレスポンスメッセージを受信するレスポンスメッセージ受信ステップと、該ユーザ認証ステップにより該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して送信するレスポンスメッセージ信頼性付与ステップと、を有することを特徴としている。
【００６５】
すなわち、本発明の電子メール転送方法は、まず、トリガメッセージ受信ステップでは、ユーザ認証データと公開鍵が付加されたトリガメッセージを受信する。ユーザ認証ステップでは、ユーザ認証データを認証する。トリガメッセージ信頼性付与ステップでは、ユーザ認証ステップにより該トリガメッセージ中のユーザ認証データが認証されたとき、トリガメッセージ中の公開鍵に信頼性を付与して送信する。レスポンスメッセージ受信ステップでは、ユーザ認証データと公開鍵が付加されたレスポンスメッセージを受信する。レスポンスメッセージ信頼性付与ステップでは、ユーザ認証ステップによりレスポンスメッセージ中のユーザ認証データが認証されたとき、レスポンスメッセージ中の公開鍵に信頼性を付与して送信する。
【００６６】
このような、上記本発明の原理を図1及び図2を参照して以下に具体的に説明する。
【００６７】
図1において、メール送信ユーザは、クライアント1Aを使用し、メール受信ユーザは、クライアント1Bを使用する。ここでのメール送信ユーザは、最終的に暗号化・電子署名付メールを送信するユーザを指し、メール受信ユーザは、最終的に暗号化・電子署名付メールを受信するユーザを指しており、それまでの過程において、メール送信ユーザ及びメール受信ユーザは、トリガメッセージ3(図2(ａ)参照)及びレスポンスメッセージ4(同図(b)参照)を送受信する。
【００６８】
トリガメッセージ3はヘッダ部を有しており、ユーザ認証データ及び公開鍵1αが付加されている。同様に、レスポンスメッセージ4はヘッダ部を有しており、ユーザ認証データ及び公開鍵1γが付加されている。
【００６９】
図1において、ISP6が管理する電子メール転送装置としてのサーバ5は、メール送受信ユーザに対してのメールボックスを有し、メール送受信ユーザからのアクセスに対し、ユーザ認証を行う。サーバ5は、従来技術におけるメールサーバ及び認証サーバ相当の機能を具備している。
【００７０】
なお、従来技術においてメールサーバは、メール送受信プロトコルであるsendmailを扱うsendmailサーバ、及び、電子メールをスプールしているシステムからメールを読み出すプロトコルであるPOP(Post Office Protocol)を扱うPOPサーバであることが多い。また、POPの代わりにIMAP(Internet Message Access Protocol)も使用する場合もある。
【００７１】
なお、図1において、上記のメールサーバ、認証サーバは、単体のサーバとして記載しているが、複数のサーバによって実現してもよい。
【００７２】
次に、クライアント1A及びクライアント1B間でのメッセージ送受信シーケンスを表すステップS1〜S7に沿って説明する。なお、以下、ステップS1〜S7において、メール送信ユーザ及びメール受信ユーザが行う処理は、実際には電子的にそれぞれクライアント1A及び1Bが行う。
【００７３】
ステップS1：メール送信ユーザは、予めまたは一連の手順開始時に公開鍵1α及び私有鍵１βを作成する。メール送信ユーザは、メール受信ユーザの公開鍵1γを得るためにトリガメッセージ3をサーバ5に送信する。その際、メール受信ユーザがメール送信ユーザの電子署名を検証することができるように、メール送信ユーザは、メール送信ユーザの公開鍵1αを添付する。またその際、ISP6からのユーザ認証を受けるために、メール送信ユーザは、ユーザ認証データ7を同時に送信する。
【００７４】
ステップS2：ISP6のサーバ5は、メール送信ユーザのユーザ認証データを、ISP6のユーザ認証データ7と比較することによりユーザ認証し、ステップS1のトリガメッセージ3中の公開鍵1αに対して信頼性を付与する(図1の付記”信”)。
【００７５】
尚、サーバ5は、ユーザ認証結果が正当であった場合の信頼性の付与を、一連の手順のメール送受信の度にトリガメッセージ3に対して行う。
【００７６】
尚、信頼性付与の方法としては、例えば、サーバ5がISP6の私有鍵による電子署名をトリガメッセージ3に対して付加する方法がある。信頼性付与の方法は、本手法に限定するものではない。
【００７７】
ステップS3：メール受信ユーザがトリガメッセージ3を取得する。メール受信ユーザは、トリガメッセージ3中の公開鍵1αの信頼性が保証されているか否かを検証する。検証の結果、正当ならば、本メール送受信に関して信頼性が証明されているメール送信ユーザの公開鍵1αをメール受信ユーザが得る。
【００７８】
尚、トリガメッセージ3を取得する際、メール受信ユーザは、ISP6からのユーザ認証を受けるために、ユーザ認証データをサーバ５に同時に送信する。
【００７９】
尚、メール送受信ユーザは、上記検証を、例えば、トリガメッセージ3に付加されているISP6の電子署名をサーバ５の公開鍵で復号化することによって行う。検証の方法は、本手法に限定するものではない。
【００８０】
ステップS4：メール受信ユーザは、予めまたは一連の手順開始時に公開鍵1γ及び私有鍵1δを作成する。メール受信ユーザが、メール受信ユーザの公開鍵1γを含むレスポンスメッセージ4を送信する。その際、ISP6からのユーザ認証を受けるために、メール受信ユーザは、ユーザ認証データを同時に送信する。
【００８１】
ステップS5：ISP6のサーバ5は、上記ステップS4におけるユーザ認証データと、ISP6の認証データ7とを比較してユーザ認証することにより、上記ステップS4のメール受信ユーザのレスポンスメッセージ４に対して信頼性を付与する。
【００８２】
尚、サーバ5は、ユーザ認証結果が正当であった場合の信頼性の付与を、一連の手順のメール送受信の度にレスポンスメッセージ4に対して行う。
【００８３】
ステップS6：メール送信ユーザがレスポンスメッセージ4を取得する。メール送信ユーザは、レスポンスメッセージ4中の公開鍵１γの信頼性が保証されているか否かを検証する。検証の結果、正当ならば、本メール送受信に関して信頼性が証明されているメール受信ユーザの公開鍵1γをメール送信ユーザが得る。
【００８４】
尚、レスポンスメッセージ4を取得する際、メール送信ユーザは、ISP6からのユーザ認証を受けるために、ユーザ認証データを同時に送信する。
【００８５】
ステップS7：メール送信ユーザは、自己の私有鍵1βで電子署名され、以て信頼性が付与されたメール受信ユーザの公開鍵1γで暗号化された暗号化・電子署名付メールを送信する。
【００８６】
したがって、上述の手順をクライアント及びサーバが行うことによって、上述の解決の方針の条件を満たした上で、メール送受信ユーザが、新たに認証局に公開鍵を証明してもらう必要なく、また、認証局または、何らかの機関が公開鍵証明書を管理することなく、暗号化・電子署名付メールを送受信するという課題を解決する。
【００８７】
また、本発明によって、公開鍵及び私有鍵のペアを、メール送受信の度に毎回生成することにより、一度作成した公開鍵及び私有鍵のペアを長期に渡り保存する従来の技術と比較して、私有鍵が漏洩する危険性を低くすることができる効果もある。
(2)本発明の電子メール転送方法を実現する装置は、電子メール送信装置及び電子メール受信装置間で公開鍵暗号化方式により電子メールを転送するための電子メール転送装置であって、ユーザ認証データと公開鍵が付加されたトリガメッセージを該電子メール送信装置から受信するトリガメッセージ受信手段と、該ユーザ認証データを認証するユーザ認証手段と、該ユーザ認証手段により該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して該電子メール受信装置に送信するトリガメッセージ信頼性付与手段と、ユーザ認証データと公開鍵が付加されたレスポンスメッセージを該電子メール受信装置から受信するレスポンスメッセージ受信手段と、該ユーザ認証手段により該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して該電子メール送信装置に送信するレスポンスメッセージ信頼性付与手段と、を有することができる。
【００８８】
すなわち、本発明の電子メール転送装置では、トリガメッセージ受信手段は、ユーザ認証データと公開鍵が付加されたトリガメッセージを該電子メール送信装置から受信する。ユーザ認証手段は、ユーザ認証データを認証する。トリガメッセージ信頼性付与手段は、ユーザ認証手段により該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して該電子メール受信装置に送信する。レスポンスメッセージ受信手段は、ユーザ認証データと公開鍵が付加されたレスポンスメッセージを該電子メール受信装置から受信する。レスポンスメッセージ信頼性付与送信手段は、ユーザ認証手段により該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して該電子メール送信装置に送信する。
【００８９】
このように、電子メール転送装置は、電子メール送信装置からのトリガメッセージ中の公開鍵に信頼性を付与して電子メール受信装置に送信し、電子メール受信装置からのレスポンスメッセージ中の公開鍵に信頼性を付与して電子メール送信装置に送信する。これにより、電子メール転送装置は認証局に代わって、電子メール送信装置及び電子メール受信装置の公開鍵に信頼性を付与して公開鍵暗号化方式による電子メールを送受信可能にする。
(3)上記の電子メール転送装置では、該電子メール送信装置が、該トリガメッセージを該電子メール転送装置に送信するトリガメッセージ送信手段と、該電子メール受信装置からのレスポンスメッセージを該電子メール転送装置から取得するレスポンスメッセージ取得手段と、該レスポンスメッセージ中の公開鍵に信頼性が付与されているか否かを検証するレスポンスメッセージ信頼性付与検証手段と、該レスポンスメッセージ信頼性付与検証手段が該レスポンスメッセージ中の公開鍵に該信頼性が付与されていることを検証した場合、該電子メール送信装置の私有鍵で電子署名され、該信頼性が付与された該電子メール受信装置の公開鍵により暗号化された電子メールを該電子メール受信装置に送信するメール送信手段と、を有することができる。
【００９０】
すなわち、上記の電子メール送信装置において、トリガメッセージ送信手段は、トリガメッセージを電子メール転送装置に送信する。レスポンスメッセージ取得手段は、電子メール受信装置からのレスポンスメッセージを該電子メール転送装置から取得する。レスポンスメッセージ信頼性付与検証手段は、レスポンスメッセージ中の公開鍵に信頼性が付与されているか否かを検証する。メール送信手段は、レスポンスメッセージ信頼性付与検証手段が該レスポンスメッセージ中の公開鍵に該信頼性が付与されていることを検証した場合、該電子メール送信装置の私有鍵で電子署名され、該信頼性が付与された該電子メール受信装置の公開鍵により暗号化された電子メールを該電子メール受信装置に送信する。
【００９１】
したがって、電子メール送信装置は、電子メール受信装置の信頼性が付与された公開鍵を取得して公開鍵暗号化方式による暗号化及び電子署名された電子メールを電子メール受信装置に送信できる。
(4)また、上記の電子メール転送装置では、電子メール受信装置が、該電子メール転送装置から該トリガメッセージを取得するトリガメッセージ取得手段と、該トリガメッセージ中の公開鍵に信頼性が付与されているか否かを検証するトリガメッセージ信頼性付与検証手段と、トリガメッセージ信頼性付与検証手段が該トリガメッセージ中の公開鍵に信頼性が付与されていることを検証した場合、該レスポンスメッセージを該電子メール転送装置に送信するレスポンスメッセージ送信手段と、該電子メール送信装置からの電子メールを、自己の私有鍵で復号化し、さらに該電子署名を該電子メール送信装置の公開鍵で復号化するメール受信手段と、を有することができる。
【００９２】
すなわち、上記の電子メール受信装置において、トリガメッセージ取得手段は、該電子メール転送装置から該トリガメッセージを取得する。トリガメッセージ信頼性付与検証手段は、トリガメッセージ中の公開鍵に信頼性が付与されているか否かを検証する。レスポンスメッセージ送信手段は、トリガメッセージ信頼性付与検証手段が該トリガメッセージ中の公開鍵に信頼性が付与されていることを検証した場合、該レスポンスメッセージを該電子メール転送装置に送信する。メール受信手段は、電子メール送信装置からの電子メールを、自己の私有鍵で復号化し、さらに該電子署名を該電子メール送信装置の公開鍵で復号化する。
【００９３】
したがって、電子メール受信装置は、トリガメッセージ中の信頼性の付与された公開鍵を取得して公開鍵暗号化方式による暗号化及び電子署名付きメールを電子メール送信装置から受信できる。
(5)また、上記のトリガメッセージ信頼性付与手段は、該トリガメッセージ中の空欄となっている公開鍵証明書部分に該電子メール送信装置の公開鍵に対する自己の電子署名を付加すると共に、該レスポンスメッセージ中の空欄となっている公開鍵証明書部分に該電子メール受信装置の公開鍵に対する自己の電子署名を付加できる。
【００９４】
したがって、トリガメッセージ及びレスポンスメッセージ中の公開鍵は、公開鍵証明書部分の電子署名により信頼性が付与される。
(6)本発明の電子メール転送装置は、該電子メール送信装置及び電子メール受信装置が、該トリガメッセージ及び該レスポンスメッセージに同一かつネットワーク内でユニークなメッセージ識別子を付与できる。
【００９５】
したがって、電子メール送信装置及び電子メール受信装置はトリガメッセージ及びレスポンスメッセージに付与された同一かつネットワーク内でユニークなメッセージ識別子により確実にメッセージを管理できる。
(7)また、上記のトリガメッセージ信頼性付与手段は、該トリガメッセージのヘッダ部に信頼性付与識別子を付与すると共に、該レスポンスメッセージ信頼性付与手段が該レスポンスメッセージのヘッダ部に信頼性付与識別子を付与できる。
【００９６】
すなわち、トリガメッセージ信頼性付与手段が、トリガメッセージのヘッダ部に信頼性付与識別子を付与することにより、トリガメッセージ中の公開鍵が保証される。レスポンスメッセージ信頼性付与手段が、レスポンスメッセージのヘッダ部に信頼性付与識別子を付与することにより、レスポンスメッセージ中の公開鍵が保証される。
【００９７】
これにより、電子メール転送装置は、公開鍵証明書に電子署名するのに比べて処理が軽くなる。
(8)さらに上記のトリガメッセージ信頼性付与手段は、該トリガメッセージと共に信頼性付与識別子を送信し、該レスポンスメッセージ信頼性付与手段は、該レスポンスメッセージと共に信頼性付与識別子を送信できる。
【００９８】
したがって、この電子メール転送装置では、トリガメッセージ及びレスポンスメッセージと共に信頼性付与識別子を送信してトリガメッセージ及びレスポンスメッセージ中の公開鍵に信頼性が付与できる。これにより、電子メール転送装置は、公開鍵証明書に電子署名するのに比べて処理が軽くなる。
(9)また、上記の電子メール転送装置では、該電子メール送信装置から、その公開鍵と該電子メール受信装置に対し暗号化及び電子署名付きメールの送信を要求する平文とを含むトリガメッセージを受信したとき、該トリガメッセージの公開鍵に信頼性を付与して該電子メール受信装置に送信し、該電子メール受信装置から、その公開鍵と暗号化及び電子署名付きメッセージを含むレスポンスメッセージを受信したとき、該レスポンスメッセージに信頼性を付与して該電子メール送信装置に送信できる。
【００９９】
したがって、電子メール転送装置は電子メール送信装置及び電子メール受信装置との間でメッセージ回数を削減できる。
(10)また、上記の電子メール転送装置では、該電子メール送信装置及び該電子メール受信装置が、それぞれ、相手側の公開鍵をその識別子と共に保管する保管手段と、該保管手段に保管した後、該メッセージを送信するとき、該識別子を該公開鍵の代わりに用いる手段とを有することができる。
【０１００】
すなわち、電子メール送信装置及び該電子メール受信装置の保管手段が、それぞれ、相手側の公開鍵をその識別子と共に保管する。公開鍵の代用する手段は、該鍵保管手段に保管した後、該メッセージを送信するとき、該識別子を該公開鍵の代わりに用いる。
【０１０１】
したがって、電子メール送信装置及び電子メール受信装置は、以前と同じ送信相手ならばメッセージを送信するとき識別子を送信するため、メッセージに公開鍵証明書を添付しなくて済むため、メッセージデータ量を削減できる。
(11)また、上記の電子メール転送装置では、該トリガメッセージ及び該レスポンスメッセージが有効であるか否かを判断する有効判断手段をさらに設け、該有効判断手段が該トリガメッセージ及び該レスポンスメッセージが有効でないと判断したとき、該トリガメッセージ信頼性付与手段が、該トリガメッセージのヘッダ部を変更した無効トリガメッセージを該電子メール送信装置に返送し、該レスポンスメッセージ信頼性付与手段が該レスポンスメッセージのヘッダ部を変更して無効レスポンスメッセージを該電子メール受信装置に返送することができる。
【０１０２】
すなわち、有効判断手段は、トリガメッセージ及び該レスポンスメッセージが有効であるか否かを判断する。有効判断手段が該トリガメッセージ及び該レスポンスメッセージが有効でないと判断したとき、該トリガメッセージ信頼性付与手段が、該トリガメッセージのヘッダ部を変更した無効トリガメッセージを該電子メール送信装置に返送し、該レスポンスメッセージ信頼性付与手段が該レスポンスメッセージのヘッダ部を変更して無効レスポンスメッセージを該電子メール受信装置に返送する。
【０１０３】
したがって、電子メール転送装置は、有効でなくなったトリガメッセージ及びレスポンスメッセージを電子メール送信装置及び電子メール受信装置に返送できるので、トリガメッセージ又はレスポンスメッセージの有効性をよりリアルタイムに電子メール送信装置及び電子メール受信装置に反映できる。
(12)また、上記の電子メール転送装置では、該メッセージの宛先が相互認証している別の電子メール転送装置であるとき、自己の公開鍵を挿入した宛先の電子メール転送装置の公開鍵証明書を該メッセージに挿入する手段をさらに備えることができる。
【０１０４】
したがって、電子メール送信装置及び電子メール受信装置は、相互認証している電子メール転送装置間で暗号化及び電子署名付きメールを送受信できる。
(13)また、上記の電子メール転送装置では、電子メール送信装置及び電子メール受信装置が、メッセージを指定するためのメッセージ作成画面を有するメッセージ作成ユーザインタフェース、又はメッセージ状態を表示するためのメッセージ状態表示画面を有するメッセージ管理インタフェースを備えることができる。
【０１０５】
すなわち、電子メール送信装置及び電子メール受信装置において、メッセージ作成ユーザインタフェースのメッセージ作成画面でメッセージの指定、又は、メッセージ管理インタフェースのメッセージ表示画面でメッセージ状態を表示できる。
【０１０６】
したがって、電子メール送信装置及び電子メール受信装置は、メッセージ作成ユーザインタフェース及びメッセージ管理インタフェースで一連のメッセージ(トリガメッセージ〜レスポンスメッセージ〜暗号化・電子署名付きメッセージ)の関連性を把握し、状態に応じて適切なメッセージを作成できる。
【発明の効果】
【０１０７】
本発明に係る電子メール転送方法及び装置は、ユーザ認証データと公開鍵が付加されたトリガメッセージを受信し、トリガメッセージ中のユーザ認証データが認証されたとき、トリガメッセージ中の公開鍵に信頼性を付与して送信すると共に、ユーザ認証データと公開鍵が付加されたレスポンスメッセージを受信し、ユーザ認証ステップによりレスポンスメッセージ中のユーザ認証データが認証されたとき、レスポンスメッセージ中の公開鍵に信頼性を付与して送信するので、電子メール転送装置は認証局に代わって、ＩＳＰ等を利用して電子メール送信装置及び電子メール受信装置間の公開鍵を認証して公開鍵暗号化方式による電子メールの送受信を簡易且つ安全に可能にする。
【発明を実施するための最良の形態】
【０１０８】
実施の形態（１）：図３〜図９
図３は、本発明に係る電子メール転送方法及び装置の実施の形態(１)のクライアントを示す。図４は、本発明に係る電子メール転送方法及び装置の実施の形態(１)のサーバを示す。図５は、本発明に係る電子メール転送方法及び装置の実施の形態(１)のトリガメッセージまたはレスポンスメッセージ送信時のユーザ認証手順を示す。図６は、本発明に係る電子メール転送方法及び装置の実施の形態(１)のトリガメッセージまたはレスポンスメッセージ取得時のユーザ認証手順を示す。図７は、本発明に係る電子メール転送方法及び装置の実施の形態(１)のトリガメッセージを示す。図８は、本発明に係る電子メール転送方法及び装置の実施の形態(１)のレスポンスメッセージを示す。図９は、本発明に係る電子メール転送方法及び装置の実施の形態の(１)のトリガメッセージおよびレスポンスメッセージで使用するsignedData(certs-only)フォーマットを示す。以下、上記の図に沿って順番に説明する。
【０１０９】
クライアント：電子メール送信装置及び電子メール受信装置
図３において、クライアント１１は、大略、メール送受信部１２と鍵管理部１３から成っている。メール送受信部１２は、トリガメッセージ作成部１２ａ、トリガメッセージ送信部１２ｂ、トリガメッセージ取得部１２ｃ、レスポンスメッセージ作成部１２ｄ、レスポンスメッセージ送信部１２ｅ、レスポンスメッセージ取得部１２ｆ、暗号化及び電子署名付き（以下、暗号化・電子署名付きのように表現する。）メール送信部１２ｇ、及び暗号化・電子署名付きメール受信部１２ｈから成っている。鍵管理部１３は、公開鍵・私有鍵作成部１３ａ、公開鍵検証部１３ｂ、及び鍵保管部１３ｃから成っている。
【０１１０】
なお、このクライアント１１は、図１に示したクライアント１Ａ及び１Ｂ両方の機能を有し、サーバ１５は同図のサーバ５に対応する。それぞれ複数個図示されているが同一のものである。
【０１１１】
また、クライアント１１Ａは公開鍵１１αと私有鍵１１βを有し、クライアント１１Bは公開鍵１１γと私有鍵１１δを有するものとする。
【０１１２】
動作において、まず、トリガメッセージ作成部１２aは、メール送信ユーザ１１ａからのメール送信要求を契機（ステップＳ１２１）に、メール送信ユーザ１１ａの公開鍵１１αを公開鍵・私有鍵作成部１３ａから入力して（ステップＳ１２２）、後述する図７に示すトリガメッセージ１４を作成する（ステップＳ１２３）。トリガメッセージ送信部１２ｂは、トリガメッセージ１４を入力して、後述する図5に示すユーザ認証手順でサーバ１５と通信し、トリガメッセージ14をサーバ１５へ送信する（ステップＳ１２４）。
【０１１３】
トリガメッセージ取得部１２cは、メール受信ユーザが予め設定した時間間隔でサーバ１５へトリガメッセージ取得要求を送信し（ステップＳ１２５）、後述する図6に示すユーザ認証手順でサーバ１５と通信し、トリガメッセージ１４を取得し（ステップＳ１２６）、トリガメッセージ１４内のメール送信ユーザ１１ａの公開鍵１１αに対して、信頼性が付与されているか否かについて、公開鍵検証部１３bへ公開鍵検証依頼を送信する（ステップＳ１２７）。
【０１１４】
レスポンスメッセージ作成部１２dは、公開鍵検証結果を入力し（ステップＳ１２８）、トリガメッセージ受信通知を公開鍵検証結果とともにメール受信ユーザ１１ｂへ通知する（ステップＳ１２９）。通常、メール受信ユーザ１１ｂは、信頼性が付与されているという検証結果ならば、レスポンスメッセージ送信許可をレスポンスメッセージ作成部１２dへ指示する（ステップＳ１３０）。また、レスポンスメッセージ作成部１２dは、該指示を契機にメール受信ユーザ１１ｂの公開鍵１１γを入力し（ステップＳ１３１）、後述する図８に示すレスポンスメッセージ１６を作成する。レスポンスメッセージ送信部１２eは、レスポンスメッセージ１６を入力して（ステップＳ１３２）、後述する図5に示すユーザ認証手順でサーバ１５と通信し、レスポンスメッセージ１６をサーバ１５へ送信する（ステップＳ１３３）。
【０１１５】
レスポンスメッセージ取得部１２fは、メール送信ユーザが予め設定した時間間隔でサーバ１５へレスポンスメッセージ取得要求を送信し（ステップＳ１３４）、後述する図６に示すユーザ認証手順でサーバ１５と通信し、レスポンスメッセージ１６を取得し（ステップＳ１３５）、レスポンスメッセージ１６内のメール受信ユーザ１１ｂの公開鍵１１γに対して、信頼性が付与されているか否かについて、公開鍵検証部１３bへ公開鍵検証依頼を送信する（ステップＳ１３６）。
【０１１６】
暗号化・電子署名付きメール送信部１２gは、公開鍵検証結果を入力し（ステップＳ１３７）、レスポンスメッセージ受信通知を検証結果とともにメール送信ユーザ１１ａへ通知する（ステップＳ１３８）。通常、メール送信ユーザ１１ａは、信頼性が付与されているという検証結果ならば、平文(メール本文)を入力する（ステップＳ１３９）ことによって、暗号化・電子署名付きメール送信部１２gへ該メールの送信を指示する。
【０１１７】
暗号化・電子署名付きメール送信部１２gは、メール送信ユーザ１１ａの平文(メール本文)の入力を契機に送信ユーザ１１ａの私有鍵１１βを入力し（ステップＳ１４０）、受信ユーザ１１ｂの公開鍵１１γを入力として（ステップＳ１４１）、図１９に示した処理手順によって作成した暗号化・電子署名付きメールをサーバ１５へ送信する（ステップＳ１４２）。
【０１１８】
暗号化・電子署名付きメール受信部１２hは、予め設定した時間間隔でサーバ１５へメール取得要求を送信した結果(図示省略)、サーバ１５から暗号化・電子署名付きメールを取得し（ステップＳ１４４）、メール受信ユーザ１１ｂの私有鍵１１δを入力し（ステップＳ１４５）、メール送信ユーザ１１ａの公開鍵１１αを入力し（ステップＳ１４６）、図１９に示した処理手順によって平文(メール本文)を得て、該平文(メール本文)をメール通知とともにメール受信ユーザ１１ｂへ提示する（ステップＳ１４７）。
【０１１９】
公開鍵・私有鍵作成部１３aは、一連のトリガメッセージ-レスポンスメッセージ１６の送受信毎に、自分(メール送信者またはメール受信者)の公開鍵/私有鍵のペアを作成し、図３で示す各処理部の求めに応じて、該鍵を出力する。
【０１２０】
上述したように、メール送信ユーザ１１ａは、公開鍵１１αと私有鍵１１βを有し、メール受信ユーザ１１ｂは公開鍵１１γと私有鍵１１δを有する。
【０１２１】
公開鍵検証部１３bは、公開鍵検証依頼で依頼された公開鍵に対して信頼性が付与されているか否かを検証し、公開鍵検証結果を図３中の各処理部へ通知する。
【０１２２】
本実施の形態において、公開鍵検証部１３bは、公開鍵証明書フォーマット９７Ｆ（図２１参照）で受信した公開鍵証明書９７にＩＳＰのサーバ１５の電子署名９７ｄが付与されているか否かで検証を行う。公開鍵検証部１３bは、予めＩＳＰの公開鍵証明書を取得する。公開鍵検証部１３bは、検証した公開鍵(メール送信ユーザ１１ａの公開鍵１１αまたはメール受信ユーザ１１ｂの公開鍵１１γ)を鍵保管部１３cへ、一連の送受信手順の間だけ一時的に保管する（ステップＳ１４８、Ｓ１４９）。鍵保管部１３cは、図３中の各処理部の求めに応じて相手(メール受信ユーザならメール送信ユーザ、メール送信ユーザならメール受信ユーザ)の公開鍵を出力する。
【０１２３】
尚、実際のソフトウェアの実装は、メール送受信部に関して、SMTP(Simple Mail Transfer Protocol)を扱う「送受信部」、POPを扱う「取得部」、メッセージを作成する「作成部」のように、より大きい単位のモジュール構成となっていてもよく、上述した各処理部の各機能が実現できていればよい。
【０１２４】
サーバ：電子メール転送装置
図４に示すように、サーバ１５は、トリガメッセージ受信部１５ａ、ユーザ認証部１５ｂ、信頼性付与部１５ｃ、トリガメッセージ取得要求応答部１５ｄ、レスポンスメッセージ受信部１５ｅ、レスポンスメッセージ゛取得要求応答部１５ｆ、認証データ保管部１５ｇ、及びメールボックス１５ｈから成る。
【０１２５】
動作において、トリガメッセージ受信部１５ａは、クライアント(メール受信ユーザ)１１Ａから図５に示すユーザ認証手順でクライアントと通信し、トリガメッセージ１４を受信する（ステップＳ１５１）。その際、トリガメッセージ受信部１５aは、ユーザ認証データ（図５に示すチャレンジとレスポンス）をユーザ認証部１５bへ送信し（ステップＳ１５２）、ユーザ認証部１５bからユーザ認証結果(認証ＯＫ／ＮＧ)を得る（ステップＳ１５３）。
【０１２６】
トリガメッセージ受信部１５aは、認証ＯＫならば、受信したトリガメッセージ１４を信頼性付与部１５cへ送信する（ステップＳ１５４）。レスポンスメッセージ受信部１５eは、レスポンスメッセージ１６に対して、トリガメッセージ受信部１５aと同様にレスポンスメッセージ１６を受信する（ステップＳ１５５）。
【０１２７】
その際、レスポンスメッセージ受信部１５eは、ユーザ認証データをユーザ認証部１５bへ送信し（ステップＳ１５６）、ユーザ認証部１５bからユーザ認証結果（認証ＯＫ／ＮＧ）を得る（ステップＳ１５７）。レスポンスメッセージ受信部１５eは、認証ＯＫならば、受信したレスポンスメッセージ１６を信頼性付与部１５cへ送信する（ステップＳ１５８）。ユーザ認証部１５bは、図４中の各処理部からのユーザ認証データを入力し、認証データ保管部１５gに対して、ユーザ名で、ユーザ認証データ検索を行い（ステップＳ１５９）、ユーザ認証検索結果を得て、該ユーザ認証検索結果（たとえばパスワード）を元にユーザ認証を行い（ステップＳ１６０）、ユーザ認証結果（認証ＯＫ／ＮＧ)を各処理部へ送信する。
【０１２８】
本実施の形態（１）において、認証データ保管部１５ｇが保管する認証データは、ユーザ名とパスワードの組である。信頼性付与部１５cは、図７で示すトリガメッセージ１４または図８で示すレスポンスメッセージ１６を入力とし、信頼性を付与したトリガメッセージ１４または信頼性を付与したレスポンスメッセージ１６をメールボックス１５hへ保存する（ステップＳ１６１、Ｓ１６２）。
【０１２９】
本実施の形態（１）において、信頼性付与部１５cは、信頼性の付与を、トリガメッセージ１４のメールボディ部１４ｃ及びレスポンスメッセージ１６のメールボディ部１６ｃをデコードした、SignedData(certs-only)１７から電子署名９７ｄの部分が空欄となっている公開鍵証明書９７（図２１(ａ)参照）を得て、該公開鍵証明書９７を検証(付与されているユーザ名が正しいか否か等)し、該公開鍵証明書９７へＩＳＰの電子署名を付与することで実現する。
【０１３０】
トリガメッセージ取得要求応答部１５dは、クライアント１１Ｂ（メール受信ユーザ）からのトリガメッセージ取得要求を契機に（ステップＳ１６３）、図６に示すユーザ認証手順を経て（ステップＳ１６４、Ｓ１６５）、メールボックス１５hから該当ユーザの信頼性付与済みであるトリガメッセージ１４を取得し（ステップＳ１６６）、該メッセージをクライアント(メール受信ユーザ)へ送信する（ステップＳ１６７）。レスポンスメッセージ取得要求応答部も、トリガメッセージ取得要求応答部１５dと同様の処理を行い（ステップＳ１６８〜Ｓ１７０）、メールボックス１５ｈから信頼性付与済みであるレスポンスメッセージ１６を取得し（ステップＳ１７１）、クライアント(メール受信ユーザ)へ送信する（ステップＳ１７２）。
【０１３１】
尚、実施のソフトウェアの実装は、ＳＭＴＰを扱う「受信部」とＰＯＰを扱う「取得要求応答部」とユーザ認証部、信頼性付与部、認証データ保管部、メールボックス１５hのように、より大きい単位のモジュール構成となっていてもよく、上述した各処理部の各機能が実現できていればよい。
【０１３２】
ユーザ認証：メール送信時
本実施の形態（１）において、トリガメッセージ１４及びレスポンスメッセージ１６をクライアント１１Ａ，１１Ｂからサーバ１５へ送信する際に、クライアント１１Ａ，１１Ｂとサーバ１５は、ユーザ認証を行う。一般に、クライアントからサーバへ電子メールを送信する際には、従来から、RFC821で規定されているSMTP(Simple Mail Transfer Protocol)を使用する。SMTPの代表的な実装がsendmailなのでsendmailプロトコルともいう。更に、ユーザ認証をサポートするためにSMTPを拡張する規格であるSMTP‐AUTH(SMTPService Extension for Authentication; RFC2554で規定)が従来からある。
【０１３３】
本実施の形態（１）においては、クライアントが上述のサーバへ送信する際のユーザ認証に、このSMTP-AUTHを使用し、従来技術でのユーザ認証後に、本発明であるトリガメッセージまたはレスポンスメッセージを、クライアントがサーバへ送信する。
【０１３４】
また、上記の説明においては、従来技術を利用したユーザ認証として、SMTP-AUTHを使用するとしたが、ユーザ認証可能な従来技術ならば、SMTP-AUTHに限るものではない。たとえば、他の従来技術としては、「POP before SMTP」などもある。
【０１３５】
なお、図３におけるトリガメッセージ送信部１２ｂから発信された「トリガメッセージ+ユーザ認証データ」及びレスポンスメッセージ送信部１２eから発信された「レスポンスメッセージ+ユーザ認証データ」、図４におけるトリガメッセージ受信部１５ａが受信した「トリガメッセージ+ユーザ認証データ」及びレスポンスメッセージ受信部１５eが受信した「レスポンスメッセージ+ユーザ認証データ」が、上述の送信に相当する。
【０１３６】
図５において、上記において簡単に触れたトリガメッセージまたはレスポンスメッセージ送信時のユーザ認証手順を示す。
【０１３７】
なお、同図において、クライアント１１Ａは、サーバ１５へトリガメッセージ１４またはレスポンスメッセージ１６を送信する。クライアント１１ＡのFQDN(Fully Qualified Domain Name)は、clienta.example.com、サーバのFQDNは、server.example.comである。なお、同図のクライアント１１Ａは一例であり、クライアント１１Ｂまたは本発明を具備する一般的なクライアントでも同様である。以降、同図のメッセージ順（ステップＳ１１〜Ｓ２７）に沿って具体的に説明する。
【０１３８】
ステップＳ１１：クライアント１１Ａからの要求に応じて、サーバ１５との間に1本の全二重通信路を確保する。通常TCP(Transmission Control Protocol)コネクション(サーバ・ポート番号=25)を使用する。その後は、クライアント１１Ａからのコマンドと、サーバ１５からの応答のやり取りによって通信を行う。
【０１３９】
ステップＳ１２：サーバ１５準備完了。“220”は応答コードで、“server.example.com”はサーバ１５のFQDN、“ESMTP”は拡張SMTPを示す。
【０１４０】
ステップＳ１３：クライアントが拡張プロトコルをサポートすることを通知。“EHLO”はExtended Helloコマンド、“clienta.example.com”はクライアントのFQDNを示す。
【０１４１】
ステップＳ１４：要求は正常に終了した。“250”は応答コードを示す。
【０１４２】
ステップＳ１５： サーバ１５がサポートする拡張サービス内容をクライアントへ通知。ここでは、ユーザ認証(AUTH)をサポートし、アルゴリズムとしては、CRAM-MD5(Challenge-Response Authentication Mechanism - Message Digest 5)とDIEGEST-MD5をサポートすることをサーバ１５がクライアント１１Ａへ通知する。
【０１４３】
ステップＳ１６： クライアントがCRAM-MD5を使用することをサーバ１５へ通知する。
【０１４４】
ステップＳ１７：サーバ１５がクライアント１１Ａへチャレンジ文字列CHL(PENCeUxFREJoUONnb..<略>.. OmNvbT4=)を送信する。“334”は応答コード(クライアントの通知が受け入れられ、サーバ１５はレスポンス待ちの意)を示す。本実施の形態（１）は「チャレンジ＆レスポンス方式」でユーザ認証を行う。これによりパスワードPWを暗号化してクライアント１１Ａへ送信することができる。尚、サーバ１５はチャレンジ文字列CHLをランダム値とタイムスタンプ及びFQDNを元に作成する。
【０１４５】
ステップＳ１８：クライアント１１Aは、BASE64でデコードした(図示省略)チャレンジ文字列CHLとパスワードPWをMD5アルゴリズム(ハッシュ関数)に掛けて、ダイジェストDGを得る。
【０１４６】
ステップＳ１９：ユーザ名UNと“空白”とダイジェストDGを文字列結合したものをBASE64でエンコードして、レスポンスRLを得る。尚、BASE64とは、バイナリデータを含む一般的なデータをテキストデータしか搬送できない電子メール上で送信するための符号化方式である。
【０１４７】
ステップＳ２０：クライアント１１Aがサーバ１５へレスポンス文字列RL(ZnJlZCA5ZTJVlMDljNDB..<略>..Nzg2ZQ==)を送信。
【０１４８】
ステップＳ２１：サーバ１５は、レスポンス文字列RLをBASE64でデコードし、ダイジェストDGとユーザ名UNを得る。
【０１４９】
ステップＳ２２：ユーザ名からユーザ認証データを検索することで対応するパスワードPWを得る。
【０１５０】
ステップＳ２３：パスワードとチャレンジをMD5アルゴリズムへかけて、上述とは別途ダイジェストを得る。
【０１５１】
ステップＳ２４：サーバ１５は、BASE64でデコードした結果得たダイジェストDGと、MD5アルゴリズム適用の結果得たダイジェストとを比較して、一致した場合、認証OKとし、不一致の場合、認証NGとする。
【０１５２】
ステップＳ２５：サーバ１５は認証が成功したことをクライアントへ通知する。“235”は応答コードを示す。なお、チャレンジとレスポンスは、ユーザ認証の度に毎回異なるので、たとえ盗聴されたとしても、不正な第三者がユーザ認証に成功することはない。
【０１５３】
ステップＳ２６：トリガメッセージ１４またはレスポンスメッセージ１６を送信する。
【０１５４】
ステップＳ２７：クライアント１１Ａが、サーバ１５へコネクションの切断を要求して、一連の手順を終了する。
【０１５５】
ユーザ認証：メッセージ取得時
本実施の形態（１）において、トリガメッセージ１４及びレスポンスメッセージ１６をクライアント１１Ａ，１１Ｂがサーバ１５から取得する際にも、クライアント１１Ａ、１１Ｂとサーバ１５は、ユーザ認証を行う。一般的に、クライアント１１Ａ、１１Ｂがサーバ１５から電子メールを取得する際には、従来は、POP(Post Office Protocol)、今はPOP3(Post Office Protocol Version3)が使用されている。
【０１５６】
しかしながらPOP3は、ユーザIDに対応したパスワードＰＷを暗号化せずにクライアント１１Ａ、１１Ｂがサーバ１５へ送信するので、セキュリティ強化のため、パスワードＰＷを暗号化して送信するプロトコルとして、RFC1939で規定されているAPOP(Authenticated Post Office Protocol)がある。
【０１５７】
本実施の形態（１）においては、クライアント１１Ａ、１１Ｂが上述のサーバ１５から該メッセージを取得する際のユーザ認証に、このAPOPを使用し、従来技術でのユーザ認証後に、本発明である信頼性付与済みトリガメッセージ１４または信頼性付与済みレスポンスメッセージ１６を、クライアント１１Ａ、１１Ｂがサーバ１５から取得する。
【０１５８】
また、上記の説明においては、従来技術を利用したユーザ認証として、APOPを使用するようにしたが、ユーザ認証可能な従来技術ならば、APOPに限るものではない。
【０１５９】
なお、図３におけるトリガメッセージ取得部１２ｃが発信した「トリガメッセージ取得要求」および、レスポンスメッセージ取得部１２ｆが発信した「レスポンスメッセージ取得要求」、図４におけるトリガメッセージ取得要求応答部１５ｄが受信した「トリガメッセージ取得要求」および、レスポンスメッセージ取得要求応答部１５ｆが受信した「レスポンスメッセージ取得要求」が、上述の取得に相当する。
【０１６０】
図６において、本実施の形態（１）のトリガメッセージ１４またはレスポンスメッセージ１６の取得時のユーザ認証手順を示す。
【０１６１】
なお、同図において、クライアント１１Ｂは、サーバ１５からトリガメッセージ１４またはレスポンスメッセージ１６を取得する。クライアント１１ＢのFQDN(Fully Qualified Domain Name)は、clientb.example.com、サーバ１５のFQDNは、server.example.comである。同図のクライアント１１Ｂは一例であり、クライアント１１Ａまたは本発明を具備する一般的なクライアントでも同様である。以下、同図ステップＳ３１〜Ｓ３６に沿って説明する。
【０１６２】
ステップＳ３１： クライアント１１Ｂからの要求に応じて、サーバ１５との間に1本の全二重通信路を確保する。通常TCP(Transmission Control Protocol)コネクション(サーバ・ポート番号=110)を使用する。その後は、クライアント１１Ｂからのコマンドと、サーバ１５からの応答のやり取りによって通信を行う。
【０１６３】
ステップＳ３２： サーバ１５がクライアント１１Ｂへチャレンジ文字列ＣＨＬを送信する。アルゴリズムはCRAM-MD5を使用する。BASE64エンコード/デコードの部分は違うものの、基本的には図５において説明したチャレンジ＆レスポンス方式と同様なので、この部分の説明は省略する。
【０１６４】
ステップＳ３３： クライアント１１ＢがパスワードＰＷとチャレンジ文字列ＣＨＬを元に作成したレスポンスＲＬをサーバ１５へ送信する。“APOP”はコマンド名、“userb”はクライアント１１Ｂを使用しているユーザ名ＵＮを示す。
【０１６５】
ステップＳ３４： サーバ１５は、認証が成功し、ここでは1通のメールをスプールしていることをクライアント１１Ｂへ通知する。認証手順は、基本的に図５において説明したチャレンジ＆レスポンス方式である。
【０１６６】
ステップＳ３５： クライアント１１Ｂは、トリガメッセージ１４またはレスポンスメッセージ１６を取得する。
【０１６７】
ステップＳ３６：クライアント１１Ｂはサーバ１５にコネクションの切断を要求して、一連の手順を終了する。
【０１６８】
トリガメッセージ及びレスポンスメッセージ
ここで、図７及び図８にそれぞれ示したトリガメッセージ１４及びレスポンスメッセージ１６のフォーマット１４Ｆ及び１６Ｆについて詳しく説明する。
【０１６９】
トリガメッセージフォーマット１４Ｆ及びレスポンスメッセージフォーマット１６Ｆの基本的な要件は以下のとおりである。
（１）トリガメッセージ１４またはレスポンスメッセージ１６であることを識別できるように、何らかの識別子を付与すること。
（２）トリガメッセージ１４とレスポンスメッセージ１６の対応がつくように、何らかの対応識別子を付与すること。
（３）公開鍵を搬送できること。
（４）公開鍵に対する信頼性を搬送できること。
【０１７０】
本発明では、従来の技術を拡張して、上述の要件を満たせればよく、その具体的な手法は極めて多岐に渡る。そこで、本実施の形態（１）では、トリガメッセージ１４のメールヘッダ部１４ａへ独自に定義した以下のヘッダ・フィールドを挿入することで、トリガメッセージ１４を識別する。また、同様に本実施の形態（１）では、レスポンスメッセージ１６のメールヘッダ部１６ａへ独自に定義した以下のヘッダ・フィールドを挿入することで、レスポンスメッセージ１６を識別する。
【０１７１】
・トリガメッセージ識別子フォーマット:X-Certs-Auth: trigger-msg < Certs-AuthメッセージID>
・レスポンスメッセージ識別子フォーマット:X-Certs-Auth: respose-msg < Certs-AuthメッセージID>
“X-Certs-Auth”は、本発明で独自に定義したフィールド名である。“<Certs-AuthメッセージID>”は、トリガメッセージ１４とレスポンスメッセージ１６の対応関係を取るためのユニークなIDである。メール送信者のクライアント(図１におけるクライアント１Ａ)が値を決定し、メール受信者のクライアント(図１におけるクライアント１Ｂ)は、受信した「Certs-AuthメッセージID」をレスポンスメッセージ１６に使用する。尚、一般的に独自の拡張ヘッダフィールドのフィール名は、“X-”で始まる文字列で定義する。
【０１７２】
本実施の形態（１）では、公開鍵の搬送をS/MIME(Secure/ Mulitpurpose Internet Mail Extensions)において、公開鍵証明書を搬送するときに使用するフォーマットである署名データ(signedData(certs-only))のフォーマット１７Ｆを使用する。従来においては、このフォーマット１７Ｆは、認証局によって電子署名済みである公開鍵証明書９７(図２１参照。)を搬送するために使用するが、本発明においては、認証局の署名を付加するフィールド９７ｄは空欄とし、ISPのサーバ１５がユーザ認証後、署名を付加するものとする。これは、本発明に独自の手順である。
【０１７３】
S/MIMEは、暗号化に必要な処理方式やデータのフォーマットに関して、PKCS(Public-Key Cryptography Standards)という規格のPKCS#1, PKCS#7, PKCS#10を実施に際して流用する。signedData(certs-only)１７のデータフォーマット１７Ｆは、PKCS#7に定義されている。トリガメッセージ１４及びレスポンスメッセージ１６のフォーマット１４Ｆ及び１６Ｆも、PKCS#7に定義されている書式に沿った形式で記述するものとする。
【０１７４】
尚、S/MIMEに相当する従来の技術として他にも、PEM(Privacy Enhanced Mail)、MOSS(MIME Object Security Services)、PGP(Pretty Good Privacy)等が存在する。データフォーマットはそれぞれ多少異なるが、公開鍵を搬送することができれば、本実施の形態（１）と同様の処理を行うことは可能であり、本発明は、S/MIMEに限定するものではない。
【０１７５】
また、トリガメッセージ識別子およびレスポンスメッセージ識別子を挿入するメールヘッダ部は、電子メールに共通のヘッダ部であり、上述のS/MIME等の技術に依存しない。
【０１７６】
このトリガメッセージ１４のフォーマット１４Ｆが図７に示されており、メールヘッダ部１４ａと空行(NULL行)１４ｂとメールボディ部１４ｃとに分けられている。
【０１７７】
メールヘッダ部１４ａは複数のヘッダフィールドによって構成されている。メールヘッダ部１４ａ内のヘッダフィールドの順序は、任意の順序で構わない。ヘッダフィールドは、行頭から“:”(コロン)までのフィールド名とそれ以降のフィールドボディによって構成されている。
【０１７８】
図７において、トリガメッセージフォーマット１４Ｆのヘッダフィールドのフィールドボディ“ 0501171937.AAbb013@usera.server.example.com”が<Certs-AuthメッセージID>である。同図では、Message-IDと同じ値を流用したが、メール送信者がユニークなIDを付与すれば、Message-IDと同じ値である必要はない。従来の技術より、RFC822は、Message-IDを<local-part"@" domain>の書式で、インターネットの全域でユニークなIDとすることを要求しているので、本実施の形態（１）では、これを適用してCerts-AuthメッセージIDとした。クライアントの一般的なメールソフトは、上述のlocal-partを、生成日時、プロセスID、生成番号等を組み合わせて作成する。また、同図では、”Subject”は、”TriggerMessage”としたが任意の文字列で構わない。”Mime-Version”は、MIME(Multipurpose Internet MailExtensions)のバージョンを示す。MIMEとは、電子メールのメッセージフォーマット標準であり、それより以前のメッセージフォーマット標準であるRFC822を拡張した規格である。MIMEでは、メールボディ部のデータ内容をヘッダフィールド(図示のContent-Type,Content-Transfer-Encoding, Content-Disposition)で規定する。
【０１７９】
Content-Typeは、コンテンツのタイプ、すなわち、メールボディ部１４ｃ、１６ｃのタイプを示す。従来より、S/MIMEは、用途に応じて、Content-Typeを以下の表１のパターンとする。その中で、本実施の形態（１）は、項3をトリガメッセージ１４およびレスポンスメッセージ１６として使用する。また、本実施の形態（１）は、項1/項4を電子署名付きメールとして使用し、項2を暗号化メールとして使用し、項1を項2で包み、入れ子構造としたものを暗号化・電子署名付きメールとして使用する。
【０１８０】
電子署名付きメール、暗号化メール、暗号化・電子署名付きメール関しては、従来と基本的に同様であるが、トリガメッセージ１４やレスポンスメッセージ１６と対応が付くように、例えば、以下のようなヘッダフィールドを付与することが好ましい(但し、必須ではない。)
暗号化または電子署名付きメッセージ識別子フォーマット:   
X-Certs-Auth:content-msg   < Certs-AuthメッセージID>
【０１８１】
【表１】
2006260490.tif 000003
なお、Content-Typeのname変数として、ファイル名(smime.p7c)を示すのは、ユーザがメールボディ部１４ｃを別途、ファイルとして保存する際に、クライアントのメールソフトがユーザへ提示するファイル名として使用するためである。上記フィールド名Content-Transfer-Encodingは、コンテンツ、すなわちメールボディ部１４ｃのエンコード方法を示しており図７は、メールボディ部をBASE64でエンコードしている。また、上記フィールド名Content-Dispositionは、コンテンツのユーザへ提示する方法を示しており、図７のattachmentは、ユーザからの指示を受けてから、提示すべきことを示す。
【０１８２】
さらに、メールボディ部１４ｃは、PKCS#7で定義されるsignedData(certs-only)１７のデータを、更に、PKCS#7で定義されるContentInfoフォーマットでカプセル化し (図示省略)、BASE64でエンコードした結果を格納する。signedData(certs-only)１７については、図９に基づいて後述する。なお、signedData(certs-only)１７をカプセル化するContentInfoは、単にデータをカプセル化するだけでそれ以外の役割はない。
【０１８３】
図８において、レスポンスメッセージ１６のフォーマット１６Ｆはメールヘッダ部１６ａと空行（NULL行）１６ｂとメールボディ部１６ｃとによって分けられている。レスポンスメッセージ１６は基本的にトリガメッセージ１４のフォーマット１４Fと同様であるが、以下の点が異なる。
【０１８４】
フィールド名”X-Certs-Auth”のフィールドボディとして、”response-msg”と受信したトリガメッセージ１４内の<Certs-AuthメッセージID>である<0501171937.AAbb013@usera.server.example.com>を付与する。”References”として、トリガメッセージ１４のMessage-IDを指定する。ただし、この“References”に関しては、従来から一般的に行われていることであり、本発明の技術ではない。Message-IDは、トリガメッセージ１４とは異なるものとなる。
【０１８５】
同図に示したメールボディ部１６ｃは、PKCS#7で定義されるsignedData(certs-only)１７のデータを、更に、PKCS#7で定義されるContentInfoフォーマットでカプセル化し(図示省略)、BASE64でエンコードした結果を格納する。signedData(certs-only)１７については、図９に基づいて以下に詳述する。
【０１８６】
SignedData(certs-only)フォーマット
図９において、トリガメッセージ１４及びレスポンスメッセージ１６で使用するsignedData(certs-only)フォーマット１７Fを示す。PKCS#7は、ASN.1(Abstract Syntax Notation One)（図９(b)参照）で、データフォーマットを定義する。ASN.1は、データの構造を定義する言語の一つで、新たなデータ型を「組み込みデータ型」の組み合わせによって定義することによって、階層的なデータ構造を定義することができる。トリガメッセージ１４のメールボディ部１４ｃ及びレスポンスメッセージ１６のメールボディ部１６ｃは、ASN.1に準拠したバイナリデータを、BER(Basic Encoding Rules)または、DER(Distinguished Encoding Rules)でエンコードし、更にBASE64でエンコードしたものである。
【０１８７】
図９は、ASN.1で定義されたフォーマットをより分かりやすいように図式化しており、SignedData17は、version17a,digestAlgorithms17b, contentInfo17c, certificates17d, crls17e, signerInfos17fによって構成される順序付きデータ列(SEQUENCE)である。順序付きとは、上述の順序(version〜singerInfo)でデータを格納することを意味する。Version17aは本フォーマットのバージョンである。digestAlgorithms17bは後述する。contenInfo17cは、電子署名付きメールの署名対象である平文である。SignedData17自体は、表１に示したように電子署名付きメールを搬送するためのフォーマットであり、同時に電子署名に対応する証明書も搬送できるようになっている。証明書のみを搬送する場合は、一部データを空欄とすることで対応する。それがSignedData(certs-only)17である。空欄とすべきデータは、規格で提示されている。本実施の形態(1)では、証明書のみを搬送するので、contentInfo17cは空欄とする。
【０１８８】
contentInfo17cは、コンテンツタイプであるcontentType17c1とコンテンツであるcontent17c2から成るが、contentInfo17cが空欄なので空欄となる。Certificates17dは、複数個のcertificate17d11またはextendedCertifcate17d12から成る順序なしデータ集合である。
【０１８９】
Certificate17d11は、X.509公開鍵証明書97(図２１参照。)を指し、extendedCertificate17d12は、PKCS#6で定義されているX.509公開鍵証明書97を拡張した公開鍵証明書を指す。
【０１９０】
SignedDataフォーマット17Fは、元々複数人の署名または、同一人物の複数の署名を格納することができるようになっており、これに対応する複数の公開鍵証明書97を格納することができる。
【０１９１】
本実施の形態(1)では、基本的にはユーザ一人がトリガメッセージ14またはレスポンスメッセージ16を送信できれば良いので、X.509公開鍵証明書97、PKCS#6拡張公開鍵証明書のそれぞれ一つ、計二つか、どちらか一つを、certificates17dは格納する。上述のとおり、公開鍵証明書97が搬送できれば良く、本発明が特に数を限定するものではない。
【０１９２】
また、本発明の技術に関して、X.509公開鍵証明書97とPKCS#6拡張公開鍵証明書との間に差分はない。また、上述したように、本発明においては、認証局の署名を付加するフィールド97dは空欄とし、サーバ15がユーザ認証後、署名を付加するものとする。これは、本発明に独自の手順である。Crls17eは、本実施の形態(1)においては空欄とする。signerInfos17fは、上述のコンテンツに対する電子署名情報を複数格納する順序なしデータ集合である。本実施の形態（１）では、公開鍵証明書97のみを搬送するので、signerInfos17fは、空欄とする。
【０１９３】
digestAlgorithms17bは、このsignerInfos17fで使用されている複数のダイジェストアルゴリズムをそのまま繰り返し格納する。図９で詳細は省略したsignerInfos17f内にも、同じdigestAlgorithm17bの指定があるが、装置の処理のし易さから、フォーマット17Fのはじめにも、digestAlgorithms17bを指定する。digestAlgorithms17bはsignerInfos17fが空欄なので、空欄とする。DigestAlgorithmIdentifier17b1は、アルゴリズムを示すalgorithm17b11と、そのパラメータであるparameters17b12から成る順序付きデータ列であるが、当然空欄となる。
【０１９４】

実施の形態（２）：図１０
図１０は本発明に係る電子メール転送方法及び装置の実施の形態（２）で使用されるメッセージを示し、同図（ａ）は図７に示したトリガメッセージの変形例を示し、同図（ｂ）は図８に示したレスポンスメッセージの変形例を示している。
【０１９５】
上述した実施の形態（１）では、サーバ１５の信頼性付与部１５ｃがトリガメッセージ１４のメールボディ部１４ｃ又はレスポンスメッセージ１６のメールボディ部１６ｃをデコードしてsignedData(certs-only)１７を取り出し、このデータから電子署名の部分が空欄の公開鍵証明書９７を得て検証し、該公開鍵証明書９７に電子署名を付与している。また、クライアント１１の鍵管理部１３の公開鍵検証部１３ｂが、上記公開鍵証明書９７にＩＳＰの電子署名が付与されているか否かを検証している。
【０１９６】
このため、サーバ１５によるＩＳＰの電子署名の付加処理とクライアント１１によるＩＳＰの電子署名の検証処理が重く時間が掛かる。
【０１９７】
そこで、本実施の形態（２）では、ISPによる信頼性付与の方法として、上述の実施の形態(１)と異なり、サーバ１５の信頼性付与部１５ｃが、トリガメッセージ１４のメールヘッダ部１４ａ又はレスポンスメッセージ１６のメールヘッダ部１６ａに信頼性付与識別子を付与することにより、信頼性を付与する。また、クライアント１１の公開鍵検証部１３ｂが、トリガメッセージ１４のメールヘッダ部１４ａ又はレスポンスメッセージ１６のメールヘッダ部１６ａに信頼性付与識別子が付与されているか否かを検証できるようにする。
【０１９８】
本実施の形態（２）のクライアント及びサーバの基本的構成は、上述の実施の形態（１）の図３及び図４と同様であるが、以下、異なる部分についてのみ説明する。
【０１９９】
図４のサーバ１５の信頼性付与部１５ｃは、トリガメッセージ１４又はレスポンスメッセージ１６の入力に対して、以下のフォーマットで信頼性付与識別子（trusted by サーバのFQDN）を、トリガメッセージ１４のメールヘッダ部１４ａ又はレスポンスメッセージ１６のメールヘッダ部１６ａに付与する。
・トリガメッセージ識別子フォーマット(信頼性付与):
X-Certs-Auth:trigger-msg <Certs-AuthメッセージID> trusted by サーバのFQDN
・レスポンスメッセージ識別子フォーマット(信頼性付与):
X-Certs-Auth: respose-msg <Certs-AuthメッセージID> trusted by サーバのFQDN
なお、上述のFQDNは、実際のサーバ１５のFQDN(例えば、server.example.com)を記載する。
【０２００】
なお、図１０で、メールボディ部１４ｃまたは１６ｃは、signedData(certs-only)１７のデータを、更に、PKCS#7で定義されるContentInfoフォーマットでカプセル化し(図示省略)、BASE64でエンコードした結果を格納しているが、本発明は、公開鍵を搬送できればよく、これに限定するものではない。
【０２０１】
図３のクライアント１１の公開鍵検証部１３ｂは、公開鍵証明書９７にISPの電子署名が付与されているか否かで信頼性を検証するのに代えて、トリガメッセージ１４のメールヘッダ部１４ａ又はレスポンスメッセージ１６のメールヘッダ部１６ａに信頼性付与識別子が付与されているか否かで、信頼性を検証する。
【０２０２】
また、上述のような識別子は、電子署名とは違い、誰でもメールに挿入することは可能である。したがって、図４のサーバ１５の信頼性付与部１５ｃは、受信したトリガメッセージ１４又はレスポンスメッセージ１６に信頼性付与識別子が付与されていないかどうかを確認し、該トリガメッセージ１４又はレスポンスメッセージ１６に信頼性付与識別子が付与されていた場合には、それ以降のメッセージ送受信を行わないようにする。このようにすることによって、サーバ１５以外が信頼性付与識別子を付与した電子メールをメール送受信ユーザ11A,11Bが取得しないようする。
【０２０３】
上述したように本実施の形態（２）では、実施の形態（１）のサーバ１５によるＩＳＰの電子署名の付加処理とクライアント１１によるＩＳＰの電子署名の検証処理を削減できる。
【０２０４】
実施の形態（３）：図１１
図１１は本発明に係る電子メール転送装置の実施の形態（３）の信頼性付与手順を示し、これは図６の変形例に相当する。
【０２０５】
上述した実施の形態（２）で説明したように、実施の形態（１）ではサーバ１５の電子署名の付加処理とクライアント１１の電子署名の検証処理が重く時間がかかる。
【０２０６】
そこで、本実施の形態（３）では、ISPによる信頼性付与の方法として、上述の実施の形態(１)と異なり、ISPのサーバ１５がクライアント11によるトリガメッセージ１４又はレスポンスメッセージ１６を取得する時に、サーバ１５がクライアント11に信頼性付与識別子を送信することにより信頼性を付与する。
【０２０７】
図１１において、ステップＳ４１からステップＳ４４までは、図６のステップＳ３１からステップＳ３４までと同様である。以下、異なるステップのみ説明する。なお、図６のクライアント11Bはクライアント11として示している。 
【０２０８】
ステップＳ４５：クライアント11がサーバ１５にTRANSACTION stateへの遷移を要求する。TRANSACTION stateとは、メールデータを送受信する状態である。ここでは、それまでのAUTHORIZATION state、すなわち認証ステートから遷移する。
【０２０９】
ステップＳ４６：上記ステップＳ４５の要求が了承された(+OK 1 369)ことを示す。”1”は、サーバ１５がスプールしているメッセージ数である。”369”は、サーバ１５がスプールしているメッセージの総容量(octet)である。
【０２１０】
ステップＳ４７：クライアント11はmessage-numberが1のメッセージの取得を要求(RETR 1)する。message-numberは、本送受信手順開始時にサーバ１５がスプールしているメッセージに対して割り当てるもので、1番から始まる。
【０２１１】
ステップＳ４８：上記ステップＳ４７の要求が了承された(+OK)ことを示す。そして、このメッセージは信頼性が付与されたメッセージなので、サーバ１５は、図１１に示すように信頼性付与識別子”trusted”をクライアント11に送信する。
【０２１２】
ステップＳ４９：トリガメッセージ１４又はレスポンスメッセージ１６を送信する。
【０２１３】
ステップＳ５０：上述のステップＳ４７及びＳ４８、そしてステップＳ４９のトリガメッセージ１４又はレスポンスメッセージ１６の時の送信は、メッセージ単位に繰り返し行うので、仮に次のメッセージに信頼性が付与されていなければ、”trusted”は付かない。必要なメッセージの送受信後、コネクションを切断する。
【０２１４】
本実施の形態（３）におけるクライアント及びサーバの基本的構成は、上述の実施の形態（１）の図３及び図４と同様であるが、以下、異なる部分についてのみ説明する。
【０２１５】
図４のサーバ１５の信頼性付与部１５ｃは、トリガメッセージ１４又はレスポンスメッセージ１６に対し、サーバ１５内部に閉じる内部データとして信頼性を付与する。この内部データは、サーバ１５外に出力しない。
【０２１６】
また、図４のサーバ１５のトリガメッセージ取得要求応答部１５ｄ又はレスポンスメッセージ取得要求応答部１５ｆは、トリガメッセージ１４又はレスポンスメッセージ１６に対し、信頼性が付与されていることを上述の内部データによって判断し、上述の図１１に示したような手順によって、クライアント11へ信頼性付与識別子を送信する。
【０２１７】
図３のクライアント１１のトリガメッセージ取得部１２ｃ又はレスポンスメッセージ取得部１２ｆは、上述の図１１に示す手順で信頼性が付与されていることを識別したならば、公開鍵検証部１３ｂへ、信頼性付与済みであることを公開鍵とともに通知する。クライアント１１の公開鍵検証部１３ｂの公開鍵検証結果は、その通知に従い、検証結果を送信する。
【０２１８】
上述したように本実施の形態（３）では、クライアント11がトリガメッセージ１４又はレスポンスメッセージ１６を取得する時に、ＩＳＰのサーバ１５はクライアント11に信頼性付与識別子を送信して信頼性を付与するようにしている。これにより、実施の形態（１）のサーバ１５による電子署名の付加処理とクライアント１１による電子署名の検証処理を削減することができる。
【０２１９】
実施の形態（４）：図１２〜図１４
上述した実施の形態（１）では、メール送信ユーザ１１ａが暗号化された情報をメール受信ユーザ１１ｂへ送るために、メール送信ユーザ１１ａとメール受信ユーザ１１ｂとの間でトリガメッセージ１４及びレスポンスメッセージ１６を送受信した後に、メール送信ユーザ１１ａがメール受信ユーザ１１ｂへ暗号化・電子署名付きメールを送信する必要がある。しかし、メール送信ユーザ１１ａがメール受信ユーザ１１ｂへ暗号化された情報を要求するだけでよい場合には、メール送信ユーザ１１ａがメール受信ユーザ１１ｂへ暗号化・電子署名付きメールを送信する必要がなくなる。
【０２２０】
そこで、本実施の形態（４）では、トリガメッセージに暗号化・電子署名付きメールを要求する平文を付加し、レスポンスメッセージに暗号化・電子署名付きメールを付加するようにする。
【０２２１】
図１２は本発明に係る電子メール転送方法及び装置の実施の形態（４）の概要図である。図１３は本実施の形態（４）のトリガ‐コンテンツメッセージを示し、これは図７の変形例に相当する。図１４は本実施の形態（４）のレスポンス‐コンテンツメッセージを示し、図８の変形例に相当する。
【０２２２】
図１２において、メール要求者（クライアント４１Ａ）は、メール応答者（クライアント４１Ｂ）に対して何らかの情報を要求する者である。この要求の意思そのものは、特に暗号化が必要な秘密の情報ではない。メール応答者４１Ｂは、メール要求者４１Ａの要求に応じて、情報をメール要求者４１Ａへ返答する者である。この返答する情報は、暗号化が必要な秘密の情報である。したがって、メール応答者４１Ｂからメール要求者４１Ａへのメール送受信をもって、一連の手順が終了する。
【０２２３】
次に、図１２のメッセージ順に沿って、図１との相違点を中心に説明する。それ以外は同様である。
【０２２４】
ステップＳ５１：メール要求者４１Ａがメール応答者４１Ｂの公開鍵４１γおよび要求する情報を得るためにトリガ‐コンテンツメッセージ４９をＩＳＰ４６のメールサーバ４５へ送信する。その際、メール要求者４１Ａは、要求する情報内容を暗号化されていない平文で添付する。要求する情報内容とは、図１３に示すように、例えば、「先日の議事録を暗号化して送ってください。」である。
【０２２５】
ステップＳ５２：ＩＳＰ４６のサーバ４５が、上記のステップＳ５１において、ＩＳＰ４６のユーザ認証データ４７を利用してユーザ認証することにより、トリガ‐コンテンツメッセージ４９に対して信頼性を付与する。
【０２２６】
ステップＳ５３：メール応答者４１Ｂがトリガ‐コンテンツメッセージ４９を取得する。メール応答者４１Ｂは、信頼性が付与（保証）されているメール要求者４１Ａの公開鍵４１αとメール要求者４１Ａが要求する情報の内容を得る。メール応答者４１Ｂは、得た公開鍵４１αの信頼性が付与されているか否かを検証する。
【０２２７】
ステップＳ５４：メール応答者４１Ｂは、公開鍵４１γと、メール応答者４１Ｂの私有鍵４１δで電子署名され、メール要求者４１Ａの公開鍵４１αで暗号化されたメッセージ(=要求された情報)を含むレスポンス-コンテンツメッセージ５０をサーバ４５に送信する。
【０２２８】
ステップＳ５５：ＩＳＰ４６のサーバ４５が、上記ステップＳ５４において、ＩＳＰ４６のユーザ認証データ４７を利用してユーザ認証することにより、メール応答者４１Ｂの公開鍵４１γに対して信頼性を付与する。
【０２２９】
ステップＳ５６：メール要求者４１Ａがレスポンス-コンテンツメッセージ５０を取得する。メール要求者４１Ａは、要求した情報と信頼性が付与されたメール応答者４１Ｂの公開鍵４１γを得る。
【０２３０】
尚、本実施の形態（４）の信頼性付与の方法は、実施の形態（１）、（２）、（３）で述べた方法を使用することができる。また、上述の実施の形態（１）とは違い、要求する情報(=コンテンツ)が含まれることを示すために、以下のようなトリガ‐コンテンツメッセージ識別子フォーマットおよびレスポンス-コンテンツメッセージ識別子フォーマットとする。
・トリガ-コンテンツメッセージ識別子フォーマット:
X-Certs-Auth:trigger-content-msg   < Certs-AuthメッセージID>
・レスポンス-コンテンツメッセージ識別子フォーマット:
X-Certs-Auth:respose-content-msg   <Certs-AuthメッセージID>
図１３において、トリガ-コンテンツメッセージフォーマット４９Ｆは、メールヘッダ部４９ａと空行(NULL行)４９ｂとメールボディ部４９ｃとに分けられている。メールヘッダ部４９ａにはトリガ-コンテンツメッセージ識別子が記載されていると共に、メールボディ部４９ｃには、要求する情報と公開鍵証明書９７がそれぞれカプセル化メッセージ1,2として、階層的に格納されている。
【０２３１】
メールヘッダ部４９ａの”Content-Type: MultiPart/Mixed”は、メールボディ部４９ｃが複数のカプセル化メッセージによって構成されることを示している。Boundary=”----=_NextPart_000_00FE_01C4F80D.72C457F0"は、カプセル化メッセージの境界が、文字列” --"と文字列”----=_NextPart_000_00FE_01C4F80D.72C457F0"を連結した文字列
1111140128827_4
で示されることを示している。境界文字列以降はヘッダ部４９ａとボディ部４９ｃを同様に記載する。カプセル化メッセージ1に関して、”Content-Type:text/plain; charset=iso-2022-jp”は、該ボディ部４９ｃが日本語で記載されたテキストであることを示している。カプセル化メッセージ2には、図７と同じsignedData(certs-only)を、更にContentInfoフォーマットでカプセル化し(図示省略)、BASE64でエンコードした結果が格納されている。
【０２３２】
図１４において、レスポンス-コンテンツメッセージフォーマット５０Ｆは、メールヘッダ部５０ａと空行(NULL行)５０ｂとメールボディ部５０ｃとに分けられている。メールヘッダ部５０ａにはレスポンス-コンテンツメッセージ識別子が記載されていると共に、メールボディ部５０ｃに、暗号化・電子署名付きメッセージと公開鍵証明書９７がそれぞれカプセル化メッセージ1,2とし、階層的にそれぞれ格納されている。
【０２３３】
カプセル化メッセージ1は、議事録(=要求された情報)に対し、表１の項1で示したsignedDataフォーマット１７Ｆで電子署名を施し、その結果を更に、表１の項2で示したenvelopedDataで暗号化し、その結果を更にContentInfoフォーマットでカプセル化し(図示省略)、BASE64でエンコードした結果を格納している。したがって、smime-typeは、最終的なデータフォーマットであるenveloped-dataとする。この暗号化・電子署名付きメッセージのフォーマットは、従来と同じなので、図９に相当するような詳細なフォーマットは省略する。カプセル化メッセージ2は、図８と同じsignedData(certs-only)を、更にContentInfoフォーマットでカプセル化し(図示省略)、BASE64でエンコードした結果を格納している。
【０２３４】
上述したように本実施の形態（４）では、トリガ‐コンテンツメッセージ４９に暗号化・電子署名付きメールを要求する平文を付加し、レスポンス-コンテンツメッセージ５０に暗号化・電子署名付きメールを付加するようにしたので、メール要求者とメール応答者との間でメッセージ送受信数を削減できる効果がある。
【０２３５】
実施の形態（５）：図１５
図１５は本発明に係る電子メール転送方法及び装置の実施の形態（５）のクライアントを示し、これは図３の変形例に相当する。
【０２３６】
上述した実施の形態（１）では、クライアント１５の鍵保管部１３ｃは公開鍵１１α，１１γを一連の送受信手続きの間だけ一時的に保管しており、以前と同じ送信相手であっても、トリガメッセージ１４及びレスポンスメッセージ１６に公開鍵証明書９７を添付する必要があった。
【０２３７】
そこで、本実施の形態（５）では、以前と同じ送信相手ならばトリガメッセージ識別子フォーマット及びレスポンスメッセージ識別子フォーマットに、鍵識別子として公開鍵証明書９７の証明書通し番号９７２を付加することによりクライアント５１が保存している相手の公開鍵証明書９７を指定できるようにする。
【０２３８】
本実施の形態（５）のクライアントの基本的構成は、上述の実施の形態（１）の図３と同様であるが、以下、異なる部分についてのみ説明する。
【０２３９】
なお、証明書通し番号９７２は初めにクライアント５１が証明書毎にユニークに作成する。例えば、クライアント５１が電子メールのMessage-IDを元に作成することもできる。
・トリガメッセージ識別子フォーマット:
X-Certs-Auth:trigger-msg   < Certs-AuthメッセージID>  certs=証明書通し番号
・レスポンスメッセージ識別子フォーマット:
X-Certs-Auth:respose-msg   < Certs-AuthメッセージID>  certs=証明書通し番号
図１５において、クライアント５１のトリガメッセージ作成部５２ａは、トリガメッセージ１４の作成に当たり、相手であるメール受信ユーザ名を公開鍵・私有鍵作成部５３ａへ送信する（ステップＳ５２２）。トリガメッセージ作成部５２ａはメール受信ユーザ１１ｂがトリガメッセージ１４を以前送信していない相手であった場合、メール送信ユーザ１１ａの公開鍵１１αを得て、メール受信ユーザ１１ｂがトリガメッセージ１４を以前送信した相手であった場合、鍵識別子を得る。
【０２４０】
同様に、レスポンスメッセージ作成部５２ｄも、相手であるメール送信ユーザ名を公開鍵・私有鍵作成部５３ａに送信し、レスポンスメッセージ作成部５２ｄはメール受信ユーザ１１ｂの公開鍵１１γまたは鍵識別子を得る（ステップＳ５３１）。
【０２４１】
公開鍵・私有鍵作成部５３ａは、メール送受信ユーザ名を受信し、鍵保管部５３ｃを該ユーザ名で検索する（ステップＳ５５０）。公開鍵・私有鍵作成部５３ａは、検索後、対応する公開鍵１１α，１１γが有った場合、その鍵識別子を送信する（ステップＳ５２２、Ｓ５３１）。また、この際、鍵保管部５３ｃの対応するエントリへ<Certs-AuthメッセージID>を追加する。
【０２４２】
公開鍵・私有鍵作成部５３ａは、検索後、対応する公開鍵１１α，１１γが無かった場合、公開鍵/私有鍵を作成し、鍵保管部５３ｃへ保管する（ステップＳ５５１）と共に、公開鍵を送信する（ステップＳ５２２、Ｓ５３１）。また、この際、鍵保管部５３ｃの対応するエントリへ<Certs-AuthメッセージID>を追加する。公開鍵・私有鍵作成部５３ａは、公開鍵/私有鍵を作成する際、メール送受信ユーザ１１ａ、１１ｂが予め指定しておいた有効期間９７ｂに従い、公開鍵証明書９７を作成する。
【０２４３】
暗号化・電子署名付きメール送信部５２ｇは、メール送信ユーザ１１ａの私有鍵１１β又はメール受信ユーザ１１ｂの公開鍵１１γを得る際（ステップＳ５４０、Ｓ５４１）、上述の<Certs-AuthメッセージID>を元に使用する私有鍵１１β又は公開鍵１１γを特定する。
【０２４４】
同様に、暗号化・電子署名付きメール受信部５２ｈは、メール送信ユーザ１１ａの公開鍵１１α又はメール受信ユーザ１１ｂの私有鍵１１δを得る際（ステップＳ５４５、Ｓ５４６）、上述の<Certs-AuthメッセージID>を元に使用する公開鍵１１α又は私有鍵１１δを特定する。
【０２４５】
鍵保管部５３ｃは、保管している公開鍵/私有鍵のペアに関して、メール送受信ユーザ１１ａ，１１ｂが指定した公開鍵証明書９７に記載の有効期間９７ｂまで保管し、有効期間９７ｂが過ぎたものを廃棄する。
【０２４６】
上述したように実施の形態（５）では、以前と同じ送信相手でならばトリガメッセージ識別子フォーマット及びレスポンスメッセージ識別子フォーマットに、識別子として公開鍵証明書９７の証明書通し番号９７２を付加するので、トリガメッセージ１４及びレスポンスメッセージ１６に公開鍵証明書９７を添付しなくて済むため、メッセージデータ量を削減できる効果がある。
【０２４７】
実施の形態（６）：図１６
図１６は本発明に係る電子メール転送方法及び装置の実施の形態（６）のサーバを示し、これは図４の変形例に相当する。
【０２４８】
上述した実施の形態（１）では、サーバ１５が有効でなくなったトリガメッセージ１４及びレスポンスメッセージ１６を受信する場合がある。そこで、本実施の形態（６）では、有効で無くなったトリガメッセージ１４及びレスポンスメッセージ１６をサーバ６５が返送できるようにする。
【０２４９】
本実施の形態（６）のサーバの基本的構成は、上述の実施の形態（１）の図４と同様であるが、以下、異なる部分についてのみ説明する。
【０２５０】
ここで、有効でなくなったトリガメッセージ（以下、無効トリガメッセージとも言う。）１４について説明する。
【０２５１】
有効で無くなったトリガメッセージ１４とは、
（１）メール受信ユーザ１１ｂのトリガメッセージ取得の前に、メール送信ユーザ１１ａの信頼性が低下(料金の不払い等)したメッセージ、
（２）メール受信ユーザ１１ｂのトリガメッセージ取得の前に、添付の公開鍵証明書９７の有効期間が過ぎたメッセージ、及び、
（３）メール受信ユーザ１１ｂのトリガメッセージ取得の前に、暗号化して送ろうとしていた情報の有意な期間が過ぎたメッセージ(速報性が必要なメッセージ等)である。
【０２５２】
なお、有効で無くなったレスポンスメッセージ（以下、無効レスポンスメッセージとも言う。）１６も上記トリガメッセージ１４と同様である。
【０２５３】
上記（３）の有意な期間は、メール送受信ユーザ１１ａ，１１ｂがメッセージヘッダ１４ａ，１６ａ中に以下のようなフォーマットで識別子（expire=有効期限(日時)）を指定し、サーバ６５のメッセージ有効判断部６５ｊはそれを元に判断するようにする。
・トリガメッセージ識別子フォーマット:
X-Certs-Auth:trigger-msg   < Certs-AuthメッセージID>  expire=有効期限(日時)
・レスポンスメッセージ識別子フォーマット:
X-Certs-Auth:respose-msg   < Certs-AuthメッセージID>  expire=有効期限(日時)
図１６において、サーバ６５の一般メール取得要求応答部６５ｉがクライアント（メール送受信ユーザ）１１Ａ，１１Ｂから一般メール取得要求を受信すると（ステップＳ６６９）、一般メール取得要求応答部６５ｉはメッセージ有効判断部６５ｊに受信信号を出力する（ステップＳ６７０）。メッセージ有効判断部６５ｊはユーザ認証データ保管部６５ｇのユーザ認証データも利用して（ステップＳ６７１）、上述した有効でなくなったトリガメッセージ１４又はレスポンスメッセージ１６をメールボックス６５ｈより検索する（ステップＳ６７２）。
【０２５４】
次に、メッセージ有効判断部６５ｊはトリガメッセージ１４及びレスポンスメッセージ１６が有効でないと判断した場合、トリガメッセージ１４のメッセージヘッダ１４ａ及びレスポンスメッセージ１６のメールヘッダ部１６ａを変更して（ステップＳ６７３）、一般メール取得要求応答部６５ｉに無効トリガメッセージ１４又はレスポンスメッセージ１６を送信する（ステップＳ６７４）。そして、一般メール取得要求応答部６５ｉは無効トリガメッセージ１４又はレスポンスメッセージ１６をクライアント（メール送受信ユーザ）１１Ａ，１１Ｂに返送する（ステップＳ６７５）。
【０２５５】
尚、一般メール取得要求応答部６５ｉの一般メッセージ取得要求は、普通のPOP/IMAP等によるメール取得であり、本実施の形態に特有の処理部ではない。そのため、図４の実施の形態（１）では本発明と直接関係のない処理部なので省略している。
【０２５６】
上述したように本実施の形態（６）では、サーバ６５が特に暗号化もされていない一般的な電子メールと共に、有効でなくなったトリガメッセージ１４及びレスポンスメッセージ１６をメール送受信ユーザ１１ａ，１１ｂに返送できるので、トリガメッセージ１４又はレスポンスメッセージ１６の有効性をよりリアルタイムにメール送受信ユーザ１１ａ，１１ｂに反映できる効果がある。
【０２５７】
実施の形態（７）：図１７
図１７は本発明に係る電子メール転送方法及び装置の実施の形態（７）の概要図である。
【０２５８】
本実施の形態（７）は、上述の実施の形態（１）におけるサーバ１５に代えて、異なる２つのＩＳＰ７１，７２のサーバ７５，７６を用い、これらが相互認証している宛先ＩＳＰ７２，７１の公開鍵証明書９７Ｃ，９７Ｄをトリガメッセージ１４又はレスポンスメッセージ１６に挿入するようにしたものである。
【０２５９】
図１７において、クライアント１１ＡはＩＳＰ７１に属すると共に、クライアント１１ＢはＩＳＰ７２に属している。尚、公開鍵１１αは、クライアント１１Ａの公開鍵である。ＩＳＰ７１とＩＳＰ７２は、予めお互いのメール送受信ユーザを信用する相互認証を取り交わしており、これにより、ＩＳＰ７１は自分の公開鍵７１αを含むＩＳＰ７２の電子署名付き公開鍵証明書９７Ｃを得ると共に、ＩＳＰ７２は自分の公開鍵７２αを含むＩＳＰ７１の電子署名付き公開鍵証明書９７Ｄを得るようになっている。
【０２６０】
ＩＳＰ７１のサーバ７５は、トリガメッセージ１４又はレスポンスメッセージ１６の受信時、宛先がＩＳＰ７２ならば、公開鍵１１αを含むＩＳＰ７１の電子署名付き公開鍵証明書９７Ｂだけでなく、公開鍵７１αを含むＩＳＰ７２の電子署名付き公開鍵証明書９７Ｃを該メッセージに挿入して送信する。該トリガメッセージ１４又はレスポンスメッセージ１６をサーバ７６を経由して受信したクライアント１１Ｂは、ステップＳ６１において、自分が属するＩＳＰ７２の電子署名によりサーバ７５の公開鍵７１αの信頼性を確認し、ステップＳ６２において、すでに信頼できるＩＳＰ７１の電子署名によりクライアント１１Ａの公開鍵１１αの信頼性を確認する。
【０２６１】
これにより、クライアント１１Ｂは、信頼性が付与されている公開鍵１１αを取得できる。
【０２６２】
上述とは逆に、クライアント１１Ａが信頼性が付与されているクライアント１１Ｂの公開鍵１１γを取得すれば、後は、従来と同じ手法で暗号化・電子署名付きメールを送受信することができる。
【０２６３】
尚、図１７のように、公開鍵証明書９７Ｂ及び公開鍵証明書９７Ｃを連ねることによって、ＩＳＰ間で信頼性を連鎖させる方法は公知である。
【０２６４】
上述したように本実施の形態（７）では、ＩＳＰ７１，７２のサーバ７５，７６が、トリガメッセージ１４又はレスポンスメッセージ１６であると識別し、宛先に応じて、宛先ＩＳＰ７２，７１の公開鍵証明書９７Ｃ，９７Ｄを該トリガメッセージ１４又はレスポンスメッセージ１６に挿入するので、異なるＩＳＰ７１，７２に属するクライアント１１Ａ，１１Ｂ同士であっても、暗号化・電子署名付きメールを送受信できるという効果がある。
【０２６５】
実施の形態（８）：図１８
図１８は本発明に係る電子メール転送方法及び装置の実施の形態（８）のユーザインタフェースのメッセージ画面を示し、同図（ａ）はメッセージ作成ユーザインタフェースのメッセージ作成画面を示し、同図（ｂ）はメッセージ管理ユーザインタフェースのメッセージ管理画面を示している。
【０２６６】
本実施の形態（８）は、上述の実施の形態（１）において、クライアント１１がメッセージ作成ユーザインタフェース８１又はメッセージ管理インタフェース８２をさらに備えている。メッセージ作成ユーザインタフェース８１はメッセージ指定するためのメッセージ作成画面８１ａを有している。メッセージ管理インタフェース８２はメッセージ状態を表示するためのメッセージ管理画面８２ａを有している。
【０２６７】
図１８において、メッセージ作成画面８１ａは、”ツール(T)”のメニュー指定の形式で、トリガメッセージ１４、レスポンスメッセージ１６、及び”+コンテンツ”のメッセージ指定を備えている。尚、上記メニュー指定の形式は、ボタンによる指定の形式であっても構わない。
【０２６８】
なお、本実施の形態（８）のメッセージ作成ユーザインタフェース８１は、GUI(Graphical User Interface)の部品の違いに関係なく、上述のメッセージ指定が行えるインタフェースを有していればよい。
【０２６９】
図１８において、メッセージ管理画面８２ａは、トリガ送信、トリガ受信、レスポンス送信、レスポンス受信、本文送信終了、トリガコンテンツ送信、トリガコンテンツ受信、本文(レスポンス)送信終了のメッセージ状態を他の属性(メール送信者、メール受信者等)と共に、リスト形式で表示する。メッセージ管理画面８２ａにおいては、Certs-AuthメッセージIDとエントリが1対1に対応し、一連のメッセージ手順を行うに従って、メッセージ状態が更新される。メッセージ管理画面８２ａのエントリを指定(例えば、クリック)することで、次のメッセージの送信確認画面又はメッセージ作成画面が表示されることによりメール送受信ユーザは、状態に応じて適切なメッセージを作成できる。
【０２７０】
上述したように本実施の形態（８）において、メール送受信ユーザは、一連のメッセージ(トリガメッセージ〜レスポンスメッセージ〜暗号化・電子署名付きメッセージ)の関連性を把握し、状態に応じて適切なメッセージを作成できる効果がある。
【０２７１】
（付記１）
公開鍵暗号化方式により電子メールを転送するための電子メール転送方法であって、
ユーザ認証データと公開鍵が付加されたトリガメッセージを受信するトリガメッセージ受信ステップと、
該ユーザ認証データを認証するユーザ認証ステップと、
該ユーザ認証ステップにより該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して送信するトリガメッセージ信頼性付与ステップと、
ユーザ認証データと公開鍵が付加されたレスポンスメッセージを受信するレスポンスメッセージ受信ステップと、
該ユーザ認証ステップにより該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して送信するレスポンスメッセージ信頼性付与ステップと、
を有することを特徴とした電子メール転送方法。
（付記２）
電子メール送信装置及び電子メール受信装置間で公開鍵暗号化方式により電子メールを転送するための電子メール転送装置であって、
ユーザ認証データと公開鍵が付加されたトリガメッセージを該電子メール送信装置から受信するトリガメッセージ受信手段と、
該ユーザ認証データを認証するユーザ認証手段と、
該ユーザ認証手段により該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して該電子メール受信装置に送信するトリガメッセージ信頼性付与手段と、
ユーザ認証データと公開鍵が付加されたレスポンスメッセージを該電子メール受信装置から受信するレスポンスメッセージ受信手段と、
該ユーザ認証手段により該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して該電子メール送信装置に送信するレスポンスメッセージ信頼性付与手段と、
を有することを特徴とした電子メール転送装置。
（付記３）付記２において、
該電子メール送信装置が、
該トリガメッセージを該電子メール転送装置に送信するトリガメッセージ送信手段と、
該電子メール受信装置からのレスポンスメッセージを該電子メール転送装置から取得するレスポンスメッセージ取得手段と、
該レスポンスメッセージ中の公開鍵に信頼性が付与されているか否かを検証するレスポンスメッセージ信頼性付与検証手段と、
該レスポンスメッセージ信頼性付与検証手段が該レスポンスメッセージ中の公開鍵に該信頼性が付与されていることを検証した場合、該電子メール送信装置の私有鍵で電子署名され、該信頼性が付与された該電子メール受信装置の公開鍵により暗号化された電子メールを該電子メール受信装置に送信するメール送信手段と、
を有することを特徴とした電子メール転送装置。
（付記４）付記２において、
該電子メール受信装置が、
該電子メール転送装置から該トリガメッセージを取得するトリガメッセージ取得手段と、
該トリガメッセージ中の公開鍵に信頼性が付与されているか否かを検証するトリガメッセージ信頼性付与検証手段と、
トリガメッセージ信頼性付与検証手段が該トリガメッセージ中の公開鍵に信頼性が付与されていることを検証した場合、該レスポンスメッセージを該電子メール転送装置に送信するレスポンスメッセージ送信手段と、
該電子メール送信装置からの電子メールを、自己の私有鍵で復号化し、さらに該電子署名を該電子メール送信装置の公開鍵で復号化するメール受信手段と、
を有することを特徴とした電子メール転送装置。
（付記５）付記２において、
該トリガメッセージ信頼性付与手段は、該トリガメッセージ中の空欄となっている公開鍵証明書部分に該電子メール送信装置の公開鍵に対する自己の電子署名を付加すると共に、該レスポンスメッセージ中の空欄となっている公開鍵証明書部分に該電子メール受信装置の公開鍵に対する自己の電子署名を付加することを特徴とした電子メール転送装置。
（付記６）付記２において、
該電子メール送信装置及び電子メール受信装置が、各メッセージに同一かつネットワーク内でユニークなメッセージ識別子を付与することを特徴とした電子メール転送装置。
（付記７）付記２において、
該トリガメッセージ信頼性付与手段が、該トリガメッセージのヘッダ部に信頼性付与識別子を付与すると共に、該レスポンスメッセージ信頼性付与手段が該レスポンスメッセージのヘッダ部に信頼性付与識別子を付与することを特徴とした電子メール転送装置。
（付記８）付記２において、
該トリガメッセージ信頼性付与手段は、該トリガメッセージと共に信頼性付与識別子を送信し、該レスポンスメッセージ信頼性付与手段は、該レスポンスメッセージと共に信頼性付与識別子を送信することを特徴とした電子メール転送装置。
（付記９）付記２において、
該電子メール送信装置から、その公開鍵と該電子メール受信装置に対し暗号化及び電子署名付きメールの送信を要求する平文とを含むトリガメッセージを受信したとき、該トリガメッセージの公開鍵に信頼性を付与して該電子メール受信装置に送信し、該電子メール受信装置から、その公開鍵と暗号化及び電子署名付きメッセージを含むレスポンスメッセージを受信したとき、該レスポンスメッセージに信頼性を付与して該電子メール送信装置に送信することを特徴とした電子メール転送装置。
（付記１０）付記２において、
該電子メール送信装置及び該電子メール受信装置は、それぞれ、相手側の公開鍵をその識別子と共に保管する保管手段と、
該保管手段に保管した後、各メッセージを送信するとき、該識別子を該公開鍵の代わりに用いる手段とを有することを特徴とした電子メール転送装置。
（付記１１）付記２において、
該トリガメッセージ又は該レスポンスメッセージが有効であるか否かを判断する有効判断手段をさらに設け、
該有効判断手段が該トリガメッセージを有効でないと判断したとき、該トリガメッセージ信頼性付与手段が、該トリガメッセージのヘッダ部を変更した無効トリガメッセージを該電子メール送信装置に返送し、該有効判断手段が、該レスポンスメッセージを有効でないと判断したとき、該レスポンスメッセージ信頼性付与手段が該レスポンスメッセージのヘッダ部を変更して無効レスポンスメッセージを該電子メール受信装置に返送することを特徴とした電子メール転送装置。
（付記１２）付記５において、
該メッセージの宛先が相互認証している別の電子メール転送装置であるとき、自己の公開鍵を挿入した宛先の電子メール転送装置の公開鍵証明書を該メッセージに挿入する手段をさらに備えたことを特徴とした電子メール転送装置。
（付記１３）付記３又は４において、
電子メール送信装置及び電子メール受信装置が、メッセージを指定するためのメッセージ作成画面を有するメッセージ作成ユーザインタフェース、又はメッセージ状態を表示するためのメッセージ状態表示画面を有するメッセージ管理インタフェースを備えたことを特徴とした電子メール転送装置。
【図面の簡単な説明】
【０２７２】
【図１】本発明に係る電子メール転送方法及び装置の原理ブロック図である。
【図２】本発明で用いられるトリガメッセージ及びレスポンスメッセージの概略図である。
【図３】本発明に係る電子メール転送方法及び装置の実施の形態（１）におけるクライアントを示したブロック図である。
【図４】本発明に係る電子メール転送方法及び装置の実施の形態（１）におけるサーバの構成を示した図である。
【図５】本発明に係る電子メール転送方法及び装置の実施の形態（１）におけるトリガメッセージまたはレスポンスメッセージ送信時のユーザ認証手順を示したシーケンス図である。
【図６】本発明に係る電子メール転送方法及び装置の実施の形態（１）におけるトリガメッセージまたはレスポンスメッセージ取得時のユーザ認証手順を示したシーケンス図である。
【図７】本発明に係る電子メール転送方法及び装置の実施の形態（１）におけるトリガメッセージを具体的に示したフォーマット図である。
【図８】本発明に係る電子メール転送方法及び装置の実施の形態（１）におけるレスポンスメッセージを具体的に示したフォーマット図である。
【図９】本発明に係る電子メール転送方法及び装置の実施の形態の（１）におけるトリガメッセージおよびレスポンスメッセージで使用するSignedData(certs-only)のフォーマット図である。
【図１０】本発明に係る電子メール転送方法及び装置の実施の形態（２）で使用されるメッセージのフォーマット図を示し、同図（ａ）は図７に示したトリガメッセージの変形例を示し、同図（ｂ）は図８に示したレスポンスメッセージの変形例を示している。
【図１１】本発明に係る電子メール転送方法及び装置の実施の形態（３）の信頼性付与手順を示し、これは図６の変形例に相当するシーケンス図である。
【図１２】本発明に係る電子メール転送方法及び装置の実施の形態（４）を概略的に示したブロック図である。
【図１３】本発明に係る電子メール転送方法及び装置の本実施の形態（４）におけるトリガ‐コンテンツメッセージのフォーマット図を示し、これは図７の変形例に相当する図である。
【図１４】本発明に係る電子メール転送方法及び装置の本実施の形態（４）におけるレスポンス‐コンテンツメッセージフォーマット図を示し、図８の変形例に相当する図である。
【図１５】本発明に係る電子メール転送方法及び装置の実施の形態（５）におけるクライアントの構成を示したブロック図であり、これは図３の変形例に相当する。
【図１６】本発明に係る電子メール転送方法及び装置の実施の形態（６）におけのサーバの構成を示したブロック図であり、これは図４の変形例に相当する図である。
【図１７】本発明に係る電子メール転送方法及び装置の実施の形態（７）を概略的に示したブロック図である。
【図１８】本発明に係る電子メール転送方法及び装置の実施の形態（８）におけるユーザインタフェースのメッセージ画面図を示し、同図（ａ）はメッセージ作成ユーザインタフェースのメッセージ作成画面を示した図であり、同図（ｂ）はメッセージ管理ユーザインタフェースのメッセージ管理画面を示した図である。
【図１９】従来技術による暗号化・電子署名付メールを送受信する手順を説明するシーケンス図である。
【図２０】従来技術による認証局が公開鍵証明書を発行して、メール送受信ユーザが暗号化・電子署名付メールを送受信するまでの過程を示した図である。
【図２１】従来技術による公開鍵証明書のフォーマット及び証明書失効リスト(Certificate RevocationList)のフォーマット図である。
【符号の説明】
【０２７３】
１Ａ，１１Ａ，４１Ａ，５１Ａ  クライアント（電子メール送信装置）
１Ｂ，１１Ｂ，４１Ｂ，５１Ｂ  クライアント（電子メール受信装置）
１α，１γ，１１α，１１γ，４１α，４１γ，７１α，７２α  公開鍵
１β，１δ，１１β，１１δ，４１β，４１δ  私有鍵
３，１４  トリガメッセージ
１４ａ  トリガメッセージヘッダ部
４，１６  レスポンスメッセージ
１６ａ  レスポンスメッセージヘッダ部
５，１５，７５，７６  サーバ（電子メール転送装置）
１２ａ，５２ａ  トリガメッセージ作成部
１２ｂ，５２ｂ  トリガメッセージ送信部
１２ｃ，５２ｃ  トリガメッセージ取得部
１２ｄ，５２ｄ  レスポンスメッセージ作成部
１２ｅ,  ５２ｅ  レスポンスメッセージ送信部
１２ｆ，５２ｆ  レスポンスメッセージ取得部
１２ｇ，５２ｇ  暗号化及び電子署名付きメール送信部
１２ｈ，５２ｈ  暗号化及び電子署名付きメール受信部
１３ａ，５３ａ  公開鍵・私有鍵作成部
１３ｂ，５３ｂ  公開鍵検証部
１３ｃ，５３ｃ  鍵保管部
１５ａ，６５ａ  トリガメッセージ受信部
１５ｂ，６５ｂ  ユーザ認証部
１５ｃ，６５ｃ  信頼性付与部
１５ｄ，６５ｄ  トリガメッセージ取得応答部
１５ｅ，６５ｅレスポンスメッセージ受信部
１５ｅ，６５ｅ  レスポンスメッセージ取得応答部
１５ｄ，６５ｄ  トリガメッセージ取得要求応答部
１５ｅ，６５ｅ  レスポンスメッセージ受信部
１５ｆ，６５ｆ  レスポンスメッセージ゛取得要求応答部
１５ｇ，６５ｇ  認証データ保管部１５
９７，９７Ｃ，９７Ｄ  公開鍵証明書
６５ｊ  メッセージ有効判断部
８１  メッセージ作成ユーザインターフェース
８１ａ  メッセージ作成画面
８２  メッセージ管理インターフェース  
８２ａ  メッセージ管理画面
図中、同一符号は同一又は相当部分を示す。
【図１】
2006260490.tif 000004
【図２】
2006260490.tif 000005
【図３】
2006260490.tif 000006
【図４】
2006260490.tif 000007
【図５】
2006260490.tif 000008
【図６】
2006260490.tif 000009
【図７】
2006260490.tif 000010
【図８】
2006260490.tif 000011
【図９】
2006260490.tif 000012
【図１０】
2006260490.tif 000013
【図１１】
2006260490.tif 000014
【図１２】
2006260490.tif 000015
【図１３】
2006260490.tif 000016
【図１４】
2006260490.tif 000017
【図１５】
2006260490.tif 000018
【図１６】
2006260490.tif 000019
【図１７】
2006260490.tif 000020
【図１８】
2006260490.tif 000021
【図１９】
2006260490.tif 000022
【図２０】
2006260490.tif 000023
【図２１】
2006260490.tif 000024