Update Japanese translation

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">

<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>

<!-- English Revision: 151408:713605 (outdated) -->

<!-- English Revision: 659902:713605 (outdated) -->

<!--

 Licensed to the Apache Software Foundation (ASF) under one or more

また、組織内の認証管理のための特定のテクニックや、

特許や輸出規制などの重要な法的な問題についても扱いません。

むしろ、更なる研究への出発点として色々な概念、定義、例を並べることで

 mod_ssl のユーザに基礎知識を提供する事を目的としています。</p>

<module>mod_ssl</module> のユーザに基礎知識を提供する事を目的としています。</p>

<p>ここに示された内容は主に、原著者の許可の下

The Open Group Research Institute の <a

href="http://home.earthlink.net/~fjhirsch/">Frederick J. Hirsch</a>

 氏の記事 <a

href="http://home.earthlink.net/~fjhirsch/Papers/wwwj/article.html">

href="http://home.earthlink.net/~fjhirsch/Papers/wwwj/">

Introducing SSL and Certificates using SSLeay</a> を基にしています。

氏の記事は <a

href="http://www.ora.com/catalog/wjsum97/">Web Security: A Matter of

    口座番号や送金の金額が含まれるため、

    アリスはそのメッセージを秘密にしたいと思います。

    解決方法の一つは暗号アルゴリズムを使って、メッセージを

    読ませたい人以外は読むことができない暗号化された

    復号されるまで読むことができない暗号化された

    形態に変えてしまうことです。

    その形態になると、

    メッセージは秘密の鍵によってのみ解釈することができます。

    メッセージは秘密の鍵によってのみ復号化することができます。

    鍵なしでは、メッセージは役に立ちません。

    良い暗号アルゴリズムは、侵入者が元のテキストを解読することを

    非常に難しくするため、努力が割に合わなくさせます。</p>

    送信者と受信者が鍵を共有することが必要です。

    鍵とは、メッセージを暗号化したり復号するのに使われる秘密

    の情報のことです。

    もし、この鍵が秘密なら、送信者と受信者以外は誰もメッセージを読

    この鍵が秘密になっている限り、送信者と受信者以外は誰もメッセージを読

    むことができません。

    もしも、アリスと銀行が秘密の鍵を知っているなら、

    彼らはお互いに秘密のメッセージを送ることができるでしょう。

    ただし、事前に内密に鍵を選ぶという仕事は問題を含んでいます。</dd>

    ただし交信の前に、事前に内密に鍵を共有するという作業自体は難題かもしれません。</dd>

    <dt>公開鍵暗号</dt>

    <dd>非対称暗号としても知られ、

    安全なメッセージを受け取ることができます。</dd>

    </dl>

    <p>誰もが暗号化されたメッセージを公開鍵によって暗号化

    することができますが、秘密鍵の持ち主だけがそれを読むことが

    できます。

    <p>公開鍵を使って誰もがメッセージを暗号化できますが、秘

    密鍵の持ち主だけがそれを読むことができます。

    この方法で、銀行の公開鍵を使って暗号化することで、

    アリスは秘密のメッセージを送ることができます。

    銀行のみが復号することができます。</p>

    銀行のみが送られたメッセージを復号することができます。</p>

</section>

<section id="messagedigests">

    <p>アリスはメッセージを秘密にすることができますが、

    誰かが例えば自分に送金するようにメッセージを変更したり、

    別のものに置き換えてしまうかもしれないという問題があります。

    アリスのメッセージの信用を保証する方法の一つは、

    アリスのメッセージだという信憑性を保証する方法の一つは、

    メッセージの簡潔なダイジェストを作って、それも銀行に送るというものです。

    メッセージを受け取ると銀行もダイジェストを作成し、

    アリスが送ったものと比べます。もし一致したなら、

    メッセージを受け取ると銀行側でもダイジェストを作成し、

    アリスが送ったダイジェストと比べます。もし一致したなら、

    受け取ったメッセージは無傷だということになります。</p>

    <p>このような要約は<dfn>メッセージダイジェスト</dfn>、

    ダイジェストアルゴリズムはメッセージから

    一意なダイジェストを生成するように作られています。

    メッセージダイジェストはダイジェストから元のメッセージを

    判定するのがとても難しいようにできています。

    また、同じ要約を作成する二つのメッセージを探すのは不可能です。

    よって、同じ要約を使ってメッセージを置き換えるという

    判定するのがとても難しいようにできていて、

    同じ要約を作成する二つのメッセージを探すのは(理論上)不可能です。

    これによって、要約を変更することなくメッセージを置き換えられる

    可能性を排除しています。</p>

    <p>アリスへのもう一つの問題は、このダイジェストを安全に送る方法を探すことです。

