利用可能な商用 CA が複数存在します。商用 CA を使用して証明書に署名するメカニズムは、選択した CA によって異なります。

商用 CA の利点は、多くの場合、多数のユーザーが信頼していることです。お使いのアプリケーションが組織外のシステムで使用できるように設計されている場合は、商用 CA を使用して証明書に署名します。アプリケーションが内部ネットワーク内で使用されている場合には、プライベート CA が適切である可能性があります。

商用 CA を選択する前に、以下の基準を考慮してください。

システムの証明書の署名を行う責任がある場合は、プライベート CA を設定します。プライベート CA を設定するには、証明書を作成および署名するためのユーティリティーを提供するソフトウェアパッケージへのアクセスが必要です。このタイプのパッケージが複数利用可能です。

プライベート CA の設定を可能にするソフトウェアパッケージの 1 つが OpenSSL http://www.openssl.org です。OpenSSL パッケージには、証明書を生成および署名するための基本的なコマンドラインユーティリティーが含まれています。OpenSSL コマンドラインユーティリティーの完全なドキュメントは、http://www.openssl.org/docs から入手できます。

プライベート CA を設定するには、「独自の証明書の作成」 の手順を参照してください。

プライベート CA を設定する上では、ホストの選択が重要な手順になります。CA ホストに関連付けられるセキュリティーのレベルは、CA によって署名された証明書に関連する信頼レベルを決定します。

Red Hat Fuse アプリケーションの開発およびテストで使用する CA を設定する場合は、アプリケーション開発者がアクセスできるホストを使用します。ただし、CA 証明書と秘密鍵を作成する場合は、セキュリティーが重要なアプリケーションを実行するホストで CA 秘密鍵を利用できるようにしないでください。

デプロイするアプリケーションの証明書に署名するために CA を設定する場合は、CA ホストをできるだけセキュアにします。たとえば、CA を保護するには、以下の点に注意してください。

このセクションで説明する手順は、OpenSSL プロジェクトの OpenSSL コマンドラインユーティリティーに基づいています。OpenSSL コマンドラインユーティリティーの詳細については、http://www.openssl.org/docs/ を参照してください。

図については、CA データベースには以下のディレクトリー構造があることを前提としています。

ここで、X509CA は CA データベースの親ディレクトリーです。

このセクションでは、独自のプライベート CA を設定する方法について説明します。実際の展開用に CA を設定する前に、「プライベート認証局」 の追加の注意事項をお読みください。

独自の CA を設定するには、以下の手順を実行します。

安全な CA ホストで、OpenSSL bin ディレクトリーをパスに追加します。

Windows

> set PATH=OpenSSLDir\bin;%PATH%

UNIX

% PATH=OpenSSLDir/bin:$PATH; export PATH

この手順により、コマンドラインから openssl ユーティリティーを利用できるようになります。

新規 CA を保持する新規ディレクトリー X509CA を作成します。このディレクトリーは、CA に関連付けられたすべてのファイルを保持するために使用されます。X509CA ディレクトリーの下に、以下のディレクトリーの階層を作成します。

OpenSSL インストールから X509CA ディレクトリーにサンプル openssl.cnf をコピーします。

openssl.cnf を編集して、X509CA ディレクトリーのディレクトリー構造を反映し、新しい CA によって使用されるファイルを特定します。

openssl.cnf ファイルの [CA_default] セクションを編集して、以下のようにします。

#############################################################
[ CA_default ]

dir        = X509CA            # Where CA files are kept
certs      = $dir/certs  # Where issued certs are kept
crl_dir    = $dir/crl          # Where the issued crl are kept
database   = $dir/index.txt    # Database index file
new_certs_dir = $dir/newcerts  # Default place for new certs

certificate   = $dir/ca/new_ca.pem # The CA certificate
serial        = $dir/serial        # The current serial number
crl           = $dir/crl.pem       # The current CRL
private_key   = $dir/ca/new_ca_pk.pem  # The private key
RANDFILE      = $dir/ca/.rand
# Private random number file

x509_extensions = usr_cert  # The extensions to add to the cert
...

この段階で、OpenSSL 設定の他の詳細を編集することもできます。詳細は、http://www.openssl.org/docs/ を参照してください。

X509CA ディレクトリーで、serial と index.txt の 2 つのファイルを初期化します。

Windows

Windows で serial ファイルを初期化するには、以下のコマンドを入力します。

> echo 01 > serial

Windows で空のファイル index.txt を作成するには、以下のように X509CA ディレクトリーのコマンドラインで Windows Notepad を起動します。

> notepad index.txt

ダイアログボックスにCannot find the text.txt file. Do you want to create a new file?というテキストが表示されたら、Yes をクリックして Notepad を閉じます。

UNIX

UNIX の serial ファイルおよび index.txt ファイルを初期化するには、以下のコマンドを入力します。

% echo "01" > serial
% touch index.txt

これらのファイルは、証明書ファイルのデータベースを維持するために CA によって使用されます。

以下のコマンドを使用して、新しい自己署名 CA 証明書と秘密鍵を作成します。

openssl req -x509 -new -config X509CA/openssl.cnf -days 365 -out X509CA/ca/new_ca.pem -keyout X509CA/ca/new_ca_pk.pem

このコマンドは、CA 秘密鍵のパスフレーズと、CA 識別名の詳細を要求します。以下に例を示します。

Using configuration from X509CA/openssl.cnf
Generating a 512 bit RSA private key
....++
.++
writing new private key to 'new_ca_pk.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN. There are quite a few fields but you can leave
some blank. For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:IE
State or Province Name (full name) []:Co. Dublin
Locality Name (eg, city) []:Dublin
Organization Name (eg, company) []:Red Hat
Organizational Unit Name (eg, section) []:Finance
Common Name (eg, YOUR name) []:Gordon Brown
Email Address []:gbrown@redhat.com

CA 証明書と秘密鍵 (new_ca.pem および new_ca_pk.pem) のファイル名と場所が、openssl.cnf で指定した値と同じであることを確認してください (前述の手順を参照)。

これで、CA で証明書に署名する準備が整いました。

Java キーストア (JKS) で証明書を作成して署名するには (CertName.jks)、以下のサブステップを実行します。

まだ追加していない場合は、Java の bin ディレクトリーをパスに追加します。

Windows

> set PATH=JAVA_HOME\bin;%PATH%

UNIX

% PATH=JAVA_HOME/bin:$PATH; export PATH

この手順により、コマンドラインから keytool ユーティリティーを利用できるようになります。

