JP2001285282A

JP2001285282A - 認証方式

Info

Publication number: JP2001285282A
Application number: JP2000093685A
Authority: JP
Inventors: Hiroyuki Sakakibara; 裕之榊原
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2000-03-30
Filing date: 2000-03-30
Publication date: 2001-10-12

Abstract

(57)【要約】【課題】公開鍵証明証の検証を行なう際、検証時間を
短縮するとともに、改竄不正を早期に検出する認証方式
を得る。【解決手段】被発行者が被発行者名と被発行者の公開
鍵に関する情報を含む証明証の発行を要求し、発行者が
要求された証明証を識別する証明証識別情報と証明証の
発行に対する被発行者の合意を確認するための合意情報
とを被発行者に送付し、被発行者は、送付された証明証
識別情報に記載された証明証の発行に合意する場合、合
意情報に署名して署名付き合意情報を発行者に送付し、
発行者は、受け取った署名付き合意情報を含む証明証を
発行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、証明証を利用し
た公開鍵暗号運用システムにおける、公開鍵証明証の検
証方式、認証方式に関するものである。特に、証明証の
認証に際して、偽造証明証を検出する認証方式に関する
ものである。

【０００２】

【従来の技術】公開鍵証明証（以下、証明証とも言う）
の検証の方式としては、例えば、ＲＦＣ２４５９（Ｉｎ
ｔｅｒｎｅｔＸ．５０９ＰｕｂｌｉｃＫｅｙＩ
ｎｆｒａｓｔｒｕｃｔｕｒｅＣｅｒｔｉｆｉｃａｔｅ
ａｎｄＣＲＬＰｒｏｆｉｌｅ）に記載の方式等が
存在する。ＲＦＣとは、ｒｅｑｕｅｓｔｆｏｒｃｏ
ｍｍｅｎｔｓであり、インターネットの研究開発機関、
ＩＥＴＦ（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇ
ＴａｓｋＦｏｒｃｅ）が取りまとめている文書群を
指す。これらの方式では、Ｘ．５０９ｖｅｒ３ベース
の証明証における検証時の必要事項を述べてある。

【０００３】図１５は、上述したＲＦＣ２４５９に記載
の方式に則った証明証の発行方式の一例である。図中に
おいて、１０３で示す認証局ＣＡ３（ＣＡ：Ｃｅｒｔｉ
ｆｉｃａｔｉｏｎＡｕｔｈｏｒｉｔｙ、以下同じ），
１０２の認証局ＣＡ２，１０１の認証局ＣＡ１は階層構
造をなしている。認証局ＣＡ３は自己署名証明証である
１１３証明証Ｃｅｒｔ＿ＣＡ３を自分自身で自分自身に
対して発行する（矢印１２３）。それにより、自分の公
開鍵が、自分自身の所持するものであることを証明す
る。さらに、認証局ＣＡ３は発行者として、被発行者で
ある認証局ＣＡ２に対して１１２証明証Ｃｅｒｔ＿ＣＡ
２を発行し、認証局ＣＡ２の公開鍵を証明する（矢印１
２２）。同様に、認証局ＣＡ２は認証局ＣＡ１に１１１
証明証Ｃｅｒｔ＿ＣＡ１を発行する（矢印１２１）。さ
らに、認証局ＣＡ１はＥｎｄ＿Ｅｎｔｉｔｙである１０
４ＥＥに１１４証明証Ｃｅｒｔ＿ＥＥを発行する（矢印
１２４）。このように、上位の認証局が発行者となり、
下位の被発行者（認証局ないしＥｎｄ＿Ｅｎｔｉｔｙ）
に対して、証明証を発行する階層構造をなす。

【０００４】この様な、階層的な証明証の発行形態にお
ける各証明証の検証方式を説明する。図１６は、証明証
の検証について示した図である。図において、２０１
は、１１４で示すＣｅｒｔ＿ＥＥと１１１で示すＣｅｒ
ｔ＿ＣＡ１との関係を示している。証明証１１４は、認
証局ＣＡ１の秘密鍵で署名が施されている。まず、証明
証１１４を検証するためには、証明証１１４に施されて
いる署名の検証を行う必要があり、証明証１１４の発行
者、すなわち、認証局ＣＡ１の公開鍵を証明する証明証
である１１１のＣｅｒｔ＿ＣＡ１が必要となる。つま
り、証明証１１１に含まれる公開鍵を利用して、証明証
１１４の署名を検証することが必要である。

【０００５】そこで、証明証１１４の上位の証明証であ
る１１１を取得する必要があるが、以下に取得方法を示
す。証明証１１４（下位証明証）に含まれる発行者名は
ＣＡ１であり、証明証１１１（上位証明証）の被発行者
名であるＣＡ１と一致している。また、証明証１１４に
含まれる上位証明証識別子（上位証明証情報とも言う）
は、証明証１１１を示す情報で構成される。証明証１１
１を示す情報とは、例えば、証明証１１１の“発行者名
ＣＡ２”と“ＳＮ（ＳｅｒｉａｌＮｕｍｂｅｒ：通し
番号）”などである。Ｘ．５０９ｖｅｒ３では、ａｕ
ｔｈｏｒｉｔｙＫｅｙＩｄｅｎｔｉｆｉｅｒというエク
ステンションがここで言う上位証明証識別子に該当す
る。また、証明証１１４の署名は、証明証１１１に含ま
れる認証局ＣＡ１の公開鍵ＰｕｂＫｅｙ＿ＣＡ１で検証
可能である。この場合、認証局ＣＡ１は複数の公開鍵を
持つ可能性があるので、それらの複数の公開鍵をそれぞ
れ証明する認証局ＣＡ１の複数の証明証のうち、証明証
１１４の署名を検証可能な公開鍵を含む認証局ＣＡ１の
証明証が必要である。従って、これらの一致を調べるこ
とにより、上位の証明証として証明証１１１を取得す
る。一致を調べるとは、証明証１１１に含まれる公開鍵
を用いて、証明証１１４の署名を検証し、検証が成功す
ることを確認することによって行われる。

【０００６】なお、証明証の仕様により、上位証明証識
別子は、どの証明証にも必ず含まれるとは限らない。こ
のため、上位証明証を取得する汎用的な方法として、証
明証１１４の発行者名＝証明証１１１の被発行者名、証
明証１１４の署名が証明証１１１の公開鍵で検証可能
という２点を調べる方法がある。

【０００７】次に、証明証１１１を取得した後について
述べる。証明証１１１は、認証局ＣＡ２により発行され
ており、署名が付加されているので、前述した説明と同
様に、認証局ＣＡ２の証明証１１２が必要となる。同様
に、証明証１１２は、証明証１１３を必要とする。この
ように、１つの証明証を検証するために段階的に上位の
証明証を取得していく。

【０００８】当例では、認証局ＣＡ３は上位の認証局を
持たず、認証局ＣＡ３の証明証１１３は、自己発行、自
己署名の形式をとるものとする。すなわち、証明証１１
３の署名は証明証１１３に含まれる公開鍵で検証可能で
ある。当例では、証明証１１４の検証者は、証明証１１
３を信用していると仮定して説明する。

【０００９】図１７は、公開鍵証明証を検証する際の、
証明証パスを示す図である。図１７において、２０２は
このようにして集めた証明証を下位から上位へ順番に並
べたものである。このように、検証対象の証明証（ここ
では１１４）からはじまり、検証者が信用している証明
証（ここでは１１３）で終端する並びを、“証明証パ
ス”と呼ぶものとする。１１４、１１１、１１２、１１
３が、証明証１１４を検証するための証明証パスであ
る。一般にシステムは、信用する証明証のリストを保持
しており、該リスト上に載っている証明証の被発行者名
と、発行者名が一致する証明証があれば、その証明証を
取得し、リスト上の該証明証で終端することが判断可能
である。仮に、信用する証明証のリストで終端しない場
合には、例えば、信頼できるエンティティから、フロッ
ピー（登録商標）ディスク等で、入手する。２０３の矢
印は、“証明証パスの構築（以下、単にパスの構築とも
いう）”を表しており、構築の向きを示す。パスの構築
の際には、検証対象の証明証から、信用する証明証ま
で、段階的に溯って収集する。すなわち、１１４から始
めて、１１３で終わる。２０４の矢印は“証明証パスの
検証（以下、単にパスの検証ともいう）”を表してお
り、検証の向きを示す。パスの検証の際には、署名など
の項目を用いて、信用する証明証から、検証対象の証明
証まで、段階的に、検証を行なう。ここでは、信用する
証明証１１３を利用して証明証１１２の署名や、エクス
テンション等のその他の項目を検証し、証明証１１２の
検証に成功した場合は、同様に、証明証１１２を利用し
て証明証１１１を、証明証１１１を利用して証明証１１
４を検証し、１１２から１１４までの全ての検証に成功
して始めて、証明証１１４の検証に成功したことにな
る。このように、図１６、図１７に示すように、証明証
の検証は、”パスの構築”と、”パスの検証”と言う２
つの処理から成り立つ。

【００１０】

【発明が解決しようとする課題】従来の検証方式では、
図１５から図１７に示すように、証明証を認証（検証）
するためには、証明証パスの構築を全て行ってから、証
明証パスの検証を行う必要がある。なぜならば、Ｘ．５
０９ｖｅｒ３のエクステンションの一部には、上位か
ら下位の方向に検証すべきものが存在するからである。

