JP4601470B2 - 電子メール転送方法及び装置 - Google Patents

電子メール転送方法及び装置 Download PDF

Info

Publication number
JP4601470B2
JP4601470B2 JP2005080717A JP2005080717A JP4601470B2 JP 4601470 B2 JP4601470 B2 JP 4601470B2 JP 2005080717 A JP2005080717 A JP 2005080717A JP 2005080717 A JP2005080717 A JP 2005080717A JP 4601470 B2 JP4601470 B2 JP 4601470B2
Authority
JP
Japan
Prior art keywords
mail
public key
message
response message
reliability
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2005080717A
Other languages
English (en)
Other versions
JP2006260490A (ja
Inventor
祐治 小島
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2005080717A priority Critical patent/JP4601470B2/ja
Priority to US11/186,359 priority patent/US8060746B2/en
Publication of JP2006260490A publication Critical patent/JP2006260490A/ja
Application granted granted Critical
Publication of JP4601470B2 publication Critical patent/JP4601470B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution

Description

本発明は、電子メール転送方法及び装置に関し、特に、電子メール送信装置及び電子メール受信装置間で公開鍵暗号化方式により電子メールを転送するための電子メール転送方法及び装置に関する。
従来、インターネット上で電子メールの平文を暗号化する方式として、暗号化と復号化に共通の鍵を使用する共通鍵暗号化方式と、暗号化と復号化にそれぞれ違う鍵を使用する公開鍵暗号化方式が知られている。ここで、平文とは、電子メールの暗号化される前のメッセージをいう。
上記共通鍵暗号化方式では、電子メール送信装置(以下、メール送信ユーザ又はクライアントと称することがある。)と電子メール受信装置(以下、メール受信ユーザ又はクライアントと称することがある。)とが共通鍵を予め所有して、メール送信ユーザは平文を共通鍵で暗号化した暗号文をメール受信ユーザに送信し、メール受信ユーザは暗号文を共通鍵で復号化する。これにより、メール送信ユーザからメール受信ユーザへの送信過程での「情報漏洩」を防止する。しかしながら、不正な第三者による「なりすまし」や、「改竄」を防ぐための電子署名が困難であり、共通鍵の安全な配送が必要となる。
上記問題に対処するため、公開鍵暗号化方式は、異なる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>
Figure 0004601470
 なお、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)のフォーマット図である。
符号の説明
１Ａ，１１Ａ，４１Ａ，５１Ａ クライアント（電子メール送信装置）
１Ｂ，１１Ｂ，４１Ｂ，５１Ｂ クライアント（電子メール受信装置）
１α，１γ，１１α，１１γ，４１α，４１γ，７１α，７２α 公開鍵
１β，１δ，１１β，１１δ，４１β，４１δ 私有鍵
３，１４ トリガメッセージ
１４ａ トリガメッセージヘッダ部
４，１６ レスポンスメッセージ
１６ａ レスポンスメッセージヘッダ部
５，１５，７５，７６ サーバ（電子メール転送装置）
１２ａ，５２ａ トリガメッセージ作成部
１２ｂ，５２ｂ トリガメッセージ送信部
１２ｃ，５２ｃ トリガメッセージ取得部
１２ｄ，５２ｄ レスポンスメッセージ作成部
１２ｅ, ５２ｅ レスポンスメッセージ送信部
１２ｆ，５２ｆ レスポンスメッセージ取得部
１２ｇ，５２ｇ 暗号化及び電子署名付きメール送信部
１２ｈ，５２ｈ 暗号化及び電子署名付きメール受信部
１３ａ，５３ａ 公開鍵・私有鍵作成部
１３ｂ，５３ｂ 公開鍵検証部
１３ｃ，５３ｃ 鍵保管部
１５ａ，６５ａ トリガメッセージ受信部
１５ｂ，６５ｂ ユーザ認証部
１５ｃ，６５ｃ 信頼性付与部
１５ｄ，６５ｄ トリガメッセージ取得応答部
１５ｅ，６５ｅレスポンスメッセージ受信部
１５ｅ，６５ｅ レスポンスメッセージ取得応答部
１５ｄ，６５ｄ トリガメッセージ取得要求応答部
１５ｅ，６５ｅ レスポンスメッセージ受信部
１５ｆ，６５ｆ レスポンスメッセージ゛取得要求応答部
１５ｇ，６５ｇ 認証データ保管部１５
９７，９７Ｃ，９７Ｄ 公開鍵証明書
６５ｊ メッセージ有効判断部
８１ メッセージ作成ユーザインターフェース
８１ａ メッセージ作成画面
８２ メッセージ管理インターフェース
８２ａ メッセージ管理画面
図中、同一符号は同一又は相当部分を示す。

