ネットワーク WG
Request for Comments: 4051
分類: スタンダードトラック

D. Eastlake 3rd
Motorola Laboratories
2005年 4月

English

追加の XML セキュリティ URI
(Additional XML Security Uniform Resource Identifiers (URIs))

 

本書の位置づけ

本書は、インターネット・コミュニティに対して、インターネット標準化過程プロトコルを定義し、その向上のための議論や提案を求めるものである。このプロトコルの標準化状況やステータスについては "Internet Official Protocol Standards" (STD 1) の最新版を参照のこと。本書の配布は 、制限されていない。

著作権表記

Copyright (C) The Internet Society (2005).

要旨

XMLディジタル署名、暗号化および正規化(Canonicalization)に使われるいくつかの URI(Uniform Resource Identifiers)が定義されている。これらの URI は、キーイング情報のアルゴリズムとタイプを識別する。

 

目次

1. はじめに

2. アルゴリズム

2.1. DigestMethod アルゴリズム

2.1.1. MD5
2.1.2. SHA-224
2.1.3. SHA-384

2.2. SignatureMethod Message Authentication Code アルゴリズム

2.2.1. HMAC-MD5
2.2.2. HMAC SHA Variations
2.2.3. HMAC-RIPEMD160

2.3. SignatureMethod Public Key 署名アルゴリズム

2.3.1. RSA-MD5
2.3.2. RSA-SHA256
2.3.3. RSA-SHA384
2.3.4. RSA-SHA512
2.3.5. RSA-RIPEMD160
2.3.6. ECDSA-SHA*
2.3.7. ESIGN-SHA1

2.4. Minimal Canonicalization

2.5. 変換アルゴリズム

2.5.1. XPointer

2.6. EncryptionMethod アルゴリズム

2.6.1. ARCFOUR 暗号化アルゴリズム
2.6.2. Camellia ブロック暗号化
2.6.3. Camellia Key Wrap
2.6.4. PSEC-KEM

3. KeyInfo

3.1. PKCS #7 Bag of Certificates and CRLs
3.2. Additional RetrievalMethod Type Values

4. IANA についての考慮事項

5. セキュリティについての考慮事項

謝辞

規範的参考文献

参考情報

著者のアドレス

著作権表記全文

 

1. はじめに English

XML ディジタル署名、暗号化および正規化(Canonicalization)は、W3C と合同の IETF/W3C XMLDSIG ワーキンググループによって標準化されている。これらのすべては、現在では、W3C 勧告(W3C Recommendation)および IETF 情報または標準化過程(IETF Informational Standards Track)文書となっている。

 

IETF level W3C REC Topic
[RFC3275] Draft Std [XMLDSIG] XML デジタル署名
[RFC3076] Info [CANON] Canonical XML
- - - - - - [XMLENC] XML Encryption
[RFC3741] Info [EXCANON] Exclusive XML Canonicalization

これらのすべての標準と勧告は、アルゴリズムとキーイング情報タイプを識別するために URI [RFC2396] を使う。本書は、使いやすい URI のリファレンスリストを提供する。そして、大きな関心はあるが、メインの文書には含めることができないアルゴリズムを説明する。注意: IETF において、XML ディジタル署名を草稿標準(Draft Standard)へ格上げするのに、メインの標準文書からインターオペラビリティが証明されていないいずれのアルゴリズムの削除が必要であった。引き続き関心があると思われる最小正規(Minimal Canonicalization)アルゴリズムの削除(必要とされた)は、標準化過程仕様(standards track specification)からは外されている。それは、本書に含まれている。

本書における "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"および "OPTIONAL" というキーワードは 、[RFC2119] で説明されているように解釈されるものとする。

 

2. アルゴリズム English

URI [RFC2396] は、プロポーズト標準(Proposed Standard)からドラフト標準(Draft Standard)への転換という理由により標準からはずされているが、これは、元のプリフィックスと共に 2.4 節に含まれている。それにより、XMLDSIG 標準のネームスペースを変更する必要がない。

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

追加のアルゴリズムも以下で始まる URI に与えられている。:

http://www.w3.org/2001/04/xmldsig-more#

"xmldsig-more" をもつ URI は、これらのアルゴリズムや識別子に対する公式な W3C ステータスを意味するものではないし、または、それらはディジタル署名でのみ有効である。現在、そのような URI のデリファレンシング(dereferencing)が、仮のプレースホルダー文書を作成するかしないかは不明である。この URI プリフィックスを使用する許可は、W3C によって与えられている。

2.1. DigestMethodアルゴリズム English

これらのアルゴリズムは、DigestMethod エレメントが発生する場合は、常に使用可能である。

2.1.1. MD5 English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#md5

MD5 アルゴリズム [RFC1321] は、明示的なパラメータを取らない。MD5 DigestAlgorithm エレメントの例は以下のとおり。

<DigestAlgorithm Algorithm="http://www.w3.org/2001/04/xmldsig-more#md5"/>

MD5 ダイジェスト(MD5 digest)は、128 bit 文字列である。DigestValue エレメントの中身は、base64 [RFC2405] となり、このビット文字列を 16 オクテットのオクテットストリームとしてコード化する。

2.1.2. SHA-224 English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#sha224

SHA-224 アルゴリズム [FIPS-180-2change, RFC3874] は、明示的なパラメータを取らない。SHA-224 DigestAlgorithm エレメントの例は、以下のとおり。

<DigestAlgorithm Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha224" />

SHA-224 ダイジェスト(SHA-224 digest)は、224 bit 文字列である。DigestValue エレメントの中身は、base64 [RFC2405] となり、このビット文字列を 28 オクテットのオクテットストリームとしてコード化する。SHA-224 メッセージ・ダイジェストを計算するには、SHA-256 ダイジェストと同じぐらいの労力が必要となり、そして、XML アプリケーションにおいては、通常、簡潔さは必要条件ではないため、別の方法として SHA-256 の使用を考慮するべきである。

2.1.3. SHA-384 English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#sha384

SHA-384 アルゴリズム [FIPS-180-2] は、明示的なパラメータを取らない。SHA-384 DigestAlgorithm エレメントの例は、以下のとおり。:

<DigestAlgorithm Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha384" />

SHA-384 ダイジェスト(SHA-384 digest)は、224 bit 文字列である。DigestValue エレメントの中身は、base64 [RFC2405] となり、このビット文字列を 48 オクテットのオクテットストリームとしてコード化する。SHA-384 メッセージダイジェストを計算するには、SHA-512 ダイジェストと同じぐらいの労力が必要となり、そして、XML アプリケーションにおいては、通常、簡潔さは必要条件ではないため、別の方法として SHA-512 の使用を考慮するべきである。

2.2. SignatureMethod メッセージ認証コードアルゴリズム English

注意: 本項のいくつかの文は、読者の便宜を考慮して、[RFC3275] から複写されている。矛盾がある場合、RFC 3275 が規範となる。

2.2.1. HMAC-MD5 English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#hmac-md5

HMAC アルゴリズム [RFC2104] は、ビットでの切り捨て長をパラメータとして取る。パラメータが指定されていない場合、ハッシュのすべてのビットがアウトプットとなる。HMAC-MD5 SignatureMethod エレメントの例は、以下のとおり。:

<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-md5">

 <HMACOutputLength>112</HMACOutputLength>

</SignatureMethod>

HMACアルゴリズムのアウトプットが、最終的には、選択されているダイジェストアルゴリズムのアウトプット(おそらくは切り捨てられている)となる。この値は、ダイジェストアルゴリズムのアウトプットと同じように簡単な方法でコード化される base64 [RFC2405] となる。例えば、HMAC-MD5 ダイジェストに対する SignatureValue エレメントは 、次のようになる。

9294727A 3638BB1C 13F48EF8 158BFC9D

[RFC2104] からのテスト・ベクターから以下のようになる。

kpRyejY4uxwT9I74FYv8nQ==

スキーマ定義:

<simpleType name="HMACOutputLength">

<restriction base="integer" />

</simpleType>

DTD:

<!ELEMENT HMACOutputLength (#PCDATA) >

上記の Schema Definition と DTD は、[RFC3275] からのものである。

最近、以下のように RSA-MD5 などの署名に MD5 を使うということに対して、ある程度の暗号的疑念が生じているが、そのことは、HMAC で MD5 を使用することには影響を与えない。

2.2.2. HMAC SHA バリエーション English

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#hmac-sha224
http://www.w3.org/2001/04/xmldsig-more#hmac-sha256
http://www.w3.org/2001/04/xmldsig-more#hmac-sha384
http://www.w3.org/2001/04/xmldsig-more#hmac-sha512

SHA-224、SHA-256, SHA-384 および SHA-512 [FIPS-180-2, FIPS-180-2change, RFC3874] も、HMAC-MD5 に関して 2.2.1 節で説明されているように HMAC で使うことができる。

2.2.3. HMAC-RIPEMD160 English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160

RIPEMD-160 [RIPEMD-160] も、HMAC-MD5 に関して 2.2.1 節で説明されているように HMAC で使うことができる。

2.3. SignatureMethod Public Key Signature (SignatureMethod パブリック・キー署名)アルゴリズム English

これらのアルゴリズムは、公開鍵キーを使うという点で、2.2 節の方法とは異なっている。認証キーは、署名キー(signing key)とは異なり、その署名キーからは取り出すことはできないものである。

2.3.1. RSA-MD5 English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#rsa-md5

RSA-MD5 は、[RFC3447] に記述されている PKCS#1 v1.5 パディングアルゴリズムを意味します。この一例は、下記のとおり。

<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-md5" />

RSA-MD5 署名に対する SignatureValueの中身は、base64 [RFC3447] であり、 8.1.1 節(signature generation for the RSASSA-PKCS1-v1_5 signature scheme)の通り計算されたオクテット文字列をコード化する。[RFC3447, 9.2.1 節] での EMSA-PKCS1-V1_5-ENCOD 関数で指定されているように、署名関数へ入力される値は、ハッシュ関数に対して「前もって保留された」(pre-pend)アルゴリズムオブジェクト識別子を含んでいなければならない(MUST)が、しかし、ASN.1パーサのアベイラビリティと、OID の認識は、署名ベリファイヤに必要ではない。PKCS#1 v1.5 は 、以下のように表現される。

CRYPT (PAD (ASN.1 (OID, DIGEST (data))))

注意: パディングされた ASN.1 は、以下の形式となる。

01 | FF* | 00 | prefix | hash

垂直バー("|")は連結を表す。"01"、"FF" および "00" は、対応する HEX 値の固定オクテットであり、"FF" の後のアステリスク("*")は繰り返しを意味する。"hash"は、データの MD5 ダイジェストである。"prefix" は、PKCS #1 [RFC3447] で必要とされるASN.1 BER MD5 アルゴリズム指定子プリフィックスであり、次のようになる。

hex 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10

このプリフィックスは、標準暗号ライブラリの使用を簡単にするために含まれている。FF オクテットは、暗号化されている量の値が、RSA 係数よりも、ちょうど 1 オクテット短くなるよう充分な回数繰り返されなければならない(MUST)

コンピュータの処理能力の増大や暗号技術の進化により、RSA-MD5 の使用は、推薦されない。

2.3.2. RSA-SHA256 English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

これは、2.3.1 節で説明されているように、PKCS#1 v1.5 パディング・アルゴリズム [RFC3447] を意味するが、しかし、ASN.1 BER SHA-256アルゴリズム指定子プリフィックスがついているものである。使用の例は、以下のとおり。

<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />

2.3.3 RSA-SHA384 English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#rsa-sha384

これは、2.3.1 節で説明されているように、PKCS#1 v1.5パディング・アルゴリズム [RFC3447] を意味するが、しかし、ASN.1 BER SHA-384 アルゴリズム指定子プリフィックスがついているものである。使用例は、以下のとおり。

<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384" />

SHA-384 メッセージ・ダイジェストを計算するには、SHA-512 メッセージダイジェストと同じ労力がかかるため、RSA-SHA384 の代わりでできるだけ RSA-SHA512 が使われることが推薦される。

2.3.4. RSA-SHA512 English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#rsa-sha512

これは、2.3.1 節で説明されているように、PKCS#1 v1.5パディング・アルゴリズム [RFC3447] を意味するが、しかし、ASN.1 BER SHA-512 アルゴリズム指定子プリフィックスがついているものである。使用例は、以下のとおり。

<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512" />

2.3.5. RSA-RIPEMD160 English

Identifier:

http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160

これは、2.3.1 節で説明されているように、PKCS#1 v1.5 パディング・アルゴリズム [RFC3447] を意味するが、しかし、ASN.1 BER RIPEMD160 アルゴリズム指定子プリフィックスが付いているものである。使用例は、以下のとおり。

<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160" />

2.3.6. ECDSA-SHA* English

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha224
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512

ECDSA(Elliptic Curve Digital Signature Algorithm) [FIPS-186-2] は、DSA(DSS)署名メソッドの楕円曲線アナログである。これを SHA ハッシュ関数と XML Digital Signature でどのように使うかの詳細仕様については [X9.62] と [ECDSA] を参照。

2.3.7. ESIGN-SHA1 English

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#esign-sha1
http://www.w3.org/2001/04/xmldsig-more#esign-sha224
http://www.w3.org/2001/04/xmldsig-more#esign-sha256
http://www.w3.org/2001/04/xmldsig-more#esign-sha384
http://www.w3.org/2001/04/xmldsig-more#esign-sha512

[IEEE-P1363a] で定義されている ESGN アルゴリズムは、整数分解問題に基づいた署名スキームである。これは、以前のディジタル署名よりもずっと高速であり、したがって、ESIGN は、特別なコプロセッサ無しでスマートカードに組み込むことができる。

以下に使用例が示されている。

<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#esign-sha1" />

2.4. Minimal Canonicalization(最小正規化) English

現在までに、Minimal Canonicalization(最小正規化)の 2つのインターオペラブルな独立したインプリメンテーションは発表されていない。したがって、XML Digital Signature が、Proposed Standard(提案標準) [RFC3075] から Draft Standard(草稿標準) [RFC3275] に格上げされた場合、Minimal Canonicalization(最小正規化)は、標準追跡文書からは除去された。しかし、Minimal Canonicalization(最小正規化)には、今後、使用される可能性を含めまだ関心がありある。その定義については[RFC3075] 6.5.1 節を参照のこと。

参考: その識別子は、以下のままである。

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

2.5. 変換(Transform)アルゴリズム English

注意: すべての CanonicalizationMethod アルゴリズムは、変換アルゴリズムとしても使うことができる。

2.5.1. XPointer English

Identifier:

http://www.w3.org/2001/04/xmldsig-more/xptr

この変換アルゴリズムは、[XPointer] を明示的パラメータとして読み込む。 使用の例は以下のとおり [RFC3092]。:

<Transform Algorithm="http://www.w3.org/2001/04/xmldsig-more/xptr">

<XPointer xmlns="http://www.w3.org/2001/04/xmldsig-more/xptr">

xpointer(id("foo")) xmlns(bar=http://foobar.example)

xpointer(//bar:Zab[@Id="foo"])

</XPointer>

</Transform>

Schema Definition:

<element name="XPointer" type="string">

DTD:

<!ELEMENT XPointer (#PCDATA) >

この変換へのインプットはオクテット・ストリーム(その後、XML にパースされる)である。

この変換からアウトプットは、ノード・セットであり、XPointer の結果は、同じ文書 XPointer に対して XMLDSIG 仕様 [RFC3275] で定義されているように処理される。

2.6. EncryptionMethodアルゴリズム English

本項は、いくつかの EncryptionMethod アルゴリズムの識別子や情報を説明する。

2.6.1. ARCFOUR 暗号化アルゴリズム English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#arcfour

ARCFOURは、高速で、単純なストリームの暗号化アルゴリズムであり、RSA Security の RC4 アルゴリズムと互換性がある。ARCFOUR を使った EncryptionMethod エレメントの例は 、以下のとおり。

<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#arcfour">

<KeySize>40</KeySize>

</EncryptionMethod>

注意: ARCFOUR は、 [XMLENC] で仕様定義されている汎用 KeySize パラメータを使う。

2.6.2. Camellia ブロック暗号化 English

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc
http://www.w3.org/2001/04/xmldsig-more#camellia192-cbc
http://www.w3.org/2001/04/xmldsig-more#camellia256-cbc

Camellia は、AES [Camellia, RFC3713] と同じインタフェース(つまり、128 bit のブロック・サイズと 128 bit、192 bit および 256 bit の鍵長)を持つ効率的でセキュアなブロック暗号である。XML Encryption(XML暗号化)では、Camellia は、AES と同じ方法で使われている。つまり、それは、128 bit の初期化ベクター(IV)を持つ CBC(Cipher Block Chaining)モードで使われる。結果の暗号テキストは、IV がプリフィックスとして付いている。それがもし XML アウトプットに含まれると、base64 エンコードされることになる。Camellia の EncryptionMethod の例が以下に示されている。

<EncryptionMethod Algorithm= "http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc" />

2.6.3. Camellia キー・ラップ English

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#kw-camellia128
http://www.w3.org/2001/04/xmldsig-more#kw-camellia192
http://www.w3.org/2001/04/xmldsig-more#kw-camellia256

Camellia [Camellia, RFC3713] キー・ラップは、XML Encryption(XML暗号化)標準で定義されている AES キーラップアルゴリズム [RFC3394] と同じである。(この場合、"AES" を ”Camellia" に置き換えて読むだけである。)AES キーラップと同じように、チェック値は 、0xA6A6A6A6A6A6A6A6 である。

このアルゴリズムは、ラッピングで使われる Camellia キー(キー暗号化キー(key encrypting key)また KEK と呼ばれる)のサイズに関係なく同じである。Camellia のインプリメンテーションはオプショナルである。しかし、それがサポートされているのであれば、KEK サイズとラップされた鍵長の組み合わせがサポートされるべきか、オプションでサポートされるべきかは、同じインプリメンテーションガイドラインが AES に従うべきである。つまり、Camellia キー・ラップがサポートされるのであれば、128 bit キーのラッピング(128 bit KEKで)と 256 bit キーのラッピング(256 bit KEKで)が要求され(REQUIRED)、そして、他のすべての組み合わせは 、任意(OPTIONAL)である。)

以下に使用例が示されている。

<EncryptionMethod Algorithm= "http://www.w3.org/2001/04/xmldsig-more#kw-camellia128" />

2.6.4. PSEC-KEM English

Identifier:

http://www.w3.org/2001/04/xmldsig-more#psec-kem

PSEC-KEM アルゴリズム([ISO/IEC-18033-2] で定義されている)は、楕円形曲線暗号化を使った鍵カプセル化メカニズムである。

以下に使用例が示されている。:

<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#psec-kem">

<ECParameters>

<Version>version</Version>

<FieldID>id</FieldID>

<Curve>curve</Curve>

<Base>base</Base>

<Order>order</Order>

<Cofactor>cofactor</Cofactor>

</ECParameters>

</EncryptionMethod>

上記のパラメータに関する情報については [ISO/IEC-18033-2] を参照のこと。

 

3. KeyInfo English

3.1 節に、新しい KeyInfo エレメントの子が定義されている。これに対して、3.2 節では、RetrievalMethod での使用に対して追加の KeyInfo Type 値が定義されている。

3.1. PKCS #7 Bag of Certificate および CRL English

PKCS #7 [RFC2315] の "signedData" も、bag of certificates(認証群)や CRL(certificate revocation list:認証取り消しリスト)として使うことができる。 PKCS7signedData エレメントは、KeyInfor 内でのそのような構造に対応するよう定義されている。バイナリ PKCS #7 構造は 、base64 [RFC2405] でコード化されている。提示されているいずれの署名者(signer)情報は、無視される。以下は、base64 データを除去する例である [RFC3092]。

<foo:PKCS7signedData xmlns:foo="http://www.w3.org/2001/04/xmldsig-more"> ... </foo:PKCS7signedData>

3.2. 追加 RetrievalMethod Type 値 English

RetrievalMethod の Type 属性は、取り出されるべきデータのタイプを示すオプショナルの識別子である。XML 構造をもつすべての KeyInfo タイプに対する RetrievalMethod リファレンスをデリファレンスした結果は、XML エレメントと、あるいは、そのエレメントをルートとする文書である。各種の生の("raw")キー情報タイプは、バイナリ値を返却する。したがって、それらは、明確にパースができないために、Type 属性を必要とする。

Identifiers:

http://www.w3.org/2001/04/xmldsig-more#KeyValue
http://www.w3.org/2001/04/xmldsig-more#RetrievalMethod
http://www.w3.org/2001/04/xmldsig-more#KeyName
http://www.w3.org/2001/04/xmldsig-more#rawX509CRL
http://www.w3.org/2001/04/xmldsig-more#rawPGPKeyPacket
http://www.w3.org/2001/04/xmldsig-more#rawSPKISexp
http://www.w3.org/2001/04/xmldsig-more#PKCS7signedData
http://www.w3.org/2001/04/xmldsig-more#rawPKCS7signedData

 

4. IANA についての考慮事項 English

人は彼ら自身のユニークな URI [RFC2396] を構築し、おそらくは、W3C から(適切であれば)から URI を得ることも容易ではあるが、本書で順列化されている以上の追加の "http://www.w3.org/2001/04/xmldsig-more#"URL が作成されることは意図されていない。(W3C Namespace 安定性基準は、"http://www.w3.org/2000/09/xmldsig#" 下での新しい URI の作成を禁じている。)

 

5. セキュリティについての考慮事項 English

コンピュータの速度は暗号技術の進展から、DigestMethod として MD5 を使うこと、そして、RSA-MD5 SignatureMethod で MD5 を使うことは、推薦されていない(NOT RECOMMENDED)。懸念されている暗号面での進化は、HMAC-MD5 のセキュリティには影響を与えないが、しかし、SHA シリーズのアルゴリズムのひとつを使わないという理由はほとんどない。

 

謝辞 English

Glenn Adams, Merlin Hughs, Gregor Karlinger, Brian LaMachia, Shiho Moriai, Joseph Reagle, Russ Housley, and Joel Halpern.

 

規範的参考文献

[Camellia] "Camellia: A 128-bit Block Cipher Suitable for Multiple Platforms - Design and Analysis -", K. Aoki, T. Ichikawa, M. Matsui, S. Moriai, J. Nakajima, T. Tokita, In Selected Areas in Cryptography, 7th Annual International Workshop, SAC 2000, 2000年 8月,
Proceedings, Lecture Notes in Computer Science 2012, pp. 39-56, Springer- Verlag, 2001年.
 
[ECDSA] Blake-Wilson, S., Karlinger, G., Kobayashi, T., and Y. Wang,
"Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures",
RFC 4050, 2005年 4月.
 
[FIPS-180-2] "Secure Hash Standard"(SHA-1/256/384/512) ,
US Federal Information Processing Standard, NIST, 2002年 8月 1日.
 
[FIPS-180-2change] "FIPS 180-2, Secure Hash Standard Change Notice 1",
SHA-224 を [FIPS 180-2] に追加, 2004年 2月25日.
 
[FIPS-186-2] "Digital Signature Standard",
US Federal Information Processing Standard, NIST, 2000年.
 
[IEEE-P1363a] "Standard Specifications for Public Key Cryptography: Additional Techniques", 2002年10月.
 
[ISO/IEC-18033-2] "Information technology -- Security techniques -- Encryption algorithms -- Part 3: Asymmetric ciphers", CD, 2002年10月.
 
[RFC1321] Rivest, R.,
"The MD5 Message-Digest Algorithm ",
RFC 1321, 1992年 4月.
 
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti,
"HMAC: Keyed-Hashing for Message Authentication",
RFC 2104, 1997年 2月.
 
[RFC2119] Bradner, S.,
"Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, 1997年 3月.
 
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, 1998年 8月.
 
[RFC2405] Madson, C. and N. Doraswamy,
"The ESP DES-CBC Cipher Algorithm With Explicit IV",
RFC 2405, 1998年11月.
 
[RFC2315] Kaliski, B.,
"PKCS #7: Cryptographic Message Syntax Version 1.5",
RFC 2315, 1998年 3月.
 
[RFC3075] Eastlake 3rd, D., Reagle, J., and D. Solo,
"XML- Signature Syntax and Processing",
RFC 3075, 2001年 3月.
(RFC 3075 was obsoleted by RFC 3275 but is referenced in this document for its description of Minimal Canonicalization which was dropped in RFC 3275.)
 
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo,
"(Extensible Markup Language) XML-Signature Syntax and Processing",
RFC 3275, 2002年 3月.
 
[RFC3394] Schaad, J. and R. Housley,
"Advanced Encryption Standard (AES) Key Wrap Algorithm",
RFC 3394, 2002年 9月.
 
[RFC3447] Jonsson, J. and B. Kaliski,
"Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1",
RFC 3447(English), 2003年 2月.
 
[RFC3713] Matsui, M., Nakajima, J., and S. Moriai,
"A Description of the Camellia Encryption Algorithm",
RFC 3713, 2004年 4月.
 
[RFC3874] Housley, R.,
"A 224-bit One-way Hash Function: SHA-224",
RFC 3874, 2004年 9月.
 
[RIPEMD-160] ISO/IEC 10118-3:1998, "Information Technology - Security techniques - Hash-functions - Part3: Dedicated hash- functions", ISO, 1998年.
 
[X9.62] X9.62-200X,
"Public Key Cryptography for the Financial Services Industry:
The Elliptic Curve Digital Signature Algorithm (ECDSA)", Accredited Standards Committee X9, American National Standards Institute.

 

[XMLDSIG]

"XML-Signature Syntax and Processing",
D. Eastlake 3rd, J. Reagle, & D. Solo, 12 2002年 2月.
<http://www.w3.org/TR/xmldsig-core/>
 

[XMLENC] "XML Encryption Syntax and Processing",
J. Reagle, D. Eastlake, 2002年12月.
<http://www.w3.org/TR/2001/RED-xmlenc-core- 20021210/>
 
[XPointer] "XML Pointer Language (XPointer) Version 1.0",
W3C working draft, Steve DeRose, Eve Maler, Ron Daniel Jr., 2001年 1月.
<http://www.w3.org/TR/2001/WD-xptr-20010108>

 

参考情報

[CANON] "Canonical XML Version 1.0", John Boyer.
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
 
[EXCANON] "Exclusive XML Canonicalization Version 1.0", D. Eastlake, J. Reagle, 2002年 7月18日. <http://www.w3.org/TR/REC-xml-enc-c14n-20020718/>.
 
[RFC3076] Boyer, J.,
"Canonical XML Version 1.0",
RFC 3076, 2001年 3月.
 
[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond,
"Etymology of "Foo"",
RFC 3092, 2001年.
 
[RFC3741] Boyer, J., Eastlake 3rd, D., and J. Reagle,
"Exclusive XML Canonicalization, Version 1.0",
RFC 3741, 2004年 3月.

 

著者のアドレス

Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street Milford,
MA 01757 USA

電話: +1-508-786-7554 (w)
    +1-508-634-2066 (h)
EMail: Donald.Eastlake@motorola.com

 

著作権表記全文

Copyright (C) The Internet Society (2005).

本書は、BCP 78 に含まれている権利、ライセンスおよび制限の対象となっており、本書で明記されている場合を除いて、著者がそれらのすべての権利を有するものとする。

本書および本書に含まれている情報は、「そのまま」の状態で提供されるものとし、寄稿者、その寄稿者が代表する、または、それにより後援されている組織(ある場合)、インターネット・ソサエティ(INTERNET SOCIETY)およびインターネット・エンジニアリング・タスク・フォースは、明示的にも暗黙のうちにも、そうとは限定されないが、本書での情報が、いかなる権利をも侵害しないとか、特定の目的に対して商品性や適性を意図した保証を含むすべての保証を拒否するものである。

知的財産権

この文書に記述される技術の実装および使用に関係すると主張される、知的財産権およびその他の権利の有効性または範囲に関して、またこのような権利の下でのあらゆる権利が効力を持つ範囲に関して、IETF はいかなる立場もとらず、また、IETF はそのような権利を確認するためのいかなる取り組みを行ったことも表明しない。 RFC 文書における権利に関する手続きの情報は、BCP 78 および BCP 79 に記述されている。

IETF 事務局に提出された IPR 公開文書のコピーおよび利用可能となるライセンス保証のコピー、あるいは、この仕様の実装者やユーザによる所有権の使用に対する一般的な権利や許可を得るために行われた試みの結果は、IETF オンライン IPR リポジリ(http://www.ietf.org/ipr)から入手可能である。

IETF は、どのような利害関係者に対しても、この標準を実装するために必要な技術をカバーする著作権や特許、特許出願、その他の所有権に対して注意を払うように依頼する。 IETF(ietf-ipr@ietf.org)までその情報を送ってください。

謝辞

RFC エディター機能に対する資金提供は、現在、インターネット・ソサエティ(Internet Society)により提供されている。