【００１１】ここで、図を用いて、従来技術における問
題点、既存の技術の範疇の中で受ける可能性のある攻撃
の具体例を挙げる。図１８は偽造パスの例を示す図であ
る。図１８において、３８０の鎖線で囲んで示す各証明
証１１４、１１１、１１２、１１３は、正しい証明証パ
スを表す。３００は“悪意を持った第三者”であり、偽
造証明証３０１、３０２を生成する。３９０の鎖線で囲
んで示す各証明証のうち、偽造証明証３０１は正しい証
明証１１１を偽造したものであり、偽造証明証３０２は
正しい証明証１１２を偽造したものであるとする。そし
て、１１４、３０１、３０２、１１３という証明証パス
を構成する。

【００１２】悪意を持った第三者３００により生成され
た偽造証明証３０１について解説する。偽造証明証３０
１は、発行者名、ＳＮ、被発行者名、公開鍵について
は、正しい証明証１１１と同じ情報、すなわち正しい情
報を利用し、上位証明証識別子’は、偽造証明証３０２
を示すように偽造する。悪意を持った第三者３００は、
公開鍵鍵対である、公開鍵ＰｕｂＫｅｙ＿ＣＡ２’、秘
密鍵ＰｒｉＫｅｙ＿ＣＡ２’を生成し、偽造証明証３０
１の署名は、ＰｒｉＫｅｙ＿ＣＡ２’で署名する。偽造
証明証３０２は、発行者名、ＳＮ、被発行者名、は正し
い証明証１１２と同じ情報、すなわち正しい情報を利用
して、公開鍵ＰｕｂＫｅｙ＿ＣＡ２’を含む。上位証明
証識別子は、信用する証明証１１３を示すようにする。
偽造証明証３０２は、ＰｕｂＫｅｙ＿ＣＡ２’を含むの
で、偽造証明証３０１の署名を検証可能である。このよ
うに、証明証の偽造を行うことで、１１４、３０１、３
０２、１１３で構成される偽の証明証パスを生成でき
る。以後、偽の証明証パスを、“偽造証明証パス”と呼
ぶことにする。

【００１３】パスの構築処理では、前に述べたように、
検証対象の証明証と上位証明証の候補の間で、「検証対
象の証明証の発行者名と候補の上位証明証の被発行者名
とが一致すること」、「検証対象の証明証の上位証明証
識別子が候補の上位証明証を示していること」、「検証
対象の証明証の署名を、候補の上位証明証に含まれてい
る公開鍵で検証が可能であること」、などの条件に合致
する候補の証明証を上位証明証として取得する。このと
き、証明証１１４を検証する検証者に、各証明証１１
１，１１２，１１３，３０１，３０２を上位証明証の候
補としてランダムに与えた場合、検索順で、先に偽造証
明証３０１を選択する可能性がある。偽造証明証３０１
は、証明証１１４の上位証明証として整合性が取れるよ
うに偽造してあるので、その場合、誤って、偽造証明証
３０１を上位証明証として取得する場合がある。する
と、証明証の内容に従って３０１、３０２、１１３と順
次取得する。この場合、偽造した証明証３０１の署名は
その上位の証明証３０２に含まれる公開鍵で検証可能だ
が、該上位の証明証３０２の署名は、信用する証明証１
１３の公開鍵で検証できないため、検証者は、当証明証
パスを破棄する。何故なら、悪意を持った第三者３００
は、信用する証明証１１３に含まれる公開鍵と対の秘密
鍵を知ることができないために、信用する証明証１１３
に含まれる公開鍵で検証可能な署名を生成して偽造証明
証３０２に含めることが、不可能だからである。従っ
て、３０１、３０２を偽造証明証と判断できるので、破
棄するのである。

【００１４】当例では、偽造証明証は、３０１、３０２
の２つだが、同じ要領で、３０２のさらに上位の証明証
を偽造することで、任意の長さの偽造証明証パスを生成
することが可能である。検証者は、長い偽造証明証パス
を与えられた場合でも、信用する証明証１１３に辿り着
くまで証明証の取得処理を行わないと偽造を検出できな
いので、結局、偽造証明証パスの最後の証明証まで取得
せざるを得ない。従って、検証者にとっては、証明証パ
ス構築の処理が大きくなり、負担になる。つまり、悪意
を持った第三者３００は、図１９の４０１に示す偽造パ
スの例のように、任意の長さの偽造証明証パスを作成可
能であり、検証者に故意に偽造証明証パスを与え、無駄
な処理をさせることで、検証者の負荷を増大させるとい
う攻撃が可能になってしまうという問題点があった。

【００１５】また、偽造証明証パスは、１１４で示すよ
うな検証対象の証明証に対して、複数生成することが可
能である。検証者が上位証明証の検索のために利用す
る、ディレクトリサービスなどの公開オンラインデータ
ベースに、偽造証明証パスを構成する偽造証明証を混入
させることが可能な場合がある。悪意を持った第三者は
偽造証明証パスを複数生成し、それらを構成する偽造証
明証をデータベースに混入させる。すると、検証者は検
索する証明証が増える分、偽造証明証パスを選択する確
率が高くなり、無駄な処理が増える可能性が高いという
問題点が生じる。これを偽造証明証パス攻撃と呼ぶこと
にする。

【００１６】偽造証明証パスでは、悪意を持った第三者
が、独自で生成した鍵対を用いて証明証を偽造するの
で、最終的には、検証者が信用する証明証の公開鍵を用
いて、当証明証の直下にくる４０１の終端偽造上位証明
証の署名を検証した場合に、失敗するので、偽造である
ことが検出される。何故なら、悪意を持った第三者は、
検証者が信用する証明証に含まれる公開鍵と対の秘密鍵
を知ることができないからである。従って、偽造証明証
パスを正しい証明証パスとして扱うことはない。しか
し、４０１の偽造パスを構築している間は、偽造パスに
含まれる偽造証明証間の整合性は取れている。従って、
偽造証明証パスを検出するためには、常に終端偽造上位
証明証まで辿り、信用する証明証に含まれる公開鍵によ
る署名の検証が必要である。この検証方法が偽造証明証
パス攻撃を可能にしているという問題点がある。

【００１７】また、証明証の検証においては、証明証の
失効を確認する必要がある。証明証パスに含まれる各証
明証について失効を確認する必要があるが、その手段と
して、ＲＦＣ２４５９で規定される”ＣＲＬ（Ｃｅｒｔ
ｉｆｉｃａｔｅＲｅｖｏｃａｔｉｏｎＬｉｓｔ）”
という情報や、ＲＦＣ２５６０（Ｘ．５０９Ｉｎｔ
ｅｒｎｅｔＰｕｂｌｉｃＫｅｙＩｎｆｒａｓｔｒ
ｕｃｔｕｒｅＯｎｌｉｎｅＣｅｒｔｉｆｉｃａｔｅ
ＳｔａｔｕｓＰｒｏｔｏｃｏｌ − ＯＣＳＰ）と
いうサービスがある。ＣＲＬは、失効している証明証の
情報をリストにし、認証局が署名したものである。ＯＣ
ＳＰでは、失効をチェックしたい証明証の情報をＯＣＳ
Ｐサーバに送ると、サーバは、失効状態を調べて応答す
る。応答情報にはＯＣＳＰサーバの署名が付加される。
つまり、両者において、情報に署名が付加されているの
で、署名を検証するためには、ＣＲＬを発行した認証局
や、ＯＣＳＰサーバの証明証が必要になる。又、認証局
の運用により、ＣＲＬの署名の検証にのみ使用可能な証
明証も生成できる。そこで、悪意を持った第三者は、こ
れらの署名を検証するための証明証用の偽造証明証パス
を作成することができる。失効情報用の偽造証明証パス
を作成することで、検証者に更に負担をかけさせること
が可能であるという問題点があった。

【００１８】偽造証明証パスにおける各偽造証明証の署
名長を大きく設定すると、その大きさの署名を検証可能
なアプリケーションの場合は、さらに、負担を増大させ
ることが可能であるという問題点があった。

【００１９】検証者が偽造証明証パスを取得するかどう
かは、証明証の検索順に依存するが、ディレクトリサー
ビスから取得する他に、暗号電子メールなどでは、送信
者が送信メッセージに添付する場合がある。従って、複
数の偽造証明証パスを構築する偽造証明証をディレクト
リに登録したり、暗号電子メールのメッセージに添付す
ることにより、検証者が偽造証明証パスを選択する可能
性を高めることができるという問題点があった。

【００２０】従来技術では偽造証明証パス攻撃の対策と
して、検証者が保持する証明証の検証装置において、あ
らかじめ決められた長さを超えるパスの場合に、異常を
通知したり、多数の証明証を受け付けないといった処置
をするしかなく、証明証パスの構築過程において、証明
証の内容だけで、偽造を検出することは不可能であった
という問題点があった。

【００２１】また、電子的な証書類や、情報に、被発行
者が何らかの合意を示した上で該証書類、情報が発行さ
れたという証拠を含めることによりシステム上の情報の
改竄不正を防止する技術として、例えば、特開平１１−
１１０４６４号公報に開示された「電子証券の発行、転
移、証明、消去のための処理システム及びその処理方
法」がある。また、特表平１０−５０４１５０号公報に
開示された「商用暗号システムにおけるディジタル署名
を安全に使用する方法」がある。だが、これらの技術
は、いずれも、公開鍵暗号によるディジタル署名が付加
された情報を特徴としている。また、ディジタル署名を
付加するエンティティは、認証局あるいは公証者などと
呼ばれる第三者が発行する公開鍵証明証を利用してい
る。しかし、公開鍵と持ち主を結び付けるという”公開
鍵証明証”の本質的な機能に対して、特徴を付加したも
のはなく、従来の公開鍵証明証の特徴をそのまま利用
し、メッセージへ署名を付加した場合、その署名を検証
するための情報として利用するだけである。従って、メ
ッセージに対する偽造を検出することはできるが、証明
証パスの構築過程において、早期に偽造を検出すること
は、不可能であるという欠点があった。