これができれば、メッセージの信用が保証されます。

一つの方法はこのダイジェストに電子署名を含むことです。</p>

    ダイジェストが安全に送られればダイジェストの信憑性が保障されて、

    ダイジェストの信憑性をもってオリジナルメッセージの信憑性を得ることができます。

    ダイジェストを安全に送った場合にのみ、そのメッセージの

    信憑性が得られます。</p>

    <p>ダイジェスト安全に送る方法の一つは、電子署名に含める方法です。</p>

</section>

<section id="digitalsignatures"><title>電子署名</title>

<p>アリスが銀行にメッセージを送ったとき、銀行は、

侵入者が彼女になりすまして彼女の口座への取引を申請していないか、

メッセージが本当に彼女からのものか確実に分からなければいけません。

アリスによって作成され、メッセージに含まれた

<p>アリスが銀行にメッセージを送ったとき、

侵入者が彼女になりすまして彼女の口座への取引を申請できないように、

銀行側ではメッセージが本当に彼女からのものか確実に分かるようにしなければなりません。

アリスによって作成されて、メッセージに含まれた

<em>電子署名</em>がここで役に立ちます。</p>

<p>電子署名はメッセージのダイジェストやその他の情報(処理番号など)を

送信者の秘密鍵で暗号化することで作られます。

誰もが公開鍵を使って署名を<em>復号</em>することができますが、

署名者のみが秘密鍵を知っています。

これは、彼らのみが署名しえたことを意味します。

送信者のみが秘密鍵を知っています。

これは送信者のみが署名しえたことを意味します。

ダイジェストを電子署名に含むことは、

その署名がそのメッセージのみに有効であることを意味します。

これは、誰もダイジェストを変えて署名をすることができないため、

<p>アリスは秘密のメッセージを銀行に送り、

署名をして、メッセージの信用を保証することができるおうになりましたが、

通信している相手が本当に銀行なのか確かめなくてはいけません。

これは、彼女が使う公開鍵が銀行の秘密鍵と対になっているものか、

彼女は確かめなくてはいけないということを意味します。

同様に、銀行はメッセージの署名が本当にアリスの署名か確認する必要が

あります。</p>

つまり彼女が使おうとしている公開鍵が、銀行の秘密鍵と対になっていて、

侵入者の秘密鍵と対になっているわけではないことを

確かめなくてはいけないことを意味しています。

同様に銀行は、メッセージの署名が本当にアリスの持っている

秘密鍵で署名された署名かを確認する必要があります。</p>

<p>もし両者に身元を証明し、公開鍵を確認し、また信頼された機関が署名

した証明書があれば、両者とも通信相手について正しい相手だと

    <p>認証局はどの項目が省略可能でどれが必須かの方針を定義する

    かもしれません。項目の内容についても認証局や証明書のユーザからの

    要件があるかもしれません。

    例えば、ネットスケープのブラウザはサーバの証明書の

    例えばネットスケープのブラウザは、サーバの証明書の

     Common Name (コモンネーム)がサーバのドメイン名の

     <code>*.example.com</code> 

     <code>*.snakeoil.com</code> 

    というようなワイルドカードのパターンにマッチすること

    を要求します。</p>

    バイナリ形式を扱うことのできない送信では、

    バイナリ形式は Base64 符号化 [<a href="#MIME">MIME</a>] で

    ASCII 形式に変換されることがあります。

    このように符号化され、以下の例に示されるように区切り行に

    挟まれたものは PEM 符号化されたと言います。

    (PEM の名前は "Privacy Enhanced Mail" に由来します)</p>

    開始デリミタ行と終了デリミタ行で囲まれた、この形式のことを

    PEM ("Privacy Enhanced Mail") 符号化された証明書と言います。</p>

    <example>

    <title>PEM 符号化された証明書の例 (example.crt)</title>