Claims (10)

  1. 公開鍵暗号化方式により電子メール送信装置及び電子メール受信装置間で電子メール転送装置が電子メールを転送するための電子メール転送方法であって、
    ユーザ認証データと公開鍵が付加されたトリガメッセージを受信するトリガメッセージ受信ステップと、
    該ユーザ認証データを認証するユーザ認証ステップと、
    該ユーザ認証ステップにより該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して送信するトリガメッセージ信頼性付与ステップと、
    ユーザ認証データと公開鍵が付加されたレスポンスメッセージを受信するレスポンスメッセージ受信ステップと、
    該ユーザ認証ステップにより該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して送信するレスポンスメッセージ信頼性付与ステップと、
    を有し、該電子メール送信装置が、
    該トリガメッセージを該電子メール転送装置に送信し、
    該電子メール受信装置からのレスポンスメッセージを該電子メール転送装置から取得し、
    該レスポンスメッセージ中の公開鍵に信頼性が付与されているか否かを検証し、
    該レスポンスメッセージ中の公開鍵に該信頼性が付与されていることが検証された場合、該電子メール送信装置の私有鍵で電子署名され、該信頼性が付与された該電子メール受信装置の公開鍵により暗号化された電子メールを該電子メール受信装置に送信することを特徴とした電子メール転送方法。
  2. 公開鍵暗号化方式により電子メール送信装置及び電子メール受信装置間で電子メール転送装置が電子メールを転送するための電子メール転送方法であって、
    ユーザ認証データと公開鍵が付加されたトリガメッセージを受信するトリガメッセージ受信ステップと、
    該ユーザ認証データを認証するユーザ認証ステップと、
    該ユーザ認証手段により該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して送信するトリガメッセージ信頼性付与ステップと、
    ユーザ認証データと公開鍵が付加されたレスポンスメッセージを受信するレスポンスメッセージ受信ステップと、
    該ユーザ認証ステップにより該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して送信するレスポンスメッセージ信頼性付与ステップと、
    を有し、該電子メール受信装置が、
    該電子メール転送装置から該トリガメッセージを取得し、
    該トリガメッセージ中の公開鍵に信頼性が付与されているか否かを検証し、
    該トリガメッセージ中の公開鍵に信頼性が付与されていることが検証された場合、該レスポンスメッセージを該電子メール転送装置に送信し、
    該電子メール送信装置からの該電子メール送信装置の私有鍵で電子署名され、該信頼性が付与された該電子メール受信装置の公開鍵により暗号化された電子メールを、自己の私有鍵で復号化し、さらに該電子署名を該電子メール送信装置の公開鍵で復号化することを特徴とした電子メール転送方法。
  3. 電子メール送信装置及び電子メール受信装置間で公開鍵暗号化方式により電子メールを転送するための電子メール転送装置であって、
    ユーザ認証データと公開鍵が付加されたトリガメッセージを該電子メール送信装置から受信するトリガメッセージ受信手段と、
    該ユーザ認証データを認証するユーザ認証手段と、
    該ユーザ認証手段により該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して該電子メール受信装置に送信するトリガメッセージ信頼性付与手段と、
    ユーザ認証データと公開鍵が付加されたレスポンスメッセージを該電子メール受信装置から受信するレスポンスメッセージ受信手段と、
    該ユーザ認証手段により該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して該電子メール送信装置に送信するレスポンスメッセージ信頼性付与手段と、
    を有し、該電子メール送信装置が、
    該トリガメッセージを該電子メール転送装置に送信するトリガメッセージ送信手段と、
    該電子メール受信装置からのレスポンスメッセージを該電子メール転送装置から取得するレスポンスメッセージ取得手段と、
    該レスポンスメッセージ中の公開鍵に信頼性が付与されているか否かを検証するレスポンスメッセージ信頼性付与検証手段と、
    該レスポンスメッセージ信頼性付与検証手段が該レスポンスメッセージ中の公開鍵に該信頼性が付与されていることを検証した場合、該電子メール送信装置の私有鍵で電子署名され、該信頼性が付与された該電子メール受信装置の公開鍵により暗号化された電子メールを該電子メール受信装置に送信するメール送信手段と、
    を有することを特徴とした電子メール転送装置。
  4. 電子メール送信装置及び電子メール受信装置間で公開鍵暗号化方式により電子メールを転送するための電子メール転送装置であって、
    ユーザ認証データと公開鍵が付加されたトリガメッセージを該電子メール送信装置から受信するトリガメッセージ受信手段と、
    該ユーザ認証データを認証するユーザ認証手段と、
    該ユーザ認証手段により該トリガメッセージ中のユーザ認証データが認証されたとき、該トリガメッセージ中の公開鍵に信頼性を付与して該電子メール受信装置に送信するトリガメッセージ信頼性付与手段と、
    ユーザ認証データと公開鍵が付加されたレスポンスメッセージを該電子メール受信装置から受信するレスポンスメッセージ受信手段と、
    該ユーザ認証手段により該レスポンスメッセージ中のユーザ認証データが認証されたとき、該レスポンスメッセージ中の公開鍵に信頼性を付与して該電子メール送信装置に送信するレスポンスメッセージ信頼性付与手段と、
    を有し、該電子メール受信装置が、
    該電子メール転送装置から該トリガメッセージを取得するトリガメッセージ取得手段と、
    該トリガメッセージ中の公開鍵に信頼性が付与されているか否かを検証するトリガメッセージ信頼性付与検証手段と、
    トリガメッセージ信頼性付与検証手段が該トリガメッセージ中の公開鍵に信頼性が付与されていることを検証した場合、該レスポンスメッセージを該電子メール転送装置に送信するレスポンスメッセージ送信手段と、
    該電子メール送信装置からの該電子メール送信装置の私有鍵で電子署名され、該信頼性が付与された該電子メール受信装置の公開鍵により暗号化された電子メールを、自己の私有鍵で復号化し、さらに該電子署名を該電子メール送信装置の公開鍵で復号化するメール受信手段と、
    を有することを特徴とした電子メール転送装置。
  5. 請求項３又は４において、
    該トリガメッセージ信頼性付与手段は、該トリガメッセージ中の空欄となっている公開鍵証明書部分に該電子メール送信装置の公開鍵に対する自己の電子署名を付加すると共に、該レスポンスメッセージ中の空欄となっている公開鍵証明書部分に該電子メール受信装置の公開鍵に対する自己の電子署名を付加することを特徴とした電子メール転送装置。
  6. 請求項３又は４において、
    該電子メール送信装置及び電子メール受信装置が、各メッセージに同一かつネットワーク内でユニークなメッセージ識別子を付与することを特徴とした電子メール転送装置。
  7. 請求項３又は４において、
    該トリガメッセージ信頼性付与手段が、該トリガメッセージのヘッダ部に信頼性付与識別子を付与すると共に、該レスポンスメッセージ信頼性付与手段が該レスポンスメッセージのヘッダ部に信頼性付与識別子を付与することを特徴とした電子メール転送装置。
  8. 請求項３又は４において、
    該電子メール送信装置から、その公開鍵と該電子メール受信装置に対し暗号化及び電子署名付きメールの送信を要求する平文とを含むトリガメッセージを受信したとき、該トリガメッセージの公開鍵に信頼性を付与して該電子メール受信装置に送信し、該電子メール受信装置から、その公開鍵と暗号化及び電子署名付きメッセージを含むレスポンスメッセージを受信したとき、該レスポンスメッセージに信頼性を付与して該電子メール送信装置に送信することを特徴とした電子メール転送装置。
  9. 請求項３又は４において、
    該電子メール送信装置及び該電子メール受信装置は、それぞれ、相手側の公開鍵をその識別子と共に保管する保管手段と、該保管手段に保管した後、各メッセージを送信するとき、該識別子を該公開鍵の代わりに用いる手段とを有することを特徴とした電子メール転送装置。
  10. 請求項３又は４において、
    電子メール送信装置及び電子メール受信装置が、メッセージを指定するためのメッセージ作成画面を有するメッセージ作成ユーザインタフェース、又はメッセージ状態を表示するためのメッセージ状態表示画面を有するメッセージ管理インタフェースを備えたことを特徴とした電子メール転送装置。