【００２２】この発明は上記のような問題点を解決する
ためになされたもので、ある証明証の検証において、証
明証パスの構築時に、偽造証明証パスの早期検知を行う
ことにより、偽造証明証パス攻撃を早期に検出すること
を目的とする。また、被発行者が発行に関して合意した
ことを示す合意情報を含んだ証明証を発行し、発行され
た証明証を検証することで、偽造証明証を早期に検出す
る認証方式を実現することを目的とする。

【００２３】

【課題を解決するための手段】この発明の認証方式は、
所定の公開鍵を所持する公開鍵所持者を被発行者とし
て、被発行者の名称である被発行者名と被発行者の公開
鍵とを含む証明証を発行者が発行して、被発行者が該公
開鍵の正当な所持者であることを電子計算機を用いて証
明する認証方式において、該証明証の発行に際して被発
行者の合意を得るための合意確認用情報を生成し、生成
した合意確認用情報を被発行者に提示して合意を確認
し、合意が確認されたことを示す確認済合意情報を該証
明証に含めて発行する証明証発行装置を備えたことを特
徴とする。

【００２４】また、この発明の認証方式は、さらに、発
行者から提示された合意確認用情報を被発行者に確認さ
せて、該合意確認用情報に被発行者が合意した場合に、
合意した旨を表す情報を該合意確認用情報に付加して確
認済合意情報を作成し、作成した確認済合意情報を発行
者に対して送付する合意情報確認装置を備えたことを特
徴とする。

【００２５】上記合意情報確認装置は、該証明証により
証明される公開鍵と対の秘密鍵を利用して該合意確認用
情報に対してディジタル署名を付加して上記確認済合意
情報を作成して、作成した上記確認済合意情報を発行者
に対して送付することを特徴とする。

【００２６】上記確認済合意情報は、該確認済合意情報
を識別する確認済合意情報識別子と、該確認済合意情報
が含まれる証明証を識別する証明証識別情報と、発行者
の公開鍵を識別するための発行者公開鍵識別情報とを含
むことを特徴とする。

【００２７】上記認証方式は、さらに、証明証を検証す
る検証者が上記確認済合意情報を含む証明証を検証する
証明証検証装置を備えたことを特徴とする。

【００２８】上記証明証検証装置は、上記証明証に含ま
れる上記確認済合意情報を検証し、上記証明証の発行に
関して被発行者が合意していることを確認することを特
徴とする。

【００２９】上記証明証検証装置は、上記証明証に含ま
れる被発行者公開鍵識別情報により識別される被発行者
の公開鍵を用いて上記確認済合意情報の署名を検証し
て、上記証明証の発行に対して被発行者が合意している
ことを確認することを特徴とする。

【００３０】上記証明証検証装置は、上記証明証に含ま
れる上記確認済合意情報を検証し、上記確認済合意情報
に含まれる発行者公開鍵識別情報が上記証明証を発行し
た発行者の公開鍵を証明する証明証に含まれる公開鍵を
示していることを確認することを特徴とする。

【００３１】上記確認済合意情報は、さらに、被発行者
の公開鍵を識別するための被発行者公開鍵識別情報を含
むことを特徴とする。

【００３２】上記確認済合意情報は、さらに、被発行者
の公開鍵を識別するための被発行者公開鍵識別情報を含
み、上記証明証検証装置は、上記証明証に含まれる上記
確認済合意情報を検証し、上記確認済合意情報に含まれ
る被発行者公開鍵識別情報が上記証明証に含まれる被発
行者の公開鍵を示していることを確認することを特徴と
する。

【００３３】上記証明証は、少なくとも、発行者名と被
発行者名と被発行者の公開鍵とを含む証明証であるとと
もに、上記確認済合意情報を格納するための拡張領域を
有し、上記証明証発行装置は、上記拡張領域に上記確認
用合意情報を未格納の状態の証明証を合意確認用情報と
して生成し、生成した合意確認用情報を被発行者に提示
して合意を確認し、合意が確認されたことを示す確認済
合意情報を該証明証の該拡張領域に格納して証明証を発
行することを特徴とする。

【００３４】上記確認済合意情報は、被発行者公開鍵識
別情報として、被発行者の公開鍵から所定の方式で算出
した被発行者の公開鍵のハッシュ値を含むとともに、上
記証明証検証装置は、上記確認済合意情報に含まれる被
発行者の公開鍵のハッシュ値と、上記証明証に含まれる
被発行者の公開鍵から上記方式と同一の方式で算出した
ハッシュ値とが一致することを確認して、上記証明証を
検証することを特徴とする。

【００３５】上記確認済合意情報は、発行者公開鍵識別
情報として、発行者の公開鍵から所定の方式で算出した
発行者の公開鍵のハッシュ値を含むとともに、上記証明
証検証装置は、上記確認済合意情報に含まれる発行者の
公開鍵のハッシュ値と、上記証明証を発行した発行者の
公開鍵を証明する証明証に含まれる発行者の公開鍵から
上記方式と同一の方式で算出したハッシュ値とを比較し
て、両者が一致することを確認して、上記証明証を検証
することを特徴とする。

【００３６】上記合意情報確認装置は、該合意確認用情
報のハッシュ値を算出して、該証明証により証明される
公開鍵と対の秘密鍵を利用して算出した該合意確認用情
報のハッシュ値に対してディジタル署名を付加して確認
済合意情報を作成して、作成した確認済合意情報を発行
者に対して送付することを特徴とする。

【００３７】上記証明証生成装置は、上記合意確認用情
報のハッシュ値を算出して、算出した合意確認用情報の
ハッシュ値を被発行者に提示するとともに、上記合意情
報確認装置は、自身が取得可能な情報を元に合意確認用
情報を確認するためのハッシュ値を算出して、算出した
ハッシュ値と提示された合意確認用情報のハッシュ値と
を比較して、両者が一致することを確認することを特徴
とする。

【００３８】上記証明証発行装置は、合意が確認された
旨をユーザに示すための表示情報をテキスト及び画像の
少なくともいずれかの形式で上記確認済合意情報に含ま
せて証明証を発行することを特徴とする。

【００３９】

【発明の実施の形態】実施の形態１．証明証は、発行者
が被発行者に対して発行を行うものである。従来の発行
処理により発行された証明証を見ると、「発行者は、被
発行者が、証明証に含まれる公開鍵を所持する」ことを
保証するが、「被発行者は、発行者が証明証を発行する
ことに合意している」ということは、保証していない。
つまり、合意情報がないので、検証者にとっては、パス
を構築している途中では、集めている上位証明証が、正
規のものなのか、悪意の第三者が勝手に発行した偽造証
明証なのか判断できない。それは、従来の証明証の構造
では、含まれている上位証明証識別情報などを元に、上
位証明証を集めるよりほかに検証の手立てがないからで
ある。この実施の形態では、合意情報を含んだ証明証の
発行および検証について説明する。ここでいう証明証と
は発行者（例えば認証局）がコンピュータを用いて発行
する証明証である。本明細書中の発明の実施の形態で説
明する証明証生成装置、合意情報確認装置および証明証
検証装置ならびにこれらを構成する各手段はいずれもコ
ンピュータを用いてインプリメントされるものである。
そしてこれら証明証生成装置、合意情報確認装置および
証明証検証装置ならびにこれらを構成する各手段はいず
れもハードウェアのみでも実現できるし、ソフトウェア
（プログラム）のみでも実現できるし、ハードウェアと
ソフトウェア（プログラム）との組み合わせでも実現で
きる。

【００４０】まず、図を用いて、この発明の認証方式の
実施の形態の構成の説明を行なう。図１は、この実施の
形態の証明証生成装置と合意情報確認装置による証明証
の発行手順を示す図である。図２は、この実施の形態の
証明証識別情報を示す図である。図３は、この実施の形
態の合意情報を示す図である。図４は、この実施の形態
の署名付き合意情報を示す図である。図５は、この発明
の認証方式の証明証の発行例を示す図である。

【００４１】図１から順に構成を説明する。図１におい
て、５０１は証明証の発行を受ける被発行者であり、通
常、Ｅｎｄ＿Ｅｎｔｉｔｙか、ＳｕｂＣＡ（サブ認証
局）が該当する。５１０ａは、被発行者５０１の公開
鍵、５１０ｂは、被発行者５０１の秘密鍵であり、５１
０ａと対になっている。５０２は、被発行者５０１に証
明証を発行する発行者であり、認証局（ＣＡ）である。
５０３は、証明証の被発行者５０１が発行者５０２に送
信する情報であり、被発行者名と被発行者の公開鍵を含
んだ情報で構成される、証明証発行要求である。５０４
は、発行者５０２が被発行者５０１に送信する情報であ
り、発行者５０２が被発行者５０１に発行する予定の証
明証の内容を示す、証明証識別情報である。証明証識別
情報５０４は、図２に示すように、発行者名，ＳＮ（Ｓ
ｅｒｉａｌＮｕｍｂｅｒ），被発行者名，被発行者公開
鍵などを含む。

【００４２】５０５は、発行者５０２が被発行者５０１
に送信する合意情報であり、“被発行者は、証明証識別
情報５０４によって示される証明証の発行に関して合意
する”という内容を示す。合意情報５０５は図３に示す
ように、その情報が合意情報であることを識別するため
の合意情報識別子と、発行する証明証を示す証明証識別
情報５０４と、被発行者の公開鍵を示す被発行者の公開
鍵情報と、発行者の公開鍵を示す発行者の公開鍵情報で
構成される。被発行者の公開鍵情報とは、例えば、被発
行者の名称と被発行者の公開鍵の値である。発行者の公
開鍵情報とは、例えば、発行者の名称と発行者の公開鍵
の値である。

