Network Working Group D. Eastlake 3rd
Request for Comments: 4051 Motorola Laboratories
Category: Standards Track April 2005
Additional XML Security Uniform Resource Identifiers (URIs)
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.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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デジタル署名、暗号化、および正規化での使用を目的とした多くのUniform Resource Identifier（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 Track文書になりました。 次のように利用できます。
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.
これらの標準と推奨事項はすべて、URI [RFC2396]を使用してアルゴリズムとキーイング情報タイプを識別します。 このドキュメントは、URIの便利なリファレンスリストと、実質的な関心はあるがメインドキュメントに含まれていない、または含まれていないアルゴリズムの説明を提供します。 IETFでXMLデジタル署名をDraft Standardに上げるには、主要な標準ドキュメントからの相互運用性が実証されていないアルゴリズムを削除する必要がありました。 これには、標準トラック仕様から削除するために、継続的な関心があると思われるMinimal Canonicalizationアルゴリズムの削除が必要でした。 ここに含まれています。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は [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.
Proposed StandardからDraft Standardへの移行のために標準からドロップされているURI [RFC2396]は、XMLDSIG標準の名前空間の変更を避けるために、元のプレフィックスとともにセクション2.4に含まれています。
http://www.w3.org/2000/09/xmldsig#
http://www.w3.org/2000/09/xmldsig#
Additional algorithms are given URIs that start with:
追加のアルゴリズムには、次で始まるURIが与えられます。
http://www.w3.org/2001/04/xmldsig-more#
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
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 DigestAlgorithm要素の例は次のとおりです。
<DigestAlgorithm Algorithm="http://www.w3.org/2001/04/xmldsig-more#md5"/>
<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 DigestAlgorithm要素の例は次のとおりです。
<DigestAlgorithm Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha224" />
<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 DigestAlgorithm要素の例は次のとおりです。
<DigestAlgorithm Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha384" />
<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>
<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>
<simpleType name = "HMACOutputLength"> <restriction base = "integer" /> </ simpleType>
DTD:
DTD：
<!ELEMENT HMACOutputLength (#PCDATA) >
<！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
識別子：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.
HMAC-MD5のセクション2.2.1で説明されているように、RIPEMD-160 [RIPEMD-160]は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" />
<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署名のSignatureValueコンテンツは、[RFC3447]、セクション8.1.1、RSASSA-PKCS1-v1_5署名スキームの署名生成に従って計算されたオクテット文字列のbase64 [RFC2405]エンコーディングです。 [RFC3447、セクション9.2.1]のEMSA-PKCS1-V1_5-ENCODE関数で指定されているように、署名関数への値の入力には、ハッシュ関数の事前保留アルゴリズムオブジェクト識別子が含まれている必要がありますが、ASNが利用可能です。 1パーサーとOIDの認識は、署名検証には必要ありません。 PKCS＃1 v1.5表現は次のように表示されます。
CRYPT (PAD (ASN.1 (OID, DIGEST (data))))
CRYPT（PAD（ASN.1（OID、DIGEST（データ））））
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」は、対応する16進値の固定オクテットで、「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
16進数30 20 30 0c 06 08 2a 86 48 86 f7 0d 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オクテットは、CRYPT処理される量の値が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" />
<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" />
<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-SHA384よりもRSA-SHA512を優先して使用することをお勧めします。
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" />
<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" />
<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
識別子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].
楕円曲線デジタル署名アルゴリズム（ECDSA）[FIPS-186-2]は、DSA（DSS）署名方式の類似した楕円曲線です。 SHAハッシュ関数および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
識別子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" />
<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.
これまで、Minimal Canonicalizationの2つの独立した相互運用可能な実装は発表されていません。 したがって、XML Digital SignatureがProposed Standard [RFC3075]からDraft Standard [RFC3275]に進められたとき、Minimal Canonicalizationは標準化過程文書から削除されました。 ただし、Minimal Canonicalizationには引き続き関心があり、将来の使用の可能性を示しています。 その定義については、[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>
<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">
<element name = "XPointer" type = "string">
DTD:
DTD：
<!ELEMENT XPointer (#PCDATA) >
<！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 SecurityのRC4アルゴリズムと互換性のある高速でシンプルなストリーム暗号化アルゴリズムです。 ARCFOURを使用したEncryptionMethod要素の例は次のとおりです。
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#arcfour"> <KeySize>40</KeySize> </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]で指定および定義された汎用KeySizeパラメーターを使用することに注意してください。
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
識別子：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）を使用したCipher Block Chaining（CBC）モードで使用されます。 結果の暗号化テキストの先頭にはIVが付きます。 XML出力に含まれている場合、base64エンコードされます。 Camellia EncryptionMethodの例は次のとおりです。
<EncryptionMethod Algorithm= "http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc" />
<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
識別子：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]キーラップは、「AES」を「Camellia」に置き換えた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の実装はオプションです。 ただし、サポートされている場合は、AESの場合と同じKEKサイズとラップキーサイズの組み合わせをサポートする必要があり、サポートするオプションは同じ実装ガイドラインに従う必要があります。 つまり、Camelliaキーラップがサポートされている場合、128ビットキーを128ビットKEKでラップし、256ビットキーを256ビットKEKでラップすることは必須であり、他のすべての組み合わせはオプションです。
An example of use is:
使用例は次のとおりです。
<EncryptionMethod Algorithm= "http://www.w3.org/2001/04/xmldsig-more#kw-camellia128" />
<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 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ではRetrievalMethodで使用する追加のKeyInfo Type値が指定されています。
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"は、証明書や証明書失効リスト（CRL）のバッグとしても使用できます。 PKCS7signedData要素は、KeyInfo内のこのような構造に対応するために定義されています。 バイナリPKCS＃7構造は、base64 [RFC2405]でエンコードされています。 存在する署名者情報はすべて無視されます。 以下は、base64データ[RFC3092]を除外する例です。
<foo:PKCS7signedData xmlns:foo="http://www.w3.org/2001/04/xmldsig-more"> ... </foo:PKCS7signedData>
<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.
RetrievalMethodのType属性は、取得するデータのタイプのオプションの識別子です。 XML構造を持つすべてのKeyInfo型のRetrievalMethod参照を逆参照した結果は、その要素をルートとして持つXML要素またはドキュメントです。 さまざまな「生の」キー情報タイプは、バイナリ値を返します。 したがって、明確に解析できないため、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
識別子：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- このドキュメントで列挙されているURIを超えてmore＃ "URIを作成します。 （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をDigestMethodとして使用し、RSA-MD5 SignatureMethodでMD5を使用することはお勧めしません。 関係する暗号化の進歩は、HMAC-MD5のセキュリティには影響しません。 ただし、SHAシリーズのアルゴリズムのいずれかを使用しない理由はほとんどありません。
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、市川T.、松井M.、森井S.、中島J.、時田T. 暗号学、第7回年次国際ワークショップ、SAC 2000、2000年8月、Proceedings、レクチャーノート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, April 2005.
[ECDSA]ブレイク-ウィルソン、S。、カーリンジャー、G。、小林、T。、およびY.ワング、「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 Standard Change Notice 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]「デジタル署名標準」、国立標準技術研究所、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]バーナーズ・リー、T。、フィールディング、R。、およびL.マスインター、「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, November 1998.
[RFC2405]マッドソン、C。、およびN.ドラスワミー、「明示的なIVを使用したESP DES-CBC暗号アルゴリズム」、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 Version 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 3075はRFC 3275で廃止されましたが、 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、「（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, 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、「公開鍵暗号化標準（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]松井M.、中島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、米国規格協会。
[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。Eastlake 3rd、J。Reagle、およびD. Solo、2002年2月12日。<http://www.w3.org/TR/xmldsig-core/>
[XMLENC] "XML Encryption Syntax and Processing", J. Reagle, D. Eastlake, December 2002. <http://www.w3.org/TR/2001/RED-xmlenc-core-20021210/>
[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., January 2001. <http://www.w3.org/TR/2001/WD-xptr-20010108>
[XPointer]「XML Pointer Language（XPointer）Version 1.0」、W3Cワーキングドラフト、Steve DeRose、Eve Maler、Ron Daniel Jr.、2001年1月。<http://www.w3.org/TR/2001/WD-xptr -20010108>
Informative References
参考資料
[CANON] "Canonical XML Version 1.0", John Boyer. <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[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, 18 July 2002. <http://www.w3.org/TR/REC-xml-enc-c14n-20020718/>.
[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, March 2001.
[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.
[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、「Exclusive 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 Beaver Street Milford、MA 01757 USA
Phone: +1-508-786-7554 (w) +1-508-634-2066 (h) EMail: Donald.Eastlake@motorola.com
電話：+ 1-508-786-7554（w）+ 1-508-634-2066（h）メール：Donald.Eastlake@motorola.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/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のietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。