JPH10504150A - 商用暗号システムにおけるディジタル署名を安全に使用するための方法 - Google Patents

Abstract

(57)【要約】 商用暗号システムにおける安全にディジタル署名を使用するためのシステムであって、産業界にわたるセキュリティ対策および許可情報を、署名および証明中に、対策と許可の要件を実施するための属性証明を用いることによってエンコードするシステム。対策および許可の要件の確認は、システムにおいて、公開鍵に対するアクセスをディジタル署名を行っておりシステムの規則に従うことに合意しているユーザに制限することにより実施する。これらの規則は、公開鍵と秘密鍵の使用に対する支払がされていることを保証することもできる。さらに、ユーザは自分自身の規則と対策の要件をシステム内のトランザクションに課すことができる。

Description

【発明の詳細な説明】 商用暗号システムにおけるディジタル署名を安全に使用するための方法 発明の背景 本発明はディジタル署名に関する。特に本発明は、ユーザのリスクを減らす方 法によりセキュリティ対策(security policies)と許可要件(authorization requ irements)を実施するための商用暗号システムにおけるディジタル署名の使用と ディジタル署名の証明(certificates)に関する。 公開鍵暗号法(public-key cryptography)は近年のコンピュータ・セキュリテ ィ技術であり、本技術は、電子文書(electronic document)上のユーザのディジ タル署名、つまり、電子文書のユーザの電子的な認証(authentication)と確認(v erification)が、十分実用的で法的な意味を与えられることが可能な場合には、 ペーパーレス電子文書システムの作成をサポートすることができる。このような ペーパーレス電子文書システム、または、「文書アーキテクチャ(document arch itecture)」には、標準的な双務契約(bilateral contract)の下で働く商取引の パートナーだけではなく、世界的な多角システム(multilateral system)も含ま れる。そこでは、正しいセキュリティ・コントロールが全体に渡って遵守されて いる場合には、いかなるエンティティ(entity)も、理論的には、ほかのエンティ ティと法的に立証可能な方法で対応を付けることができる。 このようなシステムは、多くの場合、現在の紙によるトランザクション(trans action)手続に対してオーダにして１０分の１のオーダのコスト削減を実現する ことができるため、極めて大きな商業的意味を持つ。この改善は十分に劇的なの で、その実用性がひとたび明らかにされれば多くの組織が、経済的もしくは競業 的な理由のため、これらを使用せざるをえなくなるだろう。 紙は、電子的な世界では面倒な時代遅れものであることや、ペンとインクによ る署名を確認するにはコストがかかり間違いが発生しやすいことについて、反論 する者はいない。しかし、少なくとも紙では、署名者は文書の用意と物理的な配 信(delivery)の基本的な「コンテキストのコントロール(contextual control)」 を保持している。一方、ディジタルに署名された電子文書の上では、署名者は、 エンコードされた署名しか制御しない。時間、場所および方法のコントロールは すべて欠けており、有効なユーザ署名を、最初のユーザのスマート・カード(sma rt card)とＰＩＮ（パーソナル識別番号）を何らかの手段で入手した他のユーザ によって詐欺的に作成された署名と、区別する方法はない。この「新奇(newfang led)」なオフィス・オートメーション技術によって生み出だされた節約をすべて 消してしまうことは、数百万ドルや数十億ドルの損失ではない。したがって、デ ィジタル署名は消費者向けの「電子的な小銭入れ(electronic coin purse)」ア プリケーションにおいて早期に使用され、そこでは危険に曝される度合が低く、 そして、大規模な金融移動(wholesale financial transfer)であって、極めて固 いセキュリティ手続きが既に標準となっているものにおいてのみと考えられるだ ろう。しかし、これらの使用では、一般的な商業的衝撃は少ない。 ここまでは、うまく定義されたリスク・モデルおよび会計監査(auditing)の標 準が欠けていて、法的および責任の問題が不明確なため、大企業および銀行はこ れらの技術に投資することを断ってきた。先進的で国家的な会計監査と法律の専 門家が、これらのシステムに十分なセキュリティ・コントロールが含まれるよう にして典型的には１０，０００ドルから１０００万ドルの範囲の、メインストリ ーム・ビジネス内およびビジネス間のトランザクションにおける信頼性が保証で きて初めて、ディジタル署名を商業化するための重大な投資が行われるだろう。 この目的を達成するためには、セキュリティ・コントロールを形成して、ディジ タル署名文書システムにおける当事者のリスクを、技術的に達成可能な絶対的最 低レベルにまで減少させなければならない。 ディジタル署名が使用されてきた暗号システムには、２種類がある。対称(sym metric)および非対称(asymmetric)の暗号システムである。図１（ａ）と図１（ ｂ）は暗号化(encription)に対する対称および非対称のアルゴリズムの使用を示 している。対称（従来の）暗号では、図１（ａ）に示す通り、通信の送信者 (sender)と受信者(recipient)はシークレット・キー(secret key)１１を共有す る。この鍵は、メッセージ１２を暗号化するために通信の発信者(originator)で ある送信者によって、および、メッセージ１３を復号化するために通信の受信者 によって使用される。また、この鍵は、受信者によって使用されて、メッセージ の認証を、メッセージに基いたメッセージ認証コード(Message Authentication Code)(ＭＡＣ)などのような関数を計算するためのシークレット・キーを送信者 に使用させることにより行う。このようにして、受信者は発信者本人であること を確認することができるのは、送信者と受信者のみがＭＡＣを計算するために使 用されるシークレット・キーを知っているからである。ＤＥＳは対称暗号システ ムの一例である。 非対称（公開鍵）暗号は、図１（ｂ）に示した通り、異なる鍵をメッセージの 暗号化と復号化(decrypt)に用いる。各ユーザには１対の鍵が対応付けられる。 一方の鍵１５（公開鍵）は、公に知られており、そのユーザに対して送るメッセ ージ１７を暗号化するために使用され、もう一方の鍵１６（秘密鍵(private key )）はそのユーザのみが知っており、入来メッセージ(incoming message)１８を 復号化するために使用される。公開鍵は秘密に保つ必要がないので、秘密トラヒ ック(confidential traffic)や認証メッセージ(authenticating message)を交換 する前に通信する関係者の間に共有される暗号化鍵(encryption key)を秘密に伝 える必要は、もはやない。ＲＳＡは最もよく知られた非対称アルゴリズムである 。 しかし、ディジタル署名は、メッセージ・データ・ユニットに追加されるデー タのブロックであり、受信者は、メッセージ・データ・ユニットの発送元を証明 してそれを偽造(forgery)から防護することができる。非対称アルゴリズムによ っては（たとえばＲＳＡは）ディジタル署名の使用を通じて認証と非否認(non-r epudiaton)を提供することができる。データに署名するために、送信者は自分自 身の秘密鍵の下でデータを暗号化する。データの妥当性を検証する(validate)た めに、受信者は、データを送信者の公開鍵で復号化する。送信者の公開鍵を使用 してメッセージを成功裏に復号化した場合は、メッセージは元々は送信者によっ て暗号化されていたものに違いない。というのは、送信者が対応す る秘密鍵を知る唯一のエンティティ(entity)だからである。この文書署名の方法 を使用すれば、受信者は署名データ・ブロックの復号化をしなければメッセージ を読むことができないので、暗号化されたメッセージが署名に束縛される。署名 暗号化(signature-encrypted)メッセージを、その後、受信者の公開鍵を使用し て受信者に対して暗号化することもできるのは、通常の通りである。 ディジタル署名は、以下に説明し、図２に示す通り、非対称暗号化アルゴリズ ムを使用して形成してもよい。メッセージに署名するには、まず、メッセージ２ ０を、１方向性ハッシュ関数(one-way hash function)２１を使用して、単一の ブロック２２にダイジェスト(digest)する（ハッシュする）。１方向性ハッシュ 関数は、ダイジェストが与えられた場合に、その値にハッシュするいかなるメッ セージを構築することも同じダイジェストにハッシュする２つのメッセージを見 付けることも計算量の点で実行不可能である、という性質を有する。ダイジェス ト２２は、その後ユーザの秘密鍵２３によって暗号化され、その結果２４は、暗 号化されたまたは暗号化されていないメッセージに、その署名２５として追加さ れる。受信者は送信者の公開鍵２６を使用して署名２５をハッシュ・ダイジェス ト２２に復号化する。受信者は、送信者が使用した１方向性ハッシュ関数２１と 同じものを使用して、メッセージ２０をブロック２７にダイジェスト（ハッシュ ）する。メッセージ２０は、暗号化されずに受信したもの、または、暗号化され て受信されその後に受信者によって復号化されたものである。その後、受信者は 、復号化されたハッシュ・ダイジェスト２２がハッシュされたメッセージ・ダイ ジェスト２７と同じであることをチェックすることによって、送信者の署名を確 認２８する。 この方法で署名をメッセージから分離すること、すなわち、署名を確認するた めに送信者と受信者が全メッセージを暗号化し復号化する必要がないことによっ て、暗号化されるデータの量が大幅に削減される。公開鍵アルゴリズムは、一般 に本質的に従来のアルゴリズムより遅く、署名を確認するために全メッセージを 処理することは重大な時間の量を必要とする可能性があるので、これは重要であ る。また、署名プロセスはメッセージに冗長性を導入するが、メッセージは指定 されたダイジェストにハッシュしなければならないので、これによって、受信者 は、メッセージに対する権限のない変更を検出できるのである。 ディジタル署名は、以下のセキュリティ・サービスを提供する。（ａ）完全性 。署名されたデータに対していかなる変更をしても、異なるダイジェストと異な る署名が結果として生じるからである。（ｂ）発送元の認証。署名の確認に使用 される公開鍵に対応する秘密鍵の所有者のみがそのメッセージに署名できるから である。（ｃ）非否認性(non-repudiation)。受信者やその従業員ではなく、署 名者のみがその署名を作成できた旨の、サード・パーティ(third party)に対す る取り消せない証明(irrevocable proof)としての性質である。対称シークレッ ト・キーの認証者(authenticator)は、例えばＸ９．９ ＭＡＣなどは、このよ うなサービスは提供しない。というのは、２つのパーティのいずれかがその共有 された鍵を使用して認証者を作成できるからである。 ここで説明したさまざまな機構は、複数の署名または連署(cosignature)を文 書に貼り付ける能力を前提としている。この目的に対する便利なフォーマットは 、本技術分野では周知であるが、「PKCS #7：暗号メッセージ文法(Cryptographi c Message Syntax)」(RSA Data Security，Inc.，１９９３年)に定義されており 、これは参照することにより本明細書の一部を構成する。文書上の各署名構造は 、実際の署名を含むビット列に合わせて署名が有効か調べるのに必要な証明の表 示を含む。更に、特定の署名者に関連する他の情報を個々の署名計算(signature computation)に含めることもできる。この署名者ごとの情報は、「署名属性(si gnature attribute)」として署名計算に含めてもよい。 あるユーザが、メッセージの伝送のために別のユーザを、第２のユーザが秘密 鍵を所有することを保証するような方法で識別するためには、第１のユーザは他 のユーザの公開鍵を信頼できるソースから取得できなければならない。当業界で 周知の通り、公開鍵証明(public key certificate)の使用のための枠組は「X.50 9：ディレクトリ(The Directory)：認証フレームワーク(Authentication Framew ork)」、CCITT、１９９３年４月(「X.509」)に定義されており、これは、参照す ることにより本明細書の一部を構成する。これらの基本的な公開鍵証明は、ユー ザの名前を公開鍵に束縛し、証明オーソリティ（Certification Authority）（ ＣＡ）と呼ばれる信頼できる発行者(issuer)に よって署名されている。ユーザの名前と公開鍵を含むほか、この証明は、発行し たＣＡの名前、シリアル番号および有効期間(validity period)も含む。 Ｘ．５０９はＣＡ上にいかなる特定の構造をも課していないが、多くの実装で は、各ＣＡが（一般に）それの下位であるエンティティのみを証明するような階 層構造を課すのが妥当であることがわかっている。このため、図３に示すように 、ＣＡの階層を構成することができ、ここでは、高レベルＣＡ３１（おそらく銀 行）はその下のＣＡ３２（たとえば、会社）の証明３４を署名し、ＣＡ３２の一 番下のレベルはユーザ３３の証明３５を署名する。この階層の頂上（図示してい ない）は比較的少ない他のルート(root)ＣＡで、おそらく１つの国につき１つで あり、これは互いの公開鍵（ルート鍵）を「相互証明(cross-certify)」するこ とができる。 様々なセキュリティ・アーキテクチャは、与えられたユーザの証明とこれが有 効であるか調べるために必要な全ＣＡの証明を取得するために、この階層を通じ て証明経路(certification path)を構成する機構を定義している。これらのアー キテクチャは、ユーザが任意の他の証明を取得して有効か調べるために、ただ一 つだけの他の公開鍵を信頼(trust)する必要がある、という共通の特徴を共有す る。信頼された鍵は、（中央集合化信頼モデル(centralized trust model)にお ける）トップ・レベルＣＡまたは（非中央化集合モデル(decentralized model) における）ユーザの証明を発行したローカルＣＡの鍵としてもよい。 証明は、有効期限(expiration date)も含む。証明をその有効期限の前にキャ ンセルする必要がある場合、たとえば名前の対応が無効になったり対応する秘密 鍵が失われたり危険にさらされたりした場合は、証明はＣＡの証明取消しリスト (revocation list)（ＣＲＬ）、または「ホット・リスト(hot list)」を追加す ることもできる。このリストはＣＡによって署名され、場合によってはＣＡのデ ィレクトリ・エントリの一部として、広く配送される。証明は、証明の有効期限 まで、ＣＲＬ上に残り続ける。 エンティティやＣＡに関するある情報を、信頼できる方法で利用可能にする必 要がある場合はよくある。安全なＸ．５００ディレクトリにおいては、この情報 は標準的なディレクトリ(Directory)操作を介して取得され、その結果はその ディレクトリ(Directory)によって署名される。このような安全なＸ．５００の 実装が存在しない場合は、この情報は属性証明(attribute certificate)の中に 置かれ、これは公開鍵証明と同じ方法でＣＡによって署名される。属性証明は、 正しい信用証明書(credential)の提示の上、ユーザによって作成される。たとえ ば、ユーザは自分の公開鍵証明を提示(present)して対応する秘密鍵を所有して いることを証明するが、これは、識別(identification)の一形式である。属性証 明は、ユーザの基本公開鍵証明に、基本証明のシリアル番号を参照することによ ってリンクされており、同一の並列ＣＲＬ機構によって取り消される(revoked) 。属性証明は、さらに「X9.30 パート３：ＤＳＡに対する証明管理(Certificate Management for DSA)」、ANSI X9F1、１９９４年６月と、米国特許番号第４， ８６８，８７７号、第５，００５，２００号、および第５，２１４，７０２号に おいて説明されており、これらはすべて当業界で周知であり、すべて参照するこ とにより本明細書の一部を構成する。 属性証明は、公開鍵証明から分離した構造である。というのは、役割を正しく 分離すれば、属性証明を発行するＣＡが公開鍵証明を発行するＣＡと異なること がしばしば必要とされるからである。中央のＣＡ自身が、ユーザの許可(authori zation)のすべてに「署名」するために、必要とされるセキュリティやオーソリ ティを所有していることはほとんどない。分離したＣＡが生成されるようにすれ ば、様々な種類の属性証明によってリスクがより適切に分配される。さらに、定 義された属性が全ドメイン、ネットワークおよびアプリケーションに対して必要 とされないこともある。これらの属性および付加的なドメイン固有の属性の必要 性は、各ドメインによって決定される。 ユーザの基本公開鍵証明はＸ．５０９互換のままであり、これをほかのアプリ ケーションで使用することもでき、証明生成用に商品を使用することができる。 所望されるのは、ディジタル署名と証明機構を利用してこの組織構造の内部の 規則によって定義されたセキュリティ対策を実施するような、信頼できる組織を 構成することである。 また、所望であるのは、ディジタル署名と証明機構を使用して、産業的に広い セキュリティ対策と許可情報を署名および証明内にエンコードし、署名の確認者 (verifier)がその署名や証明を有効なものとして受け付けるべきものか否かを決 定できるようにし、このようにして電子商業ビジネス・トランザクション(trans action)を適応させ容易にすることである。 さらに、所望であるのは、公開鍵証明と属性証明のこの使用を構築することに より、ディジタル署名システム、特にエンド・ユーザのスマート・カードに関連 したリスクを減少させることである。 さらに、所望であるのは、パーティが、適切な「システム規則」同意書であっ て通信する署名者許可のシステムに関連する同意書に署名していないときに、適 切な許可証明に違反してトランザクションを「受け付ける」と主張するパーティ によってこのようなディジタル署名システムが、使用されることを防止すること である。 発明の概要 本発明のこれらおよびその他の目的は、本発明の原理により、安全にディジタ ル署名を商用暗号システムにおいて使用するシステムであって、対策と許可の要 件を実施するために属性証明を使用することによって産業的に広いセキュリティ 対策および許可情報を署名と証明にエンコードできるようにするシステムを提供 することによって、達成される。トランザクションの上に配置できる値の限界、 連署の要件および文書タイプの制限に加えて、組織は、いかなるトランザクショ ンとの関係においても地理的および時間的な制御、署名の年齢(age-of-signatur e)の制限、あらかじめ承認(pre-approve)されたカウンタパーティ(counterparty )の制限および確立の要件(confirm-to requirement)を、トランザクションのユ ーザに対する属性証明を使用することによって、実施できる。証明の配送(distr ibution)の制限は、属性証明を使用することによって設定できる。証明は、この システムにおけるスマートカード(smartcard)の鍵の制限(key confinement)およ び非復号化(non-decryption)要求を保証するために使用することもできる。 図面の簡単な説明 本発明の上記およびその他の目的および利点は、以下の詳細な説明を添付した 図面と共に考慮すれば明らかになろう。これらの図面では、参照文字は全体を通 じて似た部分を参照する。ここでは、 図１（ａ）および１（ｂ）は、暗号化に対する対称および非対称アルゴリズム の従来の技術による使用を示す図である。 図２は、非対称暗号化アルゴリズムを使用するディジタル署名の従来の技術の プロセスを図示するフロー・チャートである。 図３は、署名証明オーソリティの階層を示す図である。 図４は、ディレクトリ情報木(directory information tree)（ＤＩＴ）を示す 図である。 図５は、許可証明の一例を示す図である。 図６は、トランザクション金額制限(transaction monetary value restrictio n)の確認者の実施の従来の技術のプロセスを図示するフロー・チャートである。 図７は、トランザクション連署要件(transaction cosignature requirement) の確認者の実施の従来の技術のプロセスを図示するフロー・チャートである。 図８は、トランザクション文書タイプ制限(transaction document-type restr iction)の確認者の実施のプロセスを図示するフロー・チャートである。 図９は、トランザクション地域的および時間的制御(transaction geographica l and temporal control)の確認者の実施のプロセスを図示するフロー・チャー トである。 図１０は、送信者の署名制限の最大年齢の確認者の実施のプロセスを図示する フロー・チャートである。 図１１は、あらかじめ承認されたカウンタパーティ制限の確認者およびスポン サ(sponsor)の実施のプロセスを図示するフロー・チャートである。 図１２は、トランザクション「確立」の要件("confirm-to"requirement)の確 認者の実施のプロセスを図示するフロー・チャートである。 図１３は、鍵制限(key confinement)および非復号化(decryption)の装置の証 明(certification)のプロセスを図示するフロー・チャートである。 図１４は、公開鍵を秘密に保ってシステム規則の署名を実施するプロセスを図 示するフロー・チャートである。 図１５は、トランザクションのユーザ規則を確認するプロセスを図示するフロ ー・チャートである。 発明の詳細な説明 以下の一般的な原理と哲学は、本発明で定義された署名確認モデルに反映され ている。第一に、ＣＡおよびユーザ証明は、それらが作成されたときの条件と仮 定を文書化した属性を含むことができる。確認者は、最小標準を満たさない証明 およびトランザクションのすべてを、単に拒絶してもよい。 また、属性証明は、ユーザの「スポンサ」によって署名することもでき、これ はトランザクションが属性によって言明された若しくは暗示された要件を満たす 場合に、そのスポンサの署名が公式のビジネスに対して与えられることを表わす ためである。典型的にはユーザのスポンサはユーザの雇用者であるが、モデルを 拡張してユーザの銀行、クレジット・カードの発行者、投票所、貸ビデオ屋、公 立図書館、若しくはユーザの署名を受け付けることができるいかなるエンティテ ィも含めることができる。このスポンサ（許可）証明は、このように、伝統的な 署名スタンプ(signature stamp)の関係で使用されるときは、「法的マークの宣 誓供述書(affidavit of legal mark)」の電子的な等価物となる。１９９３年７ 月２日の科学技術証明許可機関ワーク・グループのＡＢＡセクション(ABA Secti on of Science and Technology Certification Authority Work Group)、に表わ されているRobert Jueneman著「ディジタル署名の使用に関するＣＡおよび個人 の責任の制限(Limiting the Liability of CAs and Individuals Regarding the Use of Digital Signature)」を参照せよ。 さらに、産業界は、署名確認の最小要件を確立する「産業界の方針(industry policy）」声明(statement)を創り出してもよい。この場合、参加者はすべて、 全カウンタパーティがエンコードされた制限に拘束されることを保証するために 、これらの多角協定(multilateral agreements)に署名することになる。通常は 、スポンサ証明をすべての場合に要求すべきであり、そうでない場合はディジタ ル署名はそれがないときはヌル(null)でありボイド(void)であると解釈される。 産業界にわたる方針は、（１）関連する文書タイプおよびクラス、（２）署名者 の役割と肩書、および（３）標準の契約上の用語(term)と条件を参照によって一 部を構成するコード化されたシンボルも、定義することになる。 さらに、全制約がすべて自動化された方法（すなわち、「オン・サイト(on si ght)」確認）で、実施することができ、この際に紙による同意書や人間による解 釈は不要である、という原理を厳しく固守しなければならない。これはときには 「十分に機械化可能なストレートスルー(straight-through)処理」とも呼ばれる 。複雑、かつ/または高ボリュームの環境では、これらのセキュリティ・コント ロールの信頼性を会計監査や法律の専門家の目にも見えるようにするために、こ れが必要とされる。また、信頼されたサード・パーティへの参照は、確認(verif ication)遅延時間を削減するために、最小限にされるべきである。 これらの制限は複雑に見えるかもしれないが、これらは単に、機械による確認 の目的のために明示的にされた通常のビジネス手続きを反映したものにすぎない 。従来は、このような制御は、トランザクションを送信する前に、スポンサのコ ンピュータ・システム内で実施されていた。しかし、多角的な分散されたトラン ザクションの出現によって、確認を行うユーザは、典型的には、送信者のスポン サのシステムからはオフラインであり、そのため確認者はスポンサの許可モデル を、属性証明に反映されるものとして実施しなければならない。一度この方法論 が指定されれば、オフィス・ソフトウェアのベンダはユーザ属性の作成と管理を 行うメニュー駆動のシステムを開発するだろうし、ユーザ組織に対するコストは 比較的低くなるだろう。証明の組織的構造 証明自体は、スポンサの組織の構造を反映していてもよい。許可の決定の多く は、組織におけるユーザの地位、その組織の構造に基いており、そのユーザの地 位は、その中でそのユーザの名前の一部として指定してもよいからである。証明 の中の名前は、以下のように、Ｘ．５００ディレクトリ(Directory)・モデルの 用語で指定される。 Ｘ．５００ディレクトリ構造は、階層的である。結果としてできる分散データ ベースは、図４に示すように、ディレクトリ情報木(Directory Information Tre e)（ＤＩＴ）を含む。各エントリ４１は特定のオブジェクト・クラスに属し、属 性４２と呼ばれるプロパティの集合から成る。属性４２は、タイプ４３と１つ以 上の値４４から成る。したがって、クラス組織のエントリ内にある属性の１つは 、organizationNameである。クラスorganizationalPersonのエントリ内にある属 性は、titleとtelephoneNumberを含むことができる。 各エントリには、１つ以上の特別な属性値も含まれ、これはオブジェクトの名 前を構築するために使用される。この属性値はエントリの相対的に区別される名 前(relative distinguished name)(ＲＤＮ)である。オブジェクトの区別される 名前(distinguished name)（ＤＮ）４５は、ＤＩＴルートからそのエントリまで の全エントリの相対的に区別される名前４６を連結することによって生成される が、これは、グローバルなＤＩＴの中でそのオブジェクトを一意に識別する。 Ｘ．５００で定義されている属性にはユーザの属性証明内に含めると便利にな るものがある。例えば、オブジェクト・クラスは、その区別される名前が同じ形 式であるようなエンティティ（例えば、ユーザと役割）との間の区別をするため に使用することができる。また、タイトル(title)は、許可の決定をするときに 使用することができる。 組織上の線(organizational line)に沿ってエンティティをグループ化するた めにＤＩＴの使用することに加えて、Ｘ．５００ではエンティティの任意のグル ープを構築するために使用できるオブジェクト・クラスがいくつか定義されてい る。これらのオブジェクト・クラスには組織上の役割(organizatioal role)が含 まれるが、その「役割占有者(role occupant)」属性はその役割を占めるユー ザの名前をリストしており、および、その「メンバー(member)」属性がグループ ・メンバーの名前をリストしている名前のグループも含まれる。この情報を信頼 される方法で伝えるために、役割とグループの証明を定義することができるが、 これらはそれぞれ、役割占有者の名前とグループ・メンバーの名前を伝え、ＣＡ によって署名され、このようにして、Ｘ．５００ディレクトリ・システムとの関 係で外側にあるこの機能が使用できるようになる。 グループと役割の証明は、連署要件の構築を単純化するために、連署機構と組 み合わせて使用することができる。例えば、トランザクションは、３人の「購買 代理人(purchasing agent)」の役割の占有者の署名が必要となるかもしれない。 ユーザは、また、署名計算の中に、（署名者ごとの）署名属性として、その役割 を含めることによって、どの役割で自分が活動しているのか示すこともできる。 その後で、主張された役割は、役割証明（若しくはユーザの属性証明）に対して 、確認(verification)の際にマッチされてもよい。証明における対策情報 本発明の他の実施の形態は、ＣＡのセキュリティ対策に関する情報をＣＡおよ びそのサブスクライバ(subscriber)の属性証明にエンコードすることであり、こ の場合、署名の確認者は、署名を有効なものとして受け付けるか否かを決定する ために、この情報を用いることができる。一般に、ＣＡの証明は、証明の決定を しているときにＣＡが用いる規則を伝え、一方、ユーザの証明は、これらの規則 を適用するときにＣＡが使用する情報を伝える。 ＣＡ証明内の属性は、特定のＣＡのためのセキュリティ対策と保証情報(assur ance information)を示すことができる。この対策情報は、下位のＣＡに継承す ることもでき、こうすれば、共通の対策を共用するセキュリティ・ドメインを簡 単に構築できるようになる。ＣＡの証明の対策属性は、他にもあるが、以下を含 んでもよい。 （１）責任の限界(Liability Limitations)。ＣＡが様々な問題のイベント（ 例えば、ＣＡ鍵を危険にさらすこと(CA key compromise)、欠陥がある束縛(defe ctive binding))において責任を負う範囲。これは、責任なし、全責任、ま たは特定の金額(monetary amount)、とすることができる。 （２）信頼仕様(Trust Specification)。与えられたＣＡが証明(certify)でき るユーザとＣＡの記述であり、この記述は、ＣＡ自身（例えば、「下位(subordi nates)すべて」）に関して、または一般的にはＤＩＴ（例えば、「組織ＡＢＣの 下のサブツリー」）に関して、あるいは他の事項に関して表現されたものである 。 （３）要求された属性(Required Attribute)。ユーザの属性証明の中のそれら の属性であって、トランザクションを許可されたものと考えるためにトランザク ションおよび／またはそれに関して確認しなければならない属性のリスト。これ らの属性はスポンサの証明の中に見つかるかもしれず、これらの属性は、単一の 許可証明が複数のアプリケーションで使用するための許可属性を含むことができ る。提案されるユーザ・許可属性のいくつかについては、以降で定義する。 （４）許される名前形式(Allowable Name Forms)。ＣＡが証明するかもしれな い許される名前形式の仕様。この情報は、以下のものとして把握される。（ａ） 名前束縛(name binding)の集合。これは、与えられたオブジェクト・クラスの名 前エントリに使われる属性を定義する。（つまり、そのクラスのエントリに対す る許されるＲＤＮフォーマットとして）。および、（ｂ）構造規則の集合。これ はＤＩＴ内で互いに隣接（つまり、上位若しくは下位の）してもよいオブジェク ト・クラスを定義する。つまりこれは、完全ＤＮを形成するためにオブジェクト ・クラスが一緒にチェーン(chain)される順序である。この対策属性は、トラン ザクションに署名できるエンティティのタイプを制限するのに使用することがで きる。例えば、有線伝送(wire transfer)アプリケーションに対しては、署名の 能力を、その組織にはいっているユーザではなく、その組織自体に制限すること が望ましいかもしれない。ＤＥＳＭＡＣを使用する処理の現在のモードと同様だ からである。 （５）相互証明(cross-certificate)。効率の観点からは、証明経路(certific ation path)の長さを抑制するために、エンティティの証明ができるようにして 、組織としてそれぞれ他の組織を相互証明(cross-certify)できるようにするこ とが望ましい。一方、証明経路に任意の数の相互証明が含まれること は、望ましくない。というのは、他方の終端のエンティティ内の信頼のレベルを 決定することは難しいからである。多くの証明アーキテクチャでは、証明経路を 制限して、相互証明をただ１つだけ含むようにしている。より広い範囲の対策を 整理するために、属性は相互証明されているＣＡによって発行された相互証明の 使用を許す旨を相互証明者が明示的に表示する相互証明と関連付けられた属性証 明に追加してもよい。 ユーザまたはエンティティの属性証明内の属性は、そのエンティティに対して 証明を作成したときにＣＡによって確認された情報を表現することができる。ユ ーザの証明の対策属性は、ほかにもあるが、以下を含む。 （１）束縛情報(Binding Information)。公開鍵を証明されているエンティテ ィのＩＤ(identity)とバインドするために使用される基準(criteria)。これには 以下のものが含まれる。（ａ）配送の方法。例えば、人の中に表わすような方法 であって、許可されたエージェントによる、メール、若しくは他の方法によるも の。（ｂ）ＩＤ識別の方法。例えば、合理的な商業上の慣例による方法、信頼さ れたサード・パーティにより確認させる方法、デュアル・コントロール(dual co ntrol)、指紋(fingerprint)チェック、完全バックグラウンド調査、または他の 方法。（ｃ）ＣＡに提示されるＩＤ識別文書。および、（ｄ）主題(subject)の エンティティ・タイプ。つまり、個人、会社、装置、またはそのほか。 （２）信頼されたサード・パーティ。束縛過程において含まれた任意の信頼さ れたサード・パーティ若しくはエージェントの名前。 （３）役割。許可の目的に対して、どの役割（その組織の内部と外部の双方） をユーザが行使してもよいかを示すことが便利なこともある。これは、役割証明 と対照的であり、役割に対して発行され、全占有者の名前を含む。 （４）相対的ＩＤ(Relative Identity)。ＣＡが、個人のDNの一部のみを証明 したいことがあるかもしれない。特に、法律上の代理の原理(legal Agencyprinc iple)の下では、個人の署名はいかなるイベントにおいてもそれらの組織のスポ ンサ上に束縛されるので、ＣＡは、個人のパーソナル名の正しさに対する責任を 拒否することがある。以下の名前を考えよう。 C=US; O=Bankers Trust; OU=Global Electronic Commerce; CN=Frank Sudia; TI=VP ＣＡは、個人の区別される名前のうち組織、組織ユニットおよびタイトル部分 のみを証明するかもしれず、それらはすべて容易に確認できるが、一方、個人名 は「正確であると信じることが合理的」であるとだけされるかもしれない。誤っ たＩＤ確認用紙を取得することの相対的な容易性の観点からは、これによれば、 法外に高価なバックグラウンド調査の必要性が避けられる。このようなＩＤ識別 は、例えば遺言や相続に関する手続においてではなく、通常の商業的セッティン グにおいては、信頼することができる。 （５）絶対的ＩＤ(Absolute Identity)。ユーザのＩＤであってその組織的な スポンサに対して「相対的」なものとして相対的ＩＤ(relative identity)を定 義することができる。他の方法では、我々は、ユーザの「ビジネス・カードのＩ Ｄ」の全要素を、その個人名を除いて証明する。特別な場合として、いくつかの ＣＡが選択されたユーザの絶対的ＩＤの証明を請け負うかもしれない。選択され たユーザは、例えば、裕福なクライアントの子供、外交官、国家安全官(nationa l security operative)などであり、これらのユーザは、生物測定学(biometric) 技術によってほとんど確実に支持(bolster)される。しかし、これは稀な場合で あり、これを紹介したのは、完全性のためだけであり、「相対的ＩＤ」の概念の 仕上げをするためである。証明における許可情報 属性は、署名が有効である下での条件を制御する制限を伝えてもよい。仮にこ のような制限がないとすると、偽造のリスクが極めて高くなると考えられるであ ろう。というのは、電子署名は、ユーザのスマート・カードおよびパーソナル識 別番号(personal identification number)（ＰＩＮ）を所有するいかなる人によ ってもほとんどいかなるディジタル文書に添付されうるからである。電子環境で は、文書作成および物理的配送の通常のコンテキストのコントロールは、弱いか 存在しないかのいずれかである。 認証された(authentic)ユーザは、フリー・フォームのオフライン・コミット メントを引き受けることができるほど信頼されていることはほとんどない。した がって、組織は、特別な署名許可の範囲を積極的に制限する能力を歓迎するであ ろう。このような許可属性は、標準Ｘ．５００属性に加えて、トランザクション の限界(Transaction Limit)、連署の要件(Cosignature Requirement)、文書タイ プ(Document Type)、主題の制限(subject matter restrictions)、許可された署 名者(Authorized Signatories)、地域的および時間的制御(Geographical and Te mporal Controls)、署名の年齢(Age of Signature)、あらかじめ承認されたカウ ンタパーティ(Pre-approved Counterparty)、委任制御(Delegation Controls)、 確立の要件(Confirm-To Requirement)を含んでもよい。これらの属性は、署名者 の組織のスポンサによって若しくはその組織のために活動する外部のＣＡによっ て署名された１つ以上の許可証明にエンコードすることができる。許可証明とこ れに関連するトランザクションの一例は、図５に示されている。 受信者ユーザ（確認者）がトランザクション５１を送信者ユーザから受信する ときは、受信者はまず送信者の基本鍵証明５５を使用してトランザクション５１ 上の送信者の署名５２を確認する。以下にさらなる詳細を記述する通りであるが 、受信者は、送信者のスポンサ５９によって署名された送信者の許可証明５６を 使用して、トランザクション５１に追加された連署５３とタイムスタンプ公証(n otarization)５４を確認して、トランザクション５１の属性値５７が許可証明５ ６内に指定された許可された属性値５８の範囲に入ることを確認するためであ る。 ユーザは、トランザクションの限界であって、そのユーザが始めることができ るトランザクション若しくはほかの文書の値を制御するトランザクションの限界 に従うこともできる。そのユーザの署名は、ある金額の限界まで若しくは２つの 金額の境界の間にあるとして始められたトランザクションについてのみ有効とな る。それゆえ、図６に示すように、送信者ユーザは送信者によって（実際にはユ ーザの秘密鍵を含む、ユーザのスマート・カード６００によって）署名６０３さ れたトランザクション６０１を送信し、そこへ許可証明６０４を追加する。確認 者は許可証明６０４を使用してユーザの署名６０３を確認６０７し、トランザク ションの金額６０２が許可証明６０４内のトランザクションの限界属性値６０５ の範囲に入ることを確認するためである。確認者はまた、許可証明６０４上のス ポンサの署名６０６を、スポンサの公開鍵６１０を使用して、確認６０９する。 これらの署名および属性値のいずれかが確認しない場合は、トランザクションは 拒絶６１１される。確認が完全である場合は、トランザクションは受け付け６１ ２られる。 連署の要件を考慮すると、与えられた署名が有効と考えられるために、追加的 な署名が必要とされることがある。定足数(quorum)と重み付け(weighting)機構 は、各ユーザの信頼のレベルの明示的な管理のためにかなり複雑なチェックとバ ランスを構築することができる。必要とされる署名の特定の列若しくは順序も指 定することができる。図７を参照すれば、送信者側ユーザＡは、自身のスマート カード７００によって署名７０３されたトランザクション７０２を送信し、もし ユーザＢの連署がトランザクション７０２の上で必要とされる場合には、ユーザ Ｂのスマートカード７０１によって署名７０４される。送信者側ユーザＡはまた 、自分の許可証明７０５をトランザクション７０２に追加する。確認者は許可証 明７０５使用してユーザＡの署名７０３を確認７１１して、スポンサの公開鍵７ １３を使用して許可証明７０５の上のスポンサの署名７０７を確認７１２する。 いずれの署名も確認しない場合は、トランザクションは拒絶７２０される。連署 値７０６が許可証明７０５によって必要とされる７１４場合は、受信者はトラン ザクション７０２上の共同署名者(cosigner)ユーザＢの署名７０４を確認 ７１５することによって要件を実施しようとし、その後、証明の発行者の署名７ ０９を、発行者の公開鍵７１７を使用して、確認７１６することにより共同署名 者ユーザＢの公開鍵証明をチェックする。ユーザＢかＢの証明の発行者のいずれ かの署名が確認しない場合は、トランザクションは拒絶７２２される。 連署を使用すると、組織は効率的にチェックとバランスを定義でき、明示的に ユーザの信頼のレベルを指定できる。連署を使用すると、また、スマートカード やＰＩＮの盗難、誤用、入れ間違いによる秘密鍵を不慮の危険にさらすことに起 因するリスクがきわめて減少する。特に、連署、値の限界、および、関連するコ ントロールを要求する能力によって、組織は注意深く署名の許可をすべて管理し ファインチューン(finetune)できるようになり、それゆえに、これらのリスクを 管理し制限するために必要なツールをすべて与えることになる。連署を使用すれ ば、さらに、複数の場所とハードウェア・プラットフォーム上に許可機能を分散 できるようになり、その結果として、これらのプラットフォームの１つの上でア クセス・コントロールに失敗したことに起因するリスクを最小化できる。米国特 許番号第４，８６８，８７７号、第５，００５，２００号、および第５，２１４ ，７０２号を参照せよ。 許可署名は、署名者の証明内に指定された制限を満たさなければならないもの であるが、署名属性として署名目的を含めることにより、および、署名目的の表 示を署名されているデータに含めることを要求することにより、ほかの連署から 区別することもできる。署名目的(signature-purpose)属性は、以下の値を必要 とすることができる。（ａ）その文書に適切な許可署名。（ｂ）その文書に適切 な許可連署署名、ただし、共同署名者の証明はその文書を許可するのに十分なオ ーソリティを持っている。（ｃ）証人(witness)連署、ただし、共同署名者の証 明はそれ自体ではその文書を許可するのに十分なオーソリティを持っていない。 データ交換標準協会(Data Interchange Standards Association(ＤＩＳＡ))発 行のドラフトＡＮＳＩ標準X12.58第２版（付録）で説明されている署名目的エン コーディングは当業界で周知であり、参照することにより本明細書の一部を構成 する。 また、ユーザは、特定の文書タイプ、例えば通常の通信(correspondence)、購 買申込、指定されたＥＤＩトランザクション・タイプ、ビジネス契約、指定され た金融手段など、全産業的な対策によって定義されたものにのみ署名するように 制限することもできる。効率のためある大きなトランザクションと文書のクラス を排除することが所望であることもある。図８を参照すると、受信者は送信者の トランザクション８０１内の文書タイプ制限を実施するが、これは、まずそのト ランザクション上の送信者の署名８０３を確認８０７し、その後トランザクショ ン８０１内の文書タイプ属性値８０２を確認８０８することによって行う。これ は、送信者の許可証明８０４内の文書タイプ制限８０５を実施するためである。 受信者は、その後、スポンサの署名８０６を確認８０９するためにスポンサの公 開鍵８１１を使用して、許可証明８０４を確認する。署名か属性制限のいずれか 一方が確認されない場合は、トランザクションは拒絶８１０される。 また、トランザクションの主題やコンテキスト・クラスに関連する積極的若し くは消極的制限を追加することが所望であることもある。例えば、エージェント をあるクラスの商品（たとえば、オフィス用品）の購買申込の署名に制限したり 、例えば、エージェントのポルノグラフィー商品の購買能力を否定する場合など 、オーソリティを否定したりすることである。主題の制限は、文書タイプ制限と 同様の方法で、トランザクションの受信者によって実施され、より汎用の文書タ イプに対する分離した仕様を必要としつつも、多くの文書タイプ内に暗示的にい れておくこともできる。 組織は特定の許可された署名者が存在すること、つまり、ある特定の個人のみ がその組織の「ために署名」できることを表示することもでき、これは、この効 果に対する標準的な「共同解決(corporate resolution)」と同様である。これは 、文書タイプの概念を、「共同(corporate)」文書タイプの署名を付加的に制御 するものとして、補完するものである。この制限は、連署が必要とされ、この場 合に共同署名者のタイトル（その区別できる名前）が許可証明内に含まれる指定 されたリストの上の一つと同じでなければならない、ということを指定すること によって実装できる。これは、１つ以上の必要とされる共同署名者のリストをネ ーミングするかわりである。 地域的および時間的な制御には、トランザクションが有効と考えられる場所と 期間が含まれる。ローカルに信頼される「タイムスタンプ・ノータリ(timestamp notary)」の使用が仮定される。このようなノータリは、信頼されるタイムスタ ンプを文書の上の発送者の署名に追加して、その後、その結果に署名するもので ある。このように、時刻および何曜日の制限は、通常は、ユーザの現地の週間労 働時間(work-week)と一致するものである。また、場所の情報は、特定のネット ワーク・セグメントへ、典型的にはユーザが割り当てられたワーク・エリアへ、 アクセスを制限するために、ノータリと関連付けられる。場所のコントロールの 「粒度(granularity)」は、ネットワーク・アーキテクチャに依存するものであ る。署名者若しくは署名者のコンピュータ・システムは証明されたタイムスタン プを指定されたローカル・サーバからそのトランザクションへ付加しなければな らない。さもなければ、確認者はそのトランザクションを受け付けることができ ず、署名者のスポンサはそれにより束縛されない。図９に示す通り、送信者側ユ ーザは、トランザクション９０１へ、通常通り、許可証明９０２、許可されたタ イムスタンプ９０３およびタイム・サーバ証明９０４を付加する。受信者は、ト ランザクション９０１の上の送信者の署名９０５を確認９２１し、許可証明９０ ２の上のスポンサの署名９０８を確認９２２する。その後受信者は、（１）タイ ムスタンプ・トランザクション・テキスト・ハッシュ９０９が既知のハッシュ関 数でハッシュされたトランザクション９０１のテキストの結果とマッチすること を確認９２３し、（２）トランザクション・タイムスタンプ９０３の時刻と日付 ９１０が許可証明９０２に指定された許可された時刻と日付９０６属性の範囲に 入ることを確認９２４し、（３）タイムスタンプ９０３上のタイム・サーバ署名 ９１１を確認９２５し、（４）タイム・サーバ・証明の上のスポンサの署名９１ ２を確認９２６する。これらの条件がすべて満たされる場合は、トランザクショ ンは受け付け９３１られる。そうでない場合は、トランザクションは拒絶９３０ される。 さらに、文書は、その署名がある指定された期間に確認されていない場合は有 効でないとすることもできる。高価なトランザクションに対しては、この署 名の年齢属性期間は非常に短いものである一方、より普通のトランザクションに 対しては、特にＸ．４００のようなストア・アンド・フォワード(store-and-for ward)システム経由で送信されたトランザクションに対しては、より長い間隔（ たとえば２日間）が適切であろう。図１０は、署名の年齢属性値の受信者によっ て実施されることを示す。確認の時刻は、レシート１０３であって、信頼される タイムスタンプ・サービス１０４によって署名されたものであり、少くとも元の トランザクションからの受信者の名前と署名を含むもの、を使用して提供される 。確認者は、元の署名にタイムスタンプを付けたコピーであって、元のトランザ クションの時刻と日付のすぐ後の日付を付けたものを発信(submit)しなければな らない。さもなくば、スポンサはこれを拒絶するだろう。図１０に示す通り、受 信者（確認者）１２１は、トランザクション１０１０の上の送信者の署名１０７ を確認１２１し、許可証明１０２上のスポンサの署名１１５を確認する。その後 、受信者は、トランザクション１０１の上の日付１０５と時刻１０６と、タイム スタンプ１０３の上の日付１１１と時刻１１２との間の差が、許可証明１０２の 中の署名の年齢属性の制限１０８の範囲内にあることを、確認１２２する。また 、受信者は、信頼されたタイムスタンプ１０３の範囲の中のトランザクション１ ０１のハッシュ１１０が、トランザクション１０１のテキストにマッチすること を、確認１２３する。これらの条件すべてが満たされる場合は、そのトランザク ションは受け付け１３０られる。そうでない場合は、そのトランザクションは拒 絶１３１される。 同様の概念は、署名の最小年齢(minimum age)の概念である。この場合、署名 は、それが署名された後ある最小時間が過ぎるまで有効とはならない。これによ って、なくした旨の通知があったスマートカードや、受信者に同報通信(broadca st)された廃止(revocation)のお知らせを考慮に入れることができる。コントロ ール属性は、署名の最大および／または最小年齢を指定することができる。 「あらかじめ承認されたカウンタパーティ」属性値は、既知の信頼できるパー トナーのある指定された集合のみと取引をするためのエンティティを制限する。 これは、ダイアルアップ・ホーム銀行(dial-up home banking)システムにおいて は共通の要件であり、これでは、典型的には、許可された受取人(payee)のすべ てがあらかじめ指定されている必要がある。これを言明する他の方法は、「フリ ー・フォーム伝送(free-form transfer)」を禁止することである。スポンサは、 エラーの場合には、小さなよくわからない許可されていないパーティと取引する ときよりも、大きな支払能力のある信用できるパーティと取引するときに、エラ ーをうまく取り消すよい機会にあることがよくわかる。分離している証明は各カ ウンタパーティに対して発行できるが、これは、競業者が単一の証明内のユーザ の顧客リスト（自分自身ではなく）を取得してしまうことを防止するためである 。承認されたカウンタパーティは、共通の名前(common name)、区別される名前 、証明番号、または、区別される名前若しくはカウンタパーティの公開鍵のいず れかのハッシュ値として、コード化することができる。トランザクションの利益 を請求するために、確認者は、エンコードされたカウンタパーティ値にマッチす る証明を発信しなければならない。 図１１は、受信者による受信よりも後のユーザのトランザクションのユーザの スポンサによる確認を示す。受信者（カウンタパーティ）は、トランザクション １１０１の上のユーザの署名１１０３を確認１１１０し、許可証明１１０２の上 のスポンサの署名１１０５を確認１１１１する。これらの署名のいずれかが確認 しない場合、トランザクション１１０１は拒絶１１１２される。署名が確認し、 トランザクションが受信者によって受け付けられた１１１３場合、受信者は、ト ランザクション１１０１に裏書(endorse)するが、これは、自分の確認されたト ランザクション１１１４を発行することにより行い、その際に、元のユーザ・ト ランザクション１１０１と送信者のユーザの署名１１０３のテキストに副署(cou nter-sign)１１１６し、また、受信者の証明１１１５をアタッチする。あらかじ め承認されたカウンタパーティの制限を送信者側ユーザの許可証明１１０２の中 で実施する場合、送信者側ユーザのスポンサは、送信者側ユーザの署名１１０３ を確認１１２１するが、これは受信者の確認されたトランザクション１１１４に 含まれているものであり、そこで、受信者の署名１１１６を確認１１２２する。 これらの署名が確認された場合は、スポンサは次に、受信者の公開鍵１１１７を ハッシュしてその結果をユーザの許可証明１１０２に指定された 許可されたカウンタパーティ公開鍵ハッシュ値１１０４の１つに対してチェック して、カウンタパーティの公開鍵ハッシュ値を確認１１２３する（スポンサが確 認のためにハッシュする受信者の公開鍵１１１７は、そのスポンサが受信者の証 明を確認するときに、それ自身確認１１２４される）。これらの条件が満たされ る場合は、トランザクションは受け付け１１２５られる。 委任の制御の属性値は、属性証明を発行するときにＣＡが指定できる許可のタ イプと値の範囲を制限できる。これらはまた、ユーザが自分の署名オーソリティ を他の人に委任できる範囲と深さを制限するためにも働く。例えば、ルートＣＡ は、組織のＣＡを、そのエンド・ユーザの文書が州税の管理(state tax adminis tration)に関連する文書の範囲に入るユーザに対して文書への署名を許す許可の 発行のみに制限する。あるいは、ＣＡは、アシスタント会計係若しくはその上司 の階級にある他の人に対してのみ、３０日を超えない期間、さらに副委任(subde legate)する権利がない状態で、委任することができる準備ができているユーザ に対するオーソリティを許可する場合もある。 他の許可属性に、「確立要件(confirm-to requirement)」値と呼ばれるものが あるが、これは、以下の状況でない場合は、署名が有効とされないようにする。 確認者が確認しされたトランザクションのコピーを、指定されたメールやネット ワークのアドレスにあるサード・パーティに、典型的には、そのユーザの組織の スポンサや作業スーパバイザに送る状況であって、（ａ）受付／拒絶メッセージ を受信するか、（ｂ）指定された時間が経過するかのいずれかの状況である。 この要件は、連署と同様であるが、トランザクションが送られる前ではなく後 に発生する。このような事実の後の(after-the-fact)確認は、わずかな数のトラ ンザクションしか拒絶されず、あらかじめサード・パーティの連署を取得すると 過度に重荷となるかもしれないような、リスクの低い状況では、受け入れうるも のである。あるいは、これは、積極的なオンライン・チェックが要求されるよう な高い金額を扱う(high-value)な場合に好ましいかもしれない。その場合、フロ ー・パターン(flow pattern)は、オフラインではなくオンライン・システムに向 かって戻ることになる。図１２に示すように、受信者は、まず、通常、トランザ クション１２０１の上の送信者の署名１２０３を確認１２１１し、ユー ザ・許可証明１２０２の上のスポンサの署名１２０５を確認１２１２する。これ らの署名の一方が確認者されない場合は、トランザクション１２０１は拒絶１２ １３される。これらの署名が確認された場合は、受信者は、元のトランザクショ ン１２０１（トランザクション・テキスト１２０２と送信者側ユーザの署名１２ ０３）からなる確認メッセージを、ユーザのスポンサ１２１５に、送信者の許可 証明１２０２に指定１２１４されたように、送信する。受信者は、スポンサ１２ １５から、確認１２１６の返事として、スポンサによって署名１２０５されては いるが、同じメッセージ受け取る。受信者は、その後、スポンサの署名１２２０ および確認メッセージ１２１６を確認１２１７し、トランザクション１２０１を 受付１２１９ける。 複雑な制限の組合せを生成するため、１つ以上の属性を含むブーリアン(Boole an)若しくは論理式であるフィルター式を用いれば、複数の属性を含む制限を構 築できる。属性宣言(attribute assertion)は、通常のブーリアン関数結合子、 つまり「かつ(and)」「または(or)」「否定(not)」を用いて、リンクされる。例 えば、スポンサは、ユーザを、タイプが「購買申込」に等しく、かつ、価格が１ ００，０００ドル未満であるようなトランザクションの発信に制限することもで きる。宣言は、単一の属性値（等しい、未満、を超える、など）、複数の属性の 値（サブセット、スーパーセット、など）、若しくはその文書に属性が存在する ことや存在しないこと、を含むことができる。もちろん、どのような記載された 制限も、若しくはそれらの制限のいずれも、他と同様、同じ文書若しくはトラン ザクションに対して同時に効力を持ちうるものであることが認められる。これら の制限については、明らかにするために、別々に説明し、図示した。 許可属性の使用は、受信者は許可のみならず認証(authenticatoin)も確認でき るようになる。このシナリオでは、スポンサ証明は、スポンサしている組織の証 明によって結び付けられ、指定された制限がすべて満たされる場合に、それらが 適用されるトランザクションを「オン・サイト(on sight)」で許可するものとし て解釈される。 基本対策の集合を、金融サービス産業若しくは他の産業を通じた使用のために 定義して、確認プロセスに対するサービスのレベルであって、うまく定義されて いて予測できるものを提供できるようにしなければならない。これらの対策は、 多角的な基礎の上で、各参加会社により合意されるものであって、本節で説明し たある制限および許可がはっきりと他の手段で提供されない限り、常に有効であ ると解釈される旨を規定することがある。これらの産業上の合意のより重要な要 素の１つは、文書タイプの定義とコーディングであろう。これは、産業ごととい う原則でなされなければならない。例えば、税関の検査官(customs inspectors) 、航空機の検査官(aircraft inspectors)、会計監査人、徴税吏(tax official) などに対して、規則は明らかに異なるからである。 ある許可属性は、それ自体、文書の特定の内容に関係することがある。これは 、自動化された機械確認に対しては、問題を提出することがある。確認者のコン ピュータは、与えられた文書やトランザクションに対するこのような属性の値を 常に決定できるとは限らないからである。例えば、金銭的トランザクションの限 界、文書タイプ、およびセキュリティ若しくは機密性のラベルが含まれる。この ため、標準データ・ブロックを、好ましくは文書またはトランザクションの先頭 に、例えば、言明する金銭的トランザクション値、文書タイプ、若しくはセキュ リティ・センシティビティ・ラベル(security sensitivity label)などの属性を 明確にエンコードして、提供することが望ましい。この文書タグは、署名者のコ ンピュータによって、確認者の便宜のため、および、確認過程の助けとして、付 加されることになろう。しかし、タグと文書の実際の内容との間に矛盾が存在す るというイベントでは、文書の文言が制御することになる。例えばＥＤＩトラン ザクションのような、構造化されたトランザクションでは、文書タイプと金銭的 な値はすでに完全に機械可読となっており、文書タグは必要とされない。 単純な許可の処理、特に、与えられたユーザが多くの同様のトランザクション に署名する場合を、できるだけ便利にするものとして、ユーザの公開鍵をその基 本認証証明からコピーして、これを他の属性として許可証明の中に含めると、便 利であることがしばしばある。これによって、許可証明は２つの目的（認証と許 可）のために働くことができるようになり、送信者は、基本認証証明を各トラン ザクションから除外することができるようになる。さらに、装置が与えられた条 件を満たしていると信頼できる状況では、ユーザの装置公開鍵を認証若しくは許 可証明にコピーして、さらに各トランザクションとともに装置証明を送信する必 要を大幅になくせば、同様に利益があるだろう。サード・パーティ対話(interaction) さらに、ディジタル署名の役に立つ機能であって、属性証明を使用して提供さ れうる機能を超えるものには、署名者と様々なタイプのサード・パーティとの間 の対話が含まれる。 ディジタル署名のこのような使用方法の１つは、電子ノータリゼーション(not arization)である。前述した通り、正確なタイムスタンプおよび／または場所の 情報を提供するために、信頼されたサード・パーティを使用して、文書に共同署 名する必要があることがある。署名の作成者がこの情報を正確な形で提供してい ると単純に信用するのでは、署名は、これらに基づく偽物、例えば、文書の日付 を前に変更(pre-dating)したり日付を後に変更(post-dating)したりすることに 対して無防備なままになってしまう。電子的な「ノータリ(notary)」は、この情 報を正確に提供するそのＣＡの対策によって信頼されるようになる。既に仮定し た複数の署名機能を拡張して、このサービスに対する枠組を提供することができ る。 ノータリゼーションの目的のため、タイムスタンプと場所の情報は、署名属性 として含められることになる。個々の署名構造は、分離されて格納されるか、若 しくは、望む場合には、文書と分離して伝えられるかのいずれかとしてもよい。 文書自体の上の複数の署名若しくはジョイント署名は、「カウンターシグネチ ャ(countersignatures)」から区別することもできる。カウンターシグネチャと は、署名構造の上の署名であって、その署名構造の中には見つかるがドキュメン ト自体の上には見つからない署名をいう。このように、カウンターシグネチャは 、署名が加えられた順序の証明を提供する。カウンターシグネチャ自体も署名構 造なので、それ自体にカウンターシグネチャを含むことができる。こ れによって、カウンターシグネチャの任意の長さのチェーンが構築できるように なる。そして、電子ノータリゼーションは、作成者の署名をカウンター署名(cou ntersign)ることと、署名される情報の中にタイムスタンプを含めることからな る。大変リスクの高いアプリケーションに対しては、各証明に対して１つ以上の ＣＡによる複数の署名を要求し、その際に、署名が独立した暗号機能において異 なる秘密鍵と共に実行されるようにすることも望ましい。 サービスの様々なレベルが、署名の前に実行されるデータ・確認のレベル（単 に文書に存在するだけであってノータリゼーションが完全に自動的であるような 場合から、文書の内容の人間による確認までに及ぶ）に基づく電子ノータリに対 して定義できる。 ディジタル署名の他の使用方法は、委任若しくは「代理権(power of attorney )証明のためのものである。ユーザは、休暇を過ごすときに、自分の装置やスマ ートカードを他の人、例えば秘書や共同労働者(co-worker)に託したくなること がしばしばあるので、このようなしばしば発生する状況では、あるユーザが別の ユーザのスマートカードやＰＩＮを取得することになり、スマートカードが誤用 される可能性があるという危険に曝されることになる。したがって、システムは 、委任によって自分のスマートカードの署名を委任するユーザのオーソリティに 関連付けることができるような、代理権証明の発行が容易にできるようにしてあ る。代理権証明には、少なくとも委任者の名前、委任の公開鍵証明、および、短 い有効期限の識別が含まれ、委任者によって署名される。他の可能性は、委任に よって新しい鍵のペアを排他的に生成して、委任者の署名とともに使用し、新し い公開鍵を代理権証明に含めることである。これは、委任の秘密鍵の使用が、委 任者に代わってか、それとも委任者自身のためか、といういかなる潜在的な混乱 も除去する。 スマート・カードを引き渡すことによる問題は、個人実施義務の原理(princip le of individual accountability)を維持する実行可能な代替方法を提供するこ とによって、大幅に削減できる。この機能を広く実装すれば、スマートカード・ ローンの不認可が現実となるだろう。これは大変望ましいゴールである。 上述した委任証明の使用は、そのユーザがＣＡとして行動していることを暗示 する。場合によっては、特にトランザクションが組織の境界を超える場合には、 個々のユーザの暗号装置（例えば、スマートカード）で利用可能な制御と会計監 査のレベルが十分でないと心配するかもしれない。このような場合には、委任証 明は、委任者の要求に基いて通常の許可証明としてＣＡによって発行することが できる。また、これによって、委任証明を標準ＣＲＴ機構を使用して無効(revok e)にできるようになる。それから、ユーザの証明は、あり得る委任のリストを示 すことができ、委任証明自体には、委任者をネーミングする属性が含まれること になる。 代理権を行使する際に、ユーザは、自分が他のユーザのために署名しているこ とを、文書若しくはトランザクションの中に「のために署名(signing-for)」署 名属性を、すなわち、署名がされるユーザの名前を含めることによって表示する ことができる。そのユーザのために署名するために行動している署名者を許可す る有効な委任証明が存在しなければならない。また、委任は、ユーザのパーソナ ル・コンピュータ内の暗号モジュールと組み合わせると役に立つ。文書のハッシ ュと署名は、ソフトウェア・ハッキング(hacking)によって虚偽のハッシュに置 換されるのを防ぐため、理想的には単一の処理とすべきである。１つの解決方法 は、数分間しか有効でない大変寿命の短い委任証明を使用して、スマートカード がこの機能を暗号モジュールに委任できるようにすることである。この証明は、 ユーザのスマート・カードによって署名され、スマート・カードのユーザが委任 を認めたことを表示する。例えば、Gasser，M.，A．Goldstein，C．Kaufmanおよ びB．Lampson著、「ディジタル分散システム・セキュリティ・アーキテクチャ(T he Digital Distributed System Security Architecture)」、Proceedings of t he 12th National Computer Security Conference(１９８９年)や、Gasser，M. およびE．McDermott著、「分散システムにおける実用的委任のアーキテクチャ(A n Architecture for Practical Delegation in a Distributed System)」、Proc eedings of the 1990 IEEE Symposium on Security and Privacyを、参照せよ。非公開(non-public)の公開鍵 しかし、より基本的な問題は、すべてのありうる受信者が実際に、上述したよ うな証明の、および、属性の確認の方法を使用することを保証することである。 これらの方法によれば、スポンサしている組織がその組織自体、その組織のユー ザ、および、その組織がトランザクト(transact)するユーザに、偽造されたトラ ンザクションに基いた責任を負わせることを防ぐことができる。これは、これら の組織がトランザクトするユーザのＩＤと資格(qualifications)、および、トラ ンザクトする前にそのトランザクションの特徴を確認できるようにすることによ って行う。だが、受信者がすべて実際にそのように確認していることは保証でき ない。受信者が最初に送信者とトランザクションの両方の属性を確認せずにトラ ンザクションの上で動作する場合、および、送信者が後で不正な若しくは許可さ れていないトランザクションを送信したことがわかった場合は、その後で受信者 は、そのユーザの基本署名の許可確認に対するいかなる必要にも気付いていなか った旨を主張することによって、送信者若しくはそのスポンサからの責任を主張 することができる。スポンサおよびそのほかのエンティティがそのような状況に おける責任から保護されていることを保証するための１つの方法は、送信者がそ のＩＤとオーソリティ証明の各々のハッシュ値をその署名の中の属性として含め るよう要求することである。これによって、確認者がそのような証明やそれらが 課している制限に気付かなかったことを主張しないようにすることができる。し かし、署名者は、（故意に若しくは無意識に）これをしないことがある。他のよ り強調したい方法であって、確認者・コンプライアンス(verifier compliance) を保証するための方法は、ルート鍵、究極のオーソリティの公開鍵、つまり、オ ーソリティを証明する最高レベルの公開鍵であって、その鍵を、自称(would-be) 確認者が、トランザクションのいかなる部分も確認するために必要とするような 鍵が、ユーザが暗号システムと契約してあらかじめ確定した規則にしたがって全 パーティおよび全トランザクションを確認することに合意していない限り、その ユーザ（若しくはユーザの装置やスマートカード）に配送されるのを防止するこ とである。この方法では、そのユーザは技術的にはトランザクションの全パート を確認しなくともよい。しかし、それらのトランザクションを 十分に確認しないと、そのユーザと暗号システムとの間の契約が破壊され、それ によって暗号システムに対するほかのすべてのパーティ、例えばオーソリティが ないままその従業者が作業しているスポンサの、責任を解除することになる。し たがって、確認をしない受信者は、このような確認されていないトランザクショ ンのリスクを自分自身ですべて負うことになる。さらに、システム・オーソリテ ィのルート鍵は、企業秘密と考えられるので、システム規則合意に署名していな い者はそのコピーを所有することはできず、そのトランザクションのいなかる部 分も確認してあると主張することはできない。このようにすると、「外部」確認 者が、そのトランザクションを「合理的に信頼」することによって損失を被る旨 を、それが実際には有効である場合でも、主張することが極めて難しくなる。シ ステム・ルート鍵を企業秘密のままにしておくという技術によって、ここで説明 した制限および許可の方法のすべてに対してある力および効率が加えられる。価 値のあるトランザクションに対する潜在的に大きな貴任を負う可能性は、ユーザ が、本発明の属性確認の方法を使用するようさせる。証明配送(distribution)に対する制限 ユーザおよび組織は、いくつかの理由により、証明のすべてのタイプの配送を 制限できなければならない。まず、証明は機密のビジネス情報であって、ユーザ 若しくは組織が他者と共有しないことを好み、それにもかかわらず、たとえ署名 確認の限られた目的のためだけであっても確認者と証明を通じて共用されている 情報を含むことがしばしばある。また、ユーザの基本プライバシー権が、その公 開鍵およびネットワーク・アドレスが発表(publish)されることにより冒される かもしれない。例えば、一度ユーザの公開鍵が広められてしまえば、求めていな いビジネスの提案および広告によってあふれてしまうかもしれない。さらに、組 織は、ユーザ識別番号および公開鍵を割り当てることに対する一般的な対策を持 っているかもしれない。これらは、様々な種類のセキュリティに対する攻撃のス タート地点として使用されうるからである。 この機能は、ユーザの証明の属性として実装することができる。「配送制限(d istribute-restriction)」属性が真(TRUE)の場合は、ユーザ/発行者は、その 証明（これはオーソリティ若しくは公開鍵証明とすることもできる）を、署名確 認のためだけに使用する許可を与える。配送やさらなる発表は禁止される。この 制限を指定するほかの方法には、属性を組織の証明に配置すること、制限を産業 特有の対策の一部として発表すること、若しくは、（本当のＸ．５００実装にお ける）Ｘ．５００アクセス制御リスト機構を使用して証明に対するアクセスを制 限することなどがある。この制限を実施するための既存の一般的、法的な基礎は 、著作権法に見つけることができる。つまり、証明が発表されていない著作(wor k)として宣言されており、その著作に対するライセンスがネーミングされた(nam ed)確認者に対してのみ与えられている場合には、より堅固な法的基礎がなお求 められよう。スマートカードの要件 商業的なディジタル署名システムと使用される場合には、ほかにもいくつかス マートカード上の要件がある。 まず第１の要件は、秘密鍵の制限(confinement)と自己証明(self-certificati on)である。つまり、ユーザの秘密署名鍵(private signature key)がスマートカ ードから分離されることを絶対に認めてはならない。鍵の盗難を純粋に電気的な 方法を通じて何ら証拠を残さずに達成できないことを保証できるのは、この方法 によってのみである。この秘密鍵の制限の原則は、非否認性(non-repudiation) の概念に不可欠のものである。 このように、図１３に示される通り、証明された公開鍵１３０３が提供される ときには、カード１３０１は、そのカード１３０１がタンパープルーフ(tamperp roof)であって、鍵の制限の設計(key confining design)を持っていることを証 明しなければならない。証明は、「装置証明」１３０２であって、そのカードが 特定の製造業者若しくは生産ラインから始まっていることを言明している証明を 通じて提供することができる。その後で、装置１３０１の公開鍵１３０８は、製 造業者によって、若しくは、製造業者によって示されたＣＡによって証明されな ければならない。この装置証明を作成することに対する一つの有望なアプローチ は、スマートカードの組み立て時に装置鍵ペアを生成して対応する装置証明１３ ０２もカードの上に含まれるようにすることである。装置証明１３０２はカード のプロパティ１３０４を証明し、カードは、鍵のペア１３０３，１３０９であっ て、カードのユーザによって使用されユーザがいかなる適切な所望のＣＡによっ て自分自身のものであると証明させることができるペアを、生成する。このよう に、新しく生成された公開鍵１３０３を証明のために発信するときは、装置秘密 署名鍵１３０５は、証明要求データ１３０７に副署１３０６するために使用され るが、このデータは、新しく生成されたユーザ秘密鍵１３０９によって、すでに 署名されている。 また、政府がすべての復号化鍵がエスクロー(escrow)されることを要求するよ うな場合は、カードは復号化ができないことを証明できるようにすべきである。 この「署名のみ(signature only)」証明は、上述したものと同じ機構を通じて実 装することができ、このようにすれば、ユーザの署名鍵をエスクロー要件から免 除された状態にしておくことができるようになる。エスクローされた鍵が非否認 サービスに対する値を保持しているかは疑わしいので、この証明は、エスクロー の過程の間に可能な誤処置を通じて署名鍵が開示されてしまうことを防止するた めに有効である。 また、スマートカードは、パーソナル識別番号（ＰＩＮ）の許可されていない 使用から防護される必要がある。通常は、スマートカードは、パスワードと同等 のものであるＰＩＮによって許可されていない使用から保護されている。典型的 には、ＰＩＮはユーザによってのみ変更可能であり、指定された長さでなければ ならないが、典型的には、ユーザがＰＩＮを単純な数字に、例えば全部１や１２ １２１２などに設定してしまうことを防ぐ方法がない。スマートカードのベンダ は、数字の繰り返しやわかりやすいパターンでないような、単純でないＰＩＮを 保証するＰＩＮ変更ルーチンを実装するよう要求されるべきである。ＰＩＮを相 対的に長く（少なくとも６桁）して単純でないものとすれば、そのカードがこれ を見つけて盗もうとしている人間によって操作されうる機会は減少する。６桁Ｐ ＩＮの要件に対するサポートは、「X9.26：大規模な財務トランザクションに対 する財務機関サイン−オン認証(Financial Institution Sign-On Authenticatio n for Wholesale Financial Transactions」、ＡＮＳＩ（１９９０年）に見つけ ることができ、これは当業界では周知であり、ここで参照することにより本明細 書の一部を構成する。また、これは、「１００万分の１」標準であって、特に、 攻撃者が正しいパスワードを推測する機会が１００万分の１以下であり、繰り返 し推測するのを防止するためにシステムが回避行動(evasive action)をとる場合 に、ログイン機構が安全であるような標準を公表するものでもある。さらに、ス マートカードは、「回避行動」をとることを要求されるべきである。例えば、何 回も間違ったＰＩＮが許可されていないユーザによって入力された場合に、一定 時間でシャット・ダウンしたり、秘密鍵を消去することである。 また、スマートカードの製造業者は、ＩＤ確認のより安全な方法として、生物 測定学(biometrics)を使用することを要件とすることもできる。広汎な研究が、 声紋(voiceprint)や指紋によるＩＤ確認の分野で現在行われており、これはＰＩ Ｎを補うものである。しかし、肯定と否定を誤る割合を減少させなければならな い一方、生物測定学的入力装置及びそのデータ・チャネルの安全を確保すること について大きな問題があるので、これらは生物測定学的データの取得と再現に対 して免疫がある。生物測定学的装置が、例えばＡＴＭやドア・アクセス・システ ムのように、コンクリートの壁に埋め込まれているときは、これは問題とならな いが、典型的な商用オフィス・セッティングでは重大な問題のまま残されている 。理想的には、カード及び生物測定学的入力装置を、それぞれ、自分を証明でき 互いに安全なチャネルを確立できるタンパープルーフ暗号モジュールとすること になる。 スマートカードは、「会計監査の履歴(audit trail)」、若しくは、最近のア クションの内部的な記録であって少なくともタイムスタンプ、トランザクション 量、タイプ・コードおよびメッセージ・ダイジェストを含むログ(log)を維持す ることもできるようにすべきである。この情報は、４０バイト程度に圧縮できる ので、４００レコード循環ログ(circular log)はおよそ１６Ｋバイトを消費する ことになる。このログは、安全なチャネルを通じたカード発行者からの署名され た要求のレシートの上にのみアップロードされ、チェックされる。また、カード は、それが、発行者からの署名された確認であって、アップロードされたログが 完全に受信されたことを言明する確認を受信するまで、古いログを削除しない。 この制御機構は、偽造をやめさせ、偽造者によって引き起こされる損害を減少さ せるだろうし、許可されていない若しくは疑わしいトランザクションをより素早 く簡単に調査できるようになる。ほとんど若しくはすべてのトランザクションは 、発行者からオフラインで生じるので、カードはそれ自身のアクションの最もよ い証拠となる。オーソリティを証明するルートの公開鍵へのアクセスの制御とコストの回収(cos t recovery) 図３に示される通り、ある暗号システムでは、証明３４，３５を発行する証明 (certifying)オーソリティ（３１〜３３）の階層がある。より大きなシステムで は証明オーソリティの数と階層の深さがより大きくなる。図３に示すおのような 構造の中では、証明オーソリティＡ（３１）はルート証明オーソリティであり、 ほかの証明オーソリティはすべてこの下にある。図３の説明で注記した通り、証 明オーソリティＡの公開鍵は周知である。証明オーソリティが、Ａによって発行 された証明内の情報に基いてシステム内のいなかるトランザクションに対する責 任を負うようなシステムでは、証明オーソリティＡ（ルート証明オーソリティ） がその公開鍵に対するアクセスを制御するようにすることが便利で望ましいこと がある。そうすることによって、証明オーソリティＡは、システムに対して、シ ステムの構造がうまくできていることを保証する規則を実施できるようになる。 証明オーソリティの公開鍵に対するアクセスの制御のための様々な方法を、ここ で説明する。 図１４を参照すると、暗号システムでは、証明オーソリティ（ＣＡ）１４０２ はユーザ識別証明イング１４０４を暗号システムのユーザ（例えば、ユーザ１４ ３８）に発行する。証明オーソリティ１４０２は秘密鍵１４０６と公開鍵１４０ ８を持っている。秘密鍵１４０６は、証明オーソリティのディジタル署名１４１ ０とともに、証明１４０４にディジタルに署名するために使用される。証明オー ソリティ１４０２は、例えば、図３に示されるような、証明オーソリティの階層 の中にあるどの証明オーソリティでもよい。 証明オーソリティ１４０２は、システムのユーザについての情報を決定し、そ の情報に基いて、それらのユーザに証明１４０４を発行する。証明オーソリティ １４０２によってユーザ１４３８に対して発行された証明１４０４には、ユーザ の公開鍵１４１２および証明オーソリティの対策情報１４１４であってそのユー ザに関する情報を含むユーザ情報１４１０が含まれる。証明１４０４内に含まれ る情報をシステムの他のユーザが確認するために、これらのユーザは証明オーソ リティ１４０２の公開鍵１４０８にアクセスできなければならない。 事実上、証明オーソリティによって発行された証明１４０４は、システムのユ ーザによって、システムの他のユーザに対して自分の身元を証明して、システム 内のトランザクションを容易にするために、使用される。受信者(システム・ユ ーザ)であって、トランザクション１４４０を他のシステム・ユーザ１４３８ から受信した受信者は、そのトランザクションが証明オーソリティ１４０２によ って発行された証明１４０４を伴う場合には、証明１４０４内の情報を信頼する ことができる。これは、本質的には、証明１４０４を発行した証明オーソリティ １４０２がその証明の中の情報を保証し、その証明内の情報を信頼するトランザ クションに対する責任を負うからである。証明１４０４に証明オーソリティの対 策情報１４１４が含まれる場合には、受信者が証明オーソリティの公開鍵１４０ ６の有効なコピーを持っている場合で、受信者が証明１４０４に記述されている 対策１４１４に従っていた場合は、この責任を負うのは証明オーソリティ１４０ ２のみである。 例えば、ユーザＡ（１４３８）のＩＤがその条件を満たすことを確認した後に 、証明オーソリティ１４０２が証明１４０４をユーザＡ（１４３８）に発行した 場合を考えよう。その証明には、ユーザＡ（１４３８）の公開鍵１４１６、おた び、証明オーソリティ１４０２のユーザＡに関する対策１４１４が含まれ、証明 オーソリティ１４０２によってディジタルに署名されている。例えば、証明内の 対策１４１４は、ユーザＡが平日のトランザクションに参加できるのは午前９時 から午後５時までだけであると、指定していた場合を考えよう。ユーザＡ１４３ ８および証明１４０４によるトランザクション１４４０の受信者１４２４は、証 明オーソリティ１４０２が以下の場合にはそのトランザクションに対する貴任を 負うという知識を得た上で、トランザクションを実行できる。（ａ）受信者が、 そのトランザクションに対する対策１４１４を確認した場合。つまり、そのトラ ンザクションが許可された時間制限の中にあることを、受信者が確認した場合。 かつ、（ｂ）受信者が、証明オーソリティ１４０２の公開鍵１４０８の有効なコ ピーを持っていた場合。言い換えれば、受信者がその対策に関するトランザクシ ョンをチェックしない場合は、そのトランザクションは無効になる。さらに、受 信者はユーザＡからのトランザクションをチェックした場合で、そのトランザク ションが、証明オーソリティのユーザＡに関する対策（証明に指定されているも の）によって許可されている場合であっても、受信者が証明オーソリティの公開 鍵１４０８の有効なコピーを持っていない場合は、証明オーソリティ１４０２は 、そのトランザクションに対する貴任を負わない。 また、暗号システムには、ユーザに対する証明も発行する様々なスポンサ１４ １８を含めることができる。これらのスポンサが発行した証明も、許可証明１４ ２０として公知となる。これらの証明１４２０は、特に、これを発行するスポン サの規則や対策１４２２を指定するために機能する。これらの許可証明１４２０ は分離でき、証明オーソリティによって発行された身元証明１４０４とは異なる （ＩＤ証明が、証明オーソリティの対策要件を含むことがあるかもしれないが） 。ユーザは、証明オーソリティ１４０２によって発行されたＩＤ証明１４０４を ただ１つだけ持つことができる。しかし、ユーザは、１つ以上のスポンサ１４１ ８によって発行された許可証明１４２０を多数持つことができる。 受信者が、システムのほかのユーザからのトランザクションを受け取るときに 、受信者は、また、そのユーザからのトランザクションに含まれる許可証明内に 含まれるスポンサ・対策をすべて確認しなければならない。したがって、この暗 号システムでは、ユーザは、システム内の証明オーソリティおよびスポンサの規 則（対策）を実施する必要がある。 前述した通り、様々な証明内に含まれる情報がシステムのユーザによって確認 されるために、これらのユーザは、証明オーソリティ１４０２若しくはスポンサ １４１８であって、様々な証明を発行したものの公開鍵１４０８にアクセスでき なければならない。システム内の各証明オーソリティおよびスポンサの規則を実 施するためには、証明オーソリティのいくつかの公開鍵１４０８に対するアクセ スを制限する必要がある。特に、頂上（ルート）証明オーソリティ１４０２の公 開鍵に対するアクセスを制限する必要がある。 それゆえ、ルート証明オーソリティ１４０２は、その公開鍵を企業秘密にして おき、ルート証明オーソリティの公開鍵を取得するためには、システム内でトラ ンザクションに着手したいと考えるユーザ（潜在的な受信者）１４２４はルート 証明オーソリティが発行する証明オーソリティ規則１４２６を得なければならな い。受信者１４２４は、これらの規則をハッシュして後でディジタルに署名する ためにハッシュされた規則１４２８を形成し、ハッシュされた規則の署名された コピー１４３０を作成しなければならない。この、ハッシュされた規則のディジ タルに署名されたコピーは、ルート証明オーソリティ１４０２に返送しなければ ならない。これらのアクションによって、受信者１４２４は、さきほど署名した 証明オーソリティ１４０２の規則を遵守することに合意するのである。ルート証 明オーソリティ１４０２は、受信者１４２４が、システム内の他の証明オーソリ ティからのほか、システム内のスポンサからも、規則を取得して署名して返送す ることを要求することもある。例えば、受信者１４２４が、スポンサ１４１８か らのスポンサ規則１４３２を取得してこれらの規則の署名されたコピー１４３４ をスポンサ１４１８に返送することを、要求されることもできる。 ルート証明オーソリティ１４０２が、受信者１４２４によって署名されたシス テム規則の有効なコピーを受信したことをひとたび確信できれば、ルート証明オ ーソリティは、公開鍵１４０８を受信者１４２４に発行する。 ルート証明オーソリティの公開鍵１４２４は、様々な方法で受信者に対して発 行される。好適実施の形態では、受信者は、たとえばスマートカードのような安 全な装置１４３６を提供されている。好適一実施の形態では、証明オーソリティ 公開鍵１４０８は、安全な装置から直ちに取得できるようになっているので、一 度受信者１４２４がその装置を入手すれば、受信者は証明オーソリティ公開鍵１ ４０８を持っていることになる。他の好適実施の形態では、証明オーソリティ公 開鍵１４０８は無効にされている形式で装置１４３６に入れてあり、ルート証明 オーソリティ１４０２は、署名された規則１４３０のレシートと確認に基いて、 その装置内の鍵１４０８を有効にする。 場合によっては、装置１４３６内のルート証明オーソリティの公開鍵１４０６ が、ある一定期間後に無効になる若しくはアクセスできなくなるようにすると便 利である。この場合には、ルート証明オーソリティがその鍵１４０６を再度有効 (reactivate)するために、受信者１４２４は、ルート証明オーソリティ１４０２ の規則を、再度取得して署名して返送しなければならない。これらの規則は、以 前に署名した規則とは異なる。 異なる証明オーソリティは、ルートもそうだが、潜在的な受信者が、それらの 証明オーソリティの公開鍵へアクセスできるようになる前に、潜在的な受信者に よってほかの条件が満たされることを、要求することもできる。しかし、システ ム規則の中に含まれるものは、それを秘密に保つという規則に署名した者による 合意のみである。コストの回収(recovery) 規則には、システムの使用料支払契約を含めることもできる。したがって、（ システムのルートＣＡの規則に従うことに合意することによって）ユーザが有効 な鍵を取得するときは、これらの規則は、システムの支払スキーム(scheme)に従 う契約を実施できる。 暗号システムは、システムの操作を、これに対応するシステムのユーザが実行 して受け付けたトランザクションに対するシステムのユーザの支払と、リンクす る。トランザクションに対する支払は、例えば、前払いアカウントの形式で、請 求書払いの契約で、若しくは、電子マネー(digital cash)をその時に支払うこと によって、システム内の様々なパーティに対して行う。ある操作を、例えば、ト ランザクションにディジタルに署名するような操作を行うと、ユーザには、その ユーザのＩＤを保証する証明を発行する証明オーソリティに対して支払うべきあ る金額がかかる。 ディジタル支払機能は、公開鍵を含む装置の中に構築することができるものが ある。ユーザの秘密鍵は典型的には安全な装置（例えば、スマートカード）に保 管されるので、安全な装置を使用して、各ユーザの現在のディジタル収支を管理 することができる。このディジタル収支は、借方または貸方の金額である。ユー ザが、自分の安全な装置を使用してトランザクションにディジタルに署名するた びに、ある金額がそのユーザのディジタル収支から差し引かれる。安全な装置が 借方装置(debit device)である場合、その場合は、そのユーザのディジタル収支 がゼロに到達したときに、その装置は使用できなくなり、そのユーザのために署 名することがもはやできなくなる。その後は、そのユーザは、システム内の証明 オーソリティやその他のスポンサから、もっとディジタル・クレジットを貰わな ければならくなる。その一方で、安全な装置が貸方装置(credit device)である 場合、その場合は、ユーザは、ある一定の期間ごと、例えば、毎日、毎週、毎月 ごとに、証明オーソリティに対して支払トランザクションを実行することを要求 される。ディジタル・クレジットの金額は安全な装置から調べることができるの で、証明オーソリティは、そのトランザクションに示された金額が正しいことを 確認することができる。必要な支払トランザクションを実行しないユーザは、Ｃ ＲＬ中に、一事停止中若しくは無効であるとしてリストされることになり、その システムではもはやトランザクションを実行できなくなる。 トランザクションごとを基本とするディジタル支払は、確立トランザクション を使用して達成することもできる。ユーザの許可証明は、支払の受取人の確立ア ドレスをリストする。一度このトランザクションが行われると、支払の受取人に 通知がされ、そのユーザのアカウントから支払金額を差し引くことができる。値段情報 ユーザは、システムに対応する料金および使用料(fee and royalties)を支払 うことに合意しているので、そのユーザに対して、柔軟な値段付けおよび請求も 提供できるようになる。 ユーザ特有の値段付け対策は、証明を使用して実現することができる。スポン サおよび証明オーソリティにより発行された証明には、あるユーザに対する支払 と値段付け対策を含めることができる。例えば、証明には、あるトランザクショ ン（例えば、ある秘密鍵を使用して署名すること、ある公開鍵を使用して確認す ること、若しくは、ある証明の取消状態をチェックすることなどを含む）に対す る値段表(list of prices)、あるユーザに対する割引率(discount rates)、ある 受信者に対するトランザクションの割引率、および巨大なトランザクションのレ ートを含めることができる。請求によっては、そのユーザの安全な装置によって 実行されるものもあるが、請求できるイベントによってはトランザクションの受 信者によって実行されたアクションから発生することもある。 ある値段付け対策を実現するために、証明に様々なディジタル・フィールドを 含ませることができる。ある対策に対しては、これらのフィールドには、取消サ ービス(revocation service)のアドレス、取消サービスの値段、および、トラン ザクション確認の値段が含められる。取消サービスのアドレスは、確立アドレス と同様であるが、これは、証明の有効性を確認するためだけに使用される。 つまり、取消サービスは、すでに撤回された証明に基いて行われようとしている トランザクションに対するふるいとして働く(screen)。取消サービスの料金(Rev ocation Service Fee)は、このサービスに対して請求される料金である。 これらのフィールドの例を以下に示す。 (a) Private Key Signing Fee = ＄0.50 (b) Public＿Key Verify Fee = ＄0.50 (c) Revocation Service Address = rev-check@btec.com (d) Revocation Service Fee = ＄0.50 (e) Confirm＿Service Fee = ＄0.50 料金はすべて、均一料金として若しくは基本トランザクションのある金額ごと に対する料金として、言明することができる。例えば、料金は、「＄０．５０」 として、若しくは「基本トランザクションの金額＄１，０００につき＄０．５０ 」として、指定することができる。 上記の例で示した通り、トランザクションを受け取る受信者は、対応する証明 を取消サービスのアドレスに送ることがあり、サービス料金によって指定された 割合で請求を受けることになる。 確立トランザクションに対して料金を請求するために、証明にはトランザクシ ョン確認の料金を含めることもできる。例えば、以下の通りである。 Transaction Confirmation Fee = （＄0.50 per ＄1000 transaction amount） この場合、確認されるトランザクションそれぞれによって、受信者に適当な料 金がかかる。 場合によっては、受信者があまりに高価なトランザクションを受け取ってしま い、これを拒否したい場合がありうる。このため、送信者に請求する許可を示す ディジタル・フィールド、送信者によって署名されたディジタル・フィールド、 なども含めることができる。このフィールドには、送信者のアカウント番号およ び最大に受け付ける請求レートなどのほかの情報が、含まれる。この「請求-送 信者(bill-sender)」フィールドは送信者の署名ブロック内の属性として表われ るものである。知的財産(intellectual property)のライセンス 規則には、ユーザによって使用される知的財産のすべてに対して支払をするた めの合意を含んでもよい。例えば、システムは、ユーザに、特許されたトランザ クション、サービス若しくはアルゴリズム、著作権があるマテリアル(materials )などのようなものを提供することができる。ユーザが、このような知的財産に アクセスできるようにするための公開鍵を入手するには、そのユーザは、財産の 使用に対して支払を行う合意をするユーザ規則に署名しなければならない。 例えば、一実施の形態では、安全な装置には（支払が必要とされるため）アク ティブにされていないサービスが多く含まれている。これらのサービスの１つを 使用するためには、例えば、ディジタル・キャッシュの形式で、装置内の内部ト ランザクションによって、若しくは、そのシステムの他のユーザとのトランザク ションによって、支払が必要とされる。このような装置を取得するために、ユー ザは、規則の集合に（装置の中にあってその装置としたがって、そのユーザに対 してユニークな秘密鍵を使用して）ディジタルに署名しなければならない。これ らの規則に署名することによって、ユーザは要求されたときに支払をする契約を 結んだことになる。署名者が課した対策と規則 暗号システムのユーザは、ＩＤ確認証明（ＣＡによって発行される）、および 、１つ以上の許可証明（ＣＡしくはユーザのスポンサによって発行される）を持 つ。これらの証明にはそれぞれ、発行するパーティの対策が含まれ、これらの証 明のいずれかを含むトランザクションの受信者は、そのトランザクションが証明 内に指定された規則のすべてに従っていることを確認することを、期待されて いる。しかし、あるトランザクションに対して、ユーザが、その証明によって許 されているよりも厳しい制限がある規則を適用させたい場合がある。例えば、ユ ーザは、１００万ドル以下のトランザクションを認定することが許されているが 、あるトランザクションについてはその価格が１，０００ドル未満の場合にのみ 認証したい、と希望することがあるかもしれない。あるいは、ユーザはあるトラ ンザクションのみについて認証することを許されているが、ある特定のトランザ クションに対して、そのユーザが１つ若しくは複数の共同署名者を要求したいこ とがあるかもしれない。この機能のサポートにおいては、本発明の暗号システム は、ユーザに、トランザクションに対するユーザ規則、属性および制限を追加す る能力を提供している。 ユーザ規則は、ほかの手段では許されないトランザクションが認められること を許すわけではない。このため、受信者は、常に、各トランザクションに対して もっとも厳しい規則を適用しなければならない。例えば、ユーザの証明が１，０ ００ドルまでのトランザクションを許可しており、ユーザの規則が１００万ドル までのトランザクション値を指定している場合は、明らかに１，０００ドルの制 限が適用されるべきである。例えば、受信者が、まず、証明規則のすべてを適用 して、次に、トランザクションがまだ有効な場合には、ユーザ規則のすべてを適 用する、という手段をとれば、これが達成できるようになる。まずユーザ規則を 適用してから次に証明規則を適用しても、正しい結果が得られる。しかし、規則 および制限のブーリアン(boolean)結合子がサポートされているので、ユーザお よび証明の規則をインターリーブ(interleave)する場合は、注意深く実行しない と誤った結果が得られることがある。 図１５は、ユーザ供給(user-supplied)規則を含むユーザ・トランザクション の確認を示す。ユーザ・トランザクション１５０２は、トランザクション・テキ スト１５０６であって、受信者によって実行されるトランザクションを記述して いるものを含む。ユーザは、トランザクション・テキスト１５０６に対して、ユ ーザがトランザクション１５０２の受信者によって確認されることを望むユーザ 供給規則の集合１５０４を追加する。その後、ユーザは、ディジタルにトランザ クション・テキスト１５０６および規則１５０４に署名して、トランザクショ ン１５０２を形成するが、この際に、そのトランザクションに追加されるユーザ 署名１５１０を形成する。 その後、トランザクション１５０６が、要求されたスポンサおよび／またはＣ Ａ証明と、例えば、ＣＡ証明１５０８およびスポンサ・証明１５０９とともに、 その後でそのトランザクションを確認しなければならない受信者に対して送られ る。これをするために、受信者は、ＣＡ証明１５０８からユーザの公開鍵１５１ ４を使用して、ユーザの署名１５１０を確認１５１２する。ユーザの署名が受け 付けられた場合は、確認は継続し、そうでない場合は、トランザクションは拒絶 される１５１４。確認が継続する場合は、受信者は、ＣＡの公開鍵１５２０を使 用して、ＣＡの署名１５１８を確認１５１６する。ＣＡの署名が受け付けられた 場合は、確認は継続１５２２し、スポンサ・証明１５０９を含む証明の中の規則 およびユーザによって供給された規則のすべてのチェックに移る。そうでない場 合は、トランザクションは拒絶１５１４される。確認が継続する場合は、受信者 は、トランザクションをＣＡ証明１５０８内、スポンサ・証明１５０９内（およ び、このトランザクションに関連する他の証明内）の規則に対して確認１５２２ する。これらの規則のいずれかが満たされない場合は、トランザクションは拒絶 １５１４され、そうでない場合は、トランザクションの確認は継続し、ユーザ供 給規則１５０４に関するトランザクションの確認に移る。トランザクションが、 ユーザが提供した規則１５０４を満たす場合にのみ、そのトランザクションは受 け付け１５２６られ、そうでない場合は拒絶１５１４される。 ユーザ供給規則１５０４は、システムが知っている規則の任意の組合せとする ことができ、連署要件、時間的制限、トランザクション金額制限、確立要件など を含めることができるが、これらに限られない。 環境によっては、ユーザが、自分のために、あるタイプのユーザやトランザク ションに対して使用するために、規則若しくはデフォルト規則の集合を作成でき る。これらの規則やデフォルトの集合は、そのタイプのユーザ若しくはトランザ クションから、自動的に全トランザクションに付加される。例えば、銀行の支店 長(bank manager)であるユーザは、（経験によって）彼女が副署する新しい出納 係によるトランザクションのすべてに対して、彼女は、銀行が要求するよりも厳 しい制限のある規則を適用しようとする、と判断するかもしれない。そして、彼 女は、彼女が署名若しくは副署するそのような種類のトランザクションに対して 、これらの規則をデフォルトとして彼女の規則に格納することになろう。 当業者は、本発明が典型的には、ディジタル電子計算機などのような電子機器 を使用して実践されていること、および、証明、トランザクション、メッセージ 、署名などは電子機器によって生成されたディジタル電子信号であり、電子機器 同士の間を伝送(transmit)されること、の真価を認めることだろう。 こうして、商用暗号システムにおいてディジタル署名を安全に使用するための 方法が、提供された。当業者は、本発明が、ここで記載した実施の形態以外の実 施の形態で実施できることを認めることだろう。ここで記載した実施の形態は、 説明の目的のために紹介したものであって、制限を目的とするものではなく、本 発明は以下のクレームによってのみ制限される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)， ＡＭ，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，Ｃ Ｈ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ ，ＧＥ，ＨＵ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＫ，ＬＲ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ， ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ (72)発明者 サリッキー，ブライアン アメリカ合衆国 20852 メリーランド州 ロックヴィル ストランド ドライブ 11410 アパートメント ２

Claims (1)

1. 【特許請求の範囲】 １．暗号システムにおいて、証明オーソリティは前記システムのユーザを識別す るディジタル証明を発行し、前記ディジタル証明はディジタル署名を形成するた めに前記証明オーソリティの秘密鍵を用いてディジタル的に署名され、前記ディ ジタル署名を確認するために前記証明オーソリティの公開鍵を要求し、かつ、前 記暗号システムにおけるユーザ・トランザクションは前記ユーザ・トランザクシ ョンの受信者による確認を要求し、前記確認は前記ディジタル・証明内の情報に 基いて行われ、および、前記公開鍵を要求することを特徴とする暗号システムに おいて、前記公開鍵へのアクセスを制御する方法は、 前記公開鍵へのアクセスを拒否するステップと、 前記受信者に前記システムの規則を含む少くとも１つのメッセージを提供する ステップであって、前記規則は前記公開鍵の秘密の維持を含み、 前記受信者により、前記少なくとも１つの文書にディジタル的に署名するステ ップであって、それにより前記受信者は前記規則に合意し、 前記ディジタル的に署名することに応答して、前記受信者は前記公開鍵を利用 することを許可するステップと を備えたことを特徴とする方法。 ２．請求項１に記載の方法において、前記提供するステップは前記受信者に前記 公開鍵を含む安全な装置を提供するステップを含み、前記公開鍵は前記安全な装 置から取得できないことを特徴とする方法。 ３．暗号システムにおけるセキュリティ対策を実施する方法において、前記対策 は公開鍵へのアクセスの制御を要求し、前記方法は、 前記公開鍵へのアクセスを拒否するステップと、 受信者に前記暗号システムの規則を含むメッセージを提供するステップであっ て、前記規則は前記公開鍵の秘密の維持を含み、 前記受信者によりディジタル的に前記文書に署名するステップであって、それ により前記受信者は前記規則に合意し、 前記ディジタル的に署名することに応答して、前記受信者は公開鍵を利用する ことを許すステップと を備えたことを特徴とする方法。 ４．暗号システムにおけるセキュリティ対策を実施する方法において、前記対策 は公開鍵へのアクセスの制御を要求し、前記方法は、 受信者に前記システムの規則を含む文書および前記公開鍵のアクティブでない 形式を含む安全な装置を提供するステップであって、前記公開鍵は前記装置から 取得できないことを特徴とし、 前記受信者によりディジタル的に前記文書に署名するステップと、 前記ディジタル的に署名することに応答して、前記安全な装置内の前記公開鍵 をアクティブにするステップと を備えたことを特徴とする方法。 ５．暗号システムにおけるセキュリティ対策を実施する方法において、前記対策 は証明オーソリティの公開鍵へのアクセスの制御を要求し、前記方法は、 前記証明オーソリティにより、 ユーザに前記システムの規則を含むメッセージおよび前記公開鍵のアクティブ でない形式を含む安全な装置を提供するステップであって、前記公開鍵は前記装 置から取得できないことを特徴し、 前記ユーザにより、 前記規則に従う意図を表示するステップであって、前記表示するステップは、 前記メッセージを、ハッシュされた文書を取得するためにハッシュするステッ プと、 前記ハッシュされた文書にディジタル的な合意を形成するためにディジ タル的に署名するステップと、 前記ディジタルな合意を前記証明オーソリティに返送するステップ と、 前記ユーザによる前記表示するステップに応答して、 前記証明オーソリティにより、前記安全な装置内の前記公開鍵をアクテ ィブにするステップと を備えたことを特徴とする方法。 ６．請求項１から５のいずれかに記載の方法において、システムの各ユーザは秘 密鍵を有することを特徴とし、かつ、前記規則は少なくとも１つの規則であって 、サード・パーティに対して、 前記公開鍵の各使用と、 ユーザの秘密鍵の各使用と、 証明の状態の各証明と、 ユーザによる各確立トランザクションと についての支払を要求する規則を含むことを特徴とする方法。 ７．請求項１から５のいずれかに記載の方法の方法において、前記規則は、シス テムの作成若しくは操作において使用される知的財産の前記受信者による使用に 対して支払うための規則を含むことを特徴とする方法。 ８．請求項１に記載の方法において、前記ユーザ・トランザクションは、前記デ ィジタル的に署名するステップが実行されるまで無効であることを特徴とする方 法。 ９．請求項１に記載の方法において、前記受信者による前記署名をすることに応 答して、前記証明オーソリティは前記受信者からのトランザクションを受付ける ステップであって、前記トランザクションは前記ユーザ・トランザクションに基 くステップをさらに備えたことを特徴とする方法。 １０．暗号システムにおいて、証明オーソリティは前記システムのユーザを識別 するディジタル・証明を発行し、前記ディジタル証明はディジタル署名を形成す るために前記証明オーソリティの秘密鍵を用いてディジタル的に署名され、前記 ディジタル署名を確認するために前記証明オーソリティの公開鍵を要求し、かつ 、前記暗号システムにおけるユーザ・トランザクションは前記ユーザ・トランザ クションの受信者による確認を要求し、前記確認は前記ディジタル証明内の情報 に基いて行われ、および、前記公開鍵を要求することを特徴とする暗号システム において、前記公開鍵へのアクセスを制御する方法は、 前記受信者に前記公開鍵のアクティブでない形式を含む安全な装置を提供する ステップであって、前記公開鍵は前記安全な装置から取得できないことを特徴と し、 前記安全な装置におけるあらかじめ定めたトランザクションに応答して、前記 アクティブでない公開鍵をアクティブにするステップは前記安全な装置であって 、前記あらかじめ定めたトランザクションは安全な装置の操作上の能力を識別し 、かつ前記安全な装置をユニークに識別する安全な装置からの情報を含み、さら に、前記受信者を前記あらかじめ定めたトランザクションにユニークに束縛する 情報を含むことを特徴とするステップと を備えたことを特徴とする方法。 １１．暗号システムにおいて、証明オーソリティは前記システムのユーザを識別 するディジタル証明を発行し、前記ディジタル証明はディジタル署名を形成する ために前記証明オーソリティの秘密鍵を用いてディジタル的に署名され、前記デ ィジタル署名を確認するために前記証明オーソリティの公開鍵を要求し、および 、前記暗号システムにおけるユーザ・トランザクションは前記ユーザ・トランザ クションの受信者による確認を要求し、前記確認は前記ディジタル証明内の情報 に基いて行われ、および、前記公開鍵を要求することを特徴とする暗号システム において、前記公開鍵へのアクセスを制御する方法は、 前記受信者に安全な装置を提供するステップと、 前記安全な装置と共にあらかじめ定めたトランザクションに応答して、前記公 開鍵を前記安全な装置に伝送するステップであって、前記あらかじめ定めたトラ ンザクションは、安全な装置の操作上の能力を識別し、かつ前記安全な装置をユ ニークに識別する安全な装置からの情報を含み、さらに前記受信者を前記あらか じめ定めたトランザクションにユニークに束縛する情報を含み、前記公開鍵は前 記安全な装置から取得できないことを特徴とするステップと を備えたことを特徴とする方法。 １２．請求項１０および１１のいずれかに記載の方法において、前記安全な装置 内の前記公開鍵はあらかじめ定めた期間の後にアクティブでなくなり、前記方法 は、 前記装置内の前記公開鍵がアクティブでなくなった後に、 前記安全な装置における別のあらかじめ定めたトランザクションに応答して、 前記アクティブでない公開鍵をアクティブにするステップは前記安全な装置であ って、前記他のあらかじめ定めたトランザクションは安全な装置の操作上の能力 を識別する安全な装置からの情報を含み、かつさらに前記受信者を前記他のあら かじめ定めたトランザクションにユニークに束縛する情報を含むステップと を備えたことを特徴とする方法。 １３．暗号通信システムにおける対策を実施する方法において、 ユーザによりディジタル・メッセージを形成するステップと、 前記メッセージに少なくとも１つのユーザ規則を結合するステップと、 前記ディジタル・メッセージおよび前記少なくとも１つのユーザ規則および前 記ユーザの秘密鍵に基いて、ディジタル・ユーザ署名を形成するステップと、 前記ディジタル・メッセージおよび前記少なくとも１つのユーザ規則および前 記ディジタル・ユーザ署名をディジタル・ユーザ・トランザクションを形成する ために結合するステップと、 前記ディジタル・ユーザ・トランザクションに証明オーソリティにより発行さ れたディジタル識別証明を結合するステップであって、前記識別証明は複数のデ ィジタル・フィールドを有し、前記フィールドの少なくとも１つは前記ユーザを 識別し、 前記少なくとも１つのユーザ規則は前記ディジタル・メッセージ・トランザク ションが有効である条件を指定するステップと を備えたことを特徴とする方法。 １４．請求項１３に記載の方法において、前記ディジタル・トランザクションに 、ディジタル許可証明であって、前記識別証明から分離しており、前記ユーザに よる許可トランザクションのために前記ユーザのスポンサによって発行された証 明を結合するステップを備えたことを特徴とする方法。 １５．暗号通信システムにおける対策を実施する方法において、 ディジタル・メッセージを含むディジタル・ユーザ・トランザクションを受信 するステップであって、少なくとも１つのユーザ規則は前記トランザクションが 有効である条件を指定し、かつディジタル・ユーザ署名は前記ディジタル・メッ セージおよび前記少なくとも１つのユーザ規則およびユーザの秘密鍵に基づくも のであり、 証明オーソリティによって発行されたディジタル識別証明を受信するステップ であって、複数のディジタル・フィールドを有し、前記フィールドの少なくとも １つは前記ユーザを識別し、 前記トランザクションを前記証明における、および前記少なくとも１つのユー ザ規則における情報に基いて確認するステップと、 前記確認の前記出力に基いた前記トランザクションを受付けるステップと を備えたことを特徴とする方法。 １６．請求項１５に記載の方法において、ディジタル許可証明であり、前記識別 証明から分離しており、前記ユーザのスポンサによって発行され、前記ユーザの トランザクションを許可するディジタル許可証明を受信するステップと、 前記確認するステップは、前記許可証明内の情報に基いて前記トランザクショ ンを確認するステップと を備えたことを特徴とする方法。 １７．請求項１３から１６のいずれか１つに記載の方法において、前記少なくと も１つのユーザ規則は、 （ａ）前記トランザクションの許された文書タイプと、 （ｂ）トランザクションが形成される許された場所と、 （ｃ）トランザクションが形成される許された時刻と、 （ｄ）前記署名が有効である期間と、 （ｅ）前記トランザクションの金銭的制限と、 （ｆ）前記トランザクションの共同署名者の要件と のうち少なくとも１つを含むことを特徴とする方法。