コマンドプロンプトを開き、キーストアファイル KeystoreDir を保存するディレクトリーに移動します。以下のコマンドを入力します。

keytool -genkey -dname "CN=Alice, OU=Engineering, O=Progress, ST=Co. Dublin, C=IE" -validity 365 -alias CertAlias -keypass CertPassword -keystore CertName.jks -storepass CertPassword

この keytool コマンドは、-genkey オプションで呼び出され、X.509 証明書とこれに一致する秘密鍵を生成します。証明書と鍵は、新規に作成されたキーストアの キーエントリー に配置されます (CertName.jks)。指定のキーストア CertName.jks はコマンドを発行する前に存在していなかったため、keytool は暗黙的に新しいキーストアを作成します。

-dname フラグおよび -validity フラグは、新たに作成された X.509 証明書の内容を定義し、サブジェクト DN と有効期限までの日数をそれぞれ指定します。DN 形式の詳細は、付録A ASN.1 および識別名 を参照してください。

サブジェクト DN の一部は、CA 証明書の値に一致する必要があります (openssl.cnf ファイルの CA ポリシーセクションで指定)。デフォルトの openssl.cnf ファイルは、以下のエントリーと一致する必要があります。

以下のように、CertName.jks 証明書の新しい証明書署名要求 (CSR) を作成します。

keytool -certreq -alias CertAlias -file CertName_csr.pem -keypass CertPassword -keystore CertName.jks -storepass CertPassword

このコマンドは CSR をファイルにエクスポートします (CertName_csr.pem)。

以下のように CA を使用して CSR に署名します。

openssl ca -config X509CA/openssl.cnf -days 365 -in CertName_csr.pem -out CertName.pem

証明書に正常に署名するには、CA 秘密鍵パスフレーズを入力する必要があります (「独自の CA の設定」 を参照)。

以下のように、署名済み証明書 (CertName.pem) を PEM のみの形式に変換します。

openssl x509 -in CertName.pem -out CertName.pem -outform PEM

以下のように、CA 証明書ファイルと CertName.pem 証明書ファイルを連結します。

Windows

copy CertName.pem + X509CA\ca\new_ca.pem CertName.chain

UNIX

cat CertName.pem X509CA/ca/new_ca.pem> CertName.chain

以下のように、証明書の完全な証明書チェーンをインポートして、キーストア CertName.jks を更新します。

keytool -import -file CertName.chain -keypass CertPassword -keystore CertName.jks -storepass CertPassword

ステップ 2 から 7 を繰り返し、システムの完全な証明書セットを作成します。

「独自の CA の設定」 で説明されているように、プライベート CA を設定した場合は、これで、独自の証明書を作成して署名する準備が整いました。

PKCS#12 形式 CertName.p12 で証明書を作成して署名するには、以下のサブステップを実行します。

まだ追加していない場合は、以下のように OpenSSL bin ディレクトリーをパスに追加します。

Windows

> set PATH=OpenSSLDir\bin;%PATH%

UNIX

% PATH=OpenSSLDir/bin:$PATH; export PATH

この手順により、コマンドラインから openssl ユーティリティーを利用できるようになります。

証明書が、クライアントが URL 整合性チェックを実施する HTTPS サーバーを対象としている場合、およびサーバーをマルチホームホストまたは複数の DNS 名エイリアスを持つホストに展開する場合 (たとえば、展開する場合) は、この手順を実行します。マルチホーム Web サーバー上の証明書)。この場合、証明書 ID は複数のホスト名と一致する必要がありますが、これは subjectAltName 証明書エクステンションを追加することでのみ行うことができます (「HTTPS 証明書の特別な要件」 を参照)。

subjectAltName 拡張子を設定するには、CA の openssl.cnf ファイルを次のように編集します。

以下のように、CertName.p12 証明書の新しい証明書署名要求 (CSR) を作成します。

openssl req -new -config X509CA/openssl.cnf -days 365 -out X509CA/certs/CertName_csr.pem -keyout X509CA/certs/CertName_pk.pem

このコマンドは、証明書の秘密鍵のパスフレーズと、証明書の識別名に関する情報の入力を求めるプロンプトを表示します。

CSR 識別名のエントリーの一部は、CA 証明書の値と一致する必要があります (openssl.cnf ファイルの CA ポリシーセクションで指定)。デフォルトの openssl.cnf ファイルは、以下のエントリーが一致している必要があります。

証明書のサブジェクト DN の共通名は、証明書の所有者の ID を表すために通常使用されるフィールドです。共通名 (Common Name) は、次の条件に準拠している必要があります。

Using configuration from X509CA/openssl.cnf
Generating a 512 bit RSA private key
.++
.++
writing new private key to
      'X509CA/certs/CertName_pk.pem'
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be
incorporated into your certificate request.
What you are about to enter is what is called a Distinguished
Name or a DN. There are quite a few fields but you can leave
some blank. For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:IE
State or Province Name (full name) []:Co. Dublin
Locality Name (eg, city) []:Dublin
Organization Name (eg, company) []:Red Hat
Organizational Unit Name (eg, section) []:Systems
Common Name (eg, YOUR name) []:Artix
Email Address []:info@redhat.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:password
An optional company name []:Red Hat

以下のように CA を使用して CSR に署名します。

openssl ca -config X509CA/openssl.cnf -days 365 -in X509CA/certs/CertName_csr.pem -out X509CA/certs/CertName.pem

このコマンドには、new_ca.pem CA 証明書に関連付けられている秘密鍵のパスフレーズが必要です。以下に例を示します。

Using configuration from X509CA/openssl.cnf
Enter PEM pass phrase:
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName :PRINTABLE:'IE'
stateOrProvinceName :PRINTABLE:'Co. Dublin'
localityName :PRINTABLE:'Dublin'
organizationName :PRINTABLE:'Red Hat'
organizationalUnitName:PRINTABLE:'Systems'
commonName :PRINTABLE:'Bank Server Certificate'
emailAddress :IA5STRING:'info@redhat.com'
Certificate is to be certified until May 24 13:06:57 2000 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

証明書に正常に署名するには、CA 秘密鍵パスフレーズを入力する必要があります (「独自の CA の設定」 を参照)。

以下のように、CA 証明書ファイル、CertName.pem 証明書ファイル、CertName_pk.pem 秘密鍵を連結します。

Windows

copy X509CA\ca\new_ca.pem + X509CA\certspass:quotes[_CertName_].pem + X509CA\certspass:quotes[_CertName_]_pk.pem X509CA\certspass:quotes[_CertName_]_list.pem