JP2005080717A 2005-03-18 2005-03-18 電子メール転送方法及び装置 Expired - Fee Related JP4601470B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2005080717A JP4601470B2 (ja) 2005-03-18 2005-03-18 電子メール転送方法及び装置
US11/186,359 US8060746B2 (en) 2005-03-18 2005-07-21 E-mail transfer method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005080717A JP4601470B2 (ja) 2005-03-18 2005-03-18 電子メール転送方法及び装置

Publications (2)

Publication Number Publication Date
JP2006260490A JP2006260490A (ja) 2006-09-28
JP4601470B2 true JP4601470B2 (ja) 2010-12-22

Family

ID=37011737

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005080717A Expired - Fee Related JP4601470B2 (ja) 2005-03-18 2005-03-18 電子メール転送方法及び装置

Country Status (2)

Country Link
US (1) US8060746B2 (ja)
JP (1) JP4601470B2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101784756B1 (ko) 2010-05-21 2017-10-12 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 멀티-테넌트 환경 내에서의 신뢰되는 전자 우편 통신

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6990581B1 (en) * 2000-04-07 2006-01-24 At&T Corp. Broadband certified mail
US8015484B2 (en) * 2006-02-09 2011-09-06 Alejandro Backer Reputation system for web pages and online entities
EP1876549A1 (de) 2006-07-07 2008-01-09 Swisscom Mobile AG Verfahren und System zur verschlüsselten Datenübertragung
JP4245016B2 (ja) * 2006-08-18 2009-03-25 ブラザー工業株式会社 電子メール通信装置及びコンピュータプログラム
US7756937B2 (en) * 2006-08-18 2010-07-13 Brother Kogyo Kabushiki Kaisha Network device
JP4727627B2 (ja) * 2007-07-06 2011-07-20 富士通株式会社 電子メールの検証情報生成プログラム、及びその装置、ならびにその方法、電子メールの検証プログラム、及びその装置
US8462942B2 (en) * 2008-12-31 2013-06-11 Verizon Patent And Licensing Inc. Method and system for securing packetized voice transmissions
EP2302536A1 (en) * 2009-09-21 2011-03-30 Thomson Licensing System and method for automatically verifying storage of redundant contents into communication equipments, by data comparison
EP2500839A4 (en) 2009-11-09 2016-11-16 Nec Corp ACCESS CONTROL SYSTEM, COMMUNICATION END, SERVER AND ACCESS CONTROL METHOD
JP5310761B2 (ja) * 2011-03-04 2013-10-09 トヨタ自動車株式会社 車両ネットワークシステム
JP2012216023A (ja) * 2011-03-31 2012-11-08 Toshiba Corp 通信装置、通信プログラム、及び通信システム
US9148449B2 (en) * 2013-03-13 2015-09-29 Authentify, Inc. Efficient encryption, escrow and digital signatures
US9519805B2 (en) * 2013-08-01 2016-12-13 Cellco Partnership Digest obfuscation for data cryptography
EP2846500A1 (en) * 2013-09-06 2015-03-11 Lleidanetworks Serveis Telemàtics S.A. Method for producing certified electronic contracts by a user of a telecommunications provider
US9515824B2 (en) * 2013-10-21 2016-12-06 Aruba Networks, Inc. Provisioning devices for secure wireless local area networks
US10897460B2 (en) * 2014-10-10 2021-01-19 Tim Draegen Third-party documented trust linkages for email streams
JP6565194B2 (ja) * 2015-01-15 2019-08-28 富士通株式会社 端末判定装置、方法、及びプログラム
PT3188435T (pt) * 2015-12-28 2020-01-22 Lleidanetworks Serveis Telematics Sa Método para certificar um correio eletrónico compreendendo uma assinatura digital confiável por um operador de telecomunicações
JP6780410B2 (ja) * 2016-09-28 2020-11-04 日本電気株式会社 メール転送方法、メール転送装置およびメール転送プログラム
CN109104280B (zh) * 2017-06-20 2021-09-28 腾讯科技（深圳）有限公司 转发消息的方法及装置
US10896032B2 (en) * 2018-11-02 2021-01-19 Accenture Global Solutions, Limited System and method for certifying and deploying instruction code
JP2024042421A (ja) * 2022-09-15 2024-03-28 株式会社日立製作所 トラスト連携システム、トラスト連携方法及びトラストコネクタ

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001144745A (ja) * 1999-11-15 2001-05-25 Tatsuhiro Meya 電子認証方式
JP2004336776A (ja) * 2003-05-02 2004-11-25 Lucent Technol Inc モバイル・セキュリティ・アーキテクチャ

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6760752B1 (en) * 1999-06-28 2004-07-06 Zix Corporation Secure transmission system
JP2001134534A (ja) 1999-11-08 2001-05-18 Ntt Communications Kk 認証代行方法、認証代行サービスシステム、認証代行サーバ装置及びクライアント装置
US7174368B2 (en) * 2001-03-27 2007-02-06 Xante Corporation Encrypted e-mail reader and responder system, method, and computer program product
US7343394B2 (en) * 2003-03-10 2008-03-11 International Business Machines Corporation Method of managing e-mail messages
JP4324428B2 (ja) * 2003-07-28 2009-09-02 富士通株式会社 メール送信方法、メール送信プログラムおよびメール送信サーバ
US7437558B2 (en) * 2004-06-01 2008-10-14 Cisco Technology, Inc. Method and system for verifying identification of an electronic mail message

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001144745A (ja) * 1999-11-15 2001-05-25 Tatsuhiro Meya 電子認証方式
JP2004336776A (ja) * 2003-05-02 2004-11-25 Lucent Technol Inc モバイル・セキュリティ・アーキテクチャ

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101784756B1 (ko) 2010-05-21 2017-10-12 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 멀티-테넌트 환경 내에서의 신뢰되는 전자 우편 통신
KR101903923B1 (ko) 2010-05-21 2018-10-02 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 멀티-테넌트 환경 내에서의 신뢰되는 전자 우편 통신