【００４３】５０６は、被発行者が発行者に送信する情
報である。この情報は、証明証の被発行者５０１が、証
明証発行要求５０３に含まれる公開鍵５１０ａと対の秘
密鍵５１０ｂで合意情報５０５に署名を付加した、署名
付き合意情報である。５０７は、発行者５０２が被発行
者５０１に発行する証明証で、図５に示すように、署名
付き合意情報５０６を含んでいる。発行者名が、上位証
明証の被発行者名と一致する点、署名が上位証明証の公
開鍵で検証される点は、従来の証明証と同じである。図
５の５０８は、後述する被署名情報を示している。

【００４４】図６は、この発明の認証方式の証明証生成
装置を示す図である。図６に示す証明証生成装置５５１
は、証明証発行要求５０３から証明証識別情報５０４を
生成し、また、証明証発行要求５０３と署名付き合意情
報５０６から被署名情報５０８を生成する被署名情報生
成手段５５３と、被署名情報生成手段５５３と連携し合
意情報５０５を生成する合意情報生成手段５５５と、被
署名情報５０８に発行者の秘密鍵による署名を付加して
証明証５０７を生成・出力する署名生成手段５５４とか
ら構成される。

【００４５】図７は、この発明の認証方式の合意情報確
認装置を示す図である。図７に示す合意情報確認装置５
５２は、発行者の公開鍵５０９ａと証明証発行要求５０
３に含まれる情報を利用して合意情報５０５を確認する
合意情報確認手段５５６と、合意情報確認手段５５６か
ら確認済みの合意情報５０５を受け取り、証明証発行要
求５０３に含まれる被発行者の公開鍵と対の被発行者の
秘密鍵で署名を付加し署名付き合意情報５０６を生成し
出力する署名生成手段５５７とで構成される。

【００４６】図８は、この発明の認証方式の証明証検証
装置を示す図である。図９は、この発明の認証方式の証
明証検証装置の証明証取得手段における処理を示す流れ
図である。図１０は、この発明の認証方式の証明証検証
装置の合意情報確認手段における処理を示す流れ図であ
る。

【００４７】図８において、６５１は、検証対象の証明
証６０４と信用する証明証６０７とを入力とし、検証対
象の証明証６０４を検証するための証明証パスを構成す
る一連の上位証明証６０５を取得し、合意情報確認手段
６０２に渡し、確認結果６０３を受け取り、上位証明証
として正しければ上位証明証群６０６として出力する証
明証取得手段６０１と、検証対象の証明証６０４と、上
位証明証６０５を入力として受け取り、各入力に含まれ
る合意情報を確認し、確認結果６０３を証明証取得手段
６０１に渡す合意情報確認手段６０２と、検証対象の証
明証６０４を、信用する証明証６０７と上位証明証群６
０６を利用して検証する証明証検証手段６０９とから構
成される、証明証検証装置である。

【００４８】次に、動作の説明を行なう。前述したよう
に、図１は、本発明における証明証の発行手順を示す図
である。図１の被発行者５０１は、証明証の発行を受け
るＥｎｄ＿Ｅｎｔｉｔｙまたは、サブ認証局（ＳｕｂＣ
Ａ）である。発行者５０２は、証明証を発行する認証局
（ＣＡ）である。まず、Ｓ５１において、被発行者５０
１は、被発行者名、被発行者の公開鍵を含んで構成され
る証明証発行要求５０３を発行者５０２へ送信する。Ｓ
５２において、発行者５０２は、証明証発行要求５０３
を元にして証明証生成装置５５１を利用し、発行予定の
証明証を示す情報である証明証識別情報５０４を生成す
る。同時に、“被発行者は、証明証識別情報５０４で示
される証明証を、”発行者との合意の上で、発行しても
らう”という意味を表現する合意情報５０５を生成し、
生成した証明証識別情報５０４、合意情報５０５を被発
行者５０１に送信する。次に、Ｓ５３において、被発行
者５０１は、保持している合意情報確認装置５５２にお
いて、合意情報５０５の内容を見て、発行に合意するか
どうかを確認し、発行に関して合意したならば、５０１
が保持する被発行者の公開鍵５１０ａと対になっている
秘密鍵５１０ｂで、合意情報５０５に署名を付加して署
名付き合意情報５０６を生成し、発行者５０２に送信す
る。Ｓ５４で、発行者５０２は、証明証生成装置５５１
を利用して、署名付き合意情報５０６を含んだ証明証５
０７を生成し、被発行者５０１へ送信する。

【００４９】被発行者５０１は、発行者５０２の公開鍵
を利用して証明証５０７の署名と内容をチェックし、被
発行者自身が要求した証明証が被発行者自身の合意のも
とで正しく発行されたことを確認する。

【００５０】次に、図６を用いて、証明証生成装置につ
いて、詳細に説明する。図において、５５１は、発行者
５０２が保持する証明証生成装置である。被署名情報生
成手段５５３は、被発行者５０１から送られてきた証明
証発行要求５０３に基づき、発行予定の証明証を示す証
明証識別情報５０４を生成する。証明証識別情報５０４
は、例えば、発行者名、被発行者名、ＳＮ、公開鍵、上
位証明証識別子、署名アルゴリズム、エクステンション
など、被発行者５０１に発行する予定の証明証の内容を
確認できる情報で構成される。また、合意情報生成手段
５５５は被署名情報生成手段５５３と連携し、合意情報
５０５を生成する。合意情報５０５は、合意情報を識別
する“合意情報識別子”と、図において５０４で示され
る発行予定の証明証を一意に同定できる“証明証識別情
報”と、被発行者の公開鍵を示す“被発行者の公開鍵情
報”と、証明証５０７における署名を検証するための発
行者の公開鍵を示す、“発行者の公開鍵情報”で構成さ
れる。また、被署名情報生成手段５５３は、被発行者５
０１から送信された署名付き合意情報５０６を受け取る
と、署名付き合意情報５０６を含んだ証明証の被署名部
である、被署名情報５０８（図５に示す）を生成し、署
名生成手段５５４に渡す。署名生成手段５５４は、発行
者の秘密鍵を利用して被署名情報５０８に署名を付加
し、証明証５０７として出力する。

【００５１】証明証生成装置５５１、合意情報確認装置
５５２の動作について以下に述べる。

【００５２】５５２は、被発行者５０１が保持する合意
情報確認装置である。また、被発行者５０１は、あらか
じめ、発行者５０２の公開鍵である発行者の公開鍵５０
９ａを安全な手段で入手しておく。合意情報確認装置５
５２は、証明証識別情報５０４と合意情報５０５を発行
者５０２の証明証生成装置５５１から受信すると、合意
情報確認手段５５６において、証明証識別情報５０４を
利用して、合意情報５０５を確認する。すなわち、合意
情報５０５の、証明証識別情報を用いて、被発行者５０
１が発行を合意すべき証明証が証明証識別情報５０４で
示される証明証か確認し、加えて、合意情報５０５の被
発行者の公開鍵情報が、証明証で証明されるべき被発行
者の公開鍵を示していることを確認する。さらに、合意
情報５０５の発行者の公開鍵情報が、発行される予定で
ある証明証５０７の署名を検証するために必要な発行者
の公開鍵５０９ａを示しているか確認する。合意情報確
認手段５５６は、合意情報５０５を確認した上で署名生
成手段５５７に渡す。署名生成手段５５７は、証明証発
行要求５０３に含まれる被発行者の公開鍵５１０ａと対
の秘密鍵５１０ｂを利用して署名を付加し、署名付き合
意情報５０６として出力する。

【００５３】図８の６５１は、本発明における、証明証
を検証する検証者が保持する、証明証検証装置である。
検証者は、証明証検証装置６５１に、入力として、検証
対象の証明証６０４を与える。証明証検証装置６５１の
動作については後述する。

【００５４】図９は証明証取得手段６０１の処理の流れ
図である。検証対象の証明証６０４は証明証取得手段６
０１に渡される。証明証取得手段６０１は、検証対象の
証明証６０４と、信用する証明証６０７を入力とし、図
９のフローチャートに従い、処理を進める。現時点、す
なわち、証明証取得手段の処理の開始時では、図８で検
証対象の証明証６０４として示されている証明証が、図
９に示す処理の中で言うところの“検証対象の証明証”
である。

【００５５】まず、７０１において、“検証対象の証明
証”に含まれる発行者名や上位証明証識別子等を利用し
て、外部から、“検証対象の証明証”を検証するために
必要な上位証明証である６０５上位証明証を取得する。
具体的には、従来技術と同様に、検証対象の証明証の発
行者名と候補の上位証明証の被発行者名が一致するこ
と、などにより取得する。この段階では、６０５が本物
の上位証明証なのか、偽の証明証なのか不明である。

【００５６】次に、７０２の処理において、上位証明証
６０５に含まれている公開鍵で、“検証対象の証明証”
の署名を検証可能か調べる。調べた結果が、もし、検証
不可能ならば、７０６の処理で上位証明証６０５を破棄
し、７０１の処理に戻り、別の上位証明証を検索する。
７０２の処理において調べた結果、検証可能ならば、７
０４の処理において、“検証対象の証明証”と上位証明
証６０５を、合意情報確認手段６０２に渡す。“検証対
象の証明証”と上位証明証６０５を渡された合意情報確
認手段６０２は、所定の確認動作を行ない、その結果を
確認結果（確認情報とも言う）６０３として証明証取得
手段６０１に渡す。

【００５７】証明証取得手段６０１は、７０５の処理に
おいて、合意情報確認手段６０２の出力である、確認情
報６０３を受け取ってチェックする。もし、確認情報６
０３が“ＯＫ”ならば、７０３において、取得した上位
証明証６０５が信用する証明証６０７であるか調べる。