UNIX

cat X509CA/ca/new_ca.pem X509CA/certs/CertName.pem X509CA/certs/CertName_pk.pem > X509CA/certs/CertName_list.pem

以下のように CertName_list.pem ファイルから PKCS#12 ファイルを作成します。

openssl pkcs12 -export -in X509CA/certs/CertName_list.pem -out X509CA/certs/CertName.p12 -name "New cert"

PKCS#12 証明書を暗号化するパスワードを入力するように求められます。通常、このパスワードは CSR パスワードと同じです (これは、多くの証明書リポジトリーで必要です)。

ステップ 3 から 6 を繰り返し、システムの完全な証明書セットを作成します。

アプリケーションがターゲットのみの認証用に設定されている場合は、ターゲットはクライアントに対して自己認証されますが、図3.1「ターゲット認証のみ」 に示されているように、クライアントはターゲットオブジェクトに対して認証されません。

図3.1 ターゲット認証のみ

アプリケーションを実行する前に、クライアントとサーバーが以下のように設定する必要があります。

セキュリティーハンドシェイク時に、サーバーは証明書チェーンをクライアントに送信します (図3.1「ターゲット認証のみ」 を参照)。その後、クライアントは信頼される CA リストを検索し、サーバーの証明書チェーン内の CA 証明書のいずれかに一致する CA 証明書を検索します。

クライアント側では、ターゲットのみの認証に必要なポリシー設定はありません。X.509 証明書を HTTPS ポートに関連付ける ことなく、クライアントを設定するだけです。ただし、クライアントに信頼される CA 証明書の一覧を指定する必要があります (「信頼された CA 証明書の指定」 を参照)。

サーバー側では、サーバーの XML 設定ファイルで sec:clientAuthentication 要素がクライアント認証を必要としないことを確認してください。この要素は省略できます。その場合、デフォルトのポリシーはクライアント認証を必要とし ない ことです。ただし、sec:clientAuthentication 要素が存在する場合は、以下のように設定する必要があります。

<http:destination id="{Namespace}PortName.http-destination">
  <http:tlsServerParameters secureSocketProtocol="TLSv1">
    ...

    <sec:clientAuthentication want="false" required="false"/>
  </http:tlsServerParameters>
</http:destination>

want 属性は false (デフォルト) に設定され、TLS ハンドシェイク時にサーバーから X.509 証明書を要求しないように指定します。必要な属性は false(デフォルト) に設定され、クライアント証明書が存在しないと TLS ハンドシェイク時に例外がトリガーされないことが指定されます。

また、X.509 証明書をサーバーの HTTPS ポート (「アプリケーションの Own 証明書の指定」 を参照) に関連付け、サーバーに信頼される CA 証明書の一覧を提供する必要もあります (「信頼された CA 証明書の指定」 を参照してください)。

アプリケーションが相互認証用に設定されている場合、ターゲットはクライアントに対して自己認証され、クライアントはそれ自体をターゲットに対して認証します。このシナリオは、図3.2「相互認証」 で説明されています。この場合、サーバーとクライアントはそれぞれ、セキュリティーハンドシェイクに X.509 証明書が必要になります。

図3.2 相互認証

アプリケーションを実行する前に、クライアントとサーバーが以下のように設定する必要があります。

TLS ハンドシェイクの間、サーバーは証明書チェーンをクライアントに送信し、クライアントは証明書チェーンをサーバーに送信します。図3.1「ターゲット認証のみ」 を参照してください。

クライアント側では、相互認証に必要なポリシー設定はありません。X.509 証明書をクライアントの HTTPS ポートに関連付けるだけです (「アプリケーションの Own 証明書の指定」 を参照)。信頼できる CA 証明書の一覧をクライアントに提供する必要もあります (「信頼された CA 証明書の指定」 を参照してください)。

サーバー側では、サーバーの XML 設定ファイルで sec:clientAuthentication 要素がクライアント認証を 必要 とすることを確認してください。以下に例を示します。

<http:destination id="{Namespace}PortName.http-destination">
  <http:tlsServerParameters secureSocketProtocol="TLSv1">
    ...
    <sec:clientAuthentication want="true" required="true"/>
  </http:tlsServerParameters>
</http:destination>

ここで、want 属性は true に設定され、サーバーが TLS ハンドシェイク中にクライアントから X.509 証明書を要求することを指定します。required 属性も true に設定されます。クライアント証明書がない場合に TLS ハンドシェイク中に例外がトリガーされることを指定します。

また、X.509 証明書をサーバーの HTTPS ポート (「アプリケーションの Own 証明書の指定」 を参照) に関連付け、サーバーに信頼される CA 証明書の一覧を提供する必要もあります (「信頼された CA 証明書の指定」 を参照)。

アプリケーションが SSL/TLS ハンドシェイク時に X.509 証明書を受信すると、アプリケーションは発行者 CA が事前に定義された CA 証明書の 1 つであるかどうかをチェックして、受信した証明書を信頼するかどうかを決定します。受信した X.509 証明書が有効でアプリケーションの信頼された CA 証明書のいずれかによって署名されている場合、証明書は信頼できるものとみなされます。そうでない場合は拒否されます。

HTTPS ハンドシェイクの一部として X.509 証明書を受信する可能性があるすべてのアプリケーションは、信頼できる CA 証明書の一覧を指定する必要があります。たとえば、これには以下のようなタイプのアプリケーションが含まれます。

CA 証明書は Java キーストア形式で提供する必要があります。

HTTPS トランスポート用に信頼されたルート CA を 1 つ以上デプロイするには、以下の手順を実行します。

HTTPS トランスポートを使用する場合、アプリケーションの証明書は XML 設定ファイルを使用してデプロイされます。

HTTPS トランスポートのアプリケーション独自の証明書をデプロイするには、以下の手順を実行します。

トランスポート層ではなく SOAP エンコーディング層でメッセージ保護を適用することにより、より柔軟な範囲の保護ポリシーにアクセスできます。特に、SOAP レイヤーはメッセージ構造を認識しているため、たとえば、実際に保護が必要なヘッダーのみを暗号化して署名することにより、より細かいレベルで保護を適用できます。この機能により、より高度な多層アーキテクチャーをサポートできます。たとえば、1 つのプレーンテキストヘッダーが中間層 (安全なイントラネット内にある) を対象とし、暗号化されたヘッダーが最終的な宛先 (安全でないパブリックネットワークを介して到達) を対象とする場合があります。

