JP3935879B2 - データ供給のためのシステム - Google Patents

Description

【技術分野】
【０００１】
本発明は、データ供給のためのシステムに関する。本発明の分野は、公開鍵暗号の分野である。
【背景技術】
【０００２】
公開鍵暗号は、暗号化鍵と復号鍵とが異なり、一方の鍵を知っているだけではもう一方の鍵を計算することが不可能な、非対称アルゴリズムを使用している。ユーザは、１対の鍵、すなわち２つの大きな数字を受け取る（または、適切なハードウェア自体またはソフトウェア自体で生成させることができる）。ユーザは、そのうち一方を秘密にしておき、決して開示しない。もう一方の鍵は、電話番号や同様の個人データのように、安全に公開することができる。アルゴリズムの性質と鍵が生成される方法のために、秘密鍵で暗号化された情報は公開鍵でのみ、また公開鍵で暗号化された情報は秘密鍵でのみ復号することができる。したがって、送信者および受信者が秘密を共有する必要はない。
【０００３】
公開鍵暗号によって以下のいくつかのことが可能になる。
・ユーザの公開鍵を知っている人であれば誰でも、その鍵を使って暗号化したメッセージをユーザに送ることができ、唯一秘密鍵を持っているそのユーザだけが、そのメッセージを復号可能であることを確信できる。これによって機密性が提供される。
・ユーザはまた、自分の秘密鍵でメッセージを暗号化することができる。これは、公開鍵を知っている人であれば誰でもそれを復号することができるため、機密性を提供することはできない。しかし、その人たちがそのメッセージを復号できるということは、そのメッセージが、唯一、秘密鍵を持っているそのユーザからきたものにちがいないことを意味する。これによって完全性と認証が提供され、また、否認防止のための基礎、すなわち署名と同等であるディジタルのものとしての役割を果たす。
・送信者が自分の秘密鍵でメッセージに署名し、次いでそれを受信者の公開鍵で暗号化するならば、機密性、完全性、認証、否認防止が同時に提供される。
【０００４】
実際のところは、ことはより複雑である。最初の例では、パフォーマンス上および操作上の理由から、送信者は、ランダム対称セッション鍵を選択し、対称暗号を使用して、メッセージを暗号化するであろう。公開鍵は、そのセッション鍵を暗号化するためだけに使用される。同様に、２番目の例では、ユーザは、まず、自分が署名したいと思うメッセージを「ダイジェスト」し、そのダイジェストを自分の秘密鍵で暗号化する。受信者は、ダイジェストを再計算して、その値を前記ユーザから復号した値と比較する。ダイジェストは、比較的短い固定長の数学的構成物であり、任意の長さのメッセージから引き出される。ダイジェストは、メッセージおよび対応するダイジェストを知っていても、同じダイジェストで別のメッセージを計算することは不可能であるという本質的な特性を備えている。
【０００５】
全ての処理はソフトウェアによって行われる。本物の人間のユーザは、実際には何も「行う」ことはない。
【０００６】
実際には公開鍵を世間に公表する必要はないことを理解しておくことが重要である。公開鍵は、ビジネス上およびプライベート上の必要に応じた広さ、または狭さの範囲で共用することができる。
【０００７】
従来技術においては、複数の公開鍵を互いにリンクさせて、公開鍵インフラストラクチャ−ＰＫＩ−を形成することができる。これらのリンクは、証明書と呼ばれるデータ構造（またはデータ・ファイル）である。以下に、それがどのように機能するかを示す。
・アリスは、自分の公開鍵（および識別情報）を登録局（ＲＡ）に登録することを決める。（この従来技術の説明においては、それぞれ署名者と利用側当事者を表すのに、よくある名前の「アリス」と「ボブ」を使用する）。
・次いで、認証局（ＣＡ）は、ＲＡが収集した情報を使って、アリスの公開鍵がアリスおよび有効期間を識別する情報と共に含まれている、コンピュータ・ファイルを作成することができる。ＣＡは、それ自身の秘密鍵でそのファイルに署名して、証明書を作成する。
・ＣＡの公開鍵が今度は別のＣＡによって証明され、次にそのＣＡの証明書が別のＣＡによって証明される。同じことが、最終的にルート、すなわち、その値については何か別の方法で知る必要がある、未署名（または自己署名）の公開鍵があるＣＡに到達するまで繰り返される。
・したがって、ルートから出発することにより、証明書のチェーンを伝って、公開鍵の値を発見することができる。
【０００８】
このようにリンクされている１組の公開鍵が、公開鍵インフラストラクチャを形成する。最も単純なＰＫＩは、ルートとしての役割を果たし、かつ全ての証明書に署名する、単一のＣＡを備える。階層の代わりにクロス証明を使って、従来技術のＰＫＩを構築することもできるが、最終的な結果はほぼ同じである。
【０００９】
正しいソフトウェアを持つ者は誰でも、ＲＡまたはＣＡになり得る。法的またはビジネス上の制約があったとしても、ＲＡまたはＣＡが誰かによって認可を受けるための技術的な要件はない。
【００１０】
公開鍵をＰＫＩ中にリンクさせても、それにマッチする秘密鍵を使って行えることには影響しないことを理解しておくことが重要である。以下に、いくつかの一般的な誤解をはっきりさせておく。
・証明書は、秘密鍵の所有者ではなく、利用側当事者によって「使用」される。利用側当事者は、暗号化または署名のチェックに使用するための公開鍵を、証明書から抽出する。
・証明書は、ディジタル署名の作成または受信メッセージの復号には必要とされない。
・ユーザは、誰か他の人の署名をチェックするために、または暗号化メッセージを送るために、いずれかの証明書において名前が記載される必要は全くない。
・先進的電子署名（ＥＵ電子署名指令中に定義されている）ですら、マッチする公開鍵に関連する証明書が存在することを要求していない。
【００１１】
従来技術においてＰＫＩが実装される代表的な方法は、以下の通りである。
・アリスは、自分の秘密鍵を管理することに同意するとともに、「証明書のポリシー」および「証明書プラクティス・ステートメント」を記載した申込用紙に、自分の通常の手書きの署名を行う。
・アリスは、次いで、自分のＲＡに送るＰＫＣＳ＃１０オブジェクトを構築し、それに署名する。ＰＫＣＳ＃１０は、業界標準のデータ・フォーマットである。
・ＲＡは、受け取ったオブジェクトの内容を、アリスについてわかっていることと照合し、証明書要求をＣＡに送る。
・ＣＡは、世界のいずれかのボブが利用することができる証明書に署名し、それをアリスに送る。その証明書には、おそらく１年後ほどの満了日が記載されている。アリスは、証明書が満了したときには、おそらくその目的で再び手書きの署名を使って、その証明書を更新する措置をとることを覚えていなければならない。
・アリスが何かに電子的に署名すると、彼女のソフトウェアが、彼女の署名ブロックおよび署名されたオブジェクトとともにその証明書を利用側当事者に送ってくれる。
・その送信を受信すると、ボブは（すなわち彼のソフトウェアは）、まずその証明書を調べて、それが有効期間内かどうかをチェックする。ボブが「発行者」を認識し、発行者の公開鍵を知っている場合には、彼は、証明書の署名もチェックすることができる。それが計算されたならば、彼は証明書から公開鍵を抽出して、署名されているデータ上の署名をチェックすることができる。
・しかし、もちろん、彼が発行者の公開鍵を知らない場合もある。この場合、彼は、自分が知っている公開鍵にリンクしている証明書のチェーンが必要になる。場合によってはアリスが彼にチェーンを送っている。あるいは、場合によっては、彼は、自分で公開ディレクトリを検索してチェーンを組み立てなければならない。ディレクトリにアクセスするのに料金を支払わなければならない場合、または支払わないでよい場合がある。ボブは、ある証明書中の発行者名が次の証明書中の対象者名と同じであること、全ての証明書上の全ての署名が一致すること、また、チェーン内の有効期間が互いに対して理にかなっていることをチェックすることによって、チェーンを処理する必要がある。もちろん、元の証明書と彼が暗に知っているいずれかの公開鍵によって署名された証明書の両方を含むチェーンを構築できない可能性もある。
・しかし、もちろん、元の証明書、またはチェーン内の証明書のいずれかが無効になっている場合もある。したがって、ボブのソフトウェアは、次いで、各証明書に含まれているインターネット・アドレス（ＵＲＬ−ユニフォーム・リソース・ロケータ）に順番に行って、そのＵＲＬから最新の証明書廃棄リスト（ＣＲＬ）を抽出し、チェーン内の次の証明書のシリアル番号がそこに現れていないことをチェックしなければならない。各ＣＲＬにアクセスするのに料金を支払わなければならない場合、または支払わないでよい場合がある。
・上記の最後の３項目の代わりに、ボブは、証明書を検証機関（ＶＡ）に回すことができる。検証機関（ＶＡ）は、作業の多くを彼のためにやってくれ、元の証明書の検証に関する署名付きの正当／不正応答を返してくれる。検証サービスが十分に完全なものであれば、ボブが自分で行った場合に比べ、成功できる頻度が高いであろう。検証サービスを使用すると、おそらく料金がかかる。
・ボブは、当該証明書および、残りのチェーンとＣＲＬ、または署名付き検証応答のいずれかを保管する。ボブは、後でアリスの証明書が廃棄された場合に備えて、タイムスタンプ機関から、廃棄される前にその証明書を入手したことを証明するための、署名付きデータの署名ブロックのタイムスタンプを得ておくのもよいであろう。
【非特許文献１】
１９９９年１２月１３日の、欧州議会および評議会による、電子署名のためのコミュニティ・フレームワークに関する指令１９９９／９３／ＥＣ
【発明の開示】
【発明が解決しようとする課題】
【００１２】
公開鍵暗号の発明以来、世界中の誰もが、誰でも他の人のディジタル署名を確信をもって確認することができる、普遍的なインフラストラクチャのビジョンが考えられている。このようなインフラストラクチャを利用した電子トランザクションであれば、完全性と否認防止という重要な特性が得られよう。
【００１３】
このようなビジョンが実現されれば、個人は、いつでも、どこでも、何にでもディジタル署名をすることができるようになるので、個人に権限を付与することができる。また、その結果、ビジネス上の競争力がもたらされるであろう。すなわち、例えば買い手としてすでにある電子市場に参加している典型的な会社が、同じアイデンティティで、例えば売り手として、別の電子市場にスムーズに参加することができるであろう。このビジョンは、電子市場の概念の性質を−そして経済を−変える可能性を持っている。全世界は、急速に、単一の電子市場、すなわち統合された電子経済に急速に発展していく可能性がある。
【００１４】
従来技術では、対象者が、どこでも何にでも署名することができる機能を備えた公開鍵インフラストラクチャに参加することが容易に可能にはならない。従来技術の鍵ペアは、一般に、証明書とは関係なく、個人の特性の拡張というよりも「管理されたアイデンティティ」の一部としてみなされている。
【００１５】
従来技術のＰＫＩは、主として、対象者が直接、ある１つの団体に関連している、管理されたアイデンティティというコンテキストにおいてのみ関連があり、アイデンティティはそのコンテキスト内においてのみ意味を成す。例えば、従業員として、または銀行の顧客としての、または大企業を対象とするベンダなどとして参加している場合。鍵ペアを取得または生成すると、対象者は、一つのビジネス・パートナー（例えば、銀行、または企業主、または大口の顧客）に、自分のアイデンティティが自分の公開鍵に結合されていることを確信させる。特定の個人は誰も、ある時点で顕著になる、複数の管理されたアイデンティティを有すると考えられる。
【００１６】
普遍的なインフラストラクチャのビジョンの提供における、従来技術のさらなる大きな問題は、ＣＡの契約が一般に対象者との間でなされ、利用側当事者との間でなされるのではないことである。従来のＣＡビジネスの間では、対象者は「証明書が発行される」ことに伴う総コスト−または、場合によってはコストのいずれかの一部−を支払いたがらないという認識がある。
【００１７】
さらに、ＣＡの契約はアリス−証明書に名前が記載されている対象者−との契約であり、証明書の正当性を利用するボブとの契約ではないことによって生じる、道理に反する債務の問題がある。従来技術のＰＫＩにおいては、問題が生じるまでは、誰が証明書を利用しているかを証明書の署名者が知ることはないため、１証明書当りの債務は上限がない。アリスは同じ証明書を無数のボブに送ることができ、ＣＡは、どれほどの債務が増加しているのかを知る由もない。証明書の「価値」は、ＣＡ（その価値のソース）が知ることなく、繰り返し再使用することが可能である。
【００１８】
１９９９年１２月１３日の、欧州議会および評議会による、電子署名のためのコミュニティ・フレームワークに関する指令１９９９／９３／ＥＣ（「指令」）に、本明細書で使用している用語のいくつかが定義されている。しかし、本明細書における「証明書」の定義は、指令での定義よりも広い。指令で使用しているこの用語は、本明細書で使用している「検証証明書」に対応する。本明細書における「ディジタル署名」という用語は、指令の「先進的電子署名」という概念を実装するための技術を指す。
【課題を解決するための手段】
【００１９】
本発明の第１の態様によれば、記載のエンティティに関するデータを利用側エンティティに供給するための方法であって、第１の署名エンティティによって電子署名がなされた第１のディジタル証明書を生成するステップであって、前記第１のディジタル証明書が前記記載のエンティティの１つまたは複数の属性と、前記第１の署名エンティティを識別する１つまたは複数の属性を含む、前記第１のディジタル証明書の１つまたは複数の属性と、供給すべき、前記記載のエンティティに関するデータの指示と、前記供給すべきデータの１つまたは複数のソースの指示と、前記データを供給すべき先の１つまたは複数の利用側エンティティを識別する１つまたは複数の属性とを含むステップと、前記利用側エンティティが、処理のために前記第１のディジタル証明書を転送するステップと、ソースが、前記第１のディジタル証明書中に指示されている前記データを供給するステップとを含む方法が提供される。
【００２０】
第１のディジタル証明書は、ソースがデータ記憶装置中に保持することができる、記載のエンティティの個人データにアクセスできる権限を利用側エンティティに付与し、本明細書では権限付与証明書と呼ぶ場合がある。記載のエンティティおよび利用側エンティティは、個人、個人のグループ、特定の任務における個人、法人、組織、コンピュータ・アプリケーションまたはシステム、自動化機械などであってよい。
【００２１】
電子署名は、指令では、他の電子データに添付され、または論理的に関連付けられ、認証方法としての役割を果たす、電子形態のデータとして定義されている。
【００２２】
第１のディジタル証明書は、前記利用側エンティティが前に含めることを要求していた参照、ナンス、またはその他のデータを含むことができる。
【００２３】
ソースはデータを保持することが可能であり、または、１つまたは複数のデータ・ソースを参照することが可能である。
【００２４】
第１のディジタル証明書をディジタル署名付きのオブジェクトとともに送ることができるが、そのままでも送ることができる。第１のディジタル証明書の署名エンティティは、記載のエンティティであってもよく、この場合、第１のディジタル証明書は自己署名証明書の形態である。ディジタル署名付きのオブジェクトが第１のディジタル証明書とともに送られる場合、ディジタル署名、および第１のディジタル証明書中の電子署名は、異なる署名用鍵ペアを使用してもよい。
【００２５】
記載のエンティティに関するデータには、記載のエンティティが管理する秘密鍵に対応する、１つまたは複数の公開鍵を含むことができる。
【００２６】
前記記載のエンティティに関するデータを、第２のディジタル証明書を用いて前記利用側エンティティに供給することができ、この場合、前記第２のディジタル証明書は、第２の署名エンティティによって電子署名がなされており、前記供給すべきデータを含む、記載のエンティティの１つまたは複数の属性と、前記第２の署名エンティティを識別する１つまたは複数の属性を含む、前記第２のディジタル証明書の１つまたは複数の属性と、前記データを供給すべき先の１つまたは複数の利用側エンティティを識別する１つまたは複数の属性とを含んでいる。
【００２７】
第２のディジタル証明書を、本明細書ではカスタム証明書と呼ぶ。第１および第２のディジタル証明書は、公開鍵暗号を使った電子署名を用いた証明書のための国際標準および業界標準によって規定されているフォーマットであってよい。第１および第２のディジタル証明書は、記載のエンティティおよび利用側エンティティを識別するのに十分な属性を含むことができる。これは、１つの属性であってもよいし、あるいは複数の属性の組合せであってもよい。例えば、名前は、あるエンティティを一意に識別するのに十分ではないかもしれないが、一方、名前、生年月日、住所の組合せは、そのエンティティを一意に識別することが多い。
【００２８】
前記第１のディジタル証明書は、前記利用側エンティティが前記第１のディジタル証明書を使って第２のディジタル証明書を得ることを認可することができる。前記利用側エンティティは、認定されたものとしてマークされた第２のディジタル証明書を得ることを認可される場合がある。「認定証明書」は、指令の中で定義されている。
【００２９】
前記第２のディジタル証明書は、前記第１のディジタル証明書の１つまたは複数の属性を含むことができる。前記第１のディジタル証明書の内容の少なくとも一部を、前記第２のディジタル証明書にコピーすることができる。
【００３０】
この方法は、利用側エンティティが、ソースからデータを得るために前記第１のディジタル証明書を中間エンティティに転送するステップを含むことができる。中間エンティティは、利用側エンティティにサービスを提供することができ、また、ソースからのデータの供給について、保険を提供し、金融債務を受け取る場合がある。前記中間エンティティは、前記第２のディジタル証明書を生成することができる。
【００３１】
第２のディジタル証明書は、前記第１のディジタル証明書に含まれている、前記利用側エンティティを識別する１つまたは複数の属性とは異なる、前記利用側エンティティを識別する１つまたは複数の属性を含むことができる。
【００３２】
前記第２のディジタル証明書は、前記第１のディジタル証明書に含まれている、前記記載のエンティティを識別する１つまたは複数の属性とは異なる、前記記載のエンティティを識別する１つまたは複数の属性を含むことができる。
【００３３】
前記記載のエンティティは、対応する公開鍵を持つ秘密鍵を使ってディジタル署名を生成することができ、前記第１の署名エンティティは前記第１のディジタル証明書に前記ディジタル署名または暗号ダイジェストを含めることができ、前記利用側エンティティに供給すべきデータは前記公開鍵を含むことができる。暗号化ダイジェストは、ハッシュ関数を使って得ることができる。利用側エンティティが、公開鍵を含めて指示されているデータをソースから受け取ると、ディジタル署名を確認することができる。
【００３４】
第１のディジタル証明書および第２のディジタル証明書は有効期間を含むことができる。前記第１のディジタル証明書または前記第２のディジタル証明書の前記有効期間は、ディジタル証明書が生成される間の短い期間であってよい。例えば、これは１秒または２秒であってよい。そのディジタル証明書の生成時間よりも前に開始する有効期間を有する、ディジタル証明書を生成することができる。有効期間は、ディジタル証明書を生成する前の過去の場合もあれば、未来の場合もあり、または過去から未来にわたる期間の場合もある。
【００３５】
前記第１のディジタル証明書中に指示されている前記データは、前記第１のディジタル証明書中に識別される記載のエンティティから前記第１のディジタル証明書中に識別される前記利用側エンティティに対して負う支払いまたは債務の確認を含むことができる。第２の署名エンティティは、第１のディジタル証明書中に支払うべきものとして示されている債務の保証を第２のディジタル証明書中に示すことができる。
【００３６】
以前に供給されたデータの変更は、前記以前に供給されたデータに関する第２のディジタル証明書を識別するリストを供給することによって指示することができる。リストは、もはや前記利用側エンティティに供給されることが認可されていないデータを指定する、第１または第２のディジタル証明書を識別することができる。前記リストの生成は、１つまたは複数の属性が前記リストが関わる前記利用側エンティティを識別するステップを含むことができる。このリストは、証明書廃棄リストの場合がある。
【００３７】
この方法は、前記第２のディジタル証明書のリストを生成して記憶するステップであって、第２のディジタル証明書が、利用側エンティティに関連する該リスト中の全ての第２のディジタル証明書が識別され得るように、前記利用側エンティティを識別する１つまたは複数の属性ごとの索引が付けられるステップを含むことができる。
【００３８】
本発明の第２の態様によれば、記載のエンティティに関するデータを利用側エンティティに供給するためのシステムであって、前記システムは、第１の署名エンティティ・アプリケーション、利用側エンティティ・アプリケーション、および前記記載のエンティティに関するデータを保持するデータ記憶装置を含み、前記第１の署名エンティティ・アプリケーションは、前記第１の署名エンティティ・アプリケーションによって電子署名がなされた第１のディジタル証明書を生成するための手段であって、前記第１のディジタル証明書が、前記記載のエンティティの１つまたは複数の属性と、前記第１の署名エンティティを識別する１つまたは複数の属性を含む、前記第１のディジタル証明書の１つまたは複数の属性と、供給すべき、前記記載のエンティティに関するデータの指示と、前記供給すべきデータの１つまたは複数のソースの指示と、前記データを供給すべき先の１つまたは複数の利用側エンティティを識別する１つまたは複数の属性とを含む手段を備え、前記利用側エンティティ・アプリケーションは、処理のために前記第１のディジタル証明書を転送するための手段と、前記第１のディジタル証明書中に指示されている前記データを前記データ記憶装置から供給するための手段とを備えるシステムが提供される。
【００３９】
このシステムを、例えばインターネットなどのネットワークを介して、安全なメッセージングを行うシステムを使って提供することができる。記載のエンティティおよび利用側エンティティは、ソフトウェア・アプリケーションを使って、メッセージおよび証明書を生成し、それに署名することができる。供給すべきデータは、ソースがデータ記憶装置中に保持することができ、また、そのデータ記憶装置は電子データベースであってよい。ソースは前記データ記憶装置を保持することができ、または、１つまたは複数のさらなるソースを参照することができる。前記第１の署名エンティティは前記記載のエンティティであってよい。このシステムは、記載のエンティティに関するデータを保持する複数のデータ記憶装置を含むことができる。
【００４０】
前記第１のディジタル証明書は、前記利用側エンティティが前に含めることを要求していた参照、ナンス、またはその他のデータを含むことができる。
【００４１】
前記記載のエンティティに関するデータを前記利用側エンティティ・アプリケーションに供給するために第２のディジタル証明書を提供することができ、前記第２のディジタル証明書は、第２の署名エンティティ・アプリケーションによって電子署名がなされていて、また、前記供給すべきデータを含む、記載のエンティティの１つまたは複数の属性と、前記第２の署名エンティティを識別する１つまたは複数の属性を含む、前記第２のディジタル証明書の１つまたは複数の属性と、前記データを供給すべき先の１つまたは複数の利用側エンティティを識別する１つまたは複数の属性とを含んでいる。
【００４２】
前記第１のディジタル証明書は、前記利用側エンティティが前記第１のディジタル証明書を使って第２のディジタル証明書を得ることを認可することができる。前記利用側エンティティは、認定されたものとしてマークされた第２のディジタル証明書を得ることを認可され得る。前記第２のディジタル証明書は、前記第１のディジタル証明書の１つまたは複数の属性を含むことができる。前記第１のディジタル証明書の内容の少なくとも一部を、前記第２のディジタル証明書にコピーすることができる。
【００４３】
このシステムは、データ記憶装置からデータを得るために前記利用側エンティティ・アプリケーションが前記第１のディジタル証明書を転送する、中間エンティティ・アプリケーションを含むことができる。中間エンティティは、ソフトウェア・アプリケーションを使って、利用側エンティティとソースの間で動作することができる。前記中間エンティティ・アプリケーションは、第２のディジタル証明書を生成することができる。
【００４４】
前記第２のディジタル証明書は、前記第１のディジタル証明書に含まれている、前記利用側エンティティを識別する１つまたは複数の属性とは異なる、前記利用側エンティティを識別する１つまたは複数の属性を含むことができる。
【００４５】
前記第２のディジタル証明書は、前記第１のディジタル証明書に含まれている、前記記載のエンティティを識別する１つまたは複数の属性とは異なる、前記記載のエンティティを識別する１つまたは複数の属性を含むことができる。
【００４６】
前記記載のエンティティは、対応する公開鍵を持つ秘密鍵を使ってディジタル署名を生成することができ、前記第１の署名エンティティは前記第１のディジタル証明書に前記ディジタル署名または暗号ダイジェストを含めることができ、前記利用側エンティティに供給すべきデータは前記公開鍵を含むことができる。暗号化ダイジェストは、ハッシュ関数を使って得ることができる。利用側エンティティが、公開鍵を含めて指示されているデータをソースから受け取ると、ディジタル署名を確認することができる。
【００４７】
第１のディジタル証明書および第２のディジタル証明書は有効期間を含むことができる。前記第１のディジタル証明書または前記第２のディジタル証明書の前記有効期間は、ディジタル証明書が生成される間の短い期間であってよい。そのディジタル証明書の生成時間よりも前に開始する有効期間を有する、ディジタル証明書を生成することができる。有効期間は、ディジタル証明書を生成する前の過去の場合もあれば、未来の場合もあり、または過去から未来にわたる期間の場合もある。
【００４８】
前記第１のディジタル証明書中に指示されている前記データは、前記第１のディジタル証明書中に識別される前記記載のエンティティから前記第１のディジタル証明書中に識別される前記利用側エンティティに対して負う支払いまたは債務の確認を含むことができる。第２の署名エンティティは、第１のディジタル証明書中で支払うべきものとして示されている債務の保証を、第２のディジタル証明書中に示すことができる。
【００４９】
以前に供給されたデータの変更は、前記以前に供給されたデータに関する第２のディジタル証明書を識別するリストを供給することによって指示され得る。リストは、前記利用側エンティティに供給されることがもはや認可されていないデータを指定する、第１または第２のディジタル証明書を識別することができる。前記リストの生成は、１つまたは複数の属性が、前記リストが関わる前記利用側エンティティを識別するステップを含むことができる。このリストは、証明書廃棄リストの場合がある。
【００５０】
データ記憶装置は、該データ記憶装置中に含まれるデータの項目について、その項目を参照した第１のディジタル証明書中に関する、または含まれている情報、あるいは、その項目の値を提供する第２のディジタル証明書に関する、または含まれている情報を判断する手段を備えることができる。上記の証明書リストは、この手段を介して生成することができる。
【００５１】
前記中間エンティティ・アプリケーションは、第２のディジタル証明書中で識別される前記利用側エンティティが参照する、前記第２のディジタル証明書を記憶するための記憶手段を備えることができる。
【００５２】
このシステムは、次にどのデータ記憶装置またはその他のプロキシ・エンティティ・アプリケーションに前記第１の証明書を転送するかを指定する情報を得るために、前記利用側エンティティ・アプリケーションまたは前記中間エンティティ・アプリケーションが前記第１のディジタル証明書を転送することができるプロキシ・エンティティ・アプリケーションを含むことができる。
【００５３】
本発明の第３の態様によれば、コンピュータ可読記憶媒体上に記憶されたコンピュータ・プログラム製品であって、署名エンティティによって電子署名がなされたディジタル証明書を生成するステップであって、前記ディジタル証明書が記載のエンティティの１つまたは複数の属性と、前記署名エンティティを識別する１つまたは複数の属性を含む、前記ディジタル証明書の１つまたは複数の属性と、供給すべき、前記記載のエンティティに関するデータの指示および１つまたは複数のソースの指示、または前記データ自体のうちのいずれかと、前記データを供給すべき先の１つまたは複数の利用側エンティティを識別する１つまたは複数の属性とを含むステップを実行させるためのコンピュータ可読プログラム・コード手段を含むコンピュータ・プログラム製品が提供される。
【００５４】
コンピュータ・プログラム製品に、本発明の第１および第２の態様の１つまたは複数の特徴を備えることができる。
【００５５】
本発明の第４の態様によれば、署名エンティティによって電子署名がなされたディジタル証明書であって、記載のエンティティの１つまたは複数の属性と、前記署名エンティティを識別する１つまたは複数の属性を含む、前記ディジタル証明書の１つまたは複数の属性と、供給すべき、前記記載のエンティティに関するデータの指示および１つまたは複数のソースの指示、または前記データ自体のうちのいずれかと、１つまたは複数の利用側エンティティを識別する１つまたは複数の属性とを含み、前記利用側エンティティが、前記記載のエンティティに関するデータが供給される先のエンティティであるディジタル証明書が提供される。
【００５６】
利用側エンティティを識別するディジタル証明書は、記載のエンティティに関する指示されているデータを取得する権限を利用側エンティティに認定するものの場合があり、あるいは、データ自体を利用側エンティティに供給するものの場合もある。
【００５７】
ディジタル証明書に、本発明の第１および第２の態様の１つまたは複数の特徴を備えることができる。
【００５８】
本発明の第５の態様によれば、ディジタル証明書に基づいてディジタル署名を提供する方法であって、公開鍵に対応する秘密鍵を使ってディジタル署名を生成するステップであって、署名付きデータが、生成されるディジタル証明書を識別する１つまたは複数の属性を含むステップと、署名エンティティによって電子署名がなされたディジタル証明書を生成するステップであって、前記ディジタル証明書が、前記公開鍵を得るのに十分な、記載のエンティティの１つまたは複数の属性と、前記署名エンティティを識別する１つまたは複数の属性を含む、前記ディジタル証明書の１つまたは複数の属性と、前記ディジタル証明書の生成時間よりも早く開始する、前記ディジタル証明書の指示有効期間とを含むステップとを含み、前記ディジタル証明書は前記ディジタル署名の生成よりも後に生成される方法が提供される。
【００５９】
オブジェクトに、まだ生成されていないディジタル証明書を前方参照するディジタル署名を付けることができ、次いで、ディジタル証明書を逆方向参照し、そのディジタル署名が生成された時間を含む有効期間を有するディジタル証明書を生成することができる。
【００６０】
同じディジタル証明書を識別する複数のディジタル署名を生成することができる。前記署名エンティティは、前記記載のエンティティであってよい。
【００６１】
前記ディジタル証明書の前記有効期間は、前記ディジタル署名が生成される間の短い期間であってよい。
【００６２】
前記ディジタル署名中に与えられる、前記生成されるディジタル証明書を識別する１つまたは複数の属性は、シリアル番号を含むことができる。次に生成されるべきディジタル証明書に使用可能な最も小さい利用可能シリアル番号、または各秘密鍵を使って最後に使用されたシリアル番号を記録することができる。
【００６３】
本発明の第６の態様によれば、ディジタル証明書に基づいてディジタル署名を提供するシステムであって、公開鍵に対応する秘密鍵を使ってディジタル署名を生成するための手段を備えた記載エンティティ・アプリケーションであって、署名付きデータが、生成されるディジタル証明書を識別する１つまたは複数の属性を含む記載エンティティ・アプリケーションと、電子署名がなされたディジタル証明書を生成するための手段であって、前記ディジタル証明書が、前記公開鍵を得るのに十分な、記載のエンティティの１つまたは複数の属性と、前記署名エンティティを識別する１つまたは複数の属性を含む、前記ディジタル証明書の１つまたは複数の属性と、前記ディジタル証明書の生成時間よりも早く開始する、前記ディジタル証明書の指示有効期間とを含む手段を備えた署名エンティティ・アプリケーションとを含み、前記ディジタル証明書は前記ディジタル署名の生成よりも後に生成されるシステムが提供される。
【００６４】
システムに、本発明の第５の態様の機能のうち１つまたは複数を備えることができる。
【００６５】
本発明の第７の態様によれば、コンピュータ可読記憶媒体上に記憶されたコンピュータ・プログラム製品であって、公開鍵に対応する秘密鍵を使ってディジタル署名を生成するステップであって、署名付きデータが、生成されるディジタル証明書を識別する１つまたは複数の属性を含むステップと、署名エンティティによって電子署名がなされたディジタル証明書を生成するステップであって、前記ディジタル証明書が前記公開鍵を得るのに十分な、記載のエンティティの１つまたは複数の属性と、前記署名エンティティを識別する１つまたは複数の属性を含む、前記ディジタル証明書の１つまたは複数の属性と、前記ディジタル証明書の生成時間よりも早く開始する、前記ディジタル証明書の指示有効期間とを含むステップとを実行するためのコンピュータ可読プログラム・コード手段を含み、前記ディジタル証明書は前記ディジタル署名の生成よりも後に生成されるコンピュータ・プログラム製品が提供される。
【００６６】
コンピュータ・プログラム製品に、本発明の第５の態様の機能のうち１つまたは複数を備えることができる。
【００６７】
本発明の第８の態様によれば、署名エンティティによって電子署名がなされたディジタル証明書であって、記載のエンティティの１つまたは複数の属性と、前記署名エンティティを識別する１つまたは複数の属性を含む、前記ディジタル証明書の１つまたは複数の属性と、前記ディジタル証明書の生成時間よりも早く開始する、前記ディジタル証明書の指示有効期間とを含むディジタル証明書が提供される。
【００６８】
前記ディジタル証明書の前記指示有効期間は、該ディジタル証明書の有効期間が完全に過去になるように、前記ディジタル証明書の生成時間までに終了する、あるいは、有効期間を、過去から未来のある時間に延長することができる。
【００６９】
記載のエンティティは署名エンティティであってもよく、この場合、ディジタル署名は、自己署名証明書の形態である。電子署名には公開鍵暗号を使ってよい。前記ディジタル証明書は、前記生成時間を表すタイムスタンプを含むことができる。
【００７０】
本発明の第９の態様によれば、本発明の第８の態様において定義されているディジタル証明書から引き出される公開鍵に対応する、秘密鍵を使ったディジタル署名であって、前記ディジタル証明書が前記ディジタル署名の生成よりも後に生成され、署名付きデータが、前記生成されるディジタル証明書を識別する１つまたは複数の属性を含むディジタル署名が提供される。
【００７１】
本発明の一態様のさらなる目的は、所有権が保護され、また自動化手段によって証明され得るように、電子財産の所有権を譲渡する方法およびシステムを提供することである。
【００７２】
本発明の第１０の態様によれば、電子財産の所有権移転のためのシステムであって、第１のエンティティによって電子署名がなされた電子財産と、前記第１のエンティティによって生成され電子署名がなされたディジタル証明書であって、前記電子財産が移転される先の第２のエンティティの指示と、前記第２のエンティティにソースから供給すべきデータの指示またはデータ自体とを含むディジタル証明書とを含み、前記電子財産および前記ディジタル証明書は、前記電子財産を前記ディジタル証明書に接続するリンク手段を含むシステムが提供される。
【００７３】
「ディジタル証明書」という用語は、情報を含めるために使用され、署名することが可能ないずれかのデータ構造として、広い意味に解釈されるべきである。このデータ構造は、例えばＸ５０９ｖ．３証明書、ＸＭＬ構造またはこれら２つの組合せであってよい。
【００７４】
前記リンク手段は前記ディジタル証明書のシリアル番号および前記移転を参照する識別子から生成されるビット・ストリームであってよく、前記ビット・ストリームが前記電子財産に含まれ、前記ビット・ストリームまたは該ビットストリームの指示が前記ディジタル証明書に含まれている。あるいは、前記リンク手段は透かし鍵を有するディジタル透かしであってよく、この場合、前記透かしが前記電子財産に含まれ、前記透かし鍵または該透かし鍵の指示が前記ディジタル証明書に含まれている。
【００７５】
前記電子財産は、前記第１のエンティティが公開／秘密鍵ペアの秘密鍵を使って署名することができ、対応する公開鍵または該公開鍵の指示が前記ディジタル証明書中に提供される。
【００７６】
前記電子財産は、前記第１のエンティティが、前記第２のエンティティの公開／秘密鍵ペアの公開鍵を使って暗号化することができる。前記電子財産は、前記第１のエンティティが、セッション鍵を用いた対称暗号を使って暗号化することができ、前記セッション鍵は、前記第２のエンティティの公開／秘密鍵ペアの公開鍵を使って暗号化される。
【００７７】
前記ディジタル証明書は、該ディジタル証明書の生成時間よりも早く開始する有効期間を有することができる。
【００７８】
前記ディジタル証明書は、前記電子財産の権利が移転される期間に関する第２の有効期間を有することができる。
【００７９】
第３のエンティティによって電子署名がなされた第２のディジタル証明書を提供することができ、この第２のディジタル証明書は、前記第１のエンティティの指示と、前記第２のエンティティの指示と、前記第３のエンティティの指示と、供給すべきデータとを含む。前記供給すべきデータは、前記第１のエンティティの秘密／公開鍵ペアの公開鍵を含むことができる。
【００８０】
前記電子財産の移転は、該電子財産によって識別される口座を有する各エンティティによって追跡することができ、前記電子財産の移転時に、口座がある単位で増分または減分される。前記口座を、前記電子財産のハッシュによって識別することができる。
【００８１】
本発明の第１１の態様によれば、第１のエンティティから第２のエンティティに電子財産の権利を移転するための方法であって、前記第１のエンティティが電子署名を用いて電子財産に署名するステップと、前記第１のエンティティによって電子署名がなされ、前記第２のエンティティの指示と、前記第２のエンティティにソースから供給すべきデータの指示または前記データ自体とを含むディジタル証明書を生成するステップとを含み、前記電子財産および前記ディジタル証明書は、前記電子財産を前記ディジタル証明書に接続するリンク手段を含む方法が提供される。
【００８２】
この方法は、前記第１のエンティティが前記電子財産および前記ディジタル証明書を前記第２のエンティティに送るステップを含むことができる。
【００８３】
前記リンク手段は、前記ディジタル証明書のシリアル番号および前記移転を参照する識別子から生成されるビット・ストリームであってよく、前記ビット・ストリームが前記電子財産に含まれ、前記ビット・ストリームまたは該ビットストリームの指示が前記ディジタル証明書に含まれる。あるいは、前記リンク手段は透かし鍵を有するディジタル透かしであってよく、この場合、前記透かしが前記電子財産に含まれ、前記透かし鍵または該透かし鍵の指示が前記ディジタル証明書に含まれている。
【００８４】
前記方法は、前記第１のエンティティが、公開／秘密鍵ペアの秘密鍵を使って前記電子財産に署名するステップを含むことができ、対応する公開鍵または該公開鍵の指示が前記ディジタル証明書中に提供される。
【００８５】
この方法は、前記第１のエンティティが前記電子財産を前記第２のエンティティの公開／秘密鍵ペアの公開鍵を使って暗号化するステップを含むことができる。この方法は、前記第１のエンティティが、セッション鍵を用いた対称暗号を使って前記電子財産を暗号化するステップと、前記第２のエンティティの公開／秘密鍵ペアの公開鍵を使って前記セッション鍵を暗号化するステップとを含むことができる。
【００８６】
前記ディジタル証明書は、該ディジタル証明書の生成時間よりも早く開始する有効期間を有することができる。
【００８７】
前記ディジタル証明書は、前記電子財産の権利が移転される期間に関する第２の有効期間を有することができる。
【００８８】
この方法は、前記第２のエンティティが、第３のエンティティによって電子署名がなされた第２のディジタル証明書を得るステップを含むことができ、前記第２のディジタル証明書が、前記第１のエンティティの指示と、前記第２のエンティティの指示と、第３のエンティティの指示と、供給すべきデータとを含む。前記供給すべきデータは、前記第１のエンティティの秘密／公開鍵ペアの公開鍵を含むことができる。
【００８９】
前記電子財産の移転は、該電子財産によって識別される口座を有する各エンティティが追跡することができ、前記電子財産の移転時に、口座がある単位で増分または減分される。口座は、電子財産のハッシュによって識別することができる。
【００９０】
本発明の第１２の態様によれば、コンピュータ可読記憶媒体上に記憶されたコンピュータ・プログラム製品であって、前記第１のエンティティが電子署名を用いて電子財産に署名するステップと、前記第１のエンティティによって電子署名がなされ、前記第２のエンティティの指示と、前記第２のエンティティにソースから供給すべきデータの指示または前記データ自体とを含むディジタル証明書を生成するステップとを実行させるためのコンピュータ可読プログラム・コード手段を含み、前記電子財産および前記ディジタル証明書は、前記電子財産を前記ディジタル証明書に接続するリンク手段を含む、コンピュータ・プログラム製品が提供される。
【００９１】
本発明の一態様のさらなる目的は、電子投票のための方法およびシステムを提供することである。
【００９２】
本発明の第１３の態様によれば、認証機関と、集計機関と、複数の投票者とが存在し、投票者はディジタル証明書を生成し、前記ディジタル証明書が、前記投票者を一意に識別するために前記認証機関に供給すべき識別データの指示と、前記識別データの１つまたは複数のソースの参照とを含み、または前記指示データ自体を含み、あるいはその両方を含み、前記ディジタル証明書はまた投票鍵の指示も含み、前記投票者は、電子署名を用いて前記ディジタル証明書に署名し、前記ディジタル証明書は、前記認証機関のみが読めるよう暗号化され、前記投票者は、投票を含む投票メッセージを生成し、前記投票メッセージは、前記集計機関のみが読めるよう暗号化され、前記ディジタル証明書と前記投票メッセージを結合する署名ブロックが生成される電子投票のための方法であって、暗号化された前記ディジタル証明書と、暗号化された前記投票メッセージと、前記署名ブロックとが前記認証機関に送られる方法が提供される。
【００９３】
投票システムによっては、前記識別データの確認が外部ソースに対して要求され、前記ディジタル証明書が、前記識別データの指示と、前記投票者の投票権の確認と、前記識別データおよび前記確認を提供することが可能な１つまたは複数のソースの参照を含むことができるものがある。あるいは、投票システムが投票者による識別の表明を許可する場合には、ディジタル証明書は識別データ自体のみを含む場合がある。前記識別データと、前記識別データおよび参照の指示とが、ともに前記ディジタル証明書に含まれ得る。
【００９４】
識別データは、前記投票者の名前、住所、生年月日、国籍、居住の長さ、禁止されているクラスに含まれていないことのうち１つまたは複数を含むことができる。
【００９５】
前記投票者は、該投票者が自分の投票を識別するために適用する識別子という形態で、前記投票メッセージ中にナンスを含めることができる。前記投票者は、前記投票メッセージ中にランダム・スポイラを含めることができる。
【００９６】
前記ディジタル証明書は、前記認証機関の公開／秘密機密性鍵ペアの公開鍵を使って暗号化することができる。前記投票メッセージは、前記集計機関の公開／秘密機密性鍵ペアの公開鍵を使って暗号化することができる。
【００９７】
前記暗号化されたディジタル証明書のダイジェストを得、前記暗号化された投票メッセージのダイジェストを得、前記ダイジェストを結合することによって完全性ブロックを形成することができる。前記ダイジェストを結合することができ、前記結合からさらなるダイジェストを得て、得られたダイジェストを暗号化することができる。前記ダイジェストを、前記投票者が投票で使用する公開／秘密署名鍵ペアの秘密鍵を使って暗号化することにより、署名ブロックを提供することができる。前記投票鍵は、前記投票者が投票のために使用する前記公開／秘密署名鍵ペアの公開鍵であってよい。
【００９８】
前記認証機関は、前記ディジタル証明書および前記暗号化された投票メッセージが、前記投票者が送った状態のままであり、前記認証ブロックによってリンクされていることを確認することができる。前記認証機関は、前記ディジタル証明書を復号することができ、前記投票鍵を得、該投票鍵を使って前記署名ブロックを復号することができる。また、前記認証機関は、前記暗号化されたディジタル証明書と前記暗号化された投票メッセージを前記投票者と同じ方法を使って結合することができ、その結果を前記復号された署名ブロックと比較することができる。
【００９９】
前記投票者のシリアル番号を、前記認証機関が発行することができる。前記認証機関は、前記投票者のシリアル番号、前記ディジタル証明書のダイジェスト、前記投票鍵を含むメッセージを構築し、前記メッセージは前記認証機関によって暗号化される。前記認証機関は、前記メッセージと、前記暗号化された投票メッセージと、前記署名ブロックとを前記集計機関に送ることができる。
【０１００】
前記集計機関は、前記メッセージを復号することができ、また、前記暗号化されたディジタル証明書のダイジェストおよび前記メッセージからの投票鍵を使って、前記投票メッセージが、前記認証機関によってシリアル番号を割り当てられた、変更されていない元の投票であることを確認することができる。前記集計機関は、前記投票者の投票を復号して記録することができる。
【０１０１】
本発明の第１４の態様によれば、認証機関と、集計機関と、複数の投票者が存在する電子投票のためのシステムであって、投票者によって生成されるディジタル証明書を含み、前記ディジタル証明書は、前記投票者を一意に識別するために前記認証機関に供給すべき識別データの指示と、前記識別データの１つまたは複数のソースの参照とを含み、または前記識別データ自体を含み、あるいはその両方を含み、前記ディジタル証明書はまた前記投票鍵の指示も含み、前記ディジタル証明書は、前記投票者による電子署名がなされ、前記ディジタル証明書は、前記認証機関のみが読めるように暗号化され、前記投票者によって、投票を含む投票メッセージが生成され、前記投票メッセージは、前記集計機関のみが読めるように暗号化され、署名ブロックが前記ディジタル証明書と前記投票メッセージを結合し、この場合、前記暗号化されたディジタル証明書と、前記暗号化された投票メッセージと、前記署名ブロックとが前記認証機関に送られるシステムが提供される。
【０１０２】
投票システムによっては、前記識別データの確認が外部ソースに対して要求され、前記ディジタル証明書が、前記識別データの指示と、前記投票者の投票権の確認と、前記識別データおよび前記確認を提供することが可能な１つまたは複数のソースの参照を含むことができるものもある。別の投票システムでは、投票者による前記識別データの表明で十分であって、ディジタル証明書が識別データ自体のみを含む場合がある。前記識別データと、前記識別データおよび参照の指示が、ともに前記ディジタル証明書に含まれ得る。
【０１０３】
識別データは、前記投票者の名前、住所、生年月日、国籍、居住の長さ、禁止されているクラスに含まれていないことのうち１つまたは複数を含むことができる。
【０１０４】
ディジタル証明書は、Ｘ．５０９ｖ．３証明書であってよい。
【０１０５】
前記投票メッセージは、該投票者が自分の投票を識別するために適用する識別子という形態で、ナンスを含むことができる。前記投票メッセージは、ランダム・スポイラを含むことができる。前記ディジタル証明書を、前記認証機関の公開／秘密機密性鍵ペアの公開鍵を使って暗号化することができる。前記投票メッセージを、前記集計機関の公開／秘密機密性鍵ペアの公開鍵を使って暗号化することができる。
【０１０６】
前記暗号化されたディジタル証明書のダイジェストを得、前記暗号化された投票メッセージのダイジェストを得、前記ダイジェストを結合することによって完全性ブロックを形成することができる。前記ダイジェストを結合することができ、前記結合からさらなるダイジェストを得て、得られたダイジェストを暗号化することができる。前記ダイジェストを、前記投票者が投票のために使用する公開／秘密署名鍵ペアの秘密鍵を使って暗号化することができ、それによって署名ブロックが提供される。前記投票鍵は、前記投票者が投票のために使用する前記公開／秘密署名鍵ペアの公開鍵であってよい。
【０１０７】
前記ディジタル証明書および前記暗号化された投票メッセージが、前記投票者が送った状態のままであり、前記署名ブロックによってリンクされていることを確認することができる。前記ディジタル証明書を復号することができ、前記投票鍵を得、該投票鍵を使って前記署名ブロックを復号することができる。また、前記暗号化されたディジタル証明書と前記暗号化された投票メッセージを前記投票者と同じ方法を使って結合することができ、その結果を前記復号された署名ブロックと比較することができる。
【０１０８】
前記投票者のシリアル番号を、前記認証機関が発行することができる。前記認証機関は、前記投票者のシリアル番号、前記ディジタル証明書のダイジェスト、前記投票鍵を含むメッセージを構築し、前記メッセージは前記認証機関によって暗号化される。前記認証機関は、前記メッセージと、前記暗号化された投票メッセージと、前記署名ブロックとを前記集計機関に送ることができる。
【０１０９】
前記メッセージを、前記集計機関が復号することができ、また、前記暗号化されたディジタル証明書のダイジェストおよび前記メッセージからの投票鍵を使って、前記投票メッセージが、前記認証機関によってシリアル番号を割り当てられた、変更されていない元の投票であることを確認することができる。前記投票者の投票を、前記集計機関が復号して記録することができる。
【０１１０】
本発明の第１５の態様によれば、コンピュータ可読記憶媒体上に記憶されたコンピュータ・プログラム製品であって、ディジタル証明書を生成するステップであって、前記ディジタル証明書は、投票者を一意に識別するために前記認証機関に供給すべき識別データの指示と、前記識別データの１つまたは複数のソースの参照とを含み、または前記指示データ自体を含み、あるいはその両方を含み、前記ディジタル証明書はまた投票鍵の指示も含むステップと、前記投票者が電子署名を用いて前記ディジタル証明書に署名するステップと、前記ディジタル証明書を、前記認証機関のみが読めるように暗号化するステップと、投票を含む投票メッセージを生成するステップと、前記投票メッセージを、前記集計機関のみが読めるように暗号化するステップと、前記ディジタル証明書と前記投票メッセージを結合する署名ブロックを生成するステップと、暗号化された前記ディジタル証明書と、暗号化された前記投票メッセージと、前記署名ブロックとを前記認証機関に送るステップとを実行させるためのコンピュータ可読プログラム・コード手段を含むコンピュータ・プログラム製品が提供される。
【０１１１】
本発明を通して実装することができる提案の「権限付与インフラストラクチャ」は、識別された対象者によって保持されている秘密鍵にマッチする公開鍵の値を利用側当事者が確定できるようにするという意味で、また、認証局（ＣＡ）による署名付きの証明書および証明書廃棄リスト（ＣＲＬ）を含めて、従来技術の公開鍵インフラストラクチャ（ＰＫＩ）の構築を拡張するという意味では、ＰＫＩを説明するものである。本発明自体は公開鍵暗号法を利用しているが、実行可能なＰＫＩモデルにおける鍵と証明書の役割に関する従来の知恵に、根本的に挑戦するものである。
【０１１２】
本発明が可能にする権限付与のアプローチは、従来技術のＰＫＩの可能性を超えてうまく動作し、誰が自分の個人データにアクセスでき、また、どのように、いつアクセスできるかを管理できる権限を対象者に付与する、プライバシー強化フレームワークの中で、広範にわたる個人データ項目−公開鍵だけでなく−が認証されるようにする。本発明は、公開鍵だけでなく、どのような保証付き個人データでも配信する方法を可能にする。言い替えれば、個人データの買い手と売り手を引き合わせる電子市場のためのアーキテクチャである。この市場のブローカーは、データの対象者自身であり、この権限付与インフラストラクチャにおいては、そのデータが関わる対象者の明示の認可がない限り、個人データが移動することはない。
【０１１３】
本発明はまた、個人データ・フレームワーク内に統合された支払いメカニズムも提供する。「アリスは、１００¢の金額を支払うだけの価値を間違いなく保証します。」という形態の、アリスによって権限付与された、個人データの販売を仮定しよう。通常、個人データが販売される場合、それが引き出されるデータベースは変更されない。しかし、このケースは例外でなければならず、アリスの個人情報の販売者が管理しているデータベースの属性の一部は、正確に−あるいは、手数料や利子が伴う場合にはおおよそ−１００だけ変更されなければならない。支払いを、単に、それが販売されたときに変化する１つの個人データとして見るには、少しばかり想像力が必要である。したがって、本発明は、安全な支払いアーキテクチャも可能にする。拡張することによって、そのインフラストラクチャを使って、署名者が利用側当事者に対して支払わなければならない債務を確認することも可能であり、さらには、そのような債務に対する保証を示すことも可能である。
【発明を実施するための最良の形態】
【０１１４】
次に、例にすぎないが、添付の図面を参照しながら本発明の実施形態を説明する。
【０１１５】
図１を参照すると、従来技術で知られている証明書の形態で、データ・オブジェクトを配信する従来のシステムを示してある。図１には、このシステムの第１のユーザであるアリス１０２と、第２のユーザであるボブ１０４を示してある。また、登録局（ＲＡ）１０６、認証局（ＣＡ）１０８、および検証機関（ＶＡ）１１０も示してある。
【０１１６】
この従来のシステムでは、配信されるデータ・オブジェクトは、公開鍵暗号で使用するための証明書である。公開鍵暗号では、公開鍵証明書が、公開鍵の値を証明書の対象者に関連付ける。証明書の対象者とは、対応する秘密鍵を管理する、特定の人、役割、デバイス、またはその他のエンティティである。
【０１１７】
公開鍵証明書には、認証機関と呼ばれる個人またはエンティティによって、ディジタルに署名がなされている。
【０１１８】
登録局（ＲＡ）は、従来、認証局（ＣＡ）とその加入者または証明書申請者の間のやりとりを管理している。１つのＣＡについて複数のＲＡが存在する場合がある。証明書の発行は、識別書類の提出を通して申請者のアイデンティティを確認する、個人の存在を必要とする場合がある。ＲＡ自体は証明書を発行することはないが、証明書申請に対して、検証、承認、または拒絶することができる。
【０１１９】
従来技術では、証明書を配信する方法は、アリスの自己署名トークン（ＰＫＣＳ＃１０）１１２で開始する。ＰＫＣＳ＃１０は、ＣＡに証明書の発行を要求するためのメッセージのフォーマットを定義する。ＰＫＣＳ＃１０トークン１１２によって、要求側エンティティ、すなわちアリス１０２は、証明書に含めるために要求される、自分の公開鍵およびその他の値を供給することができる。アリス１０２は、トークン１１２をＲＡ１０６に送り、ＲＡ１０６は、それを証明書要求１１４に変換する。ＲＡは、この証明書要求をＣＡ１０８に送る。ＣＡ１０８は、それを証明書１１６に変換し、それをアリス１０２に送る。アリス１０２は、証明書１１６をそのままボブ１０４に送る。次いで、ボブは、その証明書をそのまま検証機関（ＶＡ）１１０に送り、検証機関（ＶＡ）１１０は、それを、ボブ１０４への検証応答１１８に変換する。図１では、これらの動作の順番を、括弧内の数字で示してある。
【０１２０】
図２は、上記の従来技術の従来システム２００の流れ図を示す。アリスは、第１のステップ２０１で自己署名トークンを作成し、これをＲＡに送る２０２。ＲＡはこのトークンを証明書要求に変換し２０３、その証明書要求をＣＡに送る２０４。ＣＡは証明書要求を証明書に変換し２０５、その証明書をアリスに送る２０６。アリスは証明書をボブに送る２０７。ボブは、その証明書を検証してもらう必要があるため、それをＶＡに送る２０８。ＶＡは証明書を、それが有効であることを確認または否定する検証応答に変換する２０９。ＶＡは、この検証応答をボブに送る２１０。
【０１２１】
本発明の記載の一実施形態では、方法およびシステムを、権限付与方法またはシステムと呼ぶ。このシステムを、比較のために図１と同じ構造を使って、図３に示す。この実施形態を、公開鍵暗号で使用するための証明書の配信に関して説明する。しかし、明白にわかるように、本発明は、この特定の使用目的のための証明書の配信に限定されない。アリス３０２をエンティティとして説明し、ボブ３０４を利用側エンティティとして説明する。
【０１２２】
図３を参照すると、アリス３０２はＲＡ３０６に前もって登録している３２０ので、ＲＡ３０６はアリス３０２に関する情報を持っている。アリス３０２は、自己署名トークン３１２をボブ３０４に送る。ボブ３０４は、トークン３１２をそのままＣＡ３０８に送る。ＣＡ３０８は、トークンを１つの（または複数の）ＲＡ３０６への要求に変換する３１４。ＲＡ３０６は、その要求をＣＡ３０８への応答に変換する３１６。ＣＡ３０８は、それを予め検証済みの証明書に変換し、それをボブ３０４に送る３１８。証明書が予め検証済みのため、ボブ３０４は、その証明書を検証するためのＶＡによる明示のサービスが必要ではない。ＶＡ３１０の機能は、ＣＡ３０８と結合されている。図３は、これらの動作の順番を、括弧内の数字で示してある。
【０１２３】
記載の実施形態の方法４００を、図４の流れ図に示す。第１のステップ４０１で、アリスは自己署名トークンを作成する。アリスは、そのトークンをボブに送る４０２。ボブは、トークンをＣＡに送る４０３。ＣＡは、トークンをデータ要求に変換し４０４、その要求をＲＡに送る４０５。ＲＡは、要求を応答に変換し４０６、その応答をＣＡに送る４０７。ＣＡは、応答を予め検証済みの証明書に変換し４０８、その予め検証済みの証明書をボブに送る４０９。
【０１２４】
従来技術の従来システムとシステムの記載の実施形態は、ともに、３種類の変換を実行する。両システムとも、アリスがトークンに自己署名することで開始し、ボブが対象者としてアリスの名前が記載された検証済み証明書を所有することで終了する。しかし、アリスからボブへの部分は、記載の実施形態の権限付与システムでは５ステップのうちの最初のステップであり、従来システムでは６ステップのうちの４番目のステップである。
【０１２５】
この順番の相違によって、結果が大きく違ってくることがわかる。権限付与システム３００では、アリス３０２は、各トランザクションの粒度で、自分のアイデンティティ（従業員、納税者、銀行の顧客、仮名などとしての）のうちどれを表明すべきか、また、自分のＲＡ３０６−または複数ＲＡ−に対して、自分の属性（個人データの項目）のうちどれを開示する権限を付与するかを選択することができる。ボブ３０４は、ここでは、ＣＡ３０８の顧客の役割にあるので、証明書のポリシーには、彼が納得して支払うものが反映されており、債務が理解されて管理される、改良されたＰＫＩビジネス・モデルが可能になっている。最初に署名を行う前に証明書が存在していなければならないわけではないので、アリスは、自分のＲＡの同意書に、手書きのフォームではなくディジタルで署名することができる。
【０１２６】
権限付与システム３００は、管理されたアイデンティティの一部としての証明書の概念から、データの対象者（アリス３０２）が検証済み個人データを利用側当事者（ボブ３０４）に見せる権限をＲＡに付与するメカニズムへと、見方を変えさせるものである。公開鍵の値は、このプロセスを介して配信される、検証済み個人データの別の一部分になる。
【０１２７】
次に、記載の実施形態の権限付与システムについてより詳細に考察する。
【０１２８】
データベース
権限付与システムの記載の実施形態は、個人データが１つまたは複数のソースにあるデータベース中に保持されていることを前提とする。（データベースという用語には、ディレクトリも含まれるものとする。）データベースは、実世界で起こっていることをモデル化する。データベースの変更は、実世界における変更を反映している。本実施形態は、対象者を識別するデータベース・エントリにのみ適用される。すなわち、対象者をそのデータベース内のその他の全ての対象者と区別するのに十分な情報がエントリ中にある場合にのみ適用される。データベースがディジタルでなければならない必要はなく、ハードコピー・データベースも含まれる。
【０１２９】
一般に、対象者を識別する方法は複数あると考えられる。アリス・アースリングの雇主であるＡｃｍｅ ＳＡの人事データベース中にある、以下を、アリス・アースリングのエントリから抽出したと仮定する。
名前 アリス・アースリング
生年月日 １９６３年１１月１７日
住所 サウスビュー・ロード６５
従業員番号 ６５１９３
米国税局のアリスの一意の番号（Ａｃｍｅは、この情報を源泉徴収税の支払いのために保持している） ＤＦ４５６７８１Ａ
アリスの銀行業者 ラットランド銀行
アリスの銀行口座番号（Ａｃｍｅは、この情報を各月のアリスへの支払いのために保持している） ０１０８１２０８
アリスの業務用電子メール・アドレス ａｌｉｃｅ．ｅａｒｔｈｌｉｎｇ＠ａｃｍｅ．ｃｏｍ
アリスの自宅用電子メール・アドレス Ａｌｉｃｅ＠ｅａｒｔｈｌｉｎｇ．ｎａｍｅ
アリスの業務用電話番号 ＋９９ １２ ３０００ ３２７４
アリスの携帯電話の電話番号 ＋９９ ７３ ０５７８ ２４０７
アリスの自宅用電話番号 ＋９９ １３ ２５５３ ８１０９
アリスの登録ドメイン名 ａｌｉｃｅ．ｅａｒｔｈｌｉｎｇ．ｎａｍｅ
アリスが管理している秘密鍵にマッチする公開鍵の値 ９５６ＤＦ５７Ｅ４…
アリスの正面顔写真を含むＪＰＥＧファイル ＡＤ５３８２７Ｄ５Ｃ８８Ｅ５７５ＥＡＢ６６７８…
アリスの手書き署名のディジタル化画像を含むＴＩＦＦファイル ＦＥ４３６８ＡＢ５４３Ｃ５５ＦＤＥ６５３ＦＢ６…
仮名 ７５６３８４９２８４７５
アリスの給与 ６０，５００ユーロ
Ａｃｍｅにおけるアリスの外部購買限度 １００，０００ユーロ
【０１３０】
アリス・アースリングのデータベース・エントリ中のデータには、識別、認証、ｌｏｃａｔｉｏｎおよび認可を提供する属性が含まれる。仮名が識別子として許可されることに注意されたい。
【０１３１】
アリス／Ａｃｍｅの例ではいくつかのデータ項目が含まれているので、それぞれが異なる識別子を備えた、いくつかのエントリ・ビューが可能である。したがって、各ビューは、主要識別子と表明部分を備えている。表明部分は、そのビューを特徴付ける主要識別子中の属性を除き、エントリの属性全てを含む。単一の主要識別子を構築するのに属性の組合せ（例えば、銀行と口座番号）を使用する必要がある場合もあれば、あるいは、単一の属性（例えば職員番号）で十分な場合もある。この例では、アリスの給与は、常に表明部分の一部である。彼女の業務用電子メール・アドレスは、１つのビュー、すなわちその業務用電子メール・アドレスが主要識別子であるビューを除くすべてのビューにおいて、表明部分の一部になる。
【０１３２】
公開鍵の値が主要識別子である可能性も考慮に入れてあることに注意されたい−実質的に、同じ鍵ペアが２回生成されることはあり得ないと想定される。
【０１３３】
この説明は、一般的なケースについての説明である。本システムはまた、主要識別子になり得る属性または１組の属性がたった１つしかないために、可能なビューが１つしかないエントリという、より単純なケースについても考慮に入れてある。
【０１３４】
上述の形態のデータベースは、世界中で、政府の部局および機関、大企業、およびほとんどのその他の種類の組織において、すでに広く存在している。
【０１３５】
証明書
個人に関するデータを記憶する１つの方法として、証明書という形態がある。記載の実施形態では、個人に関しては、証明書を、データベース中のあるエントリのディジタル署名付き抽出部分とみることができる。これを、さらに、個人ではないエンティティに関する証明書を含むように、拡張することができる。記載のシステムでは、証明書は、各データベースを運用する組織の外からエントリが見えるようになるメカニズムである。
【０１３６】
記載の実施形態における証明書は、単一のエントリの単一のビューからの情報を含んでいなければならない。後述するように、それはまたその他の情報も含むことができる。これが証明書とデータベース・エントリの決定的な違いである。データベースのエントリは、すべてのビューが等しく可能な状態で、データベースに存在する。証明書では、識別子は、１つのビューに付けられる。
【０１３７】
証明書は、選択したビューに関する主要識別子全体を含んでいなければならない。証明書中の識別子は「識別名」と呼ばれる。証明書はまた、選択したビューの表明部分からの情報、すなわち表明部分全体かまたはそのうちのいずれかの認識できる部分集合のいずれかをも含むことができる。識別名だけを含む証明書には、ほとんど価値がない。
【０１３８】
特に、表明部分の情報は、認証符号（公開鍵の値を含む）、ロケータ、認可者および非主要の識別子を含むことができる。
【０１３９】
１つまたは複数の非主要識別子が含まれる場合、それらは冗長検査メカニズムとして役立つ場合がある。例えば、銀行口座番号を主要識別子として持つ証明書では、銀行は、その他の識別子（例えば、普通の名前）の１つまたは複数を使って、誤認を防ぐためのダブルチェックを行うことができる。
【０１４０】
従来技術で知られている従来の証明書は、対象者または記載のエンティティを識別するが、特定の利用側当事者またはエンティティを識別することはない。利用側エンティティとは、証明書の利用者、すなわち、証明書の内容の正確さを利用する誰かである。
【０１４１】
次に、このモデルでは、以下のような分類がなされる。
・ディジタル署名を作成するために使用される秘密鍵にマッチする公開鍵を認証符号として含む証明書は、確認証明書として分類される。
・確認証明書は、公けに発行される場合とされない場合があり、また、認可を受ける場合と受けない場合がある。欧州連合電子署名指令では各クラスを異なって扱うため、この違いは重要である。
・このモデルは、３つのさらなるクラスのうちの１つに証明書を割り当てる。３つのクラスとは、従来、権限付与、およびカスタムである。これらのクラスについてのさらなる情報は後で記載するが、要約すると以下の通りである。
・従来の証明書は、対象者を識別するが、特定の利用側当事者を識別することはない。利用側当事者とは、証明書の利用者、すなわち証明書の内容の正確さを利用する誰かである。このクラスの証明書は、従来技術で広く見られる。
・カスタム証明書は、利用側当事者と対象者の両方を識別し、証明書に署名するエンティティは証明書の対象者ではない。
・権限付与証明書は、利用側当事者と対象者の両方を識別し、対象者が署名する。
【０１４２】
権限付与証明書およびカスタム証明書は、瞬間的または長期的のいずれかである。（従来の証明書は常に長期的である。）瞬間的証明書の有効期間は、その期限内に同じ秘密鍵で複数の署名が作成されるのを実際的に防ぐのに十分な短さである。長期的証明書の有効期間内に、同じ秘密鍵による署名を多数、作成することが可能である。
【０１４３】
このモデルでは、全ての権限付与証明書およびカスタム確認証明書は、公けに発行されるものとして分類される。このモデルでは、カスタム証明書は、認定される場合されない場合があり得るが、一方、権限付与証明書を認定することはできない。
【０１４４】
登録局
従来の登録局（ＲＡ）の概念は、供給すべきデータのソースという形態で、記載のシステム中に存続している。本実施形態では、所与の対象者のための登録局を以下のように定義する。
・データベースの管理者であって、
・その対象者に関するＲＡになることを対象者に対して同意した者であって、
・所有するその対象者についてのデータベース・エントリ中に、その対象者の公開確認鍵の値を含める者。
【０１４５】
特定の対象者に関して、ＲＡは、直接ＲＡ（ＤＲＡ）または間接ＲＡ（ＩＲＡ）のいずれかである。その違いは以下の通りである。
・直接ＲＡは、対象者の公開鍵の値を主要データとして保持し、それを実世界のできごとに応じて更新する。これを行うために、ＤＲＡは、対応する秘密鍵の損失または漏洩の際の通知をカバーする、ある種の契約を対象者と交わしていることが多い。
・間接ＲＡは、公開鍵の値を含む長期的カスタム証明書をキャッシュしておき、そのようなチェックすべき証明書の継続的な検証を可能にする現行の証明書廃棄リスト（ＣＲＬ）にアクセスすることができる。（ＣＲＬについては後述する。）
【０１４６】
同じ組織が、ある対象者のＤＲＡであって、別の対象者のＩＲＡである場合もある。
【０１４７】
どの対象者も、少なくとも１つのＤＲＡを持つことなくＩＲＡを持つことはできない。ただし、対象者が、ＤＲＡを持ちＩＲＡを持たないことは可能である。これは、インフラストラクチャのどこかに、公開鍵の値をブートストラップするところがなくてはならないためである。そもそも、もし対象者が最初の位置にＤＲＡを持っていなければ、いずれかのＩＲＡがキャッシュしておくべき長期的カスタム証明書も存在しない。対象者が最後のＤＲＡとの関係を止める場合、関連する長期的カスタム証明書が全て、ＩＲＡがチェックしているＣＲＬ中に直ちに現れる可能性が高い。したがって、対象者は、ＩＲＡとの関係も直ちに止める。
【０１４８】
記載のシステムには、対象者が複数の鍵ペアを持っているために、あるいは１つまたは複数の鍵ペアを１つまたは複数のＤＲＡが追跡するために対象者が複数のＤＲＡを持つことを妨げるものは何もない。
【０１４９】
ＤＲＡが対象者の公開鍵の値を確かめるためのメカニズムは、本明細書に記載の説明の範囲外であり、本発明の一部ではない。しかし、従来技術には、この関係をどのようにして実装できるかに関する例が多数ある。実際には、ＲＡ−ＤＲＡまたはＩＲＡ−は、公開鍵だけでなく、それが各対象者について「本当に」保持している全てのデータ項目の値を確定する何らかの方法を持っていなければならない。この場合も、この分野の多くの既存の従来技術がある。（「本当に」とは、「誰か別の人が署名した証明書中においてではなく」という意味である。）
【０１５０】
この指定していないメカニズムが正しく動作していることは、モデル全体にとって明らかである。モデル中のどこかで起きることは全て、この部分が正しく動作していることに依存している。
【０１５１】
図５は、記載のシステムのＲＡ５００を示す。ＲＡはデータベース５０４を保持している。５０６、５０７、５０８、５０９は、それぞれこのデータベースの単一ビューである。各ビュー５０６、５０７、５０８、５０９は、主要識別子である、そのビューの識別名５１０、５１２、５１３、５１４を備えている。ビュー５０６、５０７、５０８、５０９はまた、公開鍵の値、ロケータ、認可者などを含む、データベースの選択ビューの表明部分からの属性も含むことができる。記載のシステムでは、ＲＡは以下の機能を有する。
【０１５２】
ＲＡ（いずれかのクラスの）は、そのデータベース管理者としての役割において、それが各対象者について保持しているデータを、ＲＡであることとは別に、そのデータを保持している理由が何であれ、維持し、処理することができる。したがって、例えば、アリス・アースリングの雇主であるＡｃｍｅの人事部は、従業員データベースに対し、月々の支払い給与総額の処理を継続して行う。
【０１５３】
ＲＡ（いずれかのクラスの）は、対象者がディジタルに署名したエントリの更新を受け取って処理することができる。ＲＡは、対象者の公開鍵を知っているので（ＤＲＡとしてそれを追跡しているため、あるいは、ＩＲＡとして、キャッシュに保存してある証明書をＣＲＬと照合して検証できるため）、その署名を常にチェックすることができる。
【０１５４】
重要なことは、ＲＡがメッセージを認証局（ＣＡ）に送ることができ、その結果、ＣＡがディジタル証明書に署名でき、またはそれを廃棄できることである。
【０１５５】
記載のシステムは、多くの組織−おそらく公共部門内のほとんどの組織−がＲＡになるであろうことを予測する。このような場合、ＲＡであることが、何か他のものであることに付随して起こり得る。ビジネス上の全任務がＲＡとしての任務であるような組織が明らかに可能であるが、このシステムでは、このような組織に対して何も特定の要件はない。
【０１５６】
署名デバイス
このモデルは、署名デバイスと呼ばれる有限状態マシンの操作へのディジタル署名を抽出する。この署名デバイスは、一般化時間の通常の標準概念に対応し、１秒の粒度で増分する、現地時間のソースにアクセスする。このマシンの状態は以下によって定義される。
・その時々に変化し得る鍵ペアの値
・各署名操作の前または後に増加する整数である、権限付与証明書シリアル番号の値
・（任意で）権限付与証明書に含めるべきデータについてのインテリジェント推測を可能にする一組の値。
【０１５７】
このマシンおよびその状態をどのように実装するかは、このモデル中には定義されておらず、それは本発明の一部でもない。しかし、スマート・カードや無線デバイスについて考えてみることが役立つことがあろう。アリスが署名動作を実行する割合をわかりづらくするために、単位元以外の分量でシリアル番号を増分するのも、プライバシー上の副次的利点がある。
【０１５８】
署名操作は、以下のように進む。
・デバイスは現地時間の値をとる。
・デバイスは、権限付与証明書（ＥＣ）のシリアル番号を増分する。
・順番に署名すべきゼロまたは複数のオブジェクトのそれぞれについて、デバイスは、各オブジェクトをアリスに対して表示し、署名すべきかどうかの決定を彼女から受け取る。
・アリスが署名したいと思うオブジェクトがあればそのそれぞれについて、デバイスは、データ構造上の署名ブロックを計算する。署名ブロックは以下を含む。
・署名すべきオブジェクト
・シリアル番号およびアリスの公開鍵の値のハッシュによる、作成しようとしているＥＣの参照
・場合によってはその他の情報
・デバイスは、次いで、ＥＣのシリアル番号とともに、ＥＣに含める値のインテリジェント推測を示す、ＥＣ確認画面を表示する。これらのインテリジェント推測は、呼び出すことにより外部からデバイスに提供された情報から、また、内部に保持されている任意選択の値から計算される。
・デバイスは、アリスが提供した（またはインテリジェント推測から受け取った）情報から、また、署名付きオブジェクトの署名ブロックから、ＥＣを構築する。ＥＣの有効期間は、操作の開始（最初の項目）の時間に開始するように設定され、また、操作の終了時に記録される一般化時間の１秒後に終了するか、またはアリスの承認により終了するか、どちらか期間が長くなる方で終了する。デバイスは、アリスの署名をＥＣに付ける。
【０１５９】
権限付与証明書
従来技術で説明した証明書の代わりとして、記載のシステムは、ボブに権限付与証明書を送るための、アリスのソフトウェアを提供する。この代替メカニズムは、アリスが、従来の証明書を（実際には、いかなるディジタル証明書も全く）「発行」される必要がないことを意味する、いくつかの独自の利点を持っている。
【０１６０】
アリスには証明書が「発行」されないが、彼女のソフトウェアは、依然として、彼女が署名した全てのオブジェクトと共に証明書を送信する。しかし、彼女のソフトウェアが彼女のために構築し、また、彼女が、署名すべきオブジェクトに署名した後に直ちに自分自身で署名するのも常に証明書である。場合によっては、トランザクション全体を、自己署名証明書のみに完全にカプセル化することができ、それによって、関連するオブジェクトの署名が不要になる。記載のシステムでは、このような特別な自己署名証明書を「権限付与証明書」と呼ぶ。
【０１６１】
権限付与証明書は、ユーザが、それによって、通常の個人データの１つとみなすことができる自分の公開鍵を含めて、自分の個人データにアクセスする権限を他の人に付与するメカニズムとしてみることができる。
【０１６２】
権限付与証明書の生成は、以下のステップを含む。まず、署名すべきオブジェクトがあれば、その署名すべきデータ中に含まれている、作成しようとしている権限付与証明書への前方参照で、そのオブジェクトに署名がなされる。次いで、権限付与証明書が作成され、署名されたオブジェクト（もしあれば）の署名ブロックへの逆方向参照で、その権限証明書に署名がなされる。
【０１６３】
権限付与証明書には以下の情報が含まれる。
・アリスが「発行者」として表明する識別名
・対象者と同じ識別名
・利用側当事者の識別名
・アリスの識別名を公開鍵の値（または、１つまたは複数のそのような値）に解決することができるＲＡの識別名
・署名操作の開始時間の１秒前に開始し、その時間の２秒後以降に終了する有効期間
・（任意で）１組の属性定義
・各属性定義について、表明されている値、または対象者の属性値を保持するＲＡの識別名のいずれか
・（任意で）対象者の公開鍵の値である特定の属性を保持する、ＲＡの識別名
・（もしあれば）以前署名したオブジェクト（または複数オブジェクト）上の署名ブロック（または複数ブロック）
・（もしあれば）利用側当事者が提供したランダム・ナンスまたはその他の情報。ナンスは、一般に、生成されるまでは値が予測不可能な大きな数である。
・（任意で）対象者の公開鍵または対象者の公開鍵の１つ、あるいは、そのような鍵の参照
・（任意で）ポリシー情報。アリスは、権限付与証明書中に表明または参照されている個人情報が使用されてもよいことに同意する目的ステートメント、または、それが使用されてはならないことを述べる目的ステートメントを含めることができる。彼女はまた、後でＥＣを使ってカスタム証明書を生成することへの承諾を示すこともできる。
・上記全体に対する対象者の署名。この署名を省略できる状況（基本的に、権限付与証明書の署名が確認されることがない状況）もあるが、このような状況についてはこれ以上説明しない。
【０１６４】
任意で、本モデルは、提供すべきデータを保持している１つまたは複数のＲＡが、権限付与証明書において、識別名によってではなく間接的に参照される可能性も考慮に入れる。ＥＣは、各属性についてどのＲＡを使用すべきかを知っている、プロキシ・サービスを識別することができる。原則として繰り返されるこのような間接性（あるプロキシが別のプロキシを指し、それがまた別のプロキシをというように）の量については明らかに限度はない。
【０１６５】
アリスから権限付与証明書およびいずれかの署名付きオブジェクト（または複数オブジェクト）を受け取ると、ボブには４つの選択肢がある。
【０１６６】
１．ボブは、権限付与証明書の署名をわざわざチェックすることもなく、アリスが表明していることをただ単純に信じるかもしれない。
【０１６７】
最も単純な場合で、記載のシステムは、未認証の個人データを送信する方法として動作する。ボブが政府機関であり、アリスが情報案内書をメールしてもらうことを望んでいる場合であれば、もし彼女が自分の名前や住所を偽ったとしてももさほど問題ではない。権限付与証明書のこの単純な使用法は、ブラウザのクッキーと同じ種類の恩恵をもたらすことができる。
【０１６８】
より一般的には、添付の署名付きオブジェクトがある場合に、ボブは、もしアリスの公開鍵を含んでいる長期的カスタム証明書をキャッシュしているのであれば、わざわざ権限付与証明書上の署名をチェックしないことがある。彼は、単に、権限付与証明書からアリスの識別名を引き出し、関連する長期カスタム証明書を見つけ、そしてそこから彼女の公開鍵を抽出して、その署名付きオブジェクトの署名をチェックするであろう。
【０１６９】
２．あるいは、ボブは、公開鍵の表明されている値を使って署名をチェックし、署名が正しく一致するならば、単に残りの表明されている情報（もしあれば）を信じるかもしれない。
【０１７０】
これは多少は役立つ。なぜならば、もしボブが権限付与証明書をキャッシュしているならば、それは、鍵の破棄が重要ではない用途においてセッション・メカニズムを提供することができるからである。すなわち、ボブは、アリスの公開鍵の値以外の個人データのいずれかを必ずしも確実に知ることなく、彼のウェブ・サイトへのアリスの初めての訪問を、彼女の２番目およびその後の訪問に関連付ける。ボブは、訪問ごとにナンスを供給することによって、あるいは、増加していく権限付与証明書のシリアル番号をチェックすることによって、リプレイ・アタックを防ぐことができる。アリスが、いずれかの訪問において、何か他の識別子を表明したならば（たとえ仮名でも）、その後の訪問で自分の公開鍵を表明する必要はない。しかし、このメカニズムは、アリスの署名デバイスの漏洩から、あるいはアリス自身による鍵のロールオーバーから回復することはできない。最初のケースでは、誰か他の人が「セッション」を引き継ぐことができ、２番目のケースでは、セッションが帯域内でのボブへの説明の可能性なく終了する。
【０１７１】
その制約にもかかわらず、このメカニズムには、パスワード・ベースのウェブサイト・ログオン・スキームに比べて注目に値する利点がある。
【０１７２】
３．別の可能性として、ボブが、長期的カスタム証明書上にキャッシュしておいた、または何らかの他の方法で知った（例えば、彼が彼女のＤＲＡという理由で）アリスの公開鍵の値を使って、権限付与証明書上の署名をチェックすることが考えられる。
【０１７３】
これは、廃棄に対処できる認証方法を提供する。この場合も、ボブは、ナンスまたはシリアル番号によるチェックを使って、リプレイを防護することができる。ボブはまた、彼がすでにキャッシュしている、またはその他の方法で知っているものとは異なる、権限付与証明書中に表明されている情報（もしあれば）を、さらに確認することなく、納得して信じるかもしれない。
【０１７４】
権限付与証明書のこの使用法は、対象者が、ＲＡに、自分がＲＡのデータベースに対して行わなければならない変更を知らせる方法を提供する。権限付与証明書のアーカイブによって、対象者の署名付きの監査記録が提供される。
【０１７５】
４．最も重要なのは、ボブが、権限付与インフラストラクチャを使って、正しく署名された権限付与証明書をカスタム証明書に（または、実際には、複数のカスタム証明書に）変換できることである。これは記載のシステムのきわめて重要な部分であり、次にこれについて説明する。この方法をとるのであれば、ボブは、アリスがオブジェクトの署名ブロック（もしあれば）を権限付与証明書に正しくコピーしたことを確認するのが賢明であろう。
【０１７６】
カスタム証明書
アリスが１つまたは複数のＲＡと契約するように、ボブも、もし権限付与証明書をカスタム証明書に変換したいのであれば、１つまたは複数のＣＡと契約する必要がある。このプロセスは単純である。権限付与証明書の期限前であればいつでも（または、瞬間的権限付与証明書の期限後できるだけ早く）、ボブは、好きなだけ何度でも、自分が受け取った権限付与証明書をＣＡに送り、ＣＡは、ボブの要求に添ってカスタマイズした、同等のカスタム証明書に署名してそれを返す。ボブがどのＣＡを選択するか、または何回、またはいくつの異なるＣＡに同じ権限付与証明書を送るかについて、このシステムでは何の制約もない（ただし、回数については、瞬間的権限付与証明書の場合には素早く行うときに限る）。
【０１７７】
ＣＡが行っているのは、アリスの個人データのボブと共用すべき特定の部分についてアリスが権限付与証明書を作成したときに彼女から与えられた指示を実行することである。彼女の公開鍵は、このようにして共用することができる、１つの個人データである。
【０１７８】
以下に、この方法のステップを説明する。何かうまくいかなかった場合には、プロセスは終了し、ボブの要求は理由コードで拒絶される。ＣＡは、作成されているカスタム証明書のシリアル番号を生成し、権限付与証明書のシリアル番号、権限付与証明書のハッシュ、オブジェクトの署名ブロック（もしあれば）、およびナンス（もしあれば）を、属性としてカスタム証明書中にコピーする。ＣＡは、タイムスタンプとともに、自分の識別名を発行者フィールドにコピーする。
【０１７９】
長期的権限付与証明書の場合、ＣＡは、権限付与証明書の有効期間が、カスタム証明書を組み立てて署名する時間と考えられる時間よりも前に終了しないことをチェックする。瞬間的権限付与証明書の場合、ＣＡは、権限付与証明書が署名されてから妥当な時間しか過ぎていないことをチェックする。「妥当な」とは、アリスの個人データが、彼女が権限付与証明書に署名してから変更されている可能性はまずないことを意味する。
【０１８０】
ＣＡは、長期的権限付与証明書と瞬間的権限付与証明書（妥当な時間が過ぎていないもの）の両方について、カスタム証明書の有効期間開始時間を権限付与証明書の開始時間と同じに設定するであろう。そうでない場合（これは、明らかに、長期的証明書の場合のみに当てはまる）、有効期間開始時間は、ＣＡのクロックによる時間に設定される。オプションとして、蓄積交換トランザクションをサポートするために、開始時間をそれよりもずっと早い時間に設定することが役立つ場合がある。
【０１８１】
カスタム証明書の有効期間終了時間は、権限付与証明書の有効期間終了時間、またはボブが指定する、それよりも早い時間に設定される。
【０１８２】
ＣＡは、権限付与証明書中にボブの名前が利用側当事者として記載されていることをチェックし、カスタム証明書中に、利用側当事者としてボブの名前を記載する。定義済みの規則においては、ボブの名前の表現に特定の変更を加えることが許可されている。（この場合、銀行が小切手に記載されている受取人の名前を口座名義人名と照合する際の自由度と類似する。）
【０１８３】
ＣＡは、権限付与証明書の対象者名と「発行者」名が同一であることをチェックして、その値をカスタム証明書の対象者フィールドにコピーする。この場合も、定義済みの規則においては、アリスの名前に変更を加えることが許可されている。
【０１８４】
ＣＡは、権限付与証明書においてＲＡへの照会ではなく表明されている属性については、いずれも無視する（すなわち、存在していないかのように扱う）。権限付与証明書中の表明されている属性値は、アリスとボブの間の、ＣＡが関与しない通信の一部においては役立つ。表明されている公開鍵の値は、このインフラストラクチャ内においてはある使い道があり、これについては以下に説明する。
【０１８５】
ＣＡは、次いで、権限付与証明書を、アリスの識別名を彼女の公開鍵に解決できるＲＡとして権限付与証明書に識別されているＲＡに提示する。これが長期的権限付与証明書の場合、ＲＡは、まず、アリスがそれを廃棄しているかどうかを調べる。ＲＡがどのようにそれを行うかは、後で説明する。（カスタム証明書が瞬間的な状態か長期的な状態かは関係ない。）いずれの場合も、ＲＡは、権限付与証明書の有効期間をチェックする。
【０１８６】
ＲＡは、自分のデータベースを調べて、公開鍵の値を抽出し、権限付与証明書をチェックする。アリスの複数の公開鍵がわかっている場合は、彼女が権限付与証明書中に含めたヒント（例えば、公開鍵の値、または公開鍵のハッシュの値を表明することによって）に導かれて、権限付与証明書上の署名が正しく一致するまで各公開鍵を順番に試してみる。
【０１８７】
長期的カスタム証明書の場合のみ、ＲＡは、識別名を構成している属性のそれぞれに対して、次の形態（「ＤＮフラグ」、ＣＡの識別名、カスタム証明書のシリアル番号、満了日）のラベルを追加する。瞬間的カスタム証明書の場合は、ラベルは何も追加されない。（権限付与証明書が瞬間的な状態か長期的な状態かはこの決定には関係ない。）
【０１８８】
ＲＡは権限付与証明書を調べて、自分の名前が、公開鍵を含めて、表明されている属性のいずれかのＲＡとして記載されていることを確認する。ＲＡは、そのデータベースから、アリスが権限付与したどの値も引き出す。長期的カスタム証明書の場合にのみ、ＲＡは、各属性に対して、次の形態の（「ａｔｔフラグ」、ＣＡの識別名、カスタム証明書のシリアル番号、満了日）ラベルを追加する。瞬間的カスタム証明書の場合は、ラベルは何も追加されない。（権限付与証明書が瞬間的な状態か長期的な状態かはこの決定には関係ない。）
【０１８９】
長期的カスタム証明書の場合、ＲＡは、権限付与証明書をキャッシュし、権限付与証明書とカスタム証明書のシリアル番号、満了日、および「発行者」のマッピングを記録する。
【０１９０】
ＲＡは、次の情報をＣＡに送り返す。
・アリスの公開鍵の値
・ＣＡが責任を有する表明されている属性があればその値
【０１９１】
公開鍵の値が表明されている属性の間に含まれており、アリスが複数の公開鍵を持っている場合、ＲＡは、アリスが表明した公開鍵の値またはハッシュ値に基づいて１つを選択する。これは、上述の返される公開鍵の値と同じ値の場合もあるし、そうでない場合もある。なぜならば、アリスは、１つの秘密鍵を使った署名で、彼女の別の秘密鍵に対応する公開鍵を含む、カスタム証明書の作成を承諾するかもしれないからである。
【０１９２】
こうして、ＣＡは、権限付与証明書の署名をチェックすることができるようになり、それを行う。さらに情報を求めるべきＲＡがある場合には、ＣＡは、それらのＲＡに、第１のＲＡが返してきた第１の公開鍵の値とともに権限付与証明書を同時に送出する。これらのＲＡは、この場合もその満了日および廃棄の状態を含めて、権限付与証明書をチェックし、権限付与証明書中の識別名または公開鍵の値を使って対象者を識別し、その値を返す。前の場合と同様に、長期的カスタム証明書の場合は、「ａｔｔフラグ」属性のラベルを付け、権限付与証明書をキャッシュし、権限付与証明書をカスタム証明書にマップする。
【０１９３】
公開鍵カスタム証明書中に含める公開鍵は、最初にアリスの識別名を彼女の公開鍵に解決したＲＡ以外のＲＡが提供してもよいことに注意されたい。
【０１９４】
全ての属性情報が返されると、ＣＡは、次に、ボブが要求した証明書ポリシーを示すように、証明書に印を付ける。特に、ボブが認定証明書を要求し、ＣＡがそれが可能であると納得した場合には、ＣＡは、その証明書に、ボブの要求金額とＣＡの提案金額のうち低い方を債務限度額として設け、認定済みとしての印を付ける。アリスがＥＣ中に設定したポリシーも、カスタムの認定証明書を生成できるかどうかに制約を与える。
【０１９５】
ボブは、自分が望むポリシーおよび債務を得るために、さらに２つ以上のＣＡに対して別々に、または同じＣＡに対して複数回、権限付与証明書を提出することにより、１つのポリシー中の弱点を別のポリシーの強みとプレイ・オフして、１つのカスタム証明書を使って別のカスタム証明書を強化し、またはある認定証明書の債務を２つ以上のＣＡに広げることができる。
【０１９６】
ＣＡがカスタム証明書中に定義するポリシーに対する、１つの重要な制約がある。アリスが元の権限付与証明書中に定義した個人データのポリシーの制約はどれも、カスタム証明書中に持ち越される。
【０１９７】
最後に、ＣＡは、アリスの識別名を彼女の公開鍵に解決したＲＡに対して、カスタム証明書のボブへの移転を知らせる。ＣＡは、権限付与証明書と長期的カスタム証明書のシリアル番号を提供し、その長期的カスタム証明書が認定を受けたか否かを伝える（それによって、アリスは、自分の署名がＥＵ電子署名指令の条項５．１に定義されている認定状態にアップグレードしたかどうかを知る）。ＲＡは、特にポリシーに関するその他のことについては何も知らされず、また、債務の上限の金額についても知らされない。（ボブが、彼女との自分の関係に対していくらの金額を付けるかは、アリスには関係のないことである。）
【０１９８】
ボブには、明らかに、可能な表明属性のうちの部分集合のみが含まれるように依頼するオプションもある。
【０１９９】
図６は、ＣＡによって実行される方法６００の流れ図を示す。方法６００は、ボブが権限付与証明書（ＥＣ）をＣＡに送る６０１ことで開始する。ステップ６０２で、ＣＡは、新しいカスタム証明書（ＣＣ）のシリアル番号を生成し、権限付与証明書のデータが一貫していることをチェックし、そのデータをカスタム証明書中にコピーし、自分の名前をカスタム証明書の発行者として記入する。いずれかのデータが矛盾している場合６０３、権限付与証明書は拒絶されてボブに返される６０４。
【０２００】
ＣＡは、最初に瞬間的か長期的かを確認することによって６０５、権限付与証明書の有効性をチェックする。権限付与証明書が瞬間的な場合には、それが所定の時間内であることを確認するために、それが生成されてからの時間がチェックされる６０６。権限付与証明書が長期的な場合には、有効期間がチェックされる６０７。権限付与証明書が有効期間外である場合には、その権限付与証明書は拒絶されてボブに返される６０４。
【０２０１】
ＣＡは、次いで、カスタム証明書の有効期間を設定し６０８、そのカスタム証明書をＲＡに送る６０９。ＲＡは、カスタム証明書を処理して、アリスの公開鍵をＣＡに送る６１０。ＣＡは、その公開鍵で、権限付与証明書の署名をチェックする。その権限付与証明書において参照されているデータの一部が別のＲＡで保持されている場合、ＣＡはその別のＲＡにそのデータの要求を送る。ＣＡは、カスタム証明書に署名し、それをボブに送信する６１２。ＣＡはまた、データがボブに送られたことをＲＡに知らせる。
【０２０２】
カスタム証明書廃棄リスト
システムがカスタム証明書を提供するように、カスタム証明書廃棄リストもある。カスタム証明書廃棄リストは、長期的カスタム証明書のみに適用される。なぜならば、瞬間的カスタム証明書は、生成されて１秒以内に満了し、したがってそれらの廃棄の問題が生じることはないからである。
【０２０３】
これから説明しようとしているメカニズムを通して、ＣＡは、自分が署名した長期的カスタム証明書に含まれている情報に対して変更があった場合にそれを知る。ただし、その変更が、当該長期的カスタム証明書の満了前に生じた場合に限る。また、アリスは、自分が署名したどの権限付与証明書についても、それをいつでも廃棄することができる。これは、対応する長期的カスタム証明書も廃棄されなければならないことを意味する。ボブはまた、自分の名前が利用側当事者として記載されている長期的証明書で廃棄されるものがあるかどうかをたずねることができる。
【０２０４】
ＣＡは、顧客のそれぞれについて別個のカスタム証明書廃棄リスト（ＣＲＬ）を維持しており、各顧客は、自分自身のＣＲＬを入手して見ることしかできない。ボブは、いつでも望むときに自分のＣＲＬを調べることができ、自分が望む通常のＣＲＬ更新頻度を指定することができ、また、さらに、いつでも、新しいＣＲＬを作成させることができる。ボブはまた、新しいＣＲＬの閲覧が可能になるたびに通知を受けることを求められる場合もある。ボブは、いずれかの特定の時に特定の長期的カスタム証明書が廃棄されていない状態だったことを後で証明できるように、ＣＲＬを保管しておくことができる。
【０２０５】
ボブは、証明書のシリアル番号がＣＲＬに現れた場合にはいつでも、その廃棄された証明書を保管することを望むであろう。廃棄された長期的カスタム証明書にマッチする権限付与証明書が依然として満了していない場合には、ボブは、そのマッチしている権限付与証明書を再提出して、内容が更新された新しい長期的カスタム証明書を得ることができる。それが成功するかどうかは、廃棄の理由にかかっており、ボブは、自分のＣＲＬにおいて廃棄理由コードを見ることができる。
【０２０６】
明らかに、もしアリスがその権限付与証明書を廃棄した場合には、インフラストラクチャが長期的カスタム証明書をボブに与えるはずはない。アリスは、自分の個人データに対する特定の権限付与を撤回している。アリスの識別名が削除されているならば、長期的カスタム証明書は回復可能にはならない。
【０２０７】
ある属性または公開鍵のみが変更された場合、あるいは、アリスが単に、自分の個人データがＲＡに割り当てられる方法を変更しただけの場合には、通常、権限付与証明書を再提出して、交換の長期的カスタム証明書を入手することができる。これは、権限付与証明書の残っている期間の間、有効である。
【０２０８】
ボブは、権限付与証明書の満了前であればいつでも、長期的カスタム証明書を要求することができる。ボブは、さらに、自分が要求を開始させることなく、廃棄が発生するたびにＣＡが新しい要求を自動的に処理するよう、ＣＡと契約を結ぶことができる。また、ボブは、同じ権限付与証明書を、その寿命の期間、様々なＣＡに提示することができる。
【０２０９】
したがって、アリスが自分の鍵ペアをロールオーバーすると、または結婚によって自分の名前を変えると、またはＡｃｍｅから増加された購買限度額を受け取ると、または銀行を変えると、または引っ越すと、または電話番号を変えると、または、さらには雇主を変えると、彼女の名前を対象者として記載している世界中の長期的カスタム証明書は、すばやく廃棄され、交換される。ボブのアドレス帳は常に最新である。アリスは、自分の状況の変化をＲＡのうち１つだけに告げればよく、彼女がこれらの状況について知る権限を付与した人は誰でも、何が起きたかをすばやく知ることになる。これは、満了していない長期的カスタム証明書中の全てのデータ、すなわち識別子、表明部分、認証符号、認可者、ロケータについて当てはまる。
【０２１０】
ＣＡは、長期的カスタム証明書を廃棄するたびに、アリスの識別名を彼女の公開鍵に解決したＲＡに、廃棄した長期的カスタム証明書のシリアル番号がフラグとして立てられる。
【０２１１】
以下に、この方法がどのように動作するかを詳細に説明する。
【０２１２】
・アリスは、任意で、彼女のソフトウェアの機能を通して、権限付与証明書廃棄リスト（ＥＣＲＬ）として知られる構成物を維持することができる。彼女は、いつでも、以前に生成し、まだ有効な長期的権限付与証明書のうち、廃棄したいもののシリアル番号を一覧にしたＥＣＲＬを、自分のＲＡのいずれかに提示することができる。（瞬間的権限付与証明書は、作成後すぐに満了するので、廃棄の問題が生じることはない。）
ＲＡのいずれかがＥＣＲＬを受け取ると、それは、リストから、アリスのために処理した全ての権限付与証明書のシリアル番号を抽出し、自分のマッピング・テーブルを見て、マッチするＣＡ名およびカスタム証明書のシリアル番号を見つけ、「権限付与証明書の廃棄」という理由により廃棄を指示する署名付きメッセージを各ＣＡに送る。
特定の権限付与証明書に複数のＲＡの名前が記載されている場合、アリスは、それらのうちいずれか１つにＥＣＲＬを送ることができる。これによって、彼女は、そのＲＡの粒度で、権限付与証明書の一部を廃棄することができる。さらには、属性の粒度による廃棄を可能にすることもできる。廃棄コード「権限付与証明書の部分的廃棄」に対する要件がある。
【０２１３】
・アリスが、自分の個人データのある項目をあるＲＡから別のＲＡに移動させることを決めた場合、ＲＡは、データのその項目のラベルを見て、満了していないカスタム証明書のシリアル番号を抽出し、理由コード「ＲＡの変更」とともに、署名付き廃棄メッセージを関連するＣＡに送る。
【０２１４】
・ＲＡは、自分のデータベースにおいて、アリスのデータの１つの値が変わるたびに、付けられているラベルを調べて、各カスタム証明書について署名付き廃棄メッセージを送出する。ＤＮフラグが設定されているカスタム証明書の場合、廃棄理由は「アイデンティティの削除」になる。ａｔｔフラグが設定されている場合、理由は「属性の変更」になる。
【０２１５】
・最後に、ＲＡは、システムで定義されていない方法によって対象者の死亡を知った場合には、その対象者の満了していないカスタム証明書の全てを、理由コード「対象者の死亡」で廃棄させる。
【０２１６】
廃棄理由が「権限付与証明書の部分的廃棄」、「ＲＡの変更」または「属性の変更」である場合にのみ、満了していない権限付与証明書の再提出を行う価値がある。
【０２１７】
図７は、証明書廃棄リストを追加した、図３の図を示す。権限付与証明書廃棄リスト７０１が、アリス３０２によってＲＡ３０６に送信される。ＲＡ３０６はマッピング・テーブル７０２を備えており、これには、全ての権限付与証明書およびカスタム証明書のレコードが、それらのシリアル番号、およびそのデータが供給されているＣＡのレコードに関連付けられて保持されている。ＲＡ３０６は、アリス３０２からの廃棄要求に応じて、さらに廃棄すべきカスタム証明書があればそれもＣＡに知らせることができる。ＣＡ３１０は、ボブ３０４などの利用側エンティティそれぞれについて、証明書廃棄リスト７０３を保持している。
【０２１８】
インフラストラクチャ
権限付与インフラストラクチャは、顧客に権限付与サービスを提供する１組のＲＡおよびＣＡをリンクする、安全な（すなわち、署名付きの暗号化された）メッセージング／トランザクション・システムで構成される。このようなトランザクション・システムを実装する方法は、従来技術において十分に説明されている。
【０２１９】
ＣＡおよびＲＡは、自分達の間で安全に通信を行っているように、今度は、上記の説明でアリスとボブが利用していたのと同じメカニズムを利用することができる。
【０２２０】
電子財産の所有権
以下に、所有権が保護され、自動化手段によって証明され得るように電子財産の所有権を譲渡するための方法およびシステムについて説明する。記載の技術は、前述の権限付与インフラストラクチャの存在を前提としている。
【０２２１】
自動化システムの場合、特に、それらが普及していて互いに通信を行っている場合、可能な場所ではどこでも、人が介入することなく電子財産の正当な所有権をチェックできることが不可欠である。
【０２２２】
電子財産は、電子的に表現することができる財産の形態であればどのような形態にでも使用できる、一般的な用語である。電子財産には、例にすぎないが、債権やその他の有価証券などの金融証書、土地の所有権、音楽、写真、マルチメディア作品などが含まれる。このような電子財産のコピーをつくることは、技術的には容易である。したがって、特定のインスタンスがあるエンティティによって所有され、それが別のエンティティからそのエンティティに譲渡されたものであることを自動的にチェックできるのであれば、電子財産を電子的に取り引きし、配信することが可能である。
【０２２３】
電子財産には２つのタイプがある。
【０２２４】
タイプＩ 電子財産を見る、または再生する機能は問題ではない。例えば、ある債権または土地の所有権が誰でも見られるとしても、何も商業上の問題はない。問題となるのは、その債権がアリスによってボブに譲渡されたことの確認についてである。
【０２２５】
タイプＩＩ 再生する機能が問題となる。正当な所有者の認可のもとに行われるのでなければ、写真は表示可能であってはならないし、音楽は再生可能であってはならない。
【０２２６】
記載の電子財産の所有権を譲渡する方法およびシステムは、両方のタイプに適用されるが、ただし異なった方法で適用される。
【０２２７】
仮に、アリスがボブに何らかの電子財産の所有権を譲渡するとしよう。この文脈における所有権とは、その財産の使用権の全部または部分的な所有に対する無疵の権利、リース、賃貸、使用許可、および、その他の形態を含むように使用されている。アリスは、この権限付与インフラストラクチャの機能を使用する。アリスは、電子署名で電子財産に署名し、ボブのための権限付与証明書（ＥＣ）を作成する。この署名付き電子財産およびＥＣは、リンクで結合されている。
【０２２８】
リンクとしては以下が可能である。
【０２２９】
ＥＣのシリアル番号から生成されたビット・ストリング、およびその特定の譲渡のために生成され、署名付き電子財産およびＥＣの両方に記憶されている乱数。（２人の異なるボブへの２つの証明書のシリアル番号が同じであることもあり得るため、ＥＣのシリアル番号そのままでは十分ではない。）
【０２３０】
電子財産中の透かしに関連付けられたビット・ストリング。電子財産が、鍵によって変わり得る透かし技術を使っていると仮定する。この場合、この鍵をリンクとして使用し、ＥＣ中に記憶する。
【０２３１】
図８を参照すると、リンクの第１の形態を示してある。電子財産８０１は、ＥＣのシリアル番号８０３と乱数８０４という形態の、リンク８０２を含む。シリアル番号８０３と乱数８０４を様々な方法で結合して、例えば、一方向性関数などを使ったリンクを生成することができる。電子財産８０１およびリンク８０２は、アリスが公開／秘密鍵ペアの自分の秘密鍵を使って生成した署名ブロック８０５で、ディジタルに署名される。
【０２３２】
このようなディジタル署名は、リンク８０２を含めて、電子財産８０１をアリスの秘密鍵を使って暗号化することによって、生成される。前述のように、実際には、アリスは、リンク８０２を含めて電子財産８０１をダイジェストし、そのダイジェストを自分の秘密鍵で暗号化することができる。
【０２３３】
アリスは、関連ＥＣ８０６をボブのために作成し、これによってボブはアリスの公開鍵を入手し、それによって電子財産８０１のディジタル署名を確認することができる。ＥＣ８０６は、前述の通常のＥＣの要件に加えて、電子財産８０１中のリンク８０２に対応するリンク８０７を含む。リンク８０７は、ＥＣ８０６のシリアル番号８０３と乱数８０４から生成される。
【０２３４】
図９は、リンクの第２の形態を示す。電子財産８０１は、電子財産８０１中に含まれる透かし８０８の形態の、リンク８０２を含む。透かし８０８は、透かし鍵８０９を備えている。
【０２３５】
従来の透かしは、文書の紙の中にほとんど見えない印を埋め込むことによって文書を認証するために、長く使用されてきた。同様に、電子透かしは、電子データ内に隠しデータ・パターンを埋め込むことによって、電子文書、特に画像を認証することができる。
【０２３６】
電子財産８０１は、この場合は透かし８０８の形態のリンク８０２を含み、アリスが自分の秘密鍵を使って生成した署名ブロック８０５で、ディジタルに署名される。
【０２３７】
図８と同様の方法で、アリスはボブのために関連ＥＣ８０６を作成し、これによってボブはアリスの公開鍵を入手し、それによって電子財産８０１のディジタル署名を確認することができる。ＥＣ８０６は、通常のＥＣの要件に加えて、電子財産８０１中のリンク８０２に対応するリンク８０７を含み、この場合、リンク８０７は透かし鍵８０９である。
【０２３８】
ディジタル署名および関連ＥＣの生成については、上記の「署名デバイス」および「権限付与証明書」の節で詳説してある。
【０２３９】
本実施形態では、ＥＣ８０６は以下を含む。
・アリスが表明している名前。これは、仮名を含み、どのような名前でもかまわない。
・利用側当事者の名前（ボブ）
・１つまたは複数の属性識別子、およびそれらの属性の値を保持するＲＡの名前
・アリスによる電子財産の署名の有効期間
・リンク手段
・権限付与証明書の対象者の名前は、任意で含めることができる。これは、アリスが特定の立場の役割を果たしている場合には、彼女の名前になり得る。
・所有権の有効期間も含めることができる。これは、所有権の有限期間使用、または無期限の永久譲渡であり得る。その場合期間は無制限である。
・上記全体に対するアリスの署名
【０２４０】
ＥＣ８０６は、ＥＣ８０６中に定義されている属性の値を得る権限をボブに付与する。この属性には、アリスの公開鍵の値、および電子財産の所有者として記録されているアリスの名前が含まれる。アリスは、追加の属性に対する権限を付与することもできる。属性は、名前または識別子、および属性値を持つことを理解されたい。ＥＣ８０６は属性識別子を含み、その属性の値は、ＲＡソースによって利用側当事者に提供される。
【０２４１】
ＥＣ８０６は、電子財産８０１の譲受人の名前、ボブを含み、また、譲渡人の名前、アリスを含む場合もある。自動化システムは、権限付与インフラストラクチャの機能を使って、その譲渡が真実であり偽造されたものではないことをチェックし、必要とされるアリスおよびボブの属性を何でも（アリスがそれらに対して権限を付与している限り）確定することができる。ボブは、これを、カスタム証明書を得ることによって行う。
【０２４２】
ボブは、ＥＣ８０６を受け取ると、ＥＣ８０６に基づいたカスタム証明書を得る。カスタム証明書については、上記の「カスタム証明書」の節で説明してある。カスタム証明書は、ボブがその証明書を得たＣＡによって債務の上限が提供されるならば、認定される。認定証明書は、ＥＵ電子署名指令（指令１９９９／９３／ＥＣ）において定義されている。本実施形態では、カスタム証明書は以下を含む場合がある。
・署名時のアリスの公開鍵を含む、ＥＣにおいて認可されているアリスの１つまたは複数の属性値
・ＣＡの名前
・ＥＣからとった、利用側当事者の名前（ボブ）
・アリスの署名の期間に対応する、証明書の有効期間
・ＥＣから得た、電子財産の所有権の有効期間
・もしあれば、認定の値
・上記の全てに対するＣＡの署名
・リンク手段も、ＥＣからコピーしてカスタム証明書に含めることができる。
【０２４３】
ボブは、認定カスタム証明書を電子財産の所有権の証明書として記憶する。上記のステップは全て、人の介入なしに自動的に行われる。
【０２４４】
図１０は、権限付与証明書８０６およびカスタム証明書８１０の概略図である。ＥＣ８０６は、カスタム証明書８１０に送られる何項目かの情報を含む。これらの情報項目には、利用側当事者の名前（この場合ボブ）８１１、リンク８０７、ＥＣ８０６のシリアル番号８１２、およびＥＣ８０６上のアリスによる署名の有効期間８１５（アリスの署名時の正しい公開鍵が提供されることを確実にするために）が含まれる。ＥＣ８０６は、ＥＣ８０６中で識別されている属性８１６の値を、カスタム証明書８１０でもって得る権限を、ボブに付与する。カスタム証明書８１０中に与えられた属性の値は、アリスの保証された名前８１７（現在、その電子財産が所属している者の名前）およびアリスの公開鍵８１８である。ＥＣ８０６は、アリスが自分の秘密鍵を使って署名した８１３ものであり、カスタム証明書８１０には、ＣＡ８１４による署名がなされている。
【０２４５】
図１１は、電子財産の自動移転方法の第１の実施形態の流れ図を示す。この方法は、アリスまたはボブがソフトウェアを起動することによって実行される。
【０２４６】
図１１を参照すると、ステップ９０１でリンクが生成され、そのリンクの一部が移転すべき電子財産中に記憶される。このリンクは、作成しようとしている権限付与証明書を参照して生成され、例えば、このリンクは、その権限付与証明書のシリアル番号を含むことができる。次のステップ９０２で、アリスは、自分の秘密鍵を使って電子財産に署名する。ステップ９０３で、アリスは、利用側エンティティとしてボブの名前が記載され、リンクを含む権限付与証明書を生成する。権限付与証明書はまた、属性識別子、すなわち、ボブが得ることを認可されている属性値の属性識別子も含む。この属性値にはアリスの公開鍵が含まれている。次いで、アリスは、その電子財産および権限付与証明書をボブに送る９０４。
【０２４７】
ボブは、電子財産および権限付与証明書を受け取り、その権限付与証明書をＣＡに送ってカスタム証明書を得る９０５。ボブは、カスタム証明書を電子財産の所有権の証明書として記憶する９０６。カスタム証明書は、アリスが実際にその電子財産に署名したことをボブが確認できるようにする、アリスの公開鍵の詳細を含む。カスタム証明書はまた、権限付与証明書からとったリンクの詳細も含む。このリンクは、電子財産を、それが移転された電子財産であることを確証する、認定カスタム証明書に結合する。
【０２４８】
タイプＩの電子財産の場合は、この移転方法の第１の実施形態で十分である。この技術は、例えば、金融証書、土地の所有権などの移転に関連する事務処理（バック・オフィス部門の職務）を完全に自動化するために使用できる。また、デバイスの現在のユーザに正しく割り当てられていないソフトウェアの実行（または写真の表示あるいは音楽の演奏）を拒絶するように、デバイスをプログラムすることができる。
【０２４９】
タイプＩＩの電子財産の場合は、所有権を無視して素材を再生するようにデバイスをプログラムすることが可能になるため（そのデバイスが完全にユーザの管理下にある場合）、本移転方法の第１の実施形態では完全に十分ではない。
【０２５０】
タイプＩＩの電子財産のために、正当な所有者から認可を受けたエンティティのみが電子財産を再生することができる電子財産を移転する方法の第２の実施形態を説明する。
【０２５１】
この実施形態では、ボブはアリスに権限付与証明書の要求を送る。この要求自体は、ボブの公開鍵に対する権限付与証明書であってよく、あるいは、ボブのアイデンティティをアリスが確認する必要がない場合には、単にボブの公開鍵を表明するものであってよい。ボブが権限付与証明書を使用している場合、アリスはその要求を使って、権限付与インフラストラクチャ中のＣＡからボブの公開鍵を確定することができる。
【０２５２】
次いで、アリスは、ボブの公開鍵を使って、効率的なメカニズムを用いて電子財産を暗号化する。例えば、アリスは、ランダム対称セッション鍵を選択し、対称暗号を使用して、電子財産を暗号化することができる。ボブの公開鍵は、セッション鍵を暗号化するためにのみ使用される。
【０２５３】
第１の実施形態の場合のように、電子財産中にリンクが提供され、また、電子財産には、アリスが自分の秘密鍵を使って署名する。
【０２５４】
あるいは、アリスは、ボブの公開鍵で暗号化される前に電子財産に署名することができる。
【０２５５】
アリスは、第１の実施形態の場合のように、ＥＣを生成し、利用側当事者としてボブの名前を記載する。アリスは、ＥＣ中に、リンクの詳細と暗号化されたセッション鍵を含める。
【０２５６】
ボブは、そのＥＣを受け取ると、第１の実施形態の場合のように、ＣＡからカスタム証明書を得る。カスタム証明書が所有権の証明書になり、必要とされる全ての情報を含むように、リンクおよび暗号化されたセッション鍵がＥＣからカスタム証明書にコピーされ得る。ボブは、自分の秘密鍵を使って復号することによりセッション鍵を得、また、そのセッション鍵を使って解読することにより、電子財産を再生することができる。
【０２５７】
電子財産は暗号化されているため、ボブ以外の誰かが再生することは、計算上、実行不可能になっている。しかし、ボブの署名デバイスがあれば、鍵を所有権の証明書から取り出して復号し、それを使って電子財産を復号して再生することができる。
【０２５８】
図１２は、電子財産の移転の第２の実施形態で使用した、電子財産および対応する権限付与証明書の形態を示す。
【０２５９】
電子財産１００１は、図８および９に関連して上記に説明した形態の１つに、リンク１００２を含む。電子財産１００１は、セッション鍵を用いた対称暗号を使って暗号化される。暗号化された電子財産１００３はリンク１００２を含み、アリスが自分の秘密鍵を使って生成した署名ブロック１００５でディジタルに署名される。上述のように、実際には、アリスは、リンク１００２を含めて暗号化された電子財産１００１をダイジェストし、そのダイジェストを自分の秘密鍵で暗号化することができる。
【０２６０】
アリスは、関連ＥＣ１００６をボブのために作成する。ＥＣ１００６によって、ボブは、アリスの公開鍵１００９を含めて、ＥＣ１００６中のアリスが指定した特定の属性値を得ることができる。ＥＣは、リンク１００７の対応する部分、およびボブの公開鍵を使って暗号化１００８した、暗号化された対称セッション鍵１００４を含む。ボブは、自分の秘密鍵を知っているので、対称セッション鍵１００４を復号し、電子財産１００１を解読することができる。
【０２６１】
図１３を参照すると、電子財産を移転する方法の第２の実施形態の流れ図を示してある。ボブは、ボブの公開鍵を含むアリスへの要求を送る１１０１。アリスは、ボブの公開鍵を確定する１１０２。アリスは、次いで、リンクを生成し、そのリンクを電子財産中に記憶する１１０３。アリスは、セッション鍵を用いた対称暗号を使って、リンクを含む電子財産を暗号化する１１０４。アリスは、ボブの公開鍵でセッション鍵を暗号化する１１０５。アリスは、自分の秘密鍵で電子財産に署名する１１０６。
【０２６２】
アリスはＥＣを生成し１１０７、そのＥＣ中にリンクおよび暗号化したセッション鍵を含める。ＥＣは、アリスの公開鍵を得る権限をボブに付与する。アリスは、署名付きの暗号化した電子財産をＥＣとともにボブに送る１１０８。ボブは、カスタム証明書を得て１１０９、それを電子財産の所有権の証明書として記憶する。
【０２６３】
ボブは、自分の秘密鍵を知っていて対称セッション鍵を復号することができ、したがって電子財産を復号することができるので、電子財産を復号する１１１０。
【０２６４】
電子財産の所有権の移転
所有権が保護され、また自動化手段によって証明され得るように、上記の方法を使って電子財産の所有権を譲渡する環境においては、同じ電子財産の複数の移転を防ぐ、所有権を移転する（例えば、販売によって）ための方法が必要とされる。
【０２６５】
この問題をより明確に説明する。ボブが、アリスによって彼に正しく譲渡された、何らかの電子財産ＸＹＺ（フィルム、または債権などの金融証書など、ビット・ストリングとして表現されるいずれかのもの）を持っていると仮定する。ボブは、上述の所有権の証明書、すなわち、電子財産ＸＹＺへのリンクを持ち、ボブの名前を譲受人として記載している認定カスタム証明書を持っている。今、ボブは、ＸＹＺに対する所有権を証明する手段を持っており、この場合、その証明を、完全に自動化された手段によって実行することができる。しかし、例えば、ボブが財産ＸＹＺの移転を望んでいるとする。彼がキャロル、クロディーン、そしてクローに対して移転すること、すなわち、電子財産およびその所有権証明書のコピーはただでできるためそれを複数回販売することを、何が阻むことができるであろうか。
【０２６６】
本方法は、この種の不正行為を防ぎ、さらに、所轄官庁が犯罪の調査のために所有権の追跡を行う必要がある場合にはそうすることを可能にする、移転のための技術を説明する。
【０２６７】
信頼された情報提供者と呼ぶことができる登録局（ＲＡ）、および信頼された情報証明者と呼ぶことができる認証局（ＣＡ）の２種類の主体を含む、権限付与インフラストラクチャが存在すると想定する。
【０２６８】
信頼できるトランザクション機関（ＴＴＡ）と呼ばれる、別の主体が必要である。この組織は、ボブが実行する「もの」に関するトランザクションを追跡し続け、また、その「もの」の差引残高について報告する、つまり、勘定を整理する責任を持つ。「もの」とは、それが一意の識別子を持つ限り、「ポンド」「ユーロ」または「ドル」、あるいはその他の「もの」であり得る。ＴＴＡは、受け取った全てのトランザクション指示を保存し、どの時点における差引残高でも報告し、また、要求されればそのトランザクションについてのレポートを印刷することができる（すなわち、勘定書を作成する）。
【０２６９】
この特別な主体は、権限付与インフラストラクチャがいずれかの形態の資金移転機能で使用されるときにはどのような場合でも必要とされる。ＴＴＡは、ボブ（そしてアリス）のための資金を保持し、アリスまたはボブから指示があれば、これらの資金を、別のまたは同じＴＴＡのボブまたはアリスの口座に移転する、銀行または同様の組織であってよい。ＲＡまたはＣＡによって運営されている「営業勘定」は、ＴＴＡの例である。ただし、おそらく機能は限定されている。ＴＴＡを設定し運営するプロセス、およびＴＴＡ間の資金の移転を実行するプロセスは十分に理解されており、それを行う既存のシステムも多数ある。
【０２７０】
第２に、ＴＴＡがどのようにして電子財産、すなわちＸＹＺの勘定を整理するのかを説明する必要がある。この技術は、電子財産のハッシュ＃ＸＹＺを得、それを、勘定を整理している対象の「もの」の識別子として使用する。ハッシュ関数は、１つの任意の長い普通テキストを、「ダイジェスト」である、比較的短い固定長のビット・ストリングにマップする一方向性関数である。
【０２７１】
ハッシュ関数は、普通テキストが多少なりとも変更されると、全く異なる値のダイジェストがそのハッシュ関数によって生成されるという性質を持つ。同じダイジェストを持つ２つの形態の普通テキストを生成することもできない。ＸＹＺがあれば、＃ＸＹＺ（普通テキストのハッシュ）を計算することは容易なはずである。＃ＸＹＺがあっても、ＸＹＺ（元の普通テキスト）を見つけることは事実上不可能である。
【０２７２】
その見方として、＃ＸＹＺという名前の一意の通貨でつけられている帳簿であると言えよう。この識別子は、実際には、ＸＹＺの一意の識別子であり、すなわち、衝突の可能性はまずないと言えよう。
【０２７３】
したがって、ボブが電子財産ＸＹＺの正当な所有権を得ると、彼のＴＴＡは、識別子として＃ＸＹＺを使って、ＸＹＺの口座を彼のために開く。彼のＴＴＡは、そのボブの口座の貸方に１を記入する。
【０２７４】
クローがボブから購入したいという場合、彼女はボブから権限付与証明書を受け取る。これは、実質的には、ボブからクローに所有権を移転するようにというボブからの指示である。クローは、通常のやり方で、彼女のＣＡを介して、解決するためにＥＣを権限付与インフラストラクチャ中に渡す。
【０２７５】
これによって、ボブのＴＴＡにある、識別子＃ＸＹＺの彼の口座から、クローのＴＴＡの彼女のために設定される、識別子＃ＸＹＺの彼女の口座への移転が行われ、それによって、ボブの差引残高は１だけ減分され、クローの差引残高は１だけ増分される。
【０２７６】
認定カスタム証明書という形態の、ボブの元の所有権証明書は廃棄される。ボブがすでに電子財産ＸＹＺを売却している場合には、この移転指示は失敗する。すなわち、ボブのＴＴＡは、識別子＃ＸＹＺの彼の口座の差引残高がゼロになっているため、その移転指示を拒絶する。ボブの所有権証明書が廃棄されているので、プロセスがＣＲＬとボブのＣＡを照合するため、もっと早い時期に失敗する場合もある。（ボブがＣＲＬの待ち時間内に何度かＸＹＺの売却を試みている場合もあるため、このステップは高速ではあるがそれほど確かなものではない。）
【０２７７】
移転指示が成功した場合、クローのＣＡは、要求があれば、クローのための認定カスタム証明書、すなわちクローが必要とする所有権証明書を生成する。クローのＴＴＡにおける、識別子＃ＸＹＺの彼女の口座は、差引残高が１になり、監査の目的で、また、必要なときに勘定書を作成するために、この移転指示が保存される。
【０２７８】
アリスの場合は、彼女が電子財産を作成したため、動作の仕方は異なる。彼女のＴＴＡの口座は、彼女が購入、または何か別の理由でＸＹＺを移転させために、増分されない。したがって、代わりに、彼女は、自分の所有権を主張することによって、彼女のＴＴＡとの差引残高を設定する。これは、実際には、彼女が電子財産の著作権を主張することに等しく、表明は、今日、所有権が機能しているあり方である。すなわち、アリスは著作権を主張し、誰かがそれに異議を唱えない限り保有しているとみなされる。彼女はそれを使用前に証明する必要はない。例えば金融証書の場合、ボブは、自分への移転を手配しているときに、買主の危険負担を行使すべきであることに注意されたい。すなわち、彼は、アリスが、誰かから彼女に所有権を移転されることではなく、所有権を表明していることを、権限付与インフラストラクチャから知ることができ、それは、その金融証券の内容に一致していなければならない。
【０２７９】
下記の表１は、電子財産の所有権としてのアリス、ボブ、およびクローの名前の口座残高が、これら当事者間で移転されることを示している。
【０２８０】
【表１】