【００５８】７０３の処理において調べた結果、もし、
信用する証明証である場合は、７０７の処理において上
位証明証６０５を記憶し、７１０の処理において、記憶
している上位証明証を、上位証明証群６０６として、す
べて出力して証明証取得手段６０１の処理を終了する。

【００５９】もし、７０３の処理の結果が、信用する証
明証でないならば、７０８の処理において、上位証明証
を記憶する。続いて、７０９の処理において、現在の上
位証明証６０５を、新しい“検証対象の証明証”に設定
して、７０１の処理に戻る。

【００６０】もし、７０５の処理において確認情報６０
３が“ＮＧ”ならば、７０６の処理において、上位証明
証６０５を破棄して、７０１の処理に戻る。以上が、証
明証取得手段６０１の処理である。

【００６１】次に、合意情報確認手段６０２の処理を説
明する。図１０は、合意情報確認手段６０２の処理の流
れ図である。合意情報確認手段６０２は、“検証対象の
証明証”と、上位証明証６０５を受け取ると、図１０の
フローチャートに従い、処理を進める。まず、８０１の
処理において、“検証対象の証明証”に署名付き合意情
報５０６が含まれているか調べる。もし、署名付き合意
情報５０６が含まれていなければ、８０８の処理で確認
情報として“ＮＧ”を出力し、合意情報確認手段６０２
の処理を終了する。もし、署名付き合意情報５０６が含
まれていれば、８０２の処理において、“検証対象の証
明証”に含まれている公開鍵で署名付き合意情報５０６
が検証可能か調べる。検証不可能の場合は、８０８の処
理で確認情報として“ＮＧ”を出力し、合意情報確認手
段６０２の処理を終了する。

【００６２】続いて、８０３の処理において、８０２の
処理の結果として合意情報５０５を取得し、構成要素を
取り出す。続いて、８０４の処理において、合意情報５
０５内の証明証識別情報が、“検証対象の証明証”を示
しているか調べる。調べる方法としては、例えば、発行
者名、ＳＮの一致をチェックする。続いて、８０５の処
理において、合意情報５０５内の被発行者の公開鍵情報
が、“検証対象の証明証”に含まれている公開鍵を示し
ているか調べる。具体的には、例えば、合意情報５０５
内の被発行者の公開鍵情報が、被発行者の公開鍵の値そ
のものであれば、“検証対象の証明証”に含まれる、被
発行者の公開鍵の値と一致することを確認する。続い
て、８０６の処理において、合意情報５０５内の発行者
の公開鍵情報が、上位証明証６０５に含まれている公開
鍵を示しているか調べる。具体的には、例えば、合意情
報５０５内の発行者の公開鍵情報が、発行者の公開鍵の
値そのものであれば、“上位証明証”に含まれる、発行
者の公開鍵の値と一致することを確認する。もし、８０
４、８０５、８０６の処理のいずれかで“示していな
い”という結果が出た場合は、８０８の処理において、
確認情報として“ＮＧ”を出力し、合意情報確認手段６
０２の処理を終了する。また、８０４、８０５、８０６
の処理ですべて、“示している”という結果が出た場合
は、８０７の処理で確認情報として“ＯＫ”を出力し、
合意情報確認手段６０２の処理を終了する。以上が、合
意情報確認手段６０２の処理である。

【００６３】次に、図８に示した証明証検証手段６０９
の処理動作について、説明する。証明証検証手段６０９
は、証明証取得手段６０１の処理７１０の結果として出
力される上位証明証群６０６と検証対象の証明証６０４
とを入力とし、入力した検証対象の証明証６０４を、上
位証明証群６０６と信用する証明証６０７を利用して検
証する。上位証明証群６０６は、検証対象の証明証６０
４の証明証パスを構築する証明証群である。検証が終了
すると、証明証検証手段６０９は、検証した結果を検証
結果６０８として出力する。

【００６４】このように、本発明の、証明証生成装置に
より生成された証明証には、被発行者の署名が付加され
た署名付き合意情報が含まれている。合意情報は、「発
行者が、被発行者に対して発行した、証明証識別情報で
示される証明証の発行に関して、被発行者は合意する」
という意味であり、被発行者が自分の署名を付加するこ
とで発行への合意を示した情報である。また、本発明の
証明証検証装置を利用して、同証明証を検証した場合、
パスの構築時に検証対象の証明証と上位証明証の候補の
間で、署名付き合意情報の整合性を検証する。図９の７
０２、７０３、７０５（図１０の処理）のチェックを通
過可能な偽造上位証明証を作るためには、本物の上位証
明証の保持者の秘密鍵を知らなくてはならない。本物の
上位証明証は公開情報であり、入手可能だが、その情報
から秘密鍵を入手することは不可能である。従って、有
効な偽造証明証パスを生成することが不可能である。上
述のように、証明証に、被発行者の署名付き合意情報を
含めることにより、偽造証明証パス攻撃を早期に検出す
ることが可能である。また、証明証が、被発行者の合意
を得て発行されているものであることを確認できる認証
システムを得ることができる。

【００６５】以下に、図を用いて、証明証の偽造のパタ
ーン別に説明する。図１１は、証明証の署名付き合意情
報をコピーして、証明証を偽造するケースを示してい
る。７１４は正しい証明証であり、７１１，７１２が偽
造された証明証である。７１１，７１２は、それぞれ正
しい証明証から署名付き合意情報をコピーしている。ま
た，７１１は，上位証明証情報を偽造して、上位証明証
として，７１２を指すようにしている。さらに、７１２
は、公開鍵を偽造している。７１１の署名は、７１２に
含まれる偽造の公開鍵Ｐｕｂｋｅｙ＿ＣＡ２’と対の偽
造の秘密鍵により、付加されているので、７１２の公開
鍵で検証可能である。

【００６６】ここで，証明証７１４の合意情報の検証
は、証明証７１１を利用すれば成功する。次に、証明証
７１１の合意情報の検証について、説明する。８０４の
処理までは、成功する。８０４において、シリアルナン
バーが証明証のシリアルナンバーと一致しているか、
は、ＯＫとなる。被発行者名が、証明証の被発行者名と
一致しているかは、ＯＫとなる。発行者名が、証明証の
発行者名と一致しているかは、ＯＫとなる。８０５にお
いて合意情報内の被発行者の公開鍵情報が、被発行者の
公開鍵の値そのものであれば、“検証対象の証明証”に
含まれる、被発行者の公開鍵の値と一致することを確認
すると、ＯＫとなる。続いて、８０６において合意情報
内の発行者の公開鍵情報が、発行者の公開鍵の値そのも
のであれば、“上位証明証”に含まれる、発行者の公開
鍵の値と一致することを確認すると、上位証明証７１２
の公開鍵は、偽造された公開鍵であるＰｕｂｋｅｙ＿Ｃ
Ａ２‘のため、ＮＧとなる。これにより、偽造が検出で
きる。

【００６７】図１２は、前述した図１１のケースでの検
出を避けるために、証明証７２２において、公開鍵を偽
造しないケースを示している。７１４は正しい証明証で
あり、７１１，７１２が偽造された証明証である。７１
１，７１２は、それぞれ正しい証明証から署名付き合意
情報をコピーしている。また，７１１は，上位証明証情
報を偽造して、上位証明証として，７２２を指すように
している。

【００６８】ここで，証明証７１１、７２２の合意情報
のチェックは、合意情報のみであれば、成功する。図９
に示した証明証取得手段６０１の処理の流れ図におい
て、７０４の処理で証明証を渡され、７０５で確認情報
を返す合意情報確認手段６０２の処理にのみ注目する。
証明証７１１の合意情報の検証について、説明する。こ
の場合、８０４までの処理は成功する。８０４において
シリアルナンバーが証明証のシリアルナンバーと一致し
ているか、は、ＯＫとなる。被発行者名が、証明証の被
発行者名と一致しているかは、ＯＫとなる。発行者名
が、証明証の発行者名と一致しているかは、ＯＫとな
る。８０５において合意情報内の被発行者の公開鍵の値
と、証明証に含まれている公開鍵の値との一致を調べる
と、ＯＫとなる。また、８０６において合意情報内の発
行者の公開鍵の値と、上位証明証に含まれている公開鍵
の値との一致を調べると、上位証明証７２２の公開鍵
は、正しいＰｕｂｋｅｙ＿ＣＡ２のため、ＯＫとなる。
ところが、証明証７１１の署名は偽造されており、本物
のＣＡ２の秘密鍵（つまり、Ｐｕｂｋｅｙ＿ＣＡ２と
対）ではない、偽造の秘密鍵により付加されているの
で、証明証７２２の公開鍵で、証明証７１１の署名を検
証できず、偽造が検出できる。また、図９の流れ図で
は、７０２において、検出されるので、実際には７０５
の処理まで到達しない。

【００６９】図１３は、署名付き合意情報を偽造したケ
ースを示している。７１４は正しい証明証であり、７３
１，７３２が署名付き合意情報を偽造した証明証であ
る。また，７３１は，上位証明証情報を偽造して、上位
証明証として，７３２を指すようにしている。

【００７０】ここで，証明証７３１、７３２間の合意情
報の整合性は合うように偽造されているので、７３２に
含まれる情報を利用した７３１の合意情報のチェックは
成功する。ところが、証明証７３１の合意情報を検証す
る際に、合意情報が偽造されているために、正しいもの
をコピーしてきた公開鍵Ｐｕｂｋｅｙ＿ＣＡ１で検証す
ることができず、ＮＧとなり、偽造が検出できる。つま
り、７３１のチェックにおいて、図１０の８０２の処理
がエラーとなる。