<section id="certificateauthorities">

<title>認証局</title>

    <p>まず証明書の申請の情報を確認することで、

    認証局は秘密鍵の持ち主の身元を保証します。

    <p>証明書を承認する前に、証明書要求に記載されている情報を確認し、

    認証局は鍵の所有者の身元を確認します。

    例えば、アリスが個人証明書を申請したとすると、

    認証局はアリスが証明書の申請が主張する通りの

    人物だということを確認しなくてはいけません。</p>

    当の本人だということを確認しなくてはいけません。</p>

    <section id="certificatechains">

    <title>証明書階層構造</title>

    <title>証明書の連鎖</title>

        <p>認証局は他の認証局への証明書を発行することができます。

        未知の証明書を調べる時に、アリスはその証明書の発行者

        に自信が持てるまで、発行者の証明書を

        問題は、誰がその最上位の認証機関の証明書を保証するのか、

        ということです。

        このような場合に限り、証明書は「自己署名」されます。

        つまり、証明書の発行者と証明対象が同じということになります。

        その結果、自己署名された証明書を信用するには

        ブラウザには、とてもよく知られている認証局が初期登録されていますが、

        自己署名された証明書を信用する際には

        細心の注意が必要です。

        最上位認証局が公開鍵を広く公表することで、

        その鍵を信頼するリスクを低くすることができます。

        もし、他人がその認証局になりすました時に、それが露見しや

        すいからです。

        多くのブラウザは有名な認証局を信頼するように

        設定されています。</p>

        すいからです。</p>

        <p><a href="http://www.thawte.com/">Thawte</a> 

        や <a href="http://www.verisign.com/">VeriSign</a> 

        責任のある仕事です。

        認証局は証明書を発行するだけでなく、

        管理もしなければなりません。

        具体的には、証明書がいつまで有効かを決定し、更新し、

        また既に発行されたが失効した証明書のリスト

        具体的には、証明書がいつまで有効であり続けるかを決定し、更新し、

        また過去発行されて失効した証明書のリスト

        (Certificate Revocation Lists または CRL)

        を管理しなければいけません。

        例えば、アリスが会社から社員として証明書を与えられたとします。

        そして、アリスが会社を辞めるときには証明書を取り消さなければ

        いけないとします。

        を管理しなければいけません。</p>

        <p>例えばアリスが過去、会社の社員であることを証明する証明書を持っていたが、

        現在は退職していた際、その証明書は失効されなければなりません。

        証明書は次々と人に渡されていくものなので、

        証明書そのものから、それが取り消されたか判断することは

        不可能です。

        普通この過程は自動化されているものではありません。</p>

        <note><title>注意</title>

        <p>デフォルトでブラウザに設定されていない認証局を使った場合、

        <p>ブラウザに信用できる認証局としてデフォルトで登録されていない

        認証局を使おうとした場合、

        認証局の証明書をブラウザに読み込んで、

        ブラウザがその認証局によって署名されたサーバの証明書を

        有効化する必要があります。

        有効にする必要があります。

        一度読み込まれると、その認証局によって署名された全ての

        証明書を受け入れるため、危険を伴います。</p>

        </note>

    共有される対称暗号鍵をどのようにがクライアントとサーバで

    取り決めるかを定義します。

    SSL 2.0 は RSA 鍵交換しか使いませんが、

    SSL 3.0 は証明書が使われるときは RSA 鍵交換を使い、

    証明書が無く、クライアントとサーバの事前の通信が無い場合は

    Diffie-Hellman 鍵交換を使う

    SSL 3.0 は (証明書が使われるときの) RSA 鍵交換や、

    (証明書無しの場合やクライアントとサーバの事前の通信が無い場合の)

    Diffie-Hellman 鍵交換

    など様々な鍵交換アルゴリズムをサポートします。</p>

    <p>鍵の交換方法における一つの選択肢は電子署名です。

    電子署名を使うかどうか、また、

    どの種類の署名を使うかという選択があります。

    秘密鍵で署名することで共有鍵を生成すし、情報交換する時の

    秘密鍵で署名することで共有鍵を保護し、情報交換する時の

    マン・イン・ザ・ミドル攻撃を防ぐことができます。

    [<a href="#AC96">AC96</a>, p516]</p>