【０２８１】
さらに、各ＴＴＡは、各移転を指示するトランザクション（権限付与証明書）をファイル上に保管しており、それによって、あるゆる点から開始元に遡って、また、現在の所有者に向かって追跡することが技術的に可能である。この追跡は、科学捜査を行う所轄官庁にとっては非常に重要である。
【０２８２】
電子投票
電子投票には３つの側面がある。
１．集計の信頼性。これは、最も重点的に暗号化の研究の対象とされている分野である。現在、多大なコンピュータの処理能力を犠牲にして、きわめて高い水準の暗号強度が達成される、利用可能な解決策がある。
【０２８３】
２．インタフェースにおけるエラーの可能性。２０００年１１月の合衆国大統領選挙における困難な問題の後、これについていろいろと考察されている。
【０２８４】
３．投票者の遠隔認証。投票者の識別および認証は重要なこととして認識されているが、この分野の真の進歩はわずかしかみられない。前述の権限付与インフラストラクチャはこの助けとなるが、しかし、それらの問題は、依然として困難なままである。
【０２８５】
記載の方法およびシステムは、主として、認証と機密性の間のインタフェース、および権限付与インフラストラクチャによるアイデンティティと認証の問題の処理に関する。
【０２８６】
電子投票システムの目標
集計の信頼性に関する目標
１．誰も、１回しか投票できない。これは、各投票者が一意のシリアル番号を有することによって達成することができ、このシリアル番号は投票に添えられなければならない。集計組織（ＣＯ）が余分な投票用紙を作成することを防ぐために、シリアル番号は別の認証機関（ＡＡ）によって発行される。認証機関がシリアル番号を存在しない投票者に与えることを防ぐために、投票者の名前（シリアル番号ではなく）を公表することができる。
【０２８７】
２．特定の個人が誰に投票したかは誰にもわからない。これは、以下によって達成することができる。
ａ）集計組織の公開鍵で投票を暗号化することによって−データ送信中の投票を保護するために。
ｂ）集計組織を認証機関から切り離すことによって−集計組織の誰かが知ることを防ぐため。
（切り離す以外の方法が、シリアル番号の「匿名配信」によって可能であるが、しかし、これは、コンピュータの処理能力に関して非常に費用がかかり、また、現行システムからの移行−変更ではなく−が非常に難しい。）
【０２８８】
３．誰も、いったん行われた投票を変更できない。これは、投票者が署名した暗号ダイジェストを投票とともに含めることによって達成することができる。
【０２８９】
４．公衆は、投票データが選挙以外のどの目的にも使用されないという確信を持つことができる。電子投票スキームにおいては、集計組織と認証機関の間の馴合いの危険性が問われる問題もある。
【０２９０】
５．投票者は、自分の投票が集計されたことをチェックできる。電子システムでは、投票者が自分の選択したナンスを投票とともに含める場合に、ある候補者への投票に対応するナンス表を公表することが可能であり、これは、個々の投票者にとってのみ意味を持つ。ナンスは、当事者、この場合投票者が提供する、乱数またはその他の情報である。ナンスは、一般に、生成されるまではその値が予測不可能な大きな数である。
【０２９１】
６．誰も別の投票者の投票を複製できない。ナンス・システムがこれを防ぐ。
【０２９２】
７．誰も自分の投票を売ることはできない。電子システムでは、これには、投票ソフトウェアにランダム・スポイラを含めることが必要になる。
【０２９３】
インタフェースでのエラーの可能性に関する目標
８．全ての人の投票が届く。ＡＡにシリアル番号を要求した全ての人が投票に至るわけではない。ＣＯは、このような人々と、投票が入力中になくなってしまった場合の違いがどのようにすればわかるであろうか。ＭＱＳｅｒｉｅｓ（インターナショナル・ビジネス・マシン・コーポレーションの登録商標）などの工業用強度保証配信ミドルウェアが、１つのオプションになるであろう。
【０２９４】
９．忘れられる投票があってはならないし、ましてや、突然現れる投票があってはならない。投票者からＣＯへの経路には、メッセージの形態が変更されるところがある。これが、投票メッセージに悪影響を与えるようであってはならない。この場合も、保証配信ミドルウェアがこの問題を処理する。
【０２９５】
１０．システム・クラッシュの場合には再集計が可能である。これは、投票メッセージ、およびそれらを理解するために十分な付随情報がオフラインで取得されなければならないことを意味する。利点は、監査および再集計が可能になることである。
【０２９６】
１１．既存のペーパー・システムから電子システムへの移行がスムーズでなければならない。全ての投票所は、公務員のための端末を備えることができ、それによって、選挙人名簿は、ＡＡにシリアル番号を要求しなかった人々のみを含む（また、理想としては、死亡登録がなされた者は除外する）。
【０２９７】
投票者の遠隔認証に関する目標
１２．認可された投票者のみが投票できる。権限付与インフラストラクチャを使って、固定選挙人名簿に基づいてではなく、アイデンティティ、年齢、住所、国籍、投票除外者ではないことに基づいて、ある人の投票を認定することができる。
【０２９８】
１３．少なくとも本システムにおける場合と同様に、アイデンティティを確定することができる。使用されるアイデンティティの基盤の問題は、ポリシーの問題である。名前、住所、および生年月日で十分であるかどうかを決定しなければならない。国籍および禁止クラスの者でないことについても、同様に権限付与する必要がある。
【０２９９】
１４．選挙人名簿はコンピュータ化する必要がある。選挙人名簿なしに誰もが自分のアイデンティティを確定できると、その文書自体が必要でなくなる。
【０３００】
次に、図１４から１８を参照しながら、上述の目標の達成をめざす、電子投票のための方法およびシステムの単純な例を説明する。
【０３０１】
図１４および１５は、認証機関（ＡＡ）１２０１および別個の集計組織（ＣＯ）１２０２が提供されている、電子投票システム１２００を示す。複数の投票者１２０３、１２０４、１２０５、１２０６も示してある。図１４では、投票者１２０３、１２０４、１２０５、１２０６は、ＡＡ１２０１とＣＯ１２０２の両方と通信を行う。図１５では、投票者１２０３、１２０４、１２０５、１２０６は、ＡＡ１２０１にのみメッセージを送り、ＡＡ１２０１が、ＣＯ１２０２に宛てられたメッセージを、投票者１２０３、１２０４、１２０５、１２０６の代わりに転送する。
【０３０２】
図１４に示すフローでは、まず、投票者アリス１２０３は、ＡＡ１２０１に、彼女の名前、住所、生年月日、国籍、および禁止クラスの記録に対する権限を付与して、シリアル番号を要求する。ＡＡ１２０１は、これらを確認して、アリスに彼女のシリアル番号を送る。彼女は、次いで、シリアル番号、ナンス、スポイラ、投票で投票メッセージを構築し、それをＣＯ１２０２に送る。
【０３０３】
しかし、これは、アリスが自分のシリアル番号を受け取って投票できるようになる前に、ＡＡ１２０１が彼女のアイデンティティを確認するまで待たなければならないという欠点がある。別の欠点は、アリスがＡＡ１２０１とＣＯ１２０２の両方にメッセージを送らなければならないことである。
【０３０４】
図１５の場合、アリス１２０３は、ＡＡ１２０１を介してＣＯ１２０２に自分のメッセージを送る。これには、アリス１２０３が１度だけの動作で投票を完了し、ＣＯ１２０２には、アリスの電子アドレスを使って彼女を追跡する方法がないという利点がある。
【０３０５】
しかし、ＡＡ１２０１は、投票を読むことができてはならない。したがって、ＣＯ１２０２には読むことができて、しかしＡＡ１２０１には読むことができないように投票を暗号化しなければならない。これが、本明細書で提案している方法およびシステムである。
【０３０６】
図１６を参照すると、投票を行う方法を示す図が提供されている。この図では、角丸の破線ブロック内に動作を示している。オブジェクトは、実線ブロック内に示してある。
【０３０７】
アリス（投票者の例としての）は、ＡＡを利用側エンティティとして指定する、権限付与証明書１３０１を生成する。アリスは、権限付与証明書１３０１中で、自分の名前、住所、生年月日、国籍、禁止クラスの記録に対する権限を付与する（また表明することもできる）。これは、アリスを一意に識別するのに十分なデータである。アリスはまた、権限付与証明書１３０１中で、自分の投票フォームに署名するために使用しようとしている秘密／公開鍵ペアの公開鍵１３０２も表明する。
【０３０８】
権限付与証明書については、「権限付与証明書」の節で詳細に説明してある。この節では、証明書の生成者がどのようにしてデータを表明することができるのかを説明する。この場合には、データがその証明書中に現れる。また、証明書の生成者がどのようにしてデータを権限付与することができるのかを説明する。この場合には、データの指示が証明書に記載され、その証明書によって、別のソースからデータを得る権限が利用側当事者に付与される。
【０３０９】
権限付与証明書１３０１はまた、証明書を処理するために必要な技術データ、例えば使用されている暗号関数も含む。
【０３１０】
アリスは、秘密／公開署名鍵ペアの自分の秘密鍵を使って、権限付与証明書１３０１に署名し、権限付与証明書１３０１が本物であることを確証する。
【０３１１】
権限付与証明書は、Ｘ．５０９ｖ．３証明書であってよい。
【０３１２】
アリスは、ＡＡの秘密／公開機密性鍵ペアの公開鍵を使って、権限付与証明書１３０１を暗号化する１３０３。その結果、暗号化された権限付与証明書１３０４が得られる。当事者間で、複数の秘密／公開鍵ペア、例えば機密性鍵ペアおよび署名鍵ペアを持つことができる。
【０３１３】
アリスはまた、シリアル番号は含まないが、ナンス、スポイラおよび投票を含む投票メッセージ１３０５も作成する。ナンスは、当事者、この場合アリスが提供する乱数またはその他の情報である。ナンスは、一般に、生成されるまではその値を予測不可能な大きな数である。
【０３１４】
記載の方法およびシステムでは、アリス（投票者の例としての）はナンスを生成することを要求されない。ナンスは、彼女が自分の投票が記録されたかどうかをチェックしたい場合に役に立つ。自分の投票が記録されたかどうかのチェックを望まない場合には、ナンスは関係がない。本方法の異なる実装は、以下の通りである。
・一実装では、アリスにオプションを与えることができ、彼女がナンスを望む場合には彼女のためのランダム・ナンスを選び、彼女がナンスを望まない場合にはゼロを使用することができる。これには、ゼロ・ナンスは公表される必要がなく、興味がある人だけが自分のナンスを公表させるという利点がある。
・別の実装では、いずれにしてもナンスが生成されて、ＡＡおよびＣＯに送られ、アリスのコンピュータに記録される。これには、アリスが回答しなければならない質問が１つ少なくなるという利点がある。
【０３１５】
アリスは、ＣＯの秘密／公開機密性鍵ペアの公開鍵を使って、投票メッセージ１３０５を暗号化する１３０６。その結果、暗号化された投票メッセージ１３０７が得られる。
【０３１６】
アリスは、次いで、ハッシュ関数１３０８を暗号化された権限付与証明書１３０４に適用する。その結果、暗号化された権限付与証明書のダイジェスト１３０９が得られる。
【０３１７】
ハッシュ関数は、任意の長い普通テキストを、「ダイジェスト」である、比較的短い固定長のビット・ストリングにマップする一方向性関数である。ハッシュ関数は、その普通テキストが多少なりとも変更されると、そのハッシュ関数によって全く異なるダイジェスト値が生成されるという性質を持つ。また、同じダイジェストを持つ２つの形態の普通テキストを生成できるということはない。Ｐがあれば、＃Ｐ（その普通テキストのハッシュ）を計算することは容易なはずである。＃Ｐがあっても、Ｐ（元の普通テキスト）を見つけることは事実上不可能である。使用できるハッシュ関数にはいくつかの異なるタイプがある。
【０３１８】
同様に、アリスは、ハッシュ関数１３１０を暗号化された投票メッセージ１３０７に適用する。その結果、暗号化された投票メッセージのダイジェスト１３１１が得られる。２つのダイジェスト１３０９、１３１１を連結して１３１２、２つのダイジェスト１３０９、１３１１の連結物１３１３を得る。ハッシュ関数１３１４を、２つのダイジェスト１３０９、１３１１の連結物１３１３に適用する。その結果、連結物１３１３のダイジェスト１３１５が得られる。この結果が完全性ブロックになる。
【０３１９】
アリスは、連結物１３１３のダイジェスト１３１５を、自分が投票に使っている鍵ペアの自分の秘密鍵を使って暗号化する１３１６。これは、ＡＡへの権限付与証明書１３０１中で表明されている公開鍵の鍵ペアと同じ鍵ペアである。ダイジェスト１３１５の暗号化の結果、署名ブロック１３１７が得られる。
【０３２０】
アリスは、暗号化された権限付与証明書１３０４、暗号化された投票メッセージ１３０７、および署名ブロック１３１７をＡＡに送る１３１８。アリスは、ここでログオフできる。彼女は、シリアル番号を待つ必要はなく、また、ＣＯに何も送る必要はない。
【０３２１】
次に、図１７を参照しながら、ＡＡがアリスから暗号化された権限付与証明書１３０４、暗号化された投票メッセージ１３０７、署名ブロック１３１７を受け取ったときに実行される方法を説明する。
【０３２２】
ＡＡは、ＡＡの秘密機密性鍵を使って、暗号化された権限付与証明書１３０４を復号する１４０１。ＡＡは、権限付与証明書１３０１および権限付与インフラストラクチャを使って、アリスのアイデンティティおよび彼女の投票権を確定する１４０２。ＡＡは、アリスが権限付与証明書１３０１中で表明している、彼女が投票に使用している公開鍵１３０２も得る。
【０３２３】
ＡＡは、暗号化された投票メッセージ１３０７を読むことはできない。しかし、ＡＡは、２つのメッセージがアリスからＡＡに送られてきたものであり、ＡＡが受け取っている署名ブロック１３１７によってに互いにリンクされていることを確認することができる。
【０３２４】
この確認は、アリスが実行した、ハッシュ関数を適用してダイジェストを連結するプロセスをミラー化することによって行われる。ＡＡは、ハッシュ関数１４０８を暗号化された権限付与証明書１３０４に適用し、その結果、暗号化された権限付与証明書のダイジェスト１４０９が得られる。同様に、ＡＡは、ハッシュ関数１４１０を暗号化された投票メッセージ１３０７に適用し、その結果、暗号化された投票メッセージのダイジェスト１４１１が得られる。２つのダイジェスト１４０９、１４１１が連結され１４１２、２つのダイジェスト１４０９、１４１１の連結物１４１３が得られる。ハッシュ関数１４１４が、２つのダイジェスト１４０９、１４１１の連結物１４１３に適用され、その結果、連結物１４１３のダイジェスト１４１５が得られる。
【０３２５】
ＡＡが受け取った署名ブロック１３１７は、検証された権限付与証明書１３０１から得られた１４０２、アリスの投票用公開鍵１３０２を使って復号される１４０３。復号された署名ブロックは、連結物のダイジェスト１４０４である。
【０３２６】
２つの連結物のダイジェスト１４１５、１４０４を比較することができ１４０５、それらが同じものであるならば、ＡＡは、その２つのメッセージがアリスからＡＡに送られてきたものであり、署名ブロック１３１７によってリンクされているという確証が得られる。
【０３２７】
ＡＡは、次いで、アリスにシリアル番号を割り当て、アリスのシリアル番号、アリスが表明している投票用公開鍵、およびアリスの暗号化された権限付与証明書のダイジェストを含むメッセージを構築する。ＡＡは、ＡＡの秘密署名鍵でメッセージに署名し、それをアリスの投票メッセージ１３０７および署名ブロック１３１７とともにＣＯに送る。
【０３２８】
次に、図１８を参照しながら、ＣＯが、ＡＡから転送されてきた暗号化された投票メッセージ１３０７、ＡＡの署名付きのメッセージ１５００（前の段落で説明したメッセージ）、および署名ブロック１３１７を受け取ったときに実行される方法を説明する。
【０３２９】
ＣＯの秘密機密性鍵を使って、暗号化された投票メッセージ１３０７が復号され１５０１、アリスの投票が彼女のナンスおよびスポイラとともに得られる１５０２。
【０３３０】
ＡＡの公開鍵を使って、ＡＡの署名付きのメッセージ１５００が復号され１５０６、その結果、権限付与証明書のダイジェスト１５０９、アリスのシリアル番号１５０７、およびアリスの投票用公開鍵１３０２が得られる。
【０３３１】
ＣＯは、暗号化された投票メッセージ１３０７がアリスからＣＯに送られてきたものであり、ＡＡが署名ブロック１３１７により送ってきた権限付与証明書のダイジェスト１５０９にリンクされていることを確認することができる。
【０３３２】
この確認は、アリスとＡＡの両方が実行した、ハッシュ関数を適用してダイジェストを連結するプロセスをミラー化することによって行われる。ＣＯは、メッセージ１５００から、暗号化された権限付与証明書のダイジェスト１５０９を得る。ＣＯは、暗号化された投票メッセージ１３０７にハッシュ関数１５１０を適用し、その結果、暗号化された投票メッセージのダイジェスト１５１１が得られる。２つのダイジェスト１５０９、１５１１が連結され１５１２、２つのダイジェスト１５０９、１５１１の連結物１５１３が得られる。ハッシュ関数１５１４が、２つのダイジェスト１５０９、１５１１の連結物１５１３に適用され、その結果、連結物１５１３のダイジェスト１５１５が得られる。
【０３３３】
ＣＯが受け取った署名ブロック１３１７が、ＡＡからのメッセージ１５００から得られたアリスの投票用公開鍵１３０２を使って復号される１５０３。復号された署名ブロックは、連結物のダイジェスト１５０４である。
【０３３４】
２つの連結物のダイジェスト１５１５、１５０４を比較することができ１５０５、それらが同じものであるならば、ＣＯは、投票メッセージ１３０７が変更されていない元の投票であり、ＡＡによってシリアル番号が割り当てられているという確証が得られる。
【０３３５】
ＡＡからのメッセージ１５００から得られたアリスのシリアル番号１５０７が、アリスの投票、ナンスおよびスポイラ１５０２と結合され、記録される１５０８。
【０３３６】
従来通りに、ＡＡは、投票した人々のアイデンティティを公表する（少なくとも監査チームに）ことができる。このリスト上の数が投票数よりも少ないことがあってはならない。
【０３３７】
このようにして、１つのメッセージを、投票の認証と集計の両方に使用することができる。投票者が実行するプロセスは、１通信を１当事者、すなわち認証機関に送るだけでよいという点でわかりやすい。認証機関は、集計機関と通信を行う。これは、認証機関と集計機関の間のネットワークを、投票者が使用することになるインターネットよりも高速にすることができるため、通信がスピードアップされる。
【０３３８】
暗号化という用語が使用されている場合に、結果として機密性がもたらされることを必ずしも意味していないことを理解されたい。秘密鍵で暗号化されたデータは、広く利用可能なことがある対応公開鍵を保持する人であれば、誰でも復号できるからである。
【０３３９】
記載の方法およびシステム内で異なるハッシュ関数を使用することができる。ただし、使用される関数が当事者間で同意されている場合に限る。
【０３４０】
異なる当事者が使用する公開／秘密鍵技術は異なってもよい。ただし、他方の当事者がどの技術が使用されているかを知っており、その技術を実装できる場合に限る。
【０３４１】
記載の方法およびシステムは、暗号化のような動作を実行する当事者を対象としている。しかし、この方法をコンピュータ・ソフトウェアに実装することにより、それが各当事者に代わってそれらの機能を実行することを理解されたい。
【０３４２】
本発明の範囲から逸脱することなく、上記の実施形態形態に改良および修正を加えることができる。
【図面の簡単な説明】
【０３４３】
【図１】従来技術のデータ配信のシステムを示す図である。
【図２】図１のシステムの流れ図である。
【図３】本発明によるデータ配信のシステムを示す図である。
【図４】図３のシステム全体の流れ図である。
【図５】本発明によるシステムの一部を示す概略図である。
【図６】図３のシステムの一部の流れ図である。
【図７】本発明によるシステムを示す図である。
【図８】本発明の一態様による、関連権限付与証明書を有する電子財産の一形態を示す図である。
【図９】本発明の一態様による、関連権限付与証明書を有する電子財産の一形態を示す図である。
【図１０】本発明の一態様による、権限付与証明書および関連カスタム証明書を示す図である。
【図１１】本発明の一態様による、第１の電子財産の所有権の移転方法の流れ図である。
【図１２】本発明の一態様による、関連権限付与証明書を有する電子財産のさらなる形態を示す図である。
【図１３】本発明の一態様による、第２の電子財産の所有権の移転方法の流れ図である。
【図１４】本発明の一態様による電子投票システムの概略図である。
【図１５】本発明の一態様による電子投票システムの概略図である。
【図１６】本発明の一態様による電子投票方法を示す図である。
【図１７】本発明の一態様による投票確認方法を示す図である。
【図１８】本発明の一態様による投票記録方法を示す図である。