WS-SecurityPolicy 仕様で説明されているように、SOAP メッセージを保護するために次のバインディングタイプのいずれかを使用できます。

以下の保護性は、メッセージの一部またはすべてのメッセージに適用できます。

このような保護性は、1 つのメッセージに任意に組み合わせることができます。したがって、メッセージの一部の部分は暗号化のみできますが、メッセージの他の部分には署名のみが使用され、メッセージの他の部分は署名と暗号化の両方が可能です。メッセージの一部を保護を外すこともできます。

メッセージの保護を適用する最も柔軟なオプションは、SOAP 層 (sp:AsymmetricBinding または sp:SymmetricBinding) で利用できます。トランスポート層 (sp:TransportBinding) は、メッセージ 全体 に保護を適用するオプションのみを提供します。

現在、Apache CXF を使用すると、SOAP メッセージの以下の部分に署名または暗号化できます。

メッセージ保護に必要なすべての詳細がポリシーを使用して指定されるわけではありません。ポリシーは主に、サービスに必要な保護の品質を指定する方法を提供することを目的としています。セキュリティートークンやパスワードなどのサポートの詳細は、個別の製品固有のメカニズムを使用して提供する必要があります。実際には、Apache CXF では Blueprint XML 設定ファイルにいくつかのサポート設定の詳細を提供する必要があります。詳細は、「暗号化キーおよび署名キーの提供」 を参照してください。

ここで説明したシナリオは、クライアントサーバーアプリケーションです。非対称バインディングポリシー が、クライアントとサーバーの間で送受信されるメッセージの SOAP ボディーを暗号化および署名するよう設定されます。

図6.1「基本的な署名および暗号化シナリオ」 は、基本的な署名と暗号化のシナリオの概要を示しています。これは、非対称バインディングポリシーを WSDL コントラクトのエンドポイントに関連付けることで指定されます。

図6.1 基本的な署名および暗号化シナリオ

クライアントが図6.1「基本的な署名および暗号化シナリオ」受信者のエンドポイントで同期操作を呼び出すと、要求メッセージと応答メッセージは次のように処理されます。

非対称バインディングポリシーは、非対称キーアルゴリズム (公開/秘密キーの組み合わせ) を使用して SOAP メッセージ保護を実装し、SOAP レイヤーで実装します。非対称バインディングで使用される暗号化および署名アルゴリズムは、SSL/TLS で使用される暗号化および署名アルゴリズムに似ています。ただし、重要な違いは、SOAP メッセージ保護では、保護するメッセージの特定の部分 (たとえば、個々のヘッダー、本文、添付ファイル) を選択できるのに対し、トランスポート層のセキュリティーはメッセージ 全体 に対してのみ機能することです。

非対称バインディングポリシーは、エンドポイントポリシーサブジェクトに適用する必要があります (「エンドポイントポリシーサブジェクト」 を参照)。たとえば、ID MutualCertificate10SignEncrypt_IPingService_policy を持つ非同期バインディングポリシーの場合、以下のようにポリシーをエンドポイントバインディングに適用できます。

<wsdl:binding name="MutualCertificate10SignEncrypt_IPingService" type="i0:IPingService">
  <wsp:PolicyReference URI="#MutualCertificate10SignEncrypt_IPingService_policy"/>
  ...
</wsdl:binding>

AsymmetricBinding 要素の構文は以下のようになります。

<sp:AsymmetricBinding xmlns:sp="..." ... >
  <wsp:Policy xmlns:wsp="...">
  (
   <sp:InitiatorToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:InitiatorToken>
  ) | (
   <sp:InitiatorSignatureToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:InitiatorSignatureToken>
   <sp:InitiatorEncryptionToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:InitiatorEncryptionToken>
  )
  (
   <sp:RecipientToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:RecipientToken>
  ) | (
   <sp:RecipientSignatureToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:RecipientSignatureToken>
   <sp:RecipientEncryptionToken>
     <wsp:Policy> ... </wsp:Policy>
   </sp:RecipientEncryptionToken>
  )
   <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite>
   <sp:Layout ... > ... </sp:Layout> ?
   <sp:IncludeTimestamp ... /> ?
   <sp:EncryptBeforeSigning ... /> ?
   <sp:EncryptSignature ... /> ?
   <sp:ProtectTokens ... /> ?
   <sp:OnlySignEntireHeadersAndBody ... /> ?
   ...
  </wsp:Policy>
  ...
</sp:AsymmetricBinding>

例6.4「非対称バインディングの例」 は、署名と暗号化によるメッセージ保護をサポートする非対称バインディングの例を示しています。署名と暗号化は、公開鍵と秘密鍵のペアを使用して (つまり、非対称暗号化を使用して) 実行されます。この例では、署名して暗号化 する 必要があるメッセージのパーツを指定していません。方法は 「暗号化および署名するメッセージの一部の指定」 を参照してください。

<wsp:Policy wsu:Id="MutualCertificate10SignEncrypt_IPingService_policy">
  <wsp:ExactlyOne>
    <wsp:All>
      <sp:AsymmetricBinding
          xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:InitiatorToken>
            <wsp:Policy>
              <sp:X509Token
                  sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                <wsp:Policy>
                  <sp:WssX509V3Token10/>
                </wsp:Policy>
              </sp:X509Token>
            </wsp:Policy>
          </sp:InitiatorToken>
          <sp:RecipientToken>
            <wsp:Policy>
              <sp:X509Token
                  sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
                <wsp:Policy>
                  <sp:WssX509V3Token10/>
                </wsp:Policy>
              </sp:X509Token>
            </wsp:Policy>
          </sp:RecipientToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic256/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
          <sp:Layout>
            <wsp:Policy>
              <sp:Lax/>
            </wsp:Policy>
          </sp:Layout>
          <sp:IncludeTimestamp/>
          <sp:EncryptSignature/>
          <sp:OnlySignEntireHeadersAndBody/>
        </wsp:Policy>
      </sp:AsymmetricBinding>
      <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:MustSupportRefKeyIdentifier/>
          <sp:MustSupportRefIssuerSerial/>
        </wsp:Policy>
      </sp:Wss10>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

イニシエータートークン は、イニシエーターが所有する公開鍵/秘密鍵のペアを参照します。このトークンは以下のように使用されます。

このトークンは、イニシエーターと受信者の両方で使用されます。ただし、イニシエーターのみが秘密鍵にアクセスできるようにするため、トークンはイニシエーターに所属することができます。「基本的な署名および暗号化シナリオ」 では、イニシエータートークンは証明書 Alice です。