【００７１】図１４は、図１３のケースで、署名付き合
意情報と整合性が取れるように公開鍵を偽造したケース
を示している。７１４は正しい証明証であり、７４１，
７３２が署名付き合意情報と公開鍵を偽造した証明証で
ある。また，７４１は，上位証明証情報を偽造して、上
位証明証として，７３２を指すようにしている。

【００７２】ここで，証明証７４１、７３２間の合意情
報の整合性は、合うように偽造されているので、７３２
に含まれる情報を利用した７４１の合意情報のチェック
は成功する。ところが、証明証７４１の公開鍵Ｐｕｂｋ
ｅｙ＿ＣＡ１’が偽造されているために、正しい証明証
である７１４の署名が検証できず、ＮＧとなる。つま
り、７０２の処理でエラーとなる。また、７４１に含ま
れる公開鍵Ｐｕｂｋｅｙ＿ＣＡ１’の値と７１４の合意
情報に含まれる上位証明証の公開鍵の値との一致を調べ
る際も、公開鍵が偽造されているために、一致しない。
これにより、発行者の公開鍵の偽造が検出できる。

【００７３】以上、証明証に合意情報を含めたことで、
証明証の偽造を検出できる場合を、具体的に説明した。
なお、この発明を適用しても、「本来、７１４の公開鍵
で検証すべき、電子メール等への署名を偽造し、７１４
も偽造して、７４１、７３２と整合性を合わせた」場合
は、その偽造を、早期に検出することはできない。なぜ
ならば、偽造した電子メールの署名情報を元に７１４の
偽造証明証を取得して証明証のパスを構築するので、構
築されたパス内の証明証の間には矛盾が生じないので、
パスの構築過程においては、偽造パスを検出できないか
らである。

【００７４】実施の形態２．以降の実施の形態では、実
施例の変形例を説明する。前述したように、合意情報
は、合意情報識別子、証明証識別情報、被発行者の公開
鍵情報と、発行者の公開鍵情報で構成される。当実施の
形態では、実施の形態１において、用いられていた証明
証識別情報のうちで、発行者名とＳＮ（シリアルナンバ
ー）という、証明証を特定可能な最低限の情報に指定す
る。これにより、証明証の中に保持する情報量や、認証
のためにやり取り（送受信）する情報量を少なくできる
という長所がある。

【００７５】実施の形態３．実施の形態１において、被
署名情報５０８は、証明証によって保証される内容全て
の情報である。具体的には例えば、証明証がＸ．５０９
ｖｅｒ３の証明証であれば、発行者名、被発行者名、
公開鍵、有効期限、バージョン、アルゴリズム、エクス
テンションなどで構成されるＵｎｓｉｇｎｅｄＣｅｒ
ｔｉｆｉｃａｔｅと呼ばれる情報である。前述した実施
の形態１の場合では、ＵｎｓｉｇｎｅｄＣｅｒｔｉｆ
ｉｃａｔｅの中のエクステンションの一つとして、署名
付き合意情報５０６を含むことになる。

【００７６】当実施の形態では、「証明証識別情報５０
４＋署名付き合意情報５０６＝被署名情報５０８（Ｕｎ
ｓｉｇｎｅｄＣｅｒｔｉｆｉｃａｔｅ）」となるよう
に、証明証識別情報５０４を構成する。署名付き合意情
報５０６を、Ｘ．５０９ｖｅｒ３におけるエクステン
ションとして証明証に含めることにすれば、当証明証識
別情報は、「署名付き合意情報のエクステンションを含
める前のＵｎｓｉｇｎｅｄＣｅｒｔｉｆｉｃａｔｅの
全情報」である。この中には、被発行者の公開鍵も含ま
れている。

【００７７】つまり実施の形態２とは逆で、証明証を識
別する可能な限りの情報を、証明証識別情報に含める。
被署名情報生成手段５５３は、証明証発行要求５０３を
受け取った時点で、被署名情報５０８を生成するために
不足している情報は、署名付き合意情報のみなので、上
述の条件を満たす証明証識別情報を生成可能である。被
署名情報生成手段５５３は、当証明証識別情報５０４を
合意情報５０５に含め、被発行者に送信する。当証明証
識別情報は、被発行者の立場からすると、これから受理
予定の証明証の、ＵｎｓｉｇｎｅｄＣｅｒｔｉｆｉｃ
ａｔｅにおいて、自分が生成すべき署名付き合意情報を
除いた全ての情報が含まれており、当証明証識別情報が
証明証の詳細に相当するので、受理予定の証明証の内容
において詳細な情報を得られるという特徴がある。

【００７８】実施の形態４．実施の形態３においては、
証明証識別情報５０４に被発行者の公開鍵５１０ａが含
まれている。当実施の形態においては、実施の形態３の
合意情報５０５において、被発行者の公開鍵情報は含ま
ないようにする。

【００７９】実施の形態５．当実施の形態は、実施の形
態１、２において、合意情報に被発行者の公開鍵情報を
含まない形態である。署名付き合意情報５０６が含まれ
る証明証の公開鍵を用いて、署名付き合意情報の署名を
検証可能で、かつ、合意情報内の証明証識別情報が、当
証明証を示していた場合、合意情報に被発行者の公開鍵
を含めた場合と同じ意味を得られるので、省略可能であ
る。

【００８０】実施の形態６．当実施の形態では、実施の
形態１、２、３において、被発行者の公開鍵情報とし
て、被発行者の公開鍵そのものをＳＨＡ−１に代表され
る一方向性ハッシュ関数で圧縮したものを採用する。当
実施の形態により、合意情報の情報量を縮小可能であ
る。証明証検証装置６５１における合意情報確認手段６
０２の、８０５の処理においては、合意情報５０５を含
んでいる証明証内の公開鍵を、同じ一方向性ハッシュ関
数に適用し、得られた出力が、合意情報５０５に含まれ
る被発行者の公開鍵情報と同値であることを確認する。

【００８１】実施の形態７．当実施の形態では、実施の
形態１、２、３において、発行者の公開鍵情報として、
発行者の公開鍵そのものをＳＨＡ−１に代表される一方
向性ハッシュ関数で圧縮したものを採用する。当実施の
形態により、合意情報５０５の情報量を縮小可能であ
る。証明証検証装置６５１における合意情報確認手段６
０２の、８０６の処理においては、上位証明証内の公開
鍵を、同じ一方向性ハッシュ関数に適用し、得られた出
力が、合意情報５０５に含まれる発行者の公開鍵情報
と同値であることを確認する。

【００８２】実施の形態８．実施の形態６、７を併用し
ても良い。

【００８３】実施の形態９．当実施の形態では、実施の
形態１、２、３、４、５における署名付き合意情報の生
成に関して以下の手順を採用する。合意情報確認装置５
５２において、合意情報確認手段５５６は、確認した合
意情報をＳＨＡ−１に代表される一方向性ハッシュ関数
で圧縮する。これを、署名生成手段５５７に渡すと、署
名生成手段５５７は被発行者の署名を付加し、署名付き
合意情報５０６を出力する。

【００８４】一方向性ハッシュ関数をｈ（）で表し、
メッセージＭに鍵ｋｅｙで署名をつけることを、｛Ｍ｝
ｋｅｙと表現することにする。被発行者の秘密鍵をＰｒ
ｉＫｅｙとすると、当実施の形態では、合意情報と、署
名付き合意情報は、以下のように表される。合意情報＝合意情報識別子、証明証識別情報、被発行者
の公開鍵情報、発行者の公開鍵情報署名付き合意情報＝｛ｈ（合意情報）｝Ｐｒｉ
Ｋｅｙ

【００８５】この場合、各実施の形態において、証明証
検証装置６５１における合意情報確認手段６０２の、処
理を以下の様に置き換える。８０３：検証した署名付き合意情報からｈ（合意情
報）を取り出す。８０４、８０５、８０６：（１）検証対象の証明証と、上位証明証から、証明証識
別情報、被発行者の公開鍵情報、発行者の公開鍵情報を
構築し、“ｈ（合意情報識別子、証明証識別情報、被発
行者の公開鍵情報、発行者の公開鍵情報）”を計算す
る。（２）計算結果が、８０３で得られたｈ（合意情報）と
一致するか確認する。

【００８６】当実施例においては、一方向性ハッシュ関
数を合意情報に適用することで、証明証に含める署名付
き合意情報を縮小可能である。

【００８７】実施の形態１０．当実施の形態は、実施の
形態９において、以下の様に処理を変更する。合意情報＝ｈ（合意情報識別子、証明証識別情報、被
発行者の公開鍵情報、発行者の公開鍵情報）合意情報確認装置５５２における合意情報確認手段５５
６では、証明証識別情報５０４、発行者の公開鍵５０９
ａ、また、自身が保持する公開鍵から、“合意情報識別
子、証明証識別情報、被発行者の公開鍵情報、発行者の
公開鍵情報”を構築可能である。構築後、一方向性ハッ
シュ関数ｈ（）に与え、出力結果が、当合意情報と
同値になることを確認する。当実施の形態では、一方向
性ハッシュ関数の利用により、合意情報を縮小可能であ
る。実施の形態９では、合意情報を確認した上で、ｈ
（）の演算を行ったが、本実施の形態では、ｈ（）
の演算を施したものを、合意情報とおきかえるので、図
１、Ｓ５２における通信量を減らすことができる。

【００８８】実施の形態１１．本発明は、偽造パス攻撃
を防止することを目的とする。しかし、当攻撃の防止の
他にも、署名付き合意情報を証明証に含めることで、次
のような利点が生じる。すなわち、検証者は、証明証
が、“被発行者の合意のもとで”発行されたことを確認
できる。検証者は、証明証の内容を、ツールなどで表示
することで、当合意を知ることが可能である。従って、
偽造パス攻撃を防止する必要がない環境では、実施の形
態１において、署名付き合意情報の代わりに合意情報５
０５を含む証明証を生成することで、検証者の合意情報
確認装置５５２と証明証検証装置６５１の処理を軽減す
ることが可能である。

【００８９】本実施の形態は、実施の形態１において、
以下の様に処理を変更する。（１）被発行者５０１は合意情報確認装置５５２におい
て、５０６として署名付き合意情報を返す代わりに、合
意情報５０５と、それに対する確認応答（ＯＫ／ＮＧ）
を返す。（２）発行者５０２は、被発行者５０１からの確認応答
がＯＫならば、合意情報５０５を証明証に含め、被署名
情報５０８を生成し、同様に証明証５０７を発行する。（３）証明証検証装置６５１における合意情報確認手段
６０２の処理において、８０１の“署名付き合意情報”
を“合意情報”におきかえる、すなわち、検証対象の証
明証に合意情報が含まれているかを判断する。又、８０
２は署名付き合意情報でないので省略し、８０３を「合
意情報から各要素を取り出す」に変更する。

【００９０】被発行者の署名が無い合意情報を含むの
で、偽造パス攻撃を防止する効果はない。また、発行者
が、操作ミスなどで、被発行者の合意を得ない状況で証
明証を複数発行するような場合も効果が無い。しかし、
発行者が操作ミスを起こさない、信用できるシステム内
の利用であれば、当実施の形態は、当情報を含む証明証
は、該合意を示すことが可能であり、かつ、５５２、６
５１の署名に関する処理を軽減できるので有効である。

【００９１】実施の形態１２．この実施の形態では、合
意情報５０５において、合意情報に、“×××（被発行
者）は〇〇〇（発行者）に対して、次の“証明証識別情
報”で示される当証明証の発行に合意している”といっ
た意味を示す文章を、テキスト、又は画像として、追加
する。これにより、テキスト、または画像を表示可能な
ツールによる表示で、ユーザは合意情報の目視確認が行
え、合意していることをユーザに示すことが容易にな
る。

【００９２】以上のように、この発明の実施の形態にお
いては、認証局などの発行者から、被発行者に対して発
行される予定の証明証に関して、その内容に対して、被
発行者が該証明証の発行を合意した旨を表す合意情報を
生成し、かつ、該合意情報に被発行者が合意した場合、
該合意情報を証明証に含めて発行することが可能な証明
証発行装置について説明した。

【００９３】証明証の発行者である認証局は、本発明
の、証明証生成装置を利用することで、被発行者が証明
証の発行に関して合意したことを示す合意情報を生成
し、かつ、被発行者の合意情報を含んだ証明証を生成可
能である。このように生成され発行された証明証を表示
することで、当証明証が、被発行者の合意のもとで発行
されたことを示すことが可能である。これにより、証明
証が、発行者から一方的に発行されているものではない
ことを明示的に、その証明証の利用者に示すことが可能
となり、利用者にとって、価値のある証明証が発行でき
る。発行者から一方的に発行されているのではないこと
を利用者に明示的に示す証明証を発行できる証明証発行
装置を有する認証システムは、従来存在しなかった。

【００９４】また、被発行者が、発行者が提示した該合
意情報を確認し、合意／非合意の旨を表す情報を、発行
者に対して返す、合意情報確認装置について説明した。
さらに、証明証の被発行者は、本発明の、合意情報確認
装置を利用することで、発行者からの合意情報を確認
し、合意／非合意の旨を発行者に知らせることが可能で
ある。

【００９５】また、被発行者が、発行者が提示した該合
意情報に対して合意した場合、受理予定の証明証に含ま
れる公開鍵と対の秘密鍵を利用して、該合意情報に対し
てディジタル署名を付加して、署名付き合意情報として
発行者に対して返す、合意情報確認装置について説明し
た。この発明によれば、証明証の被発行者は、本発明
の、合意情報確認装置を利用することで、発行者からの
合意情報を確認し、発行を要求している証明証に含まれ
る予定の公開鍵と対の秘密鍵で、合意情報に署名を付加
することで署名付き合意情報を生成し、発行者に返すこ
とが可能である。

【００９６】また、合意情報の代わりに、署名付き合意
情報を証明証に含めて発行することが可能な証明証発行
装置について説明した。さらに、証明証の発行者は、本
発明の、証明証発行装置を利用することで、被発行者の
署名付き合意情報を含んだ証明証を生成・発行が可能で
ある。

【００９７】また、合意情報を示す識別子と、該合意情
報が含まれる証明証を識別する情報と、発行者の公開鍵
を識別可能な情報によって構成される合意情報を、生成
可能な証明証発行装置について説明した。証明証の発行
者は、本発明の、証明証生成装置を利用することで、合
意情報の一つの形態として、それを示す識別子と、当合
意情報が含まれる証明証を識別する情報と、発行者の公
開鍵と、被発行者の公開鍵を識別可能な情報で構成され
る合意情報を生成可能である。

【００９８】また、合意情報を含む証明証において、含
まれる該合意情報が、該証明証に関して被発行者が発行
に対して合意したことを確認可能な、証明証検証装置に
ついて説明した。証明証の検証者は、本発明の、証明証
検証装置を利用することで、合意情報を含んだ証明証
の、合意情報を確認することで、被発行者が当証明証の
発行に対して合意したことを示すことが可能である。

【００９９】また、上述した証明証発行装置により発行
された、署名付き合意情報を含む証明証において、該証
明証に含まれる被発行者の公開鍵を用いて該署名付き合
意情報の署名を検証し、被発行者が該証明証の発行に対
して合意していることを、該署名付き合意情報により確
認可能な、証明証検証装置について説明した。証明証の
検証者は、本発明の、証明証検証装置を利用すること
で、署名付き合意情報を含んだ証明証の、署名付き合意
情報の署名を、証明証に含まれる公開鍵で確認すること
により、被発行者が当証明証の発行に対して合意したこ
とを確認可能である。

【０１００】また、合意情報に対して、被発行者が署名
を付加した、署名付き合意情報を含む証明証において、
該証明証に含まれる被発行者の公開鍵を用いて該署名付
き合意情報の署名を検証し、被発行者が該証明証の発行
に対して合意していることを、該署名付き合意情報によ
り確認可能な、合意情報に含まれる発行者の公開鍵を識
別可能な情報が、該証明証の上位証明証として取得した
証明証に含まれる公開鍵を示していることを確認可能
な、証明証検証装置について説明した。前述の、合意情
報を示す識別子と、当合意情報が含まれる証明証を識別
する情報と、発行者の公開鍵を識別可能な情報で構成さ
れる合意情報に、被発行者が署名を付加した、署名付き
合意情報を含んだ証明証を検証する場合を考える。この
場合、証明証の検証者は、本発明の、証明証検証装置を
利用して、当証明証の署名付き合意情報の署名を、証明
証に含まれる公開鍵で確認することに加え、合意情報に
含まれる発行者の公開鍵を識別可能な情報が、当証明証
の上位証明証として取得した証明証に含まれる公開鍵を
示すことを確認する。この方法により、偽造証明証パス
攻撃を早期に検出可能である。

【０１０１】

【発明の効果】この発明によれば、被発行者が証明証の
発行に関して合意したことを示す合意情報を生成し、か
つ、被発行者の合意情報を含んだ証明証を生成して発行
するので、該証明証が、被発行者の合意のもとで発行さ
れていることを利用者に明示でき、利用者にとって価値
のある証明証が発行できる。

【０１０２】この発明によれば、証明証の被発行者は、
合意情報確認装置を利用することで、発行者からの合意
情報を確認し、合意の旨を発行者に知らせることが可能
である。

【０１０３】この発明によれば、発行を要求している証
明証に含まれる予定の公開鍵と対の秘密鍵で、合意情報
に署名を付加することで署名付き合意情報を生成し、発
行者に返すので、証明証に含まれる公開鍵で検証可能な
合意情報を得られる。

【０１０４】また、この発明によれば、証明証の発行者
の公開鍵を合意情報から識別できるという効果がある。

【０１０５】また、この発明によれば、証明証の検証者
は、本発明の、証明証検証装置を利用することで、合意
情報を含んだ証明証の検証を行なうことができる。

【０１０６】また、この発明によれば、証明証の検証者
は、本発明の、証明証検証装置を利用することで、合意
情報を含んだ証明証の合意情報を検証することで、被発
行者が当証明証の発行に対して合意したことを確認でき
る。

【０１０７】また、この発明によれば、さらに、証明証
の検証者は、本発明の、証明証検証装置を利用すること
で、署名付き合意情報を含んだ証明証の、署名付き合意
情報の署名を、証明証に含まれる公開鍵で確認すること
により、被発行者が当証明証の発行に対して合意したこ
とを確認可能である。

【０１０８】また、この発明によれば、証明証の検証者
は、本発明の、証明証検証装置を利用して、当証明証の
署名付き合意情報に含まれる発行者の公開鍵を識別可能
な情報が、当証明証を発行した発行者の公開鍵を証明す
る証明証として取得した証明証に含まれる公開鍵を示す
ことを確認することで、証明証パス攻撃を早期に検出可
能である。

【０１０９】また、この発明によれば、被発行者の公開
鍵を合意情報から得られる。

【０１１０】また、この発明によれば、被発行者の公開
鍵の一致を確認することで証明証を検証できる。

【０１１１】また、確認済合意情報を拡張領域に格納す
ることで証明証を補完することができる。すなわち、確
認済合意情報以外の証明証の内容を合意確認用情報とし
て被発行者に提示できる。

【０１１２】また、この発明によれば、確認済合意情報
の被発行者の公開鍵の情報量を縮小可能である。

【０１１３】また、この発明によれば、確認済合意情報
の発行者の公開鍵の情報量を縮小可能である。

【０１１４】また、この発明によれば、確認済合意情報
の情報量を縮小可能である。

【０１１５】また、この発明によれば、合意確認用情報
の情報量を縮小可能である。

【０１１６】また、この発明によれば、合意して発行さ
れた証明証であることが容易に確認できる。

【図面の簡単な説明】

【図１】この実施の形態の証明証生成装置と合意情報
確認装置による証明証の発行手順を示す図。

【図２】この実施の形態の証明証識別情報を示す図。

【図３】この実施の形態の合意情報を示す図。

【図４】この実施の形態の署名付き合意情報を示す
図。

【図５】この発明の認証方式の証明証発行例を示す
図。

【図６】この発明の認証方式の証明証生成装置を示す
図。

【図７】この発明の認証方式の合意情報確認装置を示
す図。

【図８】この発明の認証方式の証明証検証装置を示す
図。

【図９】この発明における、証明証検証装置の証明証
取得手段における処理を示す流れ図。

【図１０】この発明における、証明証検証装置の合意
情報確認手段における処理を示す流れ図。

【図１１】この発明の認証方式で、検出可能な偽造の
例を示す図。

【図１２】この発明の認証方式で、検出可能な偽造の
例を示す図。

【図１３】この発明の認証方式で、検出可能な偽造の
例を示す図。

【図１４】この発明の認証方式で、検出可能な偽造の
例を示す図。

【図１５】従来技術における、証明証の発行例を示す
図。

【図１６】従来技術における、証明証のパスと検証方
法を示す図。

【図１７】従来技術における、証明証のパスの構築と
検証を示す図。

【図１８】公開鍵証明証を検証する際の証明証の偽造
パスの例を示す図。

【図１９】偽造パスの例を示す図。

【符号の説明】

１０１認証局ＣＡ１、１０２認証局ＣＡ２、１０３
認証局ＣＡ３、１０４エンドエンティティＥＥ（Ｅ
ｎｄ＿Ｅｎｔｉｔｙ）、１１１認証局ＣＡ１の証明証
Ｃｅｒｔ＿ＣＡ１、１１２認証局ＣＡ２の証明証Ｃｅ
ｒｔ＿ＣＡ２、１１３認証局ＣＡ３の証明証Ｃｅｒｔ
＿ＣＡ３、１１４ＥＥの証明証Ｃｅｒｔ＿ＥＥ、２０
１１１１と１１４の証明証のパスとしての関係、２０
２１１４を検証するための証明証のパス、２０３２
０２における証明証のパスの構築の向き、２０４２０
２における証明証の検証の向き、３００悪意を持った
第三者、３０１偽造証明証、３０２偽造証明証、４
０１偽造証明証パス、５０１被発行者、５０２発
行者、５０３証明証発行要求、５０４証明証識別情
報、５０５合意情報、５０６署名付き合意情報、５
０７証明証、５０８被署名情報、５０９ａ発行者
の公開鍵、５０９ｂ発行者の秘密鍵、５５１証明証
生成装置、５５２合意情報確認装置、５５３被署名
情報生成手段、５５４署名生成手段、５５５合意情
報生成手段、５５６合意情報確認手段、５５７署名
生成手段、６０１証明証取得手段、６０２合意情報
確認手段、６０３確認結果、６０４検証対象の証明
証、６０５上位証明証、６０６上位証明証群、６０
７信用する証明証、６０８検証結果、６０９証明
証検証手段、６５１証明証検証装置。

Claims

【特許請求の範囲】

【請求項１】所定の公開鍵を所持する公開鍵所持者を
被発行者として、被発行者の名称である被発行者名と被
発行者の公開鍵とを含む証明証を発行者が発行して、被
発行者が該公開鍵の正当な所持者であることを電子計算
機を用いて証明する認証方式において、該証明証の発行に際して被発行者の合意を得るための合
意確認用情報を生成し、生成した合意確認用情報を被発
行者に提示して合意を確認し、合意が確認されたことを
示す確認済合意情報を該証明証に含めて発行する証明証
発行装置を備えたことを特徴とする認証方式。
【請求項２】上記認証方式は、さらに、発行者から提
示された合意確認用情報を被発行者に確認させて、該合
意確認用情報に被発行者が合意した場合に、合意した旨
を表す情報を該合意確認用情報に付加して確認済合意情
報を作成し、作成した確認済合意情報を発行者に対して
送付する合意情報確認装置を備えたことを特徴とする請
求項１に記載の認証方式。
【請求項３】上記合意情報確認装置は、該証明証によ
り証明される公開鍵と対の秘密鍵を利用して該合意確認
用情報に対してディジタル署名を付加して上記確認済合
意情報を作成して、作成した上記確認済合意情報を発行
者に対して送付することを特徴とする請求項２に記載の
認証方式。
【請求項４】上記確認済合意情報は、該確認済合意情
報を識別する確認済合意情報識別子と、該確認済合意情
報が含まれる証明証を識別する証明証識別情報と、発行
者の公開鍵を識別するための発行者公開鍵識別情報とを
含むことを特徴とする請求項１から３いずれかに記載の
認証方式。
【請求項５】上記認証方式は、さらに、証明証を検証
する検証者が上記確認済合意情報を含む証明証を検証す
る証明証検証装置を備えたことを特徴とする請求項４記
載の認証方式。
【請求項６】上記証明証検証装置は、上記証明証に含
まれる上記確認済合意情報を検証し、上記証明証の発行
に関して被発行者が合意していることを確認することを
特徴とする請求項５に記載の認証方式。
【請求項７】上記証明証検証装置は、上記証明証に含
まれる被発行者公開鍵識別情報により識別される被発行
者の公開鍵を用いて上記確認済合意情報の署名を検証し
て、上記証明証の発行に対して被発行者が合意している
ことを確認することを特徴とする請求項５に記載の認証
方式。
【請求項８】上記証明証検証装置は、上記証明証に含
まれる上記確認済合意情報を検証し、上記確認済合意情
報に含まれる発行者公開鍵識別情報が上記証明証を発行
した発行者の公開鍵を証明する証明証に含まれる公開鍵
を示していることを確認することを特徴とする請求項７
に記載の認証方式。
【請求項９】上記確認済合意情報は、さらに、被発行
者の公開鍵を識別するための被発行者公開鍵識別情報を
含むことを特徴とする請求項４〜８いずれかに記載の認
証方式。
【請求項１０】上記確認済合意情報は、さらに、被発
行者の公開鍵を識別するための被発行者公開鍵識別情報
を含み、上記証明証検証装置は、上記証明証に含まれる
上記確認済合意情報を検証し、上記確認済合意情報に含
まれる被発行者公開鍵識別情報が上記証明証に含まれる
被発行者の公開鍵を示していることを確認することを特
徴とする請求項５〜８に記載の認証方式。
【請求項１１】上記証明証は、少なくとも、発行者名
と被発行者名と被発行者の公開鍵とを含む証明証である
とともに、上記確認済合意情報を格納するための拡張領
域を有し、上記証明証発行装置は、上記拡張領域に上記確認用合意
情報を未格納の状態の証明証を合意確認用情報として生
成し、生成した合意確認用情報を被発行者に提示して合
意を確認し、合意が確認されたことを示す確認済合意情
報を該証明証の該拡張領域に格納して証明証を発行する
ことを特徴とする請求項１に記載の認証方式。
【請求項１２】上記確認済合意情報は、被発行者公開
鍵識別情報として、被発行者の公開鍵から所定の方式で
算出した被発行者の公開鍵のハッシュ値を含むととも
に、上記証明証検証装置は、上記確認済合意情報に含まれる
被発行者の公開鍵のハッシュ値と、上記証明証に含まれ
る被発行者の公開鍵から上記方式と同一の方式で算出し
たハッシュ値とが一致することを確認して、上記証明証
を検証することを特徴とする請求項１０に記載の認証方
式。
【請求項１３】上記確認済合意情報は、発行者公開鍵
識別情報として、発行者の公開鍵から所定の方式で算出
した発行者の公開鍵のハッシュ値を含むとともに、上記証明証検証装置は、上記確認済合意情報に含まれる
発行者の公開鍵のハッシュ値と、上記証明証を発行した
発行者の公開鍵を証明する証明証に含まれる発行者の公
開鍵から上記方式と同一の方式で算出したハッシュ値と
を比較して、両者が一致することを確認して、上記証明
証を検証することを特徴とする請求項８に記載の認証方
式。
【請求項１４】上記合意情報確認装置は、該合意確認
用情報のハッシュ値を算出して、該証明証により証明さ
れる公開鍵と対の秘密鍵を利用して算出した該合意確認
用情報のハッシュ値に対してディジタル署名を付加して
確認済合意情報を作成して、作成した確認済合意情報を
発行者に対して送付することを特徴とする請求項３に記
載の認証方式。
【請求項１５】上記証明証生成装置は、上記合意確認
用情報のハッシュ値を算出して、算出した合意確認用情
報のハッシュ値を被発行者に提示するとともに、上記合意情報確認装置は、自身が取得可能な情報を元に
合意確認用情報を確認するためのハッシュ値を算出し
て、算出したハッシュ値と提示された合意確認用情報の
ハッシュ値とを比較して、両者が一致することを確認す
ることを特徴とする請求項３に記載の認証方式。
【請求項１６】上記証明証発行装置は、合意が確認さ
れた旨をユーザに示すための表示情報をテキスト及び画
像の少なくともいずれかの形式で上記確認済合意情報に
含ませて証明証を発行することを特徴とする請求項１に
記載の認証方式。