Claims (3)

1. 対象側エンティティ・アプリケーションを有する対象側エンティティ（３０２）と、利用側エンティティ・アプリケーションを有する利用側エンティティ（３０４）と、前記対象側エンティティ（３０２）の公開鍵を保持するためのデータ記憶装置（５０４）を有するソース（３０６、５００）と、中間エンティティ・アプリケーションを有する中間エンティティ（３０８）とを備え、前記対象側エンティティ（３０２）の公開鍵を前記利用側エンティティ（３０４）に供給するためのシステムであって、
   前記対象側エンティティ・アプリケーションは、前記公開鍵に対応する前記対象側エンティティ（３０２）の秘密鍵を使って電子署名がなされた第１のディジタル証明書を生成するとともに、当該第１のディジタル証明書を前記利用側エンティティ（３０４）に転送するための手段を有し、
   前記第１のディジタル証明書は、
   前記対象側エンティティ（３０２）を識別する１つまたは複数の属性を含む、前記第１のディジタル証明書の１つまたは複数の属性と、
   前記公開鍵の指示と、
   前記公開鍵を供給すべき前記ソース（３０６、５００）の指示と、
   前記公開鍵を供給すべき先の前記利用側エンティティ（３０４）を識別する１つまたは複数の属性とを含み、
   前記利用側エンティティ・アプリケーションは、前記データ記憶装置（５０４）から前記公開鍵を得るために、前記対象側エンティティ（３０２）から受け取られた前記第１のディジタル証明書を前記中間エンティティ（３０８）に転送するための手段を有し、
   前記中間エンティティ・アプリケーションは、前記利用側エンティティ（３０４）から受け取られた前記第１のディジタル証明書を前記公開鍵の要求に変換して前記指示されたソース（３０６、５００）に転送し、その応答として前記指示されたソース（３０６、５００）の前記データ記憶装置（５０４）から供給される前記公開鍵を受け取り、前記中間エンティティ（３０８）の署名生成鍵を使って電子署名がなされた第２のディジタル証明書を生成するととともに、当該第２のディジタル証明書を前記識別された利用側エンティティ（３０４）に転送するための手段を有し、
   前記第２のディジタル証明書は、
   前記公開鍵と、
   前記対象側エンティティ（３０２）を識別する１つまたは複数の属性を含む、前記第２のディジタル証明書の１つまたは複数の属性と、
   前記公開鍵を供給すべき先の前記利用側エンティティ（３０４）を識別する１つまたは複数の属性とを含む、システム。
2. 前記ソース（３０６、５００）は、１つまたは複数のさらなるソース（３０６、５００）を参照することが可能である、請求項１に記載のシステム。
3. 前記第１のディジタル証明書は、前記利用側エンティティ（３０４）が前に含めることを要求していた参照、ナンス、またはその他のデータを含む、請求項１または２に記載のシステム。

Images