この要素には、以下のようにネストされた wsp:Policy 要素と sp:X509Token 要素が含まれている必要があります。sp:IncludeToken 属性は AlwaysToRecipient に設定され、受信者に送信されるすべてのメッセージに Alice の公開鍵を含めるようランタイムに指示します。このオプションは、受信側がイニシエーターの証明書を使用して認証を行う場合に便利です。最も深くネストされた要素 WssX509V3Token10 はオプションになります。X.509 証明書に準拠する仕様バージョンを指定します。以下の代替方法 (または none) をここで指定できます。

受信側トークン は、受信側が所有する公開鍵/秘密鍵のペアを参照します。このトークンは以下のように使用されます。

このトークンは、受信側 と イニシエーターの両方で使用されます。ただし、受信側のみが秘密鍵にアクセスできるため、その場合はトークンを受信者に所属することができます。「基本的な署名および暗号化シナリオ」 では、受信側トークンは証明書 Bob です。

この要素には、以下のようにネストされた wsp:Policy 要素と sp:X509Token 要素が含まれている必要があります。リプライメッセージに Bob の公開鍵を含める必要がないため、sp:IncludeToken 属性は Never に設定されます。

この要素は、署名と暗号化に使用する一連の暗号化アルゴリズムを指定します。利用可能なアルゴリズムスイートの詳細については、「アルゴリズムスイートの指定」 を参照してください。

この要素は、セキュリティーヘッダーが SOAP メッセージに追加される順序で条件を適用するかどうかを指定します。sp:Lax 要素は、セキュリティーヘッダーの順序に条件を課さないことを指定します。sp:Lax の代替は、sp:Strict、sp:LaxTimestampFirst、または sp:LaxTimestampLast です。

この要素がポリシーに含まれる場合、ランタイムは wsu:Timestamp 要素を wsse:Security ヘッダーに追加します。デフォルトでは、タイムスタンプは含まれ ません。

メッセージ部分が暗号化と署名の両方に依存する場合は、これらの操作が実行される順序を指定する必要があります。デフォルトの順序は、暗号化前に署名することです。ただし、非対称ポリシーにこの要素を含めると、署名前に暗号化するように順序が変更されます。

この要素は、「暗号化キーおよび署名キーの提供」で指定されている暗号化トークンによって、メッセージ署名を暗号化する必要があることを指定します。デフォルトは false です。

この要素は、署名がその署名の生成に使用されるトークンに対応する必要があるように指定します。デフォルトは false です。

この要素は、ヘッダーボディーまたはサブ要素のサブ要素ではなく、本文全体またはヘッダー全体に のみ、署名を適用できることを指定します。このオプションを有効にすると、実質的に sp:SignedElements アサーションを使用できなくなります (「暗号化および署名するメッセージの一部の指定」 を参照)。

symmetric binding ポリシーは、対称鍵アルゴリズム (共有秘密鍵) を使用して SOAP メッセージ保護を実装し、SOAP レイヤーで行います。対称バインディングの例は、Kerberos プロトコルおよび WS-SecureConversation プロトコルです。

symmetric binding ポリシーはエンドポイントポリシーサブジェクトに適用する必要があります (「エンドポイントポリシーサブジェクト」 を参照してください)。たとえば、ID SecureConversation_MutualCertificate10SignEncrypt_IPingService_policy を持つ同期バインディングポリシーの場合、以下のようにポリシーをエンドポイントバインディングに適用できます。

<wsdl:binding name="SecureConversation_MutualCertificate10SignEncrypt_IPingService" type="i0:IPingService">
  <wsp:PolicyReference URI="#SecureConversation_MutualCertificate10SignEncrypt_IPingService_policy"/>
  ...
</wsdl:binding>

SymmetricBinding 要素の構文は以下のようになります。

<sp:SymmetricBinding xmlns:sp="..." ... >
  <wsp:Policy xmlns:wsp="...">
  (
   <sp:EncryptionToken ... >
     <wsp:Policy> ... </wsp:Policy>
   </sp:EncryptionToken>
   <sp:SignatureToken ... >
     <wsp:Policy> ... </wsp:Policy>
   </sp:SignatureToken>
  ) | (
   <sp:ProtectionToken ... >
     <wsp:Policy> ... </wsp:Policy>
   </sp:ProtectionToken>
  )
   <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite>
   <sp:Layout ... > ... </sp:Layout> ?
   <sp:IncludeTimestamp ... /> ?
   <sp:EncryptBeforeSigning ... /> ?
   <sp:EncryptSignature ... /> ?
   <sp:ProtectTokens ... /> ?
   <sp:OnlySignEntireHeadersAndBody ... /> ?
   ...
  </wsp:Policy>
  ...
</sp:SymmetricBinding>

例6.5「対称バインディングの例」 は、署名と暗号化によるメッセージ保護をサポートする対称バインディングの例を示しています。署名と暗号化は、単一の対称鍵を使用して (つまり、対称暗号化を使用して) 実行されます。この例では、署名して暗号化 する 必要があるメッセージのパーツを指定していません。方法は 「暗号化および署名するメッセージの一部の指定」 を参照してください。

<wsp:Policy wsu:Id="SecureConversation_MutualCertificate10SignEncrypt_IPingService_policy">
  <wsp:ExactlyOne>
    <wsp:All>
      <sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:ProtectionToken>
            <wsp:Policy>
              <sp:SecureConversationToken>
                ...
              </sp:SecureConversationToken>
            </wsp:Policy>
          </sp:ProtectionToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic256/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
          <sp:Layout>
            <wsp:Policy>
              <sp:Lax/>
            </wsp:Policy>
          </sp:Layout>
          <sp:IncludeTimestamp/>
          <sp:EncryptSignature/>
          <sp:OnlySignEntireHeadersAndBody/>
        </wsp:Policy>
      </sp:SymmetricBinding>
      <sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
        <wsp:Policy>
          <sp:MustSupportRefKeyIdentifier/>
          <sp:MustSupportRefIssuerSerial/>
        </wsp:Policy>
      </sp:Wss10>
      ...
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

この要素は、メッセージの署名と暗号化の両方に使用する対称トークンを指定します。たとえば、ここで WS-SecureConversation トークンを指定できます。

個別のトークンを署名および暗号化操作に使用する場合は、この要素の代わりに sp:SignatureToken 要素と sp:EncryptionToken 要素を使用します。