Also Published As

Publication number Publication date
JP2006260490A (ja) 2006-09-28
US20060212703A1 (en) 2006-09-21
US8060746B2 (en) 2011-11-15

Similar Documents

Publication Publication Date Title
JP4601470B2 (ja) 電子メール転送方法及び装置
US7644268B2 (en) Automated electronic messaging encryption system
US8103867B2 (en) Method and system for obtaining digital signatures
Kent Internet privacy enhanced mail
US6092201A (en) Method and apparatus for extending secure communication operations via a shared list
US7146009B2 (en) Secure electronic messaging system requiring key retrieval for deriving decryption keys
US5774552A (en) Method and apparatus for retrieving X.509 certificates from an X.500 directory
US8489877B2 (en) System, method and computer product for sending encrypted messages to recipients where the sender does not possess the credentials of the recipient
US20070055867A1 (en) System and method for secure provisioning of encryption keys
US7971061B2 (en) E-mail system and method having certified opt-in capabilities
Schaad et al. Secure/multipurpose internet mail extensions (S/MIME) version 4.0 message specification
US20080187140A1 (en) Method and System of Securely Transmitting Electronic Mail
US20070288746A1 (en) Method of providing key containers
JP3711931B2 (ja) 電子メールシステム、その処理方法及びそのプログラム
Al-Hammadi et al. Certified exchange of electronic mail (CEEM)
van Oorschot et al. Public-key certificate management and use cases
US20020152383A1 (en) Method for measuring the latency of certificate providing computer systems
Moser S/MIME
Kovinić et al. Securing Service Access with Digital Certificates
KR20050024765A (ko) 스팸메일 차단 방법 및 시스템
Liao Securing e-mail communication with XML technology
WO2002071719A1 (en) A method and system for encrypting digital messages
Kent SECURITY SERVICES
Reddy et al. Establishment of Public Key Infrastructure for Digital Signatures
Razali et al. A Framework for Electronic Bill Presentment and Off-Line Message Viewing

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20071120

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100319

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100427

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100628

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100928

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100928

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131008

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees