目次

最終更新日: 2006年 1月25日


[1] 平成12年度電子商取引に関する市場規模・実態調査」概要 (2001/1/31)、電子商取引推進協議会(ECOM)、アクセンチュア及び、経済産業省の共同調査による。(http://www.ecom.or.jp/press/20010131_2.html)

[2] 正確には「『電磁的記録の真正な成立の推定』の効果を得られる場合があります。」とされています。

[3] よくパスワードに使われる単語を辞書として持ち、それらの組み合わせを総当りで試していく攻撃方法です。

[4] これは、「リプレイ攻撃」と呼ばれます。仮に認証にバイオメトリクスを利用していても、ネットワークを流れるバイオメトリクス情報がコピーされれば、簡単になりすまされてしまいます。

[5] 公開鍵暗号方式の詳細については 2章で説明します。

[6] 高レベルのローカル認証には、バイオメトリクス認証が向いています。

[7] 対象鍵暗号方式とも呼びます。

[8] 共通鍵は秘密鍵(Secret Key)と呼ばれることもあります。しかし、後述する公開鍵暗号方式で用いるプライベート鍵 (Private Key) のことも秘密鍵と訳すことが多いため、本書では Secret Key を「共通鍵」、Private Key を「秘密鍵」もしくは「プライベート鍵」として記述します。

[9] 一般に鍵長は、ビット数で表現します。

[10] 米国の当時の RSA Data Security 社が実施した 56 bit DES 暗号解読コンテストより。

[11] DES を 3回繰り返したもので、DES の 3倍の鍵長(168bit) を持ちます。

[12] 非対称暗号方式 (Asymmetric Cryptography) ともいいます。

[13] 秘密鍵 (Private Key) は、プライベート鍵とも呼ばれます。

[14] もしくは、A さんに直接配布します。配布方法については 4 章において解説します。

[15] ECC 160 bit の鍵で RSA 1024 bit の鍵と同等の強度といわれています。

[16] ハッシュ値とも呼びます。

[17] 衝突とも呼びます。

[18] 第三者が悪意をもってデータの内容を変更することを指します。

[19] 例えば、文書中の一文字だけが改ざんされた場合、ファイル同士を目視で比較するのは困難です。

[20] メッセージが改ざんされていないことが確認できることを指します。

[21] メッセージを作成した人を特定できることを指します。

[22] 元の電子文書の作成者を特定でき、電子文書が改ざんされていないことを意味します。

[23] 復号に使用した公開鍵に対応する秘密鍵は A さんのみが所有しているためです。

[24] 正式名称は、「電子署名及び認証業務に関する法律」です。

[25] 正式名称は、「グローバルな商取引と国内商取引における電子署名法」です。

[26] 正式名称は、「電子署名のための共同体の枠組みに関する指令」です。

[27] 法律及び指令では技術的中立性を保つためにデジタル署名に言及していませんが、現時点で現実的にこの要求を満たすことができるのはデジタル署名のみとなっています。

[28] TTPに信頼される公開鍵の所有者を、加入者(Subscriber)といいます。

[29] 電子証明書、デジタル証明書ともいいます。正確には公開鍵証明書といいます。

[30] 一例として、名前、所属組織名、メールアドレス等があります。

[31] 認証機関ともいいます。

[32] 認証実施規定ともいいます。

[33] CPS については、3.4 において解説します。

[34] 認定認証業務については、8 章で解説します。

[35] PKI を利用する個々のユーザを指します。Web サーバなどの擬人も証明書の発行対象となるため「ユーザ」という表現と区別しています。

[36] 証明書失効リスト(Certification Revocation List) のことを指します。詳細は 4 章で解説します。

[37] 2002年 2月現在。

[38] 正確には識別子はクラスとタグから構成されます。データ型はタグの一部として記述します。

[39] 厳密には [A-Z][a-z][0-9] を表します。

[40] 逆に「cn=Suzuki Taro, ou=Some Section...」の順で記述されることもあります。

[41] Critical フラグが True である場合を指します。

[42] 2002年 4月に、RFC 3280 として公開されました。RFC 3280 の改訂作業も進められています。

[43] CA 証明書の場合のみ。

[44] 基本領域の主体者 (subject) フィールドが空である場合のみ。

[45] 証明書の失効情報が記載されたファイルです。詳細は 4章にて解説します。

[46] 証明書の失効情報をオンラインで問い合わせるサーバです。詳細は 4章にて解説します。

[47] 認証局運用規程ともいいます。

[48] RFC 2527 では CP/CPS の解釈に曖昧な部分があります。CP/CPS の解釈を明確にした RFC 2527 の後継 RFC 3647 が PKIX によってインターネットドラフトとして公開されています。

[49] バイオメトリクスを単体でネットワーク認証に用いる場合は、サーバ側に生体情報を登録しなければなりません。

[50] 申請書の公開鍵と加入者が所持する秘密鍵が対応していることを確認することを、PoP (Proof of Possession)といいます。

[51] Certificate Request Message Format の略。RFC 2511 において定義されています。

[52] 秘密鍵を格納したICカードが破損した場合や、IC カードのパスワードを忘れた場合があります。

[53] CA の階層構造については、5章で解説します。

[54] 証明書の失効については、4章で解説します。

[55] 証明書拡張領域の基本制約 (basicConstraints) や名前制約 (nameConstraints) フィールドに記載されます。

[56] これを鍵の危殆化といいます。

[57] リポジトリについては 6章で解説します。

[58] 初期のPKIでは、すべての CA を一つの階層構造とする構想がありましたが、この方法はうまくいきませんでした。

[59] これを相互認証といいます。

[60] 詳しい手順は、3章 4節にて解説しています。

[61] TLS(SSL) の場合は、User1 の証明書と一緒に CA2 の証明書を配布します。証明書の配布・交換方法については、6章にて解説します。

[62] そもそもこのような信頼関係が存在していることにも気づかないと思われます。

[63] 図 5-10 では、CA3 と CA31 が階層型モデルを持っています。

[64] 電子署名を施された電子文書に対して、改竄の有無を検知することです。

[65] 署名の検証を行う人を指します。

[66] 失効情報の確認方法については、4章において解説しています。

[67] 情報を一元的に管理するサーバをリポジトリといいます。

[68] LDAP での構成例を示しています。

[69] objectClass(オブジェクトクラス)属性が inetOrgPerson(インターネットユーザ)となっています。

[70] objectClass 属性が organization (組織)となっています。

[71] title(役職)属性がManager(マネージャ)となっています。

[72] LDIF は、LDAP サーバが持つエントリ情報が記載されたテキストファイルです。データの入出力に使用されます。

[73] EC サイトでは利用者の個人情報やクレジットカード番号などを入力するためです。

[74] AH を用いた場合は、暗号化は行われません。

[75] テキストファイルなどの文書にタグをつけることにより、文書構造などの付加情報を追加するための言語仕様です。XML 以外のマークアップ言語として、SGML や HTML などがあります。

[76] 例えば、XML に含まれる空白や改行の数、文字コードなどが異なる可能性があります。

[77] 民間有識者による仕様検討会

[78] 2001年 1月には日本を「5年以内に世界最先端のIT国家を目指す」とする「e-Japan戦略」が提唱され、電子政府構想は重点政策分野として打ち出されました。

[79] ブリッジ CA については、5章で解説しています。

[80] GPKI の Web ページ(http://www.gpki.go.jp/session/)で全文を参照できます。

[81] リフェラルについては 6章を参照して下さい。

[82] LDAP については 6章を参照して下さい。

[83] BindRequest の version パラメータ設定を”2”にしなければなりません。

[84] 総務省 Web ページ(http://www.soumu.go.jp/joho_tsusin/top/ninshou-law/law-index.html)を参照

[85] 法務省 Web ページ(http://www.moj.go.jp/MINJI/minji32-3.html)で全文を参照できます。

[86] JQA:日本品質保証機構(8.6.3 特殊法人と民間)

[87] http://www.gpki.go.jp/cross/cross.pdf で全文を参照できます。

[88] Local Government Wide Area Network

[89] 詳細については http://www.shugiin.go.jp/itdb_main.nsf/html/housei/h145133.htm を参照

[90] カナダ GOCPKI(http://www.cio-dpi.gc.ca/PKI-icp/default.asp)

[91] アメリカ FPKI(http://www.egov.gov/federal_public_key_infrastructure.htm)

[92] オーストラリア GPKA(http://www.govonline.gov.au/projects/publickey/index.asp)

[93] イギリス CLOUD COVER(http://www.cesg.gov.uk/technology/PKI/cloud-cover/index.htm)

[94] 標準化団体については 10章を参照してください。

[95] ETSI については 10章を参照してください。

[96] 法務省による譲渡性預金に対する確定日付など、一部のサービスのみ。一般市民向けの公証サービスは実施未定。

[97] http://www.imc.org/ietf-pkix/ を参照してください。

[98] 「エッツィ」と発音します。

[99] 9章を参照してください。


目次