この要素は、メッセージの署名に使用する対称トークンを指定します。これは、sp:EncryptionToken 要素と組み合わせて使用する必要があります。

この要素は、メッセージの暗号化に使用する対称トークンを指定します。これは、sp:SignatureToken 要素と組み合わせて使用する必要があります。

この要素は、署名と暗号化に使用する一連の暗号化アルゴリズムを指定します。利用可能なアルゴリズムスイートの詳細については、「アルゴリズムスイートの指定」 を参照してください。

この要素は、セキュリティーヘッダーが SOAP メッセージに追加される順序で条件を適用するかどうかを指定します。sp:Lax 要素は、セキュリティーヘッダーの順序に条件を課さないことを指定します。sp:Lax の代替は、sp:Strict、sp:LaxTimestampFirst、または sp:LaxTimestampLast です。

この要素がポリシーに含まれる場合、ランタイムは wsu:Timestamp 要素を wsse:Security ヘッダーに追加します。デフォルトでは、タイムスタンプは含まれ ません。

メッセージ部分が暗号化と署名の両方に依存する場合は、これらの操作が実行される順序を指定する必要があります。デフォルトの順序は、暗号化前に署名することです。ただし、対称ポリシーにこの要素を含めると、署名前に暗号化するように順序が変更されます。

この要素は、メッセージ署名を暗号化する必要があることを指定します。デフォルトは false です。

この要素は、署名がその署名の生成に使用されるトークンに対応する必要があるように指定します。デフォルトは false です。

この要素は、ヘッダーボディーまたはサブ要素のサブ要素ではなく、本文全体またはヘッダー全体に のみ、署名を適用できることを指定します。このオプションを有効にすると、実質的に sp:SignedElements アサーションを使用できなくなります (「暗号化および署名するメッセージの一部の指定」 を参照)。

暗号化と署名は、それぞれ機密性と整合性の 2 種類の保護を提供します。WS-SecurityPolicy の保護アサーションは、メッセージの どの 部分を保護するかを指定するために使用されます。一方、保護メカニズムの詳細は、関連するバインディングポリシー (x「AsymmetricBinding ポリシーの指定」、「SymmetricBinding ポリシーの指定」、および 「トランスポート層のメッセージ保護」を参照) で個別に指定されます。

ここで説明する保護アサーションは、SOAP メッセージの機能に適用されるため、SOAP セキュリティーと組み合わせて使用することが意図されています。ただし、これらのポリシーは、特定の部分ではなくメッセージ 全体 に対して保護を適用するトランスポートバインディング (HTTPS など) によっても満たされます。

保護アサーションは、メッセージポリシーの件名 に適用する必要があります (「メッセージポリシー件名」 を参照)。つまり、WSDL バインディングの wsdl:input、wsdl:output、または wsdl:fault 要素内に配置する必要があります。たとえば、ID MutualCertificate10SignEncrypt_IPingService_header_Input_policy を使用した保護ポリシーでは、以下のように wsdl:input メッセージにポリシーを適用することができます。

<wsdl:operation name="header">
  <soap:operation soapAction="http://InteropBaseAddress/interop/header" style="document"/>
  <wsdl:input name="headerRequest">
    <wsp:PolicyReference
        URI="#MutualCertificate10SignEncrypt_IPingService_header_Input_policy"/>
      <soap:header message="i0:headerRequest_Headers" part="CustomHeader" use="literal"/>
      <soap:body use="literal"/>
    </wsdl:input>
    ...
</wsdl:operation>

Apache CXF では、以下の WS-SecurityPolicy の保護アサーションがサポートされます。

SignedParts 要素の構文は以下のようになります。

<sp:SignedParts xmlns:sp="..." ... >
  <sp:Body />?
  <sp:Header Name="xs:NCName"? Namespace="xs:anyURI" ... />*
  <sp:Attachments />?
  ...
</sp:SignedParts>

EncryptedParts 要素の構文は以下のようになります。

<sp:EncryptedParts xmlns:sp="..." ... >
  <sp:Body/>?
  <sp:Header Name="xs:NCName"? Namespace="xs:anyURI" ... />*
  <sp:Attachments />?
  ...
</sp:EncryptedParts>

例6.6「整合性および暗号化ポリシーの評価」 は、署名済みの部分アサーションと暗号化されたパーツアサーションの 2 つの保護アサーションを組み合わせるポリシーを示しています。このポリシーがメッセージ部分に適用されると、影響を受けるメッセージボディーは署名され、暗号化されます。また、CustomHeader という名前のメッセージヘッダーは署名されます。

<wsp:Policy wsu:Id="MutualCertificate10SignEncrypt_IPingService_header_Input_policy">
    <wsp:ExactlyOne>
        <wsp:All>
            <sp:SignedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <sp:Body/>
                <sp:Header Name="CustomHeader" Namespace="http://InteropBaseAddress/interop"/>
            </sp:SignedParts>
            <sp:EncryptedParts xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <sp:Body/>
            </sp:EncryptedParts>
        </wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

この要素は、保護 (暗号化または署名) がメッセージの本文に適用されることを指定します。保護は、メッセージボディー 全体 (つまり soap:Body 要素、その属性、およびそのコンテンツ) に適用されます。

この要素は、Name 属性を使用したヘッダーのローカル名および Namespace 属性を使用した namespace で指定された SOAP ヘッダーに保護が適用されるように指定します。保護は、属性とコンテンツを含むメッセージヘッダー 全体 に適用されます。

この要素は、添付ファイル付きのすべての SOAP (SwA) 添付ファイルが保護されることを指定します。

標準の WS-SecurityPolicy ポリシーは、セキュリティープロトコル、セキュリティーアルゴリズム、トークンタイプ、認証 要件 など、セキュリティー要件の詳細を指定するように設計されています。ただし、標準のポリシーアサーションは、キーやクレデンシャルなどの関連するセキュリティーデータを指定するためのメカニズムを提供しません。WS-SecurityPolicy は、必要なセキュリティーデータが独自のメカニズムを通じて提供されることを期待しています。Apache CXF では、関連するセキュリティーデータはブループリント XML 設定を通じて提供されます。

クライアントのリクエストコンテキストまたはエンドポイントコンテキストでプロパティーを設定することで、アプリケーションの暗号化キーと署名キーを指定できます (「Blueprint 設定への暗号化および署名プロパティーの追加」 を参照)。設定可能なプロパティーは 表6.1「暗号化プロパティーおよび署名プロパティー」 に表示されます。

