[要約] RFC 4051は、XMLセキュリティのための追加のUniform Resource Identifiers (URIs)に関する情報を提供します。このRFCの目的は、XMLセキュリティの実装において、新しいURIスキームを使用するためのガイドラインを提供することです。
Network Working Group D. Eastlake 3rd
Request for Comments: 4051 Motorola Laboratories
Category: Standards Track April 2005
Additional XML Security Uniform Resource Identifiers (URIs)
追加のXMLセキュリティユニフォームリソース識別子（URI）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
A number of Uniform Resource Identifiers (URIs) intended for use with XML Digital Signatures, Encryption, and Canonicalization are defined. These URIs identify algorithms and types of keying information.
XMLデジタル署名、暗号化、および標準化を使用することを目的とした多くの均一なリソース識別子（URI）が定義されています。これらのURIは、アルゴリズムとキーイング情報の種類を識別します。
Table of Contents
目次
1. Introduction.................................................. 2
2. Algorithms.................................................... 3
2.1. DigestMethod Algorithms................................. 3
2.1.1. MD5............................................. 3
2.1.2. SHA-224......................................... 3
2.1.3. SHA-384......................................... 4
2.2. SignatureMethod Message Authentication Code Algorithms.. 4
2.2.1. HMAC-MD5........................................ 4
2.2.2. HMAC SHA Variations............................. 5
2.2.3. HMAC-RIPEMD160.................................. 6
2.3. SignatureMethod Public Key Signature Algorithms......... 6
2.3.1. RSA-MD5......................................... 6
2.3.2. RSA-SHA256...................................... 7
2.3.3. RSA-SHA384...................................... 7
2.3.4. RSA-SHA512...................................... 7
2.3.5. RSA-RIPEMD160................................... 8
2.3.6. ECDSA-SHA*...................................... 8
2.3.7. ESIGN-SHA1...................................... 8
2.4. Minimal Canonicalization................................ 9
2.5. Transform Algorithms.................................... 9
2.5.1. XPointer........................................ 9
2.6. EncryptionMethod Algorithms............................. 10
2.6.1. ARCFOUR Encryption Algorithm.................... 10
2.6.2. Camellia Block Encryption....................... 10
2.6.3. Camellia Key Wrap............................... 11
2.6.4. PSEC-KEM........................................ 11
3. KeyInfo....................................................... 12
3.1. PKCS #7 Bag of Certificates and CRLs.................... 12
3.2. Additional RetrievalMethod Type Values.................. 12
4. IANA Considerations........................................... 13
5. Security Considerations....................................... 13
Acknowledgements.................................................. 13
Normative References.............................................. 13
Informative References............................................ 15
Author's Address.................................................. 16
Full Copyright Statement.......................................... 17
XML Digital Signatures, Canonicalization, and Encryption have been standardized by the W3C and the joint IETF/W3C XMLDSIG working group. All of these are now W3C Recommendations and IETF Informational or Standards Track documents. They are available as follows:
XMLデジタル署名、標準化、および暗号化は、W3CおよびジョイントIETF/W3C XMLDSIGワーキンググループによって標準化されています。これらはすべてW3Cの推奨事項であり、IETF InformationalまたはStandardsはドキュメントを追跡しています。次のように利用できます。
IETF level W3C REC Topic
----------- ------- -----
[RFC3275] Draft Std [XMLDSIG] XML Digital Signatures
[RFC3076] Info [CANON] Canonical XML
- - - - - - [XMLENC] XML Encryption
[RFC3741] Info [EXCANON] Exclusive XML Canonicalization
All of these standards and recommendations use URIs [RFC2396] to identify algorithms and keying information types. This document provides a convenient reference list of URIs and descriptions for algorithms in which there is substantial interest, but which cannot or have not been included in the main documents. Note that raising XML digital signature to a Draft Standard in the IETF required removal of any algorithms for which interoperability from the main standards document has not been demonstrated. This required removal of the Minimal Canonicalization algorithm, in which there appears to be a continued interest, to be dropped from the standards track specification. It is included here.
これらの標準と推奨事項はすべて、URIS [RFC2396]を使用して、アルゴリズムとキーイング情報タイプを識別します。このドキュメントは、非常に関心があるが、メインドキュメントに含まれていない、または含まれていないアルゴリズムのURIの便利な参照リストと説明の説明を提供します。IETFのドラフト標準にXMLデジタル署名を上げるには、メイン標準ドキュメントからの相互運用性が実証されていないアルゴリズムを削除する必要があることに注意してください。これには、標準のトラック仕様から削除されるために、継続的な関心があると思われる最小限の標準化アルゴリズムを削除する必要がありました。ここに含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The URI [RFC2396] being dropped from the standard because of the transition from Proposed Standard to Draft Standard is included in Section 2.4 with its original prefix so as to avoid changing the XMLDSIG standard's namespace.
XMLDSIG標準の名前空間の変更を避けるために、提案された標準からドラフト標準への移行のために、標準から標準のドラフト標準への移行のために標準から削除されているURI [RFC2396]が標準から削除されます。
http://www.w3.org/2000/09/xmldsig#
Additional algorithms are given URIs that start with:
追加のアルゴリズムには、以下から始まるurisが与えられます。
http://www.w3.org/2001/04/xmldsig-more#
An "xmldsig-more" URI does not imply any official W3C status for these algorithms or identifiers or that they are only useful in digital signatures. Currently, dereferencing such URIs may or may not produce a temporary placeholder document. Permission to use this URI prefix has been given by the W3C.
「XMLDSIG-MORE」URIは、これらのアルゴリズムまたは識別子の公式W3Cステータス、またはデジタル署名でのみ有用であることを意味するものではありません。現在、そのようなURIを宣告すると、一時的なプレースホルダー文書が作成される場合とそうでない場合があります。このURIプレフィックスを使用する許可は、W3Cによって与えられています。
These algorithms are usable wherever a DigestMethod element occurs.
これらのアルゴリズムは、DigestMethod要素が発生した場合は使用できます。
Identifier:
識別子：
http://www.w3.org/2001/04/xmldsig-more#md5
The MD5 algorithm [RFC1321] takes no explicit parameters. An example of an MD5 DigestAlgorithm element is:
MD5アルゴリズム[RFC1321]は、明示的なパラメーターを取得しません。MD5消化器gorthmer要素の例は次のとおりです。
<DigestAlgorithm
Algorithm="http://www.w3.org/2001/04/xmldsig-more#md5"/>
An MD5 digest is a 128-bit string. The content of the DigestValue element shall be the base64 [RFC2405] encoding of this bit string viewed as a 16-octet octet stream.
MD5ダイジェストは128ビット文字列です。Digestvalue要素の内容は、16オクテットのオクテットストリームと見なされるこのビット文字列のエンコードをbase64 [RFC2405]エンコードするものとします。
Identifier: http://www.w3.org/2001/04/xmldsig-more#sha224
識別子：http：//www.w3.org/2001/04/xmldsig-more#sha224
The SHA-224 algorithm [FIPS-180-2change, RFC3874] takes no explicit parameters. An example of a SHA-224 DigestAlgorithm element is:
SHA-224アルゴリズム[FIPS-180-2Change、RFC3874]は、明示的なパラメーターを取得しません。SHA-224消化器gorthmの要素の例は次のとおりです。
<DigestAlgorithm
Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha224" />
A SHA-224 digest is a 224 bit string. The content of the DigestValue element shall be the base64 [RFC2405] encoding of this string viewed as a 28-octet stream. Because it takes roughly the same amount of effort to compute a SHA-224 message digest as a SHA-256 digest, and terseness is usually not a criteria in an XML application, consideration should be given to the use of SHA-256 as an alternative.
SHA-224ダイジェストは224ビット文字列です。DigestValue要素の内容は、28オクテットのストリームと見なされるこの文字列のbase64 [RFC2405]エンコードでなければなりません。SHA-224メッセージダイジェストをSHA-256ダイジェストとして計算するにはほぼ同じ努力が必要であり、通常はXMLアプリケーションの基準ではないため、代替としてSHA-256を使用することを考慮する必要があります。。
Identifier: http://www.w3.org/2001/04/xmldsig-more#sha384
識別子：http：//www.w3.org/2001/04/xmldsig-more#sha384
The SHA-384 algorithm [FIPS-180-2] takes no explicit parameters. An example of a SHA-384 DigestAlgorithm element is:
SHA-384アルゴリズム[FIPS-180-2]は、明示的なパラメーターを取得しません。SHA-384消化器goRithm要素の例は次のとおりです。
<DigestAlgorithm
Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha384" />
A SHA-384 digest is a 384 bit string. The content of the DigestValue element shall be the base64 [RFC2405] encoding of this string viewed as a 48-octet stream. Because it takes roughly the same amount of effort to compute a SHA-384 message digest as a SHA-512 digest and terseness is usually not a criteria in XML application, consideration should be given to the use of SHA-512 as an alternative.
SHA-384ダイジェストは384ビット文字列です。DigestValue要素の内容は、48オクテットストリームと見なされるこの文字列のbase64 [RFC2405]エンコードでなければなりません。SHA-384メッセージダイジェストをSHA-512ダイジェストとして計算するにはほぼ同じ努力が必要であり、通常はXMLアプリケーションの基準ではないため、代替としてSHA-512の使用を考慮する必要があります。
Note: Some text in this section is duplicated from [RFC3275] for the convenience of the reader. RFC 3275 is normative in case of conflict.
注：このセクションの一部のテキストは、読者の利便性のために[RFC3275]から複製されています。RFC 3275は紛争の場合に規範的です。
Identifier: http://www.w3.org/2001/04/xmldsig-more#hmac-md5
識別子：http：//www.w3.org/2001/04/xmldsig-more#hmac-md5
The HMAC algorithm [RFC2104] takes the truncation length in bits as a parameter; if the parameter is not specified then all the bits of the hash are output. An example of an HMAC-MD5 SignatureMethod element is as follows:
HMACアルゴリズム[RFC2104]は、パラメーターとしてビットの切り捨ての長さを取得します。パラメーターが指定されていない場合、ハッシュのすべてのビットが出力されます。HMAC-MD5 SignatureMethod要素の例は次のとおりです。
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-md5">
<HMACOutputLength>112</HMACOutputLength>
</SignatureMethod>
The output of the HMAC algorithm is ultimately the output (possibly truncated) of the chosen digest algorithm. This value shall be base64 [RFC2405] encoded in the same straightforward fashion as the output of the digest algorithms. For example, the SignatureValue element for the HMAC-MD5 digest
HMACアルゴリズムの出力は、最終的に選択したダイジェストアルゴリズムの出力（おそらく切り捨てられた）です。この値は、ダイジェストアルゴリズムの出力と同じ簡単な方法でエンコードされたbase64 [rfc2405]でなければなりません。たとえば、HMAC-MD5ダイジェストのSignatureValue要素
9294727A 3638BB1C 13F48EF8 158BFC9D
9294727a 3638bb1c 13f48ef8 158bfc9d
from the test vectors in [RFC2104] would be
[RFC2104]のテストベクトルから
kpRyejY4uxwT9I74FYv8nQ==
kpryejy4uxwt9i74fyv8nq ==
Schema Definition:
スキーマ定義：
<simpleType name="HMACOutputLength">
<restriction base="integer" />
</simpleType>
DTD:
DTD：
<!ELEMENT HMACOutputLength (#PCDATA) >
The Schema Definition and DTD immediately shown above are taken from [RFC3275].
上記のスキーマ定義とDTDは[RFC3275]から取得されます。
Although some cryptographic suspicions have recently been cast on MD5 for use in signatures such as RSA-MD5 below, this does not effect use of MD5 in HMAC.
下のRSA-MD5などの署名で使用するために、最近MD5でいくつかの暗号化の疑いがキャストされましたが、これはHMACでのMD5の使用に影響しません。
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, and SHA-512 [FIPS-180-2, FIPS-180-2change, RFC3874] can also be used in HMAC as described in section 2.2.1 for HMAC-MD5.
SHA-224、SHA-256、SHA-384、およびSHA-512 [FIPS-180-2、FIPS-180-2Change、RFC3874]は、HMAC-MD5のセクション2.2.1で説明されているようにHMACでも使用できます。
Identifier: http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160
識別子：http：//www.w3.org/2001/04/xmldsig-more#hmac-ripemd160
RIPEMD-160 [RIPEMD-160] can also be used in HMAC as described in section 2.2.1 for HMAC-MD5.
RIPEMD-160 [RIPEMD-160]は、HMAC-MD5のセクション2.2.1で説明されているように、HMACでも使用できます。
These algorithms are distinguished from those in Section 2.2 in that they use public key methods. The verification key is different from and not feasibly derivable from the signing key.
これらのアルゴリズムは、公開キー方法を使用するという点で、セクション2.2のアルゴリズムと区別されます。検証キーは、署名キーとは異なるものであり、署名キーから派生できないものではありません。
Identifier: http://www.w3.org/2001/04/xmldsig-more#rsa-md5
識別子：http：//www.w3.org/2001/04/xmldsig-more#rsa-md5
RSA-MD5 implies the PKCS#1 v1.5 padding algorithm described in [RFC3447]. An example of use is
RSA-MD5は、[RFC3447]で説明されているPKCS＃1 V1.5パディングアルゴリズムを意味します。使用の例は次のとおりです
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-md5" />
The SignatureValue content for an RSA-MD5 signature is the base64 [RFC2405] encoding of the octet string computed as per [RFC3447], section 8.1.1, signature generation for the RSASSA-PKCS1-v1_5 signature scheme. As specified in the EMSA-PKCS1-V1_5-ENCODE function in [RFC3447, section 9.2.1], the value input to the signature function MUST contain a pre-pended algorithm object identifier for the hash function, but the availability of an ASN.1 parser and recognition of OIDs are not required of a signature verifier. The PKCS#1 v1.5 representation appears as:
RSA-MD5署名の署名バリューコンテンツは、[RFC3447]、セクション8.1.1、RSASSA-PKCS1-V1_5署名スキームの署名生成に従って計算されたオクテット文字列のベース64 [RFC2405]エンコードです。[RFC3447、セクション9.2.1]のEMSA-PKCS1-V1_5-ENCODE関数で指定されているように、署名関数への値入力には、ハッシュ関数の事前に塗装されたアルゴリズムオブジェクト識別子を含める必要がありますが、ASNの可用性を含める必要があります。1 Signature VerifierのParserとOIDの認識は必要ありません。PKCS＃1 V1.5表現は次のように表示されます。
CRYPT (PAD (ASN.1 (OID, DIGEST (data))))
Crypt（Pad（asn.1（oid、digest（data））））
Note that the padded ASN.1 will be of the following form:
パッド入りのasn.1は次の形式であることに注意してください。
01 | FF* | 00 | prefix | hash
01 |ff* |00 |プレフィックス|ハッシュ
Vertical bar ("|") represents concatenation. "01", "FF", and "00" are fixed octets of the corresponding hexadecimal value and the asterisk ("*") after "FF" indicates repetition. "hash" is the MD5 digest of the data. "prefix" is the ASN.1 BER MD5 algorithm designator prefix required in PKCS #1 [RFC3447], that is:
垂直バー（ "|"）は連結を表します。「01」、「ff」、および「00」は、対応する六量体値の固定オクテットであり、「ff」の後のアスタリスク（ "*"）は繰り返しを示します。「ハッシュ」は、データのMD5ダイジェストです。「プレフィックス」は、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
ヘックス30 20 30 0C 06 08 2A 86 48 86 F7 02 05 05 00 04 10
This prefix is included to facilitate the use of standard cryptographic libraries. The FF octet MUST be repeated enough times that the value of the quantity being CRYPTed is exactly one octet shorter than the RSA modulus.
このプレフィックスは、標準の暗号化ライブラリの使用を容易にするために含まれています。FFオクテットは、登く量の値がRSAモジュラスよりもちょうど1オクテット短いことを十分に繰り返す必要があります。
Due to increases in computer processor power and advances in cryptography, use of RSA-MD5 is NOT RECOMMENDED.
コンピュータープロセッサの電力の増加と暗号化の進歩により、RSA-MD5の使用は推奨されません。
Identifier: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
識別子：http：//www.w3.org/2001/04/xmldsig-more#rsa-sha256
This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described in section 2.3.1, but with the ASN.1 BER SHA-256 algorithm designator prefix. An example of use is:
これは、セクション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" />
Identifier: http://www.w3.org/2001/04/xmldsig-more#rsa-sha384
識別子：http：//www.w3.org/2001/04/xmldsig-more#rsa-sha384
This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described in section 2.3.1, but with the ASN.1 BER SHA-384 algorithm designator prefix. An example of use is:
これは、セクション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" />
Because it takes about the same effort to calculate a SHA-384 message digest as a SHA-512 message digest, it is suggested that RSA-SHA512 be used in preference to RSA-SHA384 where possible.
SHA-384メッセージダイジェストをSHA-512メッセージダイジェストとして計算するのにほぼ同じ努力が必要であるため、RSA-SHA512を可能な限りRSA-Sha384よりも優先して使用することをお勧めします。
Identifier: http://www.w3.org/2001/04/xmldsig-more#rsa-sha512
識別子：http：//www.w3.org/2001/04/xmldsig-more#rsa-sha512
This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described in section 2.3.1, but with the ASN.1 BER SHA-512 algorithm designator prefix. An example of use is:
これは、セクション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" />
Identifier: http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160
識別子：http：//www.w3.org/2001/04/xmldsig-more/rsa-ripemd160
This implies the PKCS#1 v1.5 padding algorithm [RFC3447], as described in section 2.3.1, but with the ASN.1 BER RIPEMD160 algorithm designator prefix. An example of use is:
これは、セクション2.3.1で説明されているように、PKCS＃1 V1.5パディングアルゴリズム[RFC3447]を意味しますが、ASN.1 BER RIPEMD160アルゴリズム指定のプレフィックスを意味します。使用の例は次のとおりです。
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160" />
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
The Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS-186-2] is the elliptic curve analogue of the DSA (DSS) signature method. For detailed specifications on how to use it with SHA hash functions and XML Digital Signature, please see [X9.62] and [ECDSA].
Elliptic Curve Digital Signature Algorithm（ECDSA）[FIPS-186-2]は、DSA（DSS）署名法の楕円曲線類似体です。Sha Hash関数とXMLデジタル署名でそれを使用する方法に関する詳細な仕様については、[X9.62]および[ECDSA]を参照してください。
Identifier
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
The ESIGN algorithm specified in [IEEE-P1363a] is a signature scheme based on the integer factorization problem. It is much faster than previous digital signature schemes so ESIGN can be implemented on smart cards without special co-processors.
[IEEE-P1363A]で指定されているESIGNアルゴリズムは、整数因子化問題に基づく署名スキームです。以前のデジタル署名スキームよりもはるかに高速であるため、特別な共同プロセッサなしではesignをスマートカードに実装できます。
An example of use is:
使用の例は次のとおりです。
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#esign-sha1" />
Thus far two independent interoperable implementations of Minimal Canonicalization have not been announced. Therefore, when XML Digital Signature was advanced from Proposed Standard [RFC3075] to Draft Standard [RFC3275], Minimal Canonicalization was dropped from the standards track documents. However, there is still interest in Minimal Canonicalization, indicating its possible future use. For its definition, see [RFC3075], Section 6.5.1.
これまで、最小限の標準化の2つの独立した相互運用可能な実装は発表されていません。したがって、XMLデジタル署名が提案された標準[RFC3075]から標準[RFC3275]のドラフトに進出した場合、標準の追跡ドキュメントから最小限の標準化が削除されました。ただし、最小限の標準化にはまだ関心があり、将来の使用の可能性を示しています。その定義については、[RFC3075]、セクション6.5.1を参照してください。
For reference, its identifier remains: http://www.w3.org/2000/09/xmldsig#minimal
参照のために、その識別子は次のとおりです：http：//www.w3.org/2000/09/xmldsig#minimal
Note that all CanonicalizationMethod algorithms can also be used as transform algorithms.
すべてのCanonicalizationMethodアルゴリズムは、変換アルゴリズムとしても使用できることに注意してください。
Identifier: http://www.w3.org/2001/04/xmldsig-more/xptr
識別子：http：//www.w3.org/2001/04/xmldsig-more/xptr
This transform algorithm takes an [XPointer] as an explicit parameter. An example of use is [RFC3092]:
この変換アルゴリズムは、[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:
DTD：
<!ELEMENT XPointer (#PCDATA) >
Input to this transform is an octet stream (which is then parsed into XML).
この変換への入力は、オクテットストリームです（その後、XMLに解析されます）。
Output from this transform is a node set; the results of the XPointer are processed as defined in the XMLDSIG specification [RFC3275] for a same document XPointer.
この変換からの出力はノードセットです。Xpointerの結果は、同じドキュメントXPointerのXMLDSIG仕様[RFC3275]で定義されているように処理されます。
This subsection gives identifiers and information for several EncryptionMethod Algorithms.
このサブセクションは、いくつかのencryptionmethodアルゴリズムの識別子と情報を提供します。
Identifier: http://www.w3.org/2001/04/xmldsig-more#arcfour
識別子：http：//www.w3.org/2001/04/xmldsig-more#arcfour
ARCFOUR is a fast, simple stream encryption algorithm that is compatible with RSA Security's RC4 algorithm. An example of the EncryptionMethod element using ARCFOUR is
ArcFourは、RSAセキュリティのRC4アルゴリズムと互換性のある高速でシンプルなストリーム暗号化アルゴリズムです。arcfourを使用したencryptionmethod要素の例です
<EncryptionMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#arcfour">
<KeySize>40</KeySize>
</EncryptionMethod>
Note that Arcfour makes use of the generic KeySize parameter specified and defined in [XMLENC].
ArcFourは、[XMLENC]で指定および定義されている汎用キーサイズパラメーターを使用していることに注意してください。
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 is an efficient and secure block cipher with the same interface as the AES [Camellia, RFC3713], that is 128-bit block size and 128, 192, and 256 bit key sizes. In XML Encryption, Camellia is used in the same way as the AES: It is used in the Cipher Block Chaining (CBC) mode with a 128-bit initialization vector (IV). The resulting cipher text is prefixed by the IV. If included in XML output, it is then base64 encoded. An example Camellia EncryptionMethod is as follows:
Camelliaは、AES [Camellia、RFC3713]、つまり128ビットブロックサイズと128、192、および256ビットキーサイズと同じインターフェイスを持つ効率的で安全なブロック暗号です。XML暗号化では、CamelliaはAESと同じ方法で使用されます。128ビット初期化ベクトル（IV）を備えた暗号ブロックチェーン（CBC）モードで使用されます。結果の暗号テキストには、IVが付いています。XML出力に含まれる場合、Base64エンコードされます。Camellia encryptionMethodの例は次のとおりです。
<EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc" />
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
The Camellia [Camellia, RFC3713] key wrap is identical to the AES key wrap algorithm [RFC3394] specified in the XML Encryption standard with "AES" replaced by "Camellia". As with AES key wrap, the check value is 0xA6A6A6A6A6A6A6A6.
Camellia [Camellia、RFC3713]キーラップは、XML暗号化標準で指定されたAESキーラップアルゴリズム[RFC3394]と同一です。AESキーラップと同様に、チェック値は0xA6A6A6A6A6A6A6A6です。
The algorithm is the same regardless of the size of the Camellia key used in wrapping (called the key encrypting key or KEK). The implementation of Camellia is OPTIONAL. However, if it is supported, the same implementation guidelines of which combinations of KEK size and wrapped key size should be required to be supported and which are optional to be supported should be followed as for AES. That is to say, if Camellia key wrap is supported, then wrapping 128-bit keys with a 128-bit KEK and wrapping 256-bit keys with a 256-bit KEK are REQUIRED and all other combinations are OPTIONAL.
アルゴリズムは、ラッピングに使用されるCamelliaキーのサイズに関係なく同じです（キー暗号化キーまたはKEKと呼ばれます）。Camelliaの実装はオプションです。ただし、サポートされている場合は、KEKサイズとラップされたキーサイズの組み合わせをサポートする必要があり、サポートするオプションの同じ実装ガイドラインに従う必要があります。つまり、Camelliaキーラップがサポートされている場合、128ビットKEKで128ビットキーをラップし、256ビットKEKで256ビットキーをラップし、他のすべての組み合わせがオプションです。
An example of use is:
使用の例は次のとおりです。
<EncryptionMethod
Algorithm=
"http://www.w3.org/2001/04/xmldsig-more#kw-camellia128" />
Identifier: http://www.w3.org/2001/04/xmldsig-more#psec-kem
識別子：http：//www.w3.org/2001/04/xmldsig-more#psec-kem
The PSEC-KEM algorithm, specified in [ISO/IEC-18033-2], is a key encapsulation mechanism using elliptic curve encryption.
[ISO/IEC-18033-2]で指定されたPSEC-KEMアルゴリズムは、楕円曲線暗号化を使用した重要なカプセル化メカニズムです。
An example of use is:
使用の例は次のとおりです。
<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>
</encryptionMethod>
See [ISO/IEC-18033-2] for information on the parameters above.
上記のパラメーターについては、[ISO/IEC-18033-2]を参照してください。
In section 3.1 a new KeyInfo element child is specified, while in section 3.2 additional KeyInfo Type values for use in RetrievalMethod are specified.
セクション3.1では、新しいkeyInfo要素の子が指定され、セクション3.2では、検索で使用する追加のキーインフォタイプ値が指定されています。
A PKCS #7 [RFC2315] "signedData" can also be used as a bag of certificates and/or certificate revocation lists (CRLs). The PKCS7signedData element is defined to accommodate such structures within KeyInfo. The binary PKCS #7 structure is base64 [RFC2405] encoded. Any signer information present is ignored. The following is an example, eliding the base64 data [RFC3092]:
PKCS＃7 [RFC2315]「SignedData」は、証明書および/または証明書の取り消しリスト（CRLS）の袋としても使用できます。PKCS7SignedData要素は、KeyInfo内のそのような構造に対応するために定義されています。バイナリPKCS＃7構造は、base64 [rfc2405]エンコードされています。存在する署名者情報は無視されます。以下は、Base64データを排除する例です[RFC3092]：
<foo:PKCS7signedData
xmlns:foo="http://www.w3.org/2001/04/xmldsig-more">
...
</foo:PKCS7signedData>
The Type attribute of RetrievalMethod is an optional identifier for the type of data to be retrieved. The result of dereferencing a RetrievalMethod reference for all KeyInfo types with an XML structure is an XML element or document with that element as the root. The various "raw" key information types return a binary value. Thus, they require a Type attribute because they are not unambiguously parseable.
retirevalMethodの型属性は、取得するデータのタイプのオプションの識別子です。XML構造を使用したすべてのKeyINFOタイプの検索値参照を繰り返し回避した結果は、その要素をルートとしてXML要素またはドキュメントです。さまざまな「生」キー情報タイプは、バイナリ値を返します。したがって、それらは明確に分離できないため、型属性を必要とします。
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
As it is easy for people to construct their own unique URIs [RFC2396] and possibly obtain a URI from the W3C if appropriate, it is not intended that any additional "http://www.w3.org/2001/04/xmldsig-more#" URIs be created beyond those enumerated in this document. (W3C Namespace stability rules prohibit the creation of new URIs under "http://www.w3.org/2000/09/xmldsig#".)
人々が独自のURI [RFC2396]を構築し、必要に応じてW3CからURIを取得することは簡単であるため、追加の「http://www.w3.org/2001/04/xmldsig-その他の＃「urisは、このドキュメントに列挙されているものを超えて作成されます。（W3Cネームスペースの安定性ルール「http://www.w3.org/2000/09/xmldsig#」の下で新しいURIの作成を禁止しています。）
Due to computer speed and cryptographic advances, the use of MD5 as a DigestMethod and the use of MD5 in the RSA-MD5 SignatureMethod is NOT RECOMMENDED. The concerned cryptographic advances do not effect the security of HMAC-MD5; however, there is little reason not to use one of the SHA series of algorithms.
コンピューターの速度と暗号化の進歩により、MD5の消化量としての使用とRSA-MD5 SignatureMethodでのMD5の使用は推奨されません。関係する暗号化の進歩は、HMAC-MD5のセキュリティに影響しません。ただし、SHAシリーズのアルゴリズムの1つを使用しない理由はほとんどありません。
Acknowledgements
謝辞
Glenn Adams, Merlin Hughs, Gregor Karlinger, Brian LaMachia, Shiho Moriai, Joseph Reagle, Russ Housley, and Joel Halpern.
グレン・アダムス、マーリン・ヒューズ、グレゴール・カーリンガー、ブライアン・ラマキア、聖原森、ジョセフ・レーグル、ラス・ハウズリー、ジョエル・ハルパーン。
Normative References
引用文献
[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, August 2000, Proceedings, Lecture Notes in Computer Science 2012, pp. 39-56, Springer-Verlag, 2001.
[Camellia] "Camellia：複数のプラットフォームに適した128ビットブロック暗号 - 設計と分析 - "、K。Aoki、T。Matsui、S。Moriai、J。Nakajima、T。Tokita、選択された地域Cryptography、第7回年次国際ワークショップ、SAC 2000、2000年8月、議事録、コンピューターサイエンス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, April 2005.
[ECDSA] Blake-Wilson、S.、Karlinger、G.、Kobayashi、T。、およびY. Wang、「XMLデジタル署名の楕円曲線署名アルゴリズム（ECDSA）を使用して」、RFC 4050、2005年4月。
[FIPS-180-2] "Secure Hash Standard", (SHA-1/256/384/512) US Federal Information Processing Standard, 1 August 2002.
[FIPS-180-2]「Secure Hash Standard」、（SHA-1/256/384/512）米国連邦情報処理標準、2002年8月1日。
[FIPS-180-2change] "FIPS 180-2, Secure Hash Standard Change Notice 1", adds SHA-224 to [FIPS 180-2], 25 February 2004.
[FIPS-180-2CHANGE]「FIPS 180-2、SECURE HASH STARDAND CHANGE NOTAITANS 1」、2004年2月25日、SHA-224を[FIPS 180-2]に追加します。
[FIPS-186-2] "Digital Signature Standard", National Institute of Standards and Technology, 2000.
[FIPS-186-2]「Digital Signature Standard」、国立標準技術研究所、2000。
[IEEE-P1363a] "Standard Specifications for Public Key Cryptography: Additional Techniques", October 2002.
[IEEE-P1363A]「公開キー暗号化の標準仕様：追加手法」、2002年10月。
[ISO/IEC-18033-2] "Information technology -- Security techniques -- Encryption algorithms -- Part 3: Asymmetric ciphers", CD, October 2002.
[ISO/IEC-18033-2]「情報技術 - セキュリティ技術 - 暗号化アルゴリズム - パート3：非対称暗号」、CD、2002年10月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年4月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2396] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、RFC 2396、1998年8月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405] Madson、C。およびN. Doraswamy、「ESP Des-CBC暗号アルゴリズムを備えたIVを備えた」、RFC 2405、1998年11月。
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[RFC2315] Kaliski、B。、「PKCS＃7：Cryptographic Message Syntaxバージョン1.5」、RFC 2315、1998年3月。
[RFC3075] Eastlake 3rd, D., Reagle, J., and D. Solo, "XML-Signature Syntax and Processing", RFC 3075, March 2001. (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.)
[RFC3075] EastLake 3rd、D.、Reagle、J。、およびD. Solo、「XML-Signature Syntax and Processing」、RFC 3075、2001年3月。RFC 3275で落とされた最小限の標準化の説明。）
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275] EastLake 3rd、D.、Reagle、J。、およびD. Solo、 "（拡張可能なマークアップ言語）XML-Signature構文と処理"、RFC 3275、2002年3月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394] Schaad、J。および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, February 2003.
[RFC3447] Jonsson、J.およびB. Kaliski、「Public-Key Cryptography Standards（PKCS）＃1：RSA暗号仕様バージョン2.1」、RFC 3447、2003年2月。
[RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, April 2004.
[RFC3713] Matsui、M.、Nakajima、J。、およびS. Moriai、「Camellia暗号化アルゴリズムの説明」、RFC 3713、2004年4月。
[RFC3874] Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, September 2004.
[RFC3874] Housley、R。、「224ビットの一方向ハッシュ関数：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.
[RIPEMD-160] ISO/IEC 10118-3：1998、「情報技術 - セキュリティ技術 - ハッシュファンクション - パート3：専用ハッシュ関数」、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.
[X9.62] X9.62-200X、「金融サービス業界向けの公開鍵暗号：楕円曲線デジタル署名アルゴリズム（ECDSA）」、認定基準委員会X9、American National Standards Institute。
[XMLDSIG] "XML-Signature Syntax and Processing", D. Eastlake 3rd, J. Reagle, & D. Solo, 12 February 2002. <http://www.w3.org/TR/xmldsig-core/>
[xmldsig] "xml-signature syntax and processing"、D。Eastlake3rd、J。Reagle、＆D。Solo、2002年2月12日。
[XMLENC] "XML Encryption Syntax and Processing", J. Reagle, D. Eastlake, December 2002. <http://www.w3.org/TR/2001/RED-xmlenc-core-20021210/>
[xmlenc] "xml暗号化構文と処理"、J。Reagle、D。Eastlake、2002年12月。
[XPointer] "XML Pointer Language (XPointer) Version 1.0", W3C working draft, Steve DeRose, Eve Maler, Ron Daniel Jr., January 2001. <http://www.w3.org/TR/2001/WD-xptr-20010108>
[Xpointer] "XML Pointer Language（XPOINTER）バージョン1.0"、W3Cワーキングドラフト、スティーブデロース、イブマーラー、ロンダニエルJr.、2001年1月。<http://www.w3.org/tr/2001/wd-xpt-20010108>
Informative References
参考引用
[CANON] "Canonical XML Version 1.0", John Boyer. <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[Canon] "Canonical XMLバージョン1.0"、ジョンボイヤー。<http://www.w3.org/tr/2001/rec-xml-c14n-20010315>。
[EXCANON] "Exclusive XML Canonicalization Version 1.0", D. Eastlake, J. Reagle, 18 July 2002. <http://www.w3.org/TR/REC-xml-enc-c14n-20020718/>.
[Excanon] "独占XML Canonicalizationバージョン1.0"、D。イーストレイク、J。レーグル、2002年7月18日。
[RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[RFC3076] Boyer、J。、「Canonical XMLバージョン1.0」、RFC 3076、2001年3月。
[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology of "Foo"", RFC 3092, 2001.
[RFC3092] EastLake 3rd、D.、Manros、C。、およびE. Raymond、「Foo」の語源、RFC 3092、2001。
[RFC3741] Boyer, J., Eastlake 3rd, D., and J. Reagle, "Exclusive XML Canonicalization, Version 1.0", RFC 3741, March 2004.
[RFC3741] Boyer、J.、Eastlake 3rd、D。、およびJ. Reagle、「排他的XML Canonicalization、バージョン1.0」、RFC 3741、2004年3月。
Author's Address
著者の連絡先
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第3モトローラ研究所155ビーバーストリートミルフォード、マサチューセッツ州01757 USA
Phone: +1-508-786-7554 (w)
+1-508-634-2066 (h)
EMail: Donald.Eastlake@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。