</section>

<section id="ciphertransfer">

<title>データ通信の暗号術</title>

    <p>SSL はセッションのメッセージの暗号化に前述した

    従来型暗号(対称暗号)を用います。

    暗号化しないという選択肢も含め九つの選択肢があります:</p>

    対称暗号方式を用います。

    暗号化しないという選択肢も含め九つの暗号方式の選択肢があります:</p>

    <ul>

    <li>暗号化なし</li>

        </ul></li>

    </ul>

    <p>ここでの CBC とは暗号ブロック連鎖 (Cipher Block Chaining)

    <p>CBC とは暗号ブロック連鎖 (Cipher Block Chaining)

     の略で、一つ前の暗号化された暗号文の一部が

    ブロックの暗号化に使われることを意味します。

    DES はデータ暗号化標準規格 (Data Encryption Standard)

     [<a href="#AC96">AC96</a>, ch12] の略で、

    DES40 や 3DES_EDE を含むいくつもの種類があります。

    Idea は最高なものの一つで、暗号術的には現在ある中で

    Idea は現在最高なものの一つで、暗号術的には現在ある中で

    最も強力なものです。

    RC2 は RSA DSI による独占的なアルゴリズムです。

     [<a href="#AC96">AC96</a>,

    </ul>

    <p>メッセージダイジェストは Message Authentication Code (MAC) 

    の生成に使われ、メッセージと共に暗号化され、メッセージの信用を

    提供し、リプレイ攻撃を防ぎます。</p>

    の生成に使われ、メッセージと共に暗号化され、メッセージの信憑性を

    確認し、リプレイ攻撃を防ぎます。</p>

</section>

<section id="handshake">

    </p>

    <p>

    レコードプロトコルによる SSL コントロールプロトコルのカプセル化は、

    アクティブなセッションの二回目の通信があった場合、

    コントロールプロトコルが安全であることを意味します。

    既にセッションが無い場合は、Null 暗号スイートが使われ、

    レコードプロトコルで SSL コントロールプロトコルがカプセル化されているということは、

    アクティブなセッション上で再ネゴシエーションされたときにも、

    コントロールプロトコルは安全であることを意味します。

    既存のセッションが無い場合は、Null 暗号スイートが使われ、

    暗号化は行なわれず、セッションが確立するまでは

    ダイジェストも無い状態となります。</p>

</section>

    <p><a href="#figure3">図3</a>に示される SSL レコードプロトコル

    はクライアントとサーバ間のアプリケーションや

    SSL コントロールデータの通信に使われます。

    このデータはより小さいユニットに分けられたり、

    必要に応じてこのデータはより小さいユニットに分けられたり、

    いくつかの高級プロトコルをまとめて一ユニットとして通信が

    行なわれることもあります。

    データを圧縮し、ダイジェスト署名を添付して、

    <p>よくある SSL の使い方はブラウザとウェブサーバ間の HTTP 通信

    の安全化です。

    これは、従来の安全ではない HTTP の使用を除外するものではありません。

    安全化されたものは主に SSH 上の普通の HTTP で、HTTPS と呼ばれます。

    大きな違いは、URL スキームに <code>http</code> の代わりに <code>https</code>

    を用い、サーバが別のポートを使うことです (デフォルトでは443)。

    これが主に <module

    >mod_ssl</module> が Apache ウェブサーバに提供する機能です。</p>

    安全化されたもの (HTTPS と呼ばれます) は、SSL 上での普通の HTTP で、

    URL スキームに <code>http</code> の代わりに <code>https</code>

    を用い、サーバで別のポートを使うことです (デフォルトでは443)。

    これが主に <module>mod_ssl</module> が Apache 

    ウェブサーバに提供する機能です。</p>

</section>

</section>

<!-- /ssl -->