上記のプロパティーの名前は、使用目的を正確に反映していないため、あまり適切に選択されていません。security.signature.properties で指定されるキーは、実際には署名 および 復号化の両方に使用されます。security.encryption.properties で指定されるキーは、署名の暗号化 および 検証の両方に使用されます。

Apache CXF アプリケーションで WS-Policy ポリシーを使用する前に、ポリシー機能をデフォルトの CXF バスに追加する必要があります。以下の Blueprint 設定のフラグメントに示されるように、p:policies 要素を CXF バスに追加します。

<beans xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xmlns:cxf="http://cxf.apache.org/core"
       xmlns:p="http://cxf.apache.org/policy" ... >

    <cxf:bus>
        <cxf:features>
            <p:policies/>
            <cxf:logging/>
        </cxf:features>
    </cxf:bus>
    ...
</beans>

以下の例は、署名および暗号化プロパティーを指定されたサービスタイプのプロキシーに追加する方法を示しています (サービス名は jaxws:client 要素の name 属性で指定されます)。プロパティーは WSS4J プロパティーファイルに格納されます。alice.properties には署名キーのプロパティーが含まれ、bob.properties には暗号化キーのプロパティーが含まれます。

<beans ... >
    <jaxws:client name="{http://InteropBaseAddress/interop}MutualCertificate10SignEncrypt_IPingService"
                  createdFromAPI="true">
        <jaxws:properties>
            <entry key="ws-security.signature.properties" value="etc/alice.properties"/>
            <entry key="ws-security.encryption.properties" value="etc/bob.properties"/>
        </jaxws:properties>
    </jaxws:client>
    ...
</beans>

実際、プロパティー名からは明らかではありませんが、これらの各キーは、クライアント側で 2 つの異なる目的に使用されます。

これが混乱した場合は、「基本的な署名および暗号化シナリオ」 で詳細の説明を参照してください。

以下の例は、署名および暗号化プロパティーを JAX-WS エンドポイントに追加する方法を示しています。プロパティーファイル bob.properties には署名キーのプロパティーが含まれ、プロパティーファイル alice.properties には暗号化キーのプロパティーが含まれます (これはクライアント設定の逆になります)。

<beans ... >
    <jaxws:endpoint
       name="{http://InteropBaseAddress/interop}MutualCertificate10SignEncrypt_IPingService"
       id="MutualCertificate10SignEncrypt"
       address="http://localhost:9002/MutualCertificate10SignEncrypt"
       serviceName="interop:PingService10"
       endpointName="interop:MutualCertificate10SignEncrypt_IPingService"
       implementor="interop.server.MutualCertificate10SignEncrypt">

        <jaxws:properties>
            <entry key="security.signature.properties" value="etc/bob.properties"/>
            <entry key="security.encryption.properties" value="etc/alice.properties"/>
        </jaxws:properties>

    </jaxws:endpoint>
    ...
</beans>

これらのキーはそれぞれ、サーバー側で 2 つの異なる目的で使用されます。

Apache CXF は WSS4J プロパティーファイルを使用して、暗号化と署名に必要な公開鍵と秘密鍵をロードします。表6.2「WSS4J Keystore プロパティー」 は、これらのファイルに設定できるプロパティーを説明します。

たとえば、etc/alice.properties ファイルには、以下のように PKCS#12 ファイル certs/alice.pfx をロードするためのプロパティー設定が含まれています。

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin

org.apache.ws.security.crypto.merlin.keystore.type=PKCS12
org.apache.ws.security.crypto.merlin.keystore.password=password
org.apache.ws.security.crypto.merlin.keystore.file=certs/alice.pfx

etc/bob.properties ファイルには、以下のように PKCS#12 ファイル certs/bob.pfx をロードするためのプロパティー設定が含まれています。

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin

org.apache.ws.security.crypto.merlin.keystore.password=password

# for some reason, bouncycastle has issues with bob.pfx
org.apache.ws.security.crypto.merlin.keystore.provider=SunJSSE
org.apache.ws.security.crypto.merlin.keystore.type=PKCS12
org.apache.ws.security.crypto.merlin.keystore.file=certs/bob.pfx

暗号化キーと署名キーをロードする別の方法は、表6.3「暗号オブジェクトを指定するプロパティー」 に示すプロパティーを使用して、関連するキーをロードする Crypto オブジェクトを指定することです。これは、 WSS4J Crypto インタフェース org.apache.ws.security.components.crypto.Crypto の独自の実装を提供する必要があります。

例6.7「WSS4J Crypto インターフェイス」 は、プログラミングで暗号キーと署名キーを提供する場合は、実装できる Crypto インターフェイスの定義を示しています。詳細は、WSS4J ホームページ を参照してください。

// Java
package org.apache.ws.security.components.crypto;

import org.apache.ws.security.WSSecurityException;

import java.io.InputStream;
import java.math.BigInteger;
import java.security.KeyStore;
import java.security.PrivateKey;
import java.security.cert.Certificate;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;

public interface Crypto {
    X509Certificate loadCertificate(InputStream in)
    throws WSSecurityException;

    X509Certificate[] getX509Certificates(byte[] data, boolean reverse)
    throws WSSecurityException;

    byte[] getCertificateData(boolean reverse, X509Certificate[] certs)
    throws WSSecurityException;

    public PrivateKey getPrivateKey(String alias, String password)
    throws Exception;

    public X509Certificate[] getCertificates(String alias)
    throws WSSecurityException;

    public String getAliasForX509Cert(Certificate cert)
    throws WSSecurityException;

    public String getAliasForX509Cert(String issuer)
    throws WSSecurityException;

    public String getAliasForX509Cert(String issuer, BigInteger serialNumber)
    throws WSSecurityException;

    public String getAliasForX509Cert(byte[] skiBytes)
    throws WSSecurityException;

    public String getDefaultX509Alias();

    public byte[] getSKIBytesFromCert(X509Certificate cert)
    throws WSSecurityException;

    public String getAliasForX509CertThumb(byte[] thumb)
    throws WSSecurityException;

    public KeyStore getKeyStore();

    public CertificateFactory getCertificateFactory()
    throws WSSecurityException;

    public boolean validateCertPath(X509Certificate[] certs)
    throws WSSecurityException;

    public String[] getAliasesForDN(String subjectDN)
    throws WSSecurityException;
}

アルゴリズムスイートは、署名、暗号化、メッセージダイジェストの生成などの操作を実行する暗号化アルゴリズムの一貫したコレクションです。

ここでは、WS-SecurityPolicy 仕様で定義されたアルゴリズムスイートについて説明します。ただし、特定のアルゴリズムスイートを利用できるかどうかは、基礎となるセキュリティープロバイダーによって異なります。Apache CXF セキュリティーは、プラグイン可能な Java Cryptography Extension (JCE) および Java Secure Socket Extension (JSSE) レイヤーに基づいています。デフォルトでは、Apache CXF は Sun の JSSE プロバイダーで設定されています。このプロバイダーは、Sun の JSSE リファレンスガイド の 付録 A で説明されている暗号スイートをサポートしています。

AlgorithmSuite 要素の構文は以下のようになります。

<sp:AlgorithmSuite xmlns:sp="..." ... >
  <wsp:Policy xmlns:wsp="...">
   (<sp:Basic256 ... /> |
    <sp:Basic192 ... /> |
    <sp:Basic128 ... /> |
    <sp:TripleDes ... /> |
    <sp:Basic256Rsa15 ... /> |
    <sp:Basic192Rsa15 ... /> |
    <sp:Basic128Rsa15 ... /> |
    <sp:TripleDesRsa15 ... /> |
    <sp:Basic256Sha256 ... /> |
    <sp:Basic192Sha256 ... /> |
    <sp:Basic128Sha256 ... /> |
    <sp:TripleDesSha256 ... /> |
    <sp:Basic256Sha256Rsa15 ... /> |
    <sp:Basic192Sha256Rsa15 ... /> |
    <sp:Basic128Sha256Rsa15 ... /> |
    <sp:TripleDesSha256Rsa15 ... /> |
    ...)
    <sp:InclusiveC14N ... /> ?
    <sp:SOAPNormalization10 ... /> ?
    <sp:STRTransform10 ... /> ?
   (<sp:XPath10 ... /> |
    <sp:XPathFilter20 ... /> |
    <sp:AbsXPath ... /> |
    ...)?
    ...
  </wsp:Policy>
  ...
</sp:AlgorithmSuite>

アルゴリズムスイートのアサーションは、多数の代替アルゴリズム (例: Basic256) をサポートします。代替アルゴリズムスイートの詳細については、表6.4「アルゴリズムスイート」 を参照してください。

表6.4「アルゴリズムスイート」 WS-SecurityPolicy によってサポートされるアルゴリズムスイートの概要を示します。列見出しは、次のようにさまざまなタイプの暗号化アルゴリズムを示しています。\Dig はダイジェストアルゴリズムです。\Enc は暗号化アルゴリズムです。\SymKW は対称鍵ラップアルゴリズムです。\AsymKW は非対称キーラップアルゴリズムです。\ Enc KD は、暗号化キー導出アルゴリズムです。\ Sig KD は、署名鍵導出アルゴリズムです。

WS-SecurityPolicy では、以下のタイプの暗号化アルゴリズムがサポートされます。

対称キー署名プロパティー [Sym Sig] は、対称キーを使用して署名を生成するアルゴリズムを指定します。WS-SecurityPolicy は、HmacSha1 アルゴリズムを常に使用するように指定します。

HmacSha1 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2000/09/xmldsig#hmac-sha1

非対称鍵の署名プロパティー [Asym Sig] は、非対称キーを使用して署名を生成するアルゴリズムを指定します。WS-SecurityPolicy は、RsaSha1 アルゴリズムを常に使用するように指定します。

RsaSha1 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2000/09/xmldsig#rsa-sha1

digest プロパティー [Dig] は、メッセージダイジェスト値の生成に使用されるアルゴリズムを指定します。WS-SecurityPolicy は、2 つの代替ダイジェストアルゴリズム (Sha1 および Sha256) をサポートします。

Sha1 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2000/09/xmldsig#sha1

Sha256 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#sha256

暗号化プロパティー [Enc] は、データの暗号化に使用されるアルゴリズムを指定します。WS-SecurityPolicy は、Aes256、Aes192、Aes128、TripleDes の暗号化アルゴリズムをサポートします。

Aes256 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#aes256-cbc

Aes192 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#aes192-cbc

Aes128 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#aes128-cbc

TripleDes アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#tripledes-cbc

対称キーラッピングプロパティー [Sym KW] は、対称鍵の署名および暗号化に使用されるアルゴリズムを指定します。WS-SecurityPolicy は、対称鍵ラップアルゴリズムの KwAes256、KwAes192、KwAes128、KwTripleDes をサポートします。

KwAes256 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#kw-aes256

KwAes192 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#kw-aes192

KwAes128 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#kw-aes128

KwTripleDes アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#tripledes-cbc

非対称キーラッププロパティー [AsymKW] は、非対称キーの署名と暗号化に使用されるアルゴリズムを指定します。WS-SecurityPolicy は、非対称鍵ラップアルゴリズムの KwRsaOaep と KwRsa15 をサポートします。

KwRsaOaep アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

KwRsa15 アルゴリズムは、以下の URI で識別されます。

http://www.w3.org/2001/04/xmlenc#rsa-1_5

コンピュートキープロパティー [Comp Key] は、派生された鍵の計算に使用されるアルゴリズムを指定します。セキュアな参加者が共有秘密鍵の ID と通信する場合 (WS-SecureConversation を使用する場合など)、悪意のあるサードパーティーによる分析に過剰なデータが公開されないように、元の共有キーの代わりに派生キーを使用することが推奨されます。WS-SecurityPolicy は、PSha1 アルゴリズムを常に使用するように指定します。

PSha1 アルゴリズムは、以下の URI で識別されます。

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha1

暗号化キー導出プロパティー [Enc KD] は、派生した暗号化キーの計算に使用するアルゴリズムを指定します。WS-SecurityPolicy は、PSha1L256、PSha1L192、PSha1L128 の暗号化キーの派生アルゴリズムをサポートします。

PSha1 アルゴリズムは以下の URI で識別されます (PSha1L256、PSha1L192、および PSha1L128 に同じアルゴリズムが使用されます。キーの長さのみが異なります)。

http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk/p_sha1

署名キー導出プロパティー [Sig KD] は、派生署名キーの計算に使用されるアルゴリズムを指定します。WS-SecurityPolicy は、PSha1L192、PSha1L128 の署名キーの派生アルゴリズムをサポートします。

表6.5「キー長のプロパティー」 は、WS-SecurityPolicy でサポートされるキーの最小および最大の長さを示しています。

最小対称鍵長の値 MinSKL は、選択されているアルゴリズムスイートによって異なります。