[要約] RFC 6931は、XMLセキュリティのための追加のURI（Uniform Resource Identifier）を定義しています。このRFCの目的は、XMLセキュリティの標準化と相互運用性の向上を促進することです。
Internet Engineering Task Force (IETF) D. Eastlake 3rd
Request for Comments: 6931 Huawei
Obsoletes: 4051 April 2013
Category: Standards Track
ISSN: 2070-1721
Additional XML Security Uniform Resource Identifiers (URIs)
追加のXMLセキュリティUniform Resource Identifier（URI）
Abstract
概要
This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051.
このドキュメントは、XMLデジタル署名、暗号化、正規化、およびキー管理での使用を目的としたURIのリストのIANAレジストリを拡張、更新、および確立します。これらのURIは、アルゴリズムと情報のタイプを識別します。このドキュメントはRFC 4051を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6931.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6931で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Acronyms ...................................................4
2. Algorithms ......................................................5
2.1. DigestMethod (Hash) Algorithms .............................5
2.1.1. MD5 .................................................5
2.1.2. SHA-224 .............................................6
2.1.3. SHA-384 .............................................6
2.1.4. Whirlpool ...........................................6
2.1.5. New SHA Functions ...................................7
2.2. SignatureMethod MAC Algorithms .............................7
2.2.1. HMAC-MD5 ............................................7
2.2.2. HMAC SHA Variations .................................8
2.2.3. HMAC-RIPEMD160 ......................................8
2.3. SignatureMethod Public-Key Signature Algorithms ............9
2.3.1. RSA-MD5 .............................................9
2.3.2. RSA-SHA256 .........................................10
2.3.3. RSA-SHA384 .........................................10
2.3.4. RSA-SHA512 .........................................10
2.3.5. RSA-RIPEMD160 ......................................11
2.3.6. ECDSA-SHA*, ECDSA-RIPEMD160, ECDSA-Whirlpool .......11
2.3.7. ESIGN-SHA* .........................................12
2.3.8. RSA-Whirlpool ......................................12
2.3.9. RSASSA-PSS with Parameters .........................13
2.3.10. RSASSA-PSS without Parameters .....................14
2.3.11. RSA-SHA224 ........................................15
2.4. Minimal Canonicalization ..................................15
2.5. Transform Algorithms ......................................16
2.5.1. XPointer ...........................................16
2.6. EncryptionMethod Algorithms ...............................17
2.6.1. ARCFOUR Encryption Algorithm .......................17
2.6.2. Camellia Block Encryption ..........................17
2.6.3. Camellia Key Wrap ..................................17
2.6.4. PSEC-KEM ...........................................18
2.6.5. SEED Block Encryption ..............................19
2.6.6. SEED Key Wrap ......................................19
3. KeyInfo ........................................................19
3.1. PKCS #7 Bag of Certificates and CRLs ......................20
3.2. Additional RetrievalMethod Type Values ....................20
4. Indexes ........................................................20
4.1. Fragment Index ............................................21
4.2. URI Index .................................................24
5. Allocation Considerations ......................................27
5.1. W3C Allocation Considerations .............................27
5.2. IANA Considerations .......................................28
6. Security Considerations ........................................28
7. Acknowledgements ...............................................29
Appendix A. Changes from RFC 4051 .................................30
Normative References ..............................................31
Informative References ............................................33
XML digital signatures, canonicalization, and encryption have been standardized by the W3C and by the joint IETF/W3C XMLDSIG working group [W3C]. All of these are now W3C Recommendations and some are also RFCs. They are available as follows:
XMLデジタル署名、正規化、および暗号化は、W3CおよびIETF / W3C XMLDSIG共同作業グループ[W3C]によって標準化されています。これらはすべてW3C勧告になり、一部はRFCにもなっています。次のように利用できます。
RFC
Status W3C REC Topic
----------- ------- -----
[RFC3275] [XMLDSIG10] XML Digital Signatures Draft Standard
[RFC3275] [XMLDSIG10] XMLデジタル署名ドラフト標準
[RFC3076] [CANON10] Canonical XML Informational
[RFC3076] [CANON10] Canonical XML Informational
- - - - - - [XMLENC10] XML Encryption 1.0
[RFC3741] [XCANON] Exclusive XML Canonicalization 1.0 Informational
[RFC3741] [XCANON] Exclusive XML Canonicalization 1.0 Informational
All of these documents and recommendations use URIs [RFC3986] to identify algorithms and keying information types. The W3C has subsequently produced updated XML Signature 1.1 [XMLDSIG11], Canonical XML 1.1 [CANON11], and XML Encryption 1.1 [XMLENC11] versions, as well as a new XML Signature Properties specification [XMLDSIG-PROP].
これらのドキュメントと推奨事項はすべて、URIとアルゴリズム[RFC3986]を使用して、アルゴリズムとキー情報タイプを識別します。 W3Cはその後、更新されたXML署名1.1 [XMLDSIG11]、Canonical XML 1.1 [CANON11]、およびXML暗号化1.1 [XMLENC11]バージョンと、新しいXML署名プロパティ仕様[XMLDSIG-PROP]を作成しました。
All camel-case element names herein, such as DigestValue, are from these documents.
ここでのDigestValueなどのすべてのキャメルケース要素名は、これらのドキュメントからのものです。
This document is an updated convenient reference list of URIs and corresponding algorithms in which there is expressed interest. Since the previous list [RFC4051] was issued in 2005, significant new cryptographic algorithms of interest to XML security, for some of which the URI is only specified in this document, have been added. This document obsoletes [RFC4051]. All of the URIs appear in the indexes in Section 4. Only the URIs that were added by [RFC4051] or this document have a subsection in Section 2 or 3, with the exception of Minimal Canonicalization (Section 2.4), for example, use of
このドキュメントは、URIと、関心が表明されている対応するアルゴリズムの更新された便利なリファレンスリストです。前のリスト[RFC4051]が2005年に発行されて以来、XMLセキュリティに関係する重要な新しい暗号化アルゴリズムが追加されました。その一部については、このドキュメントでのみURIが指定されています。このドキュメントは廃止されました[RFC4051]。すべてのURIはセクション4のインデックスに表示されます。[RFC4051]またはこのドキュメントによって追加されたURIのみが、セクション2または3にサブセクションがあります。ただし、最小正規化（セクション2.4）を除きます。
SHA-256 is defined in [XMLENC11] and hence there is no subsection on that algorithm here, but its URI is included in the indexes in Section 4.
SHA-256は[XMLENC11]で定義されているため、ここではそのアルゴリズムに関するサブセクションはありませんが、そのURIはセクション4のインデックスに含まれています。
Specification in this document of the URI representing an algorithm does not imply endorsement of the algorithm for any particular purpose. A protocol specification, which this is not, generally gives algorithm and implementation requirements for the protocol. Security considerations for algorithms are constantly evolving, as documented elsewhere. This specification simply provides some URIs and relevant formatting for when those URIs are used.
このドキュメントでのアルゴリズムを表すURIの仕様は、特定の目的のためのアルゴリズムの推奨を意味するものではありません。これはプロトコル仕様ではありませんが、通常、プロトコルのアルゴリズムと実装の要件を示しています。他の場所で説明されているように、アルゴリズムのセキュリティに関する考慮事項は常に進化しています。この仕様は、いくつかのURIと、それらのURIが使用されるときの関連フォーマットを提供するだけです。
Note that progressing XML Digital Signature [RFC3275] along the Standards Track required removal of any algorithms from the original version [RFC3075] for which there was not demonstrated interoperability. This required removal of the Minimal Canonicalization algorithm, in which there appears to be continued interest. The URI for Minimal Canonicalization was included in [RFC4051] and is included here.
標準トラックに沿ってXMLデジタル署名[RFC3275]を進めるには、相互運用性が実証されていない元のバージョン[RFC3075]からアルゴリズムを削除する必要があることに注意してください。これには、最小の正規化アルゴリズムを削除する必要がありました。最小正規化のURIは[RFC4051]に含まれており、ここに含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
This document is not intended to change the algorithm implementation requirements of any IETF or W3C document. Use of [RFC2119] terminology is intended to be only such as is already stated or implied by other authoritative documents.
このドキュメントは、IETFまたはW3Cドキュメントのアルゴリズム実装要件を変更することを意図したものではありません。 [RFC2119]の用語の使用は、他の信頼できる文書ですでに述べられているか、または黙示されているものだけであることを意図しています。
The following acronyms are used in this document:
このドキュメントでは、次の頭字語が使用されています。
HMAC - Keyed-Hashing MAC [RFC2104]
HMAC-鍵付きハッシュMAC [RFC2104]
IETF - Internet Engineering Task Force <www.ietf.org>
MAC - Message Authentication Code
MAC-メッセージ認証コード
MD - Message Digest
MD-メッセージダイジェスト
NIST - United States National Institute of Standards and Technology <www.nist.gov>
NIST-米国国立標準技術研究所<www.nist.gov>
RC - Rivest Cipher RSA - Rivest, Shamir, and Adleman
RC-Rivest Cipher RSA-Rivest、Shamir、およびAdleman
SHA - Secure Hash Algorithm
SHA-セキュアハッシュアルゴリズム
URI - Uniform Resource Identifier [RFC3986]
うり ー うにふぉｒｍ れそうｒせ いでんちふぃえｒ 「ＲＦＣ３９８６」
W3C - World Wide Web Consortium <www.w3.org>
XML - eXtensible Markup Language
XML-eXtensible Markup Language
The URI [RFC3986] that was dropped from the XML Digital Signature standard due to the transition from Proposed Standard to Draft Standard [RFC3275] is included in Section 2.4 below with its original
提案された標準からドラフト標準[RFC3275]への移行によりXMLデジタル署名標準から削除されたURI [RFC3986]は、元のセクション2.4に含まれています。
http://www.w3.org/2000/09/xmldsig#
prefix so as to avoid changing the XMLDSIG standard's namespace.
XMLDSIG標準の名前空間を変更しないようにするための接頭辞。
Additional algorithms in [RFC4051] were given URIs that start with
[RFC4051]の追加のアルゴリズムには、
http://www.w3.org/2001/04/xmldsig-more#
while further algorithms added in this document are given URIs that start with
このドキュメントに追加されたアルゴリズムには、次で始まるURIが与えられます
http://www.w3.org/2007/05/xmldsig-more#
In addition, for ease of reference, this document includes in the indexes in Section 4 many cryptographic algorithm URIs from several XML security documents using the namespaces with which they are defined in those documents. For example, 2000/09/xmldsig# for some URIs specified in [RFC3275] and 2001/04/xmlenc# for some URIs specified in [XMLENC10].
さらに、参照しやすいように、このドキュメントは、セクション4のインデックスに、それらのドキュメントで定義されている名前空間を使用する複数のXMLセキュリティドキュメントからの多くの暗号化アルゴリズムURIを含めています。たとえば、[RFC3275]で指定された一部のURIの場合は2000/09 / xmldsig＃、[XMLENC10]で指定された一部のURIの場合は2001/04 / xmlenc＃。
See also [XMLSECXREF].
[XMLSECXREF]も参照してください。
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 DigestAlgorithm要素の例は次のとおりです。
<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 [RFC2045] encoding of this bit string viewed as a 16-octet stream. See [RFC6151] for MD5 security considerations.
MD5ダイジェストは128ビットの文字列です。 DigestValue要素のコンテンツは、16オクテットストリームとして表示されるこのビット文字列のbase64 [RFC2045]エンコーディングである必要があります。 MD5セキュリティの考慮事項については、[RFC6151]を参照してください。
Identifier:
http://www.w3.org/2001/04/xmldsig-more#sha224
The SHA-224 algorithm [FIPS180-4] [RFC6234] takes no explicit parameters. An example of a SHA-224 DigestAlgorithm element is:
SHA-224アルゴリズム[FIPS180-4] [RFC6234]は明示的なパラメーターを取りません。 SHA-224 DigestAlgorithm要素の例は次のとおりです。
<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 [RFC2045] encoding of this string viewed as a 28-octet stream.
SHA-224ダイジェストは224ビットの文字列です。 DigestValue要素のコンテンツは、28オクテットストリームとして表示されるこの文字列のbase64 [RFC2045]エンコーディングである必要があります。
Identifier:
http://www.w3.org/2001/04/xmldsig-more#sha384
The SHA-384 algorithm [FIPS180-4] takes no explicit parameters. An example of a SHA-384 DigestAlgorithm element is:
SHA-384アルゴリズム[FIPS180-4]は明示的なパラメーターを取りません。 SHA-384 DigestAlgorithm要素の例は次のとおりです。
<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 [RFC2045] encoding of this string viewed as a 48-octet stream.
SHA-384ダイジェストは384ビットの文字列です。 DigestValue要素のコンテンツは、48オクテットストリームとして表示されるこの文字列のbase64 [RFC2045]エンコーディングである必要があります。
Identifier:
http://www.w3.org/2007/05/xmldsig-more#whirlpool
The Whirlpool algorithm [10118-3] takes no explicit parameters. A Whirlpool digest is a 512-bit string. The content of the DigestValue element SHALL be the base64 [RFC2045] encoding of this string viewed as a 64-octet stream.
Whirlpoolアルゴリズム[10118-3]は明示的なパラメータを取りません。ワールプールダイジェストは512ビットの文字列です。 DigestValue要素のコンテンツは、64オクテットストリームとして表示されるこの文字列のbase64 [RFC2045]エンコーディングである必要があります。
Identifiers:
http://www.w3.org/2007/05/xmldsig-more#sha3-224
http://www.w3.org/2007/05/xmldsig-more#sha3-256
http://www.w3.org/2007/05/xmldsig-more#sha3-384
http://www.w3.org/2007/05/xmldsig-more#sha3-512
NIST has recently completed a hash function competition for an alternative to the SHA family. The Keccak-f[1600] algorithm was selected [Keccak] [SHA-3]. This hash function is commonly referred to as "SHA-3", and this section is a space holder and reservation of URIs for future information on Keccak use in XML security.
NISTは最近、SHAファミリーに代わるハッシュ関数のコンテストを完了しました。 Keccak-f [1600]アルゴリズムが選択されました[Keccak] [SHA-3]。このハッシュ関数は一般に「SHA-3」と呼ばれ、このセクションは、XMLセキュリティーでのKeccakの使用に関する将来の情報のためのURIのスペースホルダーおよび予約です。
A SHA-3 224, 256, 384, and 512 digest is a 224-, 256-, 384-, and 512-bit string, respectively. The content of the DigestValue element SHALL be the base64 [RFC2045] encoding of this string viewed as a 28-, 32-, 48-, and 64-octet stream, respectively.
SHA-3 224、256、384、および512のダイジェストは、それぞれ224、256、384、および512ビットの文字列です。 DigestValue要素のコンテンツは、この文字列のbase64 [RFC2045]エンコーディングである必要があり、それぞれ28、32、48、および64オクテットストリームとして表示されます。
This section covers SignatureMethod MAC (Message Authentication Code) Algorithms.
このセクションでは、SignatureMethod MAC（メッセージ認証コード）アルゴリズムについて説明します。
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
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 [RFC2045] encoded in the same straightforward fashion as the
output of the digest algorithms. Example: the SignatureValue element
for the HMAC-MD5 digest
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 above are copied from [RFC3275].
すぐ上のスキーマ定義とDTDは[RFC3275]からコピーされます。
See [RFC6151] for HMAC-MD5 security considerations.
HMAC-MD5のセキュリティに関する考慮事項については、[RFC6151]を参照してください。
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 [FIPS180-4] [RFC6234] can also be used in HMAC as described in Section 2.2.1 above for HMAC-MD5.
SHA-224、SHA-256、SHA-384、およびSHA-512 [FIPS180-4] [RFC6234]は、HMAC-MD5について上記のセクション2.2.1で説明されているように、HMACでも使用できます。
Identifier:
http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160
RIPEMD-160 [10118-3] can also be used in HMAC as described in Section 2.2.1 above for HMAC-MD5.
RIPEMD-160 [10118-3]は、HMAC-MD5について上記のセクション2.2.1で説明されているように、HMACでも使用できます。
These algorithms are distinguished from those in Section 2.2 above in that they use public-key methods. That is to say, 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
This implies the PKCS#1 v1.5 padding algorithm described in [RFC3447]. An example of use is
これは、[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 [RFC2045] encoding of the octet string computed as per [RFC3447], Section 8.2.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, 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 is not required of a signature verifier. The PKCS#1 v1.5 representation appears as:
RSA-MD5署名のSignatureValueコンテンツは、[RFC3447]、セクション8.2.1、RSASSA-PKCS1-v1_5署名スキームの署名生成に従って計算されたオクテット文字列のbase64 [RFC2045]エンコーディングです。 [RFC3447]、セクション9.2の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（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」は対応する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 make it easier to use 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オクテット短くなるように十分な回数繰り返す必要があります。
See [RFC6151] for MD5 security considerations.
MD5セキュリティの考慮事項については、[RFC6151]を参照してください。
Identifier:
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
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 it does a SHA-512 message digest, it is suggested that RSA-SHA512 be used in preference to RSA-SHA384 where possible.
SHA-512メッセージダイジェストを計算するのとほぼ同じ労力でSHA-384メッセージダイジェストを計算するため、可能な場合はRSA-SHA384よりもRSA-SHA512を使用することをお勧めします。
Identifier:
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
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
http://www.w3.org/2007/05/xmldsig-more#ecdsa-ripemd160
http://www.w3.org/2007/05/xmldsig-more#ecdsa-whirlpool
The Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS180-4] is the elliptic curve analogue of the Digital Signature Algorithm (DSA) signature method, i.e., the Digital Signature Standard (DSS). It takes no explicit parameters. For detailed specifications of how to use it with SHA hash functions and XML Digital Signature, please see [X9.62] and [RFC4050]. The #ecdsa-ripemd160 and #ecdsa-whirlpool fragments in the new namespace identifies a signature method processed in the same way as specified by the #ecdsa-sha1 fragment of this namespace, with the exception that RIPEMD160 or Whirlpool is used instead of SHA-1.
楕円曲線デジタル署名アルゴリズム（ECDSA）[FIPS180-4]は、デジタル署名アルゴリズム（DSA）署名メソッド、つまりデジタル署名標準（DSS）の楕円曲線アナログです。明示的なパラメータは必要ありません。 SHAハッシュ関数およびXMLデジタル署名での使用方法の詳細な仕様については、[X9.62]および[RFC4050]を参照してください。新しい名前空間の＃ecdsa-ripemd160と＃ecdsa-whirlpoolフラグメントは、この名前空間の＃ecdsa-sha1フラグメントで指定されたのと同じ方法で処理される署名メソッドを識別しますが、SHA-の代わりにRIPEMD160またはWhirlpoolが使用されます。 1。
The output of the ECDSA algorithm consists of a pair of integers usually referred by the pair (r, s). The signature value consists of the base64 encoding of the concatenation of two octet streams that respectively result from the octet-encoding of the values r and s in that order. Conversion from integer to octet stream must be done according to the I2OSP operation defined in the [RFC3447] specification with the l parameter equal to the size of the base point order of the curve in bytes (e.g., 32 for the P-256 curve and 66 for the P-521 curve [FIPS186-3]).
ECDSAアルゴリズムの出力は、通常ペア（r、s）によって参照される整数のペアで構成されます。シグニチャ値は、値rとsをこの順序でオクテットエンコーディングしてそれぞれ生成される2つのオクテットストリームを連結したbase64エンコーディングで構成されます。整数からオクテットストリームへの変換は、[RFC3447]仕様で定義されているI2OSP操作に従って行う必要があります。lパラメータは、曲線の基点の次数のサイズ（バイト単位）に等しくなります（たとえば、P-256曲線の場合は32、 P-521曲線の場合は66 [FIPS186-3]）。
For an introduction to elliptic curve cryptographic algorithms, see [RFC6090] and note the errata (Errata ID 2773-2777).
楕円曲線暗号アルゴリズムの概要については、[RFC6090]を参照し、正誤表（正誤表ID 2773-2777）に注意してください。
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
The ESIGN algorithm specified in [IEEEP1363a] 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.
[IEEEP1363a]で指定されているESIGNアルゴリズムは、整数分解問題に基づく署名方式です。これは、以前のデジタル署名方式よりもはるかに高速であるため、特別なコプロセッサなしでスマートカードにESIGNを実装できます。
An example of use is
使用例は
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#esign-sha1"
/>
Identifier:
http://www.w3.org/2007/05/xmldsig-more#rsa-whirlpool
As in the definition of the RSA-SHA1 algorithm in [XMLDSIG11], the designator "RSA" means the RSASSA-PKCS1-v1_5 algorithm as defined in [RFC3447]. When identified through the #rsa-whirlpool fragment identifier, Whirlpool is used as the hash algorithm instead. Use of the ASN.1 BER Whirlpool algorithm designator is implied. That designator is hex 30 4e 30 0a 06 06 28 cf 06 03 00 37 05 00 04 40 as an explicit octet sequence. This corresponds to OID 1.0.10118.3.0.55 defined in [10118-3].
[XMLDSIG11]のRSA-SHA1アルゴリズムの定義と同様に、指定子「RSA」は、[RFC3447]で定義されているRSASSA-PKCS1-v1_5アルゴリズムを意味します。 ＃rsa-whirlpoolフラグメント識別子で識別される場合、代わりにWhirlpoolがハッシュアルゴリズムとして使用されます。 ASN.1 BER Whirlpoolアルゴリズム指定子の使用が暗示されています。その指定子は、明示的なオクテットシーケンスとして16進数30 4e 30 0a 06 06 28 cf 06 03 00 37 05 00 04 40です。これは、[10118-3]で定義されているOID 1.0.10118.3.0.55に対応しています。
An example of use is
使用例は
<SignatureMethod
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-whirlpool"
/>
Identifiers:
http://www.w3.org/2007/05/xmldsig-more#rsa-pss
http://www.w3.org/2007/05/xmldsig-more#MGF1
These identifiers imply the PKCS#1 EMSA-PSS encoding algorithm [RFC3447]. The RSASSA-PSS algorithm takes the digest method (hash function), a mask generation function, the salt length in bytes (SaltLength), and the trailer field as explicit parameters.
これらの識別子は、PKCS＃1 EMSA-PSSエンコードアルゴリズム[RFC3447]を意味します。 RSASSA-PSSアルゴリズムは、ダイジェストメソッド（ハッシュ関数）、マスク生成関数、ソルト長（バイト）（SaltLength）、およびトレーラーフィールドを明示的なパラメーターとして受け取ります。
Algorithm identifiers for hash functions specified in XML encryption [XMLENC11] [XMLDSIG11] and in Section 2.1 are considered to be valid algorithm identifiers for hash functions. According to [RFC3447], the default value for the digest function is SHA-1, but due to the discovered weakness of SHA-1 [RFC6194], it is recommended that SHA-256 or a stronger hash function be used. Notwithstanding [RFC3447], SHA-256 is the default to be used with these SignatureMethod identifiers if no hash function has been specified.
XML暗号化[XMLENC11] [XMLDSIG11]およびセクション2.1で指定されたハッシュ関数のアルゴリズム識別子は、ハッシュ関数の有効なアルゴリズム識別子と見なされます。 [RFC3447]によれば、ダイジェスト関数のデフォルト値はSHA-1ですが、SHA-1 [RFC6194]の弱点が発見されたため、SHA-256またはより強力なハッシュ関数を使用することをお勧めします。 [RFC3447]にもかかわらず、ハッシュ関数が指定されていない場合、SHA-256がこれらのSignatureMethod識別子で使用されるデフォルトです。
The default salt length for these SignatureMethod identifiers if the SaltLength is not specified SHALL be the number of octets in the hash value of the digest method, as recommended in [RFC4055]. In a parameterized RSASSA-PSS signature the ds:DigestMethod and the SaltLength parameters usually appear. If they do not, the defaults make this equivalent to http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1 (see Section 2.3.10). The TrailerField defaults to 1 (0xBC) when omitted.
[RFC4055]で推奨されているように、SaltLengthが指定されていない場合のこれらのSignatureMethod識別子のデフォルトのソルト長は、ダイジェストメソッドのハッシュ値のオクテット数でなければなりません。パラメーター化されたRSASSA-PSSシグニチャーでは、通常、ds：DigestMethodパラメーターとSaltLengthパラメーターが表示されます。そうでない場合、デフォルトでは、これはhttp://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1と同等になります（セクション2.3.10を参照）。 TrailerFieldは、省略した場合、デフォルトで1（0xBC）になります。
Schema Definition (target namespace http://www.w3.org/2007/05/xmldsig-more#):
スキーマ定義（ターゲット名前空間http://www.w3.org/2007/05/xmldsig-more#）：
<xs:element name="RSAPSSParams" type="pss:RSAPSSParamsType">
<xs:annotation>
<xs:documentation>
Top level element that can be used in xs:any namespace="#other"
wildcard of ds:SignatureMethod content.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:complexType name="RSAPSSParamsType">
<xs:sequence>
<xs:element ref="ds:DigestMethod" minOccurs="0"/>
<xs:element name="MaskGenerationFunction"
type="pss:MaskGenerationFunctionType" minOccurs="0"/>
<xs:element name="SaltLength" type="xs:int"
minOccurs="0"/>
<xs:element name="TrailerField" type="xs:int"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="MaskGenerationFunctionType">
<xs:sequence>
<xs:element ref="ds:DigestMethod" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="Algorithm" type="xs:anyURI"
default="http://www.w3.org/2007/05/xmldsig-more#MGF1"/>
</xs:complexType>
[RFC3447] currently specifies only one mask generation function MGF1 based on a hash function. Although [RFC3447] allows for parameterization, the default is to use the same hash function as the digest method function. Only this default approach is supported by this section; therefore, the definition of a mask generation function type is not needed yet. The same applies to the trailer field. There is only one value (0xBC) specified in [RFC3447]. Hence, this default parameter must be used for signature generation. The default salt length is the length of the hash function.
[RFC3447]は現在、ハッシュ関数に基づいて1つのマスク生成関数MGF1のみを指定しています。 [RFC3447]ではパラメータ化が可能ですが、デフォルトでは、ダイジェストメソッド関数と同じハッシュ関数を使用します。このセクションでは、このデフォルトのアプローチのみがサポートされています。したがって、マスク生成関数タイプの定義はまだ必要ありません。同じことがトレーラーフィールドにも当てはまります。 [RFC3447]で指定されている値は1つだけ（0xBC）です。したがって、このデフォルトパラメータは署名の生成に使用する必要があります。デフォルトのソルト長は、ハッシュ関数の長さです。
Identifiers:
http://www.w3.org/2007/05/xmldsig-more#sha3-224-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#sha3-256-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#sha3-384-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#sha3-512-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#md2-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#md5-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#sha1-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#sha224-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#sha384-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#sha512-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#ripemd128-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#ripemd160-rsa-MGF1
http://www.w3.org/2007/05/xmldsig-more#whirlpool-rsa-MGF1
An example of use is
使用例は
<SignatureMethod
Algorithm=
"http://www.w3.org/2007/05/xmldsig-more#SHA3-256-rsa-MGF1"
/>
Identifier:
http://www.w3.org/2007/05/xmldsig-more#rsa-sha224
This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described in Section 2.3.1, but with the ASN.1 BER SHA-224 algorithm designator prefix. An example of use is
これは、セクション2.3.1で説明したPKCS＃1 v1.5パディングアルゴリズム[RFC3447]を意味しますが、ASN.1 BER SHA-224アルゴリズム指定子プレフィックスが付いています。使用例は
<SignatureMethod
Algorithm="http://www.w3.org/2007/05/xmldsig-more#rsa-sha224" />
Because it takes about the same effort to calculate a SHA-224 message digest as it does a SHA-256 message digest, it is suggested that RSA-SHA256 be used in preference to RSA-SHA224 where possible.
SHA-256メッセージダイジェストを計算するのとほぼ同じ労力がかかるため、可能な場合はRSA-SHA224よりもRSA-SHA256を優先して使用することをお勧めします。
Thus far, two independent interoperable implementations of Minimal Canonicalization have not been announced. Therefore, when XML Digital Signature was advanced along the Standards Track from [RFC3075] to [RFC3275], Minimal Canonicalization was dropped. However, there is still interest. For its definition, see Section 6.5.1 of [RFC3075].
これまでのところ、最小正規化の2つの独立した相互運用可能な実装は発表されていません。したがって、XMLデジタル署名が[RFC3075]から[RFC3275]へと標準化過程に沿って進んだとき、最小限の正規化は削除されました。しかし、まだ興味があります。その定義については、[RFC3075]のセクション6.5.1を参照してください。
For reference, its identifier remains:
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
This transform algorithm takes an [XPointer] as an explicit parameter. An example of use is:
この変換アルゴリズムは、[XPointer]を明示的なパラメーターとして受け取ります。使用例は次のとおりです。
<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
ARCFOUR is a fast, simple stream encryption algorithm that is compatible with RSA Security's RC4 algorithm [RC4]. An example EncryptionMethod element using ARCFOUR is
ARCFOURは、RSA SecurityのRC4アルゴリズム[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 [XMLENC11].
Arcfourは、[XMLENC11]で指定および定義された汎用の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
Camellia is a block cipher with the same interface as the AES [Camellia] [RFC3713]; it has a 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"
/>
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] 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」が「Camellia」に置き換えられています。 AESキーラップと同様に、チェック値は0xA6A6A6A6A6A6A6A6です。
The algorithm is the same whatever the size of the Camellia key used in wrapping, called the "key encrypting key" or "KEK". If Camellia is supported, it is particularly suggested that wrapping 128-bit keys with a 128-bit KEK and wrapping 256-bit keys with a 256-bit KEK be supported.
アルゴリズムは、「キー暗号化キー」または「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"
/>
Identifier:
http://www.w3.org/2001/04/xmldsig-more#psec-kem
The PSEC-KEM algorithm, specified in [18033-2], is a key encapsulation mechanism using elliptic curve encryption.
[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>
See [18033-2] for information on the parameters above.
上記のパラメータの詳細については、[18033-2]を参照してください。
Identifier:
http://www.w3.org/2007/05/xmldsig-more#seed128-cbc
SEED [RFC4269] is a 128-bit block size with 128-bit key sizes. In XML Encryption, SEED can be 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.
SEED [RFC4269]は、128ビットのキーサイズを持つ128ビットのブロックサイズです。 XML暗号化では、SEEDは128ビットの初期化ベクトル（IV）を使用する暗号化ブロックチェーン（CBC）モードで使用できます。結果の暗号テキストには、IVが前に付けられます。 XML出力に含まれている場合は、base64でエンコードされます。
An example SEED EncryptionMethod is as follows:
SEED EncryptionMethodの例は次のとおりです。
<EncryptionMethod
Algorithm="http://www.w3.org/2007/05/xmldsig-more#seed128-cbc" />
Identifier:
http://www.w3.org/2007/05/xmldsig-more#kw-seed128
Key wrapping with SEED is identical to Section 2.2.1 of [RFC3394] with "AES" replaced by "SEED". The algorithm is specified in [RFC4010]. The implementation of SEED is optional. The default initial value is 0xA6A6A6A6A6A6A6A6.
SEEDでの鍵のラッピングは、[RFC3394]のセクション2.2.1と同じですが、「AES」が「SEED」に置き換えられています。アルゴリズムは[RFC4010]で指定されています。 SEEDの実装はオプションです。デフォルトの初期値は0xA6A6A6A6A6A6A6A6です。
An example of use is:
使用例は次のとおりです。
<EncryptionMethod
Algorithm=
"http://www.w3.org/2007/05/xmldsig-more#kw-seed128"
/>
In Section 3.1 below 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 [RFC2045] encoded. Any signer information present is ignored. The following is an example [RFC3092], eliding the base64 data:
PKCS＃7 [RFC2315] "signedData"は、証明書および/または証明書失効リスト（CRL）のバッグとしても使用できます。 PKCS7signedData要素は、KeyInfo内のこのような構造に対応するように定義されています。バイナリPKCS＃7構造はbase64 [RFC2045]でエンコードされています。存在する署名者情報は無視されます。以下は[RFC3092]の例で、base64データを除外しています：
<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 parsable.
RetrievalMethodのType属性は、取得するデータのタイプのオプションの識別子です。 XML構造を持つすべてのKeyInfoタイプのRetrievalMethod参照を逆参照した結果は、その要素をルートとするXML要素またはドキュメントです。さまざまな「生の」キー情報タイプはバイナリ値を返します。したがって、明確に解析可能ではないため、Type属性が必要です。
Identifiers:
http://www.w3.org/2001/04/xmldsig-more#KeyName
http://www.w3.org/2001/04/xmldsig-more#KeyValue
http://www.w3.org/2001/04/xmldsig-more#PKCS7signedData
http://www.w3.org/2001/04/xmldsig-more#rawPGPKeyPacket
http://www.w3.org/2001/04/xmldsig-more#rawPKCS7signedData
http://www.w3.org/2001/04/xmldsig-more#rawSPKISexp
http://www.w3.org/2001/04/xmldsig-more#rawX509CRL
http://www.w3.org/2001/04/xmldsig-more#RetrievalMethod
The following subsections provide an index by URI and by fragment identifier (the portion of the URI after "#") of the algorithm and KeyInfo URIs defined in this document and in the standards (plus the one KeyInfo child element name defined in this document). The "Sec/Doc" column has the section of this document or, if not specified in this document, the document where the item is specified. See also [XMLSECXREF].
次のサブセクションでは、このドキュメントと標準で定義されているアルゴリズムとKeyInfo URI（およびこのドキュメントで定義されている1つのKeyInfo子要素名）のアルゴリズムとKeyInfo URIのURIおよびフラグメント識別子（URIの "＃"の後の部分）によるインデックスを提供します。 。 「Sec / Doc」列には、このドキュメントのセクション、またはこのドキュメントで指定されていない場合は、アイテムが指定されているドキュメントが含まれます。 [XMLSECXREF]も参照してください。
The initial "http://www.w3.org/" part of the URI is not included below. The first six entries have a null fragment identifier or no fragment identifier.
URIの最初の「http://www.w3.org/」の部分は以下に含まれていません。最初の6つのエントリには、フラグメント識別子がnullであるか、フラグメント識別子がありません。
Fragment URI Sec/Doc
--------- ---- --------
2002/06/xmldsig-filter2 [XPATH]
2006/12/xmlc12n11# [CANON11]
TR/1999/REC-xslt-19991116 [XSLT]
TR/1999/REC-xpath-19991116 [XPATH]
TR/2001/06/xml-exc-c14n# [XCANON]
TR/2001/REC-xml-c14n-20010315 [CANON10]
TR/2001/REC-xmlschema-1-20010502 [Schema]
aes128-cbc 2001/04/xmlenc#aes128-cbc [XMLENC11]
aes128-gcm 2009/xmlenc11#aes128-gcm [XMLENC11]
aes192-cbc 2001/04/xmlenc#aes192-cbc [XMLENC11]
aes192-gcm 2009/xmlenc11#aes192-gcm [XMLENC11]
aes256-cbc 2001/04/xmlenc#aes256-cbc [XMLENC11]
aes256-gcm 2009/xmlenc11#aes256-gcm [XMLENC11]
arcfour 2001/04/xmldsig-more#arcfour 2.6.1
base64 2000/09/xmldsig#base64 [RFC3275]
camellia128-cbc 2001/04/xmldsig-more#camellia128-cbc 2.6.2
camellia192-cbc 2001/04/xmldsig-more#camellia192-cbc 2.6.2
camellia256-cbc 2001/04/xmldsig-more#camellia256-cbc 2.6.2
ConcatKDF 2009/xmlenc11#ConcatKDF [XMLENC11]
decrypt#XML 2002/07/decrypt#XML [DECRYPT]
decrypt#Binary 2002/07/decrypt#Binary [DECRYPT]
DEREncodedKeyValue 2009/xmldsig11#DEREncodedKeyValue [XMLDSIG11]
dh 2001/04/xmlenc#dh [XMLENC11]
dh-es 2009/xmlenc11#dh-es [XMLENC11]
dsa-sha1 2000/09/xmldsig#dsa-sha1 [RFC3275]
dsa-sha256 2009/xmldsig11#dsa-sha256 [XMLDSIG11]
DSAKeyValue 2000/09/xmldsig#DSAKeyValue [XMLDSIG11]
ECDH-ES 2009/xmlenc11#ECDH-ES [XMLENC11]
ecdsa-ripemd160 2007/05/xmldsig-more#ecdsa-ripemd160 2.3.6
ecdsa-sha1 2001/04/xmldsig-more#ecdsa-sha1 2.3.6
ecdsa-sha224 2001/04/xmldsig-more#ecdsa-sha224 2.3.6
ecdsa-sha256 2001/04/xmldsig-more#ecdsa-sha256 2.3.6
ecdsa-sha384 2001/04/xmldsig-more#ecdsa-sha384 2.3.6
ecdsa-sha512 2001/04/xmldsig-more#ecdsa-sha512 2.3.6
ecdsa-whirlpool 2007/05/xmldsig-more#ecdsa-whirlpool 2.3.5
ecies-kem 2010/xmlsec-ghc#ecies-kem [GENERIC]
ECKeyValue 2009/xmldsig11#ECKeyValue [XMLDSIG11]
enveloped-signature 2000/09/xmldsig#enveloped-signature [RFC3275]
esign-sha1 2001/04/xmldsig-more#esign-sha1 2.3.7
esign-sha224 2001/04/xmldsig-more#esign-sha224 2.3.7
esign-sha256 2001/04/xmldsig-more#esign-sha256 2.3.7
esign-sha384 2001/04/xmldsig-more#esign-sha384 2.3.7
esign-sha512 2001/04/xmldsig-more#esign-sha512 2.3.7
generic-hybrid 2010/xmlsec-ghc#generic-hybrid [GENERIC]
generic-hybrid 2010 / xmlsec-ghc＃generic-hybrid [GENERIC]
hmac-md5 2001/04/xmldsig-more#hmac-md5 2.2.1
hmac-ripemd160 2001/04/xmldsig-more#hmac-ripemd160 2.2.3
hmac-sha1 2000/09/xmldsig#hmac-sha1 [RFC3275]
hmac-sha224 2001/04/xmldsig-more#hmac-sha224 2.2.2
hmac-sha256 2001/04/xmldsig-more#hmac-sha256 2.2.2
hmac-sha384 2001/04/xmldsig-more#hmac-sha384 2.2.2
hmac-sha512 2001/04/xmldsig-more#hmac-sha512 2.2.2
KeyName 2001/04/xmldsig-more#KeyName 3.2
KeyValue 2001/04/xmldsig-more#KeyValue 3.2
kw-aes128 2001/04/xmlenc#kw-aes128 [XMLENC11]
kw-aes128-pad 2009/xmlenc11#kw-aes-128-pad [XMLENC11]
kw-aes192 2001/04/xmlenc#kw-aes192 [XMLENC11]
kw-aes192-pad 2009/xmlenc11#kw-aes-192-pad [XMLENC11]
kw-aes256 2001/04/xmlenc#kw-aes256 [XMLENC11]
kw-aes256-pad 2009/xmlenc11#kw-aes-256-pad [XMLENC11]
kw-camellia128 2001/04/xmldsig-more#kw-camellia128 2.6.3
kw-camellia192 2001/04/xmldsig-more#kw-camellia192 2.6.3
kw-camellia256 2001/04/xmldsig-more#kw-camellia256 2.6.3
kw-seed128 2007/05/xmldsig-more#kw-seed128 2.6.6
md2-rsa-MGF1 2007/05/xmldsig-more#md2-rsa-MGF1 2.3.10
md5 2001/04/xmldsig-more#md5 2.1.1
md5-rsa-MGF1 2007/05/xmldsig-more#md5-rsa-MGF1 2.3.10
MGF1 2007/05/xmldsig-more#MGF1 2.3.9
mgf1sha1 2009/xmlenc11#mgf1sha1 [XMLENC11]
mgf1sha224 2009/xmlenc11#mgf1sha224 [XMLENC11]
mgf1sha256 2009/xmlenc11#mgf1sha256 [XMLENC11]
mgf1sha384 2009/xmlenc11#mgf1sha384 [XMLENC11]
mgf1sha512 2009/xmlenc11#mgf1sha512 [XMLENC11]
MgmtData 2000/09/xmldsig#MgmtData [XMLDSIG11]
minimal 2000/09/xmldsig#minimal 2.4
pbkdf2 2009/xmlenc11#pbkdf2 [XMLENC11]
PGPData 2000/09/xmldsig#PGPData [XMLDSIG11]
PKCS7signedData 2001/04/xmldsig-more#PKCS7signedData 3.1
PKCS7signedData 2001/04/xmldsig-more#PKCS7signedData 3.2
psec-kem 2001/04/xmldsig-more#psec-kem 2.6.4
rawPGPKeyPacket 2001/04/xmldsig-more#rawPGPKeyPacket 3.2
rawPKCS7signedData 2001/04/xmldsig-more#rawPKCS7signedData 3.2
rawSPKISexp 2001/04/xmldsig-more#rawSPKISexp 3.2
rawX509Certificate 2000/09/xmldsig#rawX509Certificate [RFC3275]
rawX509CRL 2001/04/xmldsig-more#rawX509CRL 3.2
RetrievalMethod 2001/04/xmldsig-more#RetrievalMethod 3.2
ripemd128-rsa-MGF1 2007/05/xmldsig-more#ripemd128-rsa-MGF1 2.3.10
ripemd160 2001/04/xmlenc#ripemd160 [XMLENC11]
ripemd160-rsa-MGF1 2007/05/xmldsig-more#ripemd160-rsa-MGF1 2.3.10
rsa-1_5 2001/04/xmlenc#rsa-1_5 [XMLENC11]
rsa-md5 2001/04/xmldsig-more#rsa-md5 2.3.1
rsa-oaep 2009/xmlenc11#rsa-oaep [XMLENC11]
rsa-oaep-mgf1p 2001/04/xmlenc#rsa-oaep-mgf1p [XMLENC11]
rsa-pss 2007/05/xmldsig-more#rsa-pss 2.3.9
rsa-ripemd160 2001/04/xmldsig-more#rsa-ripemd160 2.3.5
rsa-sha1 2000/09/xmldsig#rsa-sha1 [RFC3275]
rsa-sha224 2007/05/xmldsig-more#rsa-sha224 2.3.11
rsa-sha256 2001/04/xmldsig-more#rsa-sha256 2.3.2
rsa-sha384 2001/04/xmldsig-more#rsa-sha384 2.3.3
rsa-sha512 2001/04/xmldsig-more#rsa-sha512 2.3.4
rsa-whirlpool 2007/05/xmldsig-more#rsa-whirlpool 2.3.5
rsaes-kem 2010/xmlsec-ghc#rsaes-kem [GENERIC]
RSAKeyValue 2000/09/xmldsig#RSAKeyValue [XMLDSIG11]
seed128-cbc 2007/05/xmldsig-more#seed128-cbc 2.6.5
sha1 2000/09/xmldsig#sha1 [RFC3275]
sha1-rsa-MGF1 2007/05/xmldsig-more#sha1-rsa-MGF1 2.3.10
sha224 2001/04/xmldsig-more#sha224 2.1.2
sha224-rsa-MGF1 2007/05/xmldsig-more#sha224-rsa-MGF1 2.3.10
sha256 2001/04/xmlenc#sha256 [XMLENC11]
sha256-rsa-MGF1 2007/05/xmldsig-more#sha256-rsa-MGF1 2.3.10
sha3-224 2007/05/xmldsig-more#sha3-224 2.1.5
sha3-224-rsa-MGF1 2007/05/xmldsig-more#sha3-224-rsa-MGF1 2.3.10
sha3-256 2007/05/xmldsig-more#sha3-256 2.1.5
sha3-256-rsa-MGF1 2007/05/xmldsig-more#sha3-256-rsa-MGF1 2.3.10
sha3-384 2007/05/xmldsig-more#sha3-384 2.1.5
sha3-384-rsa-MGF1 2007/05/xmldsig-more#sha3-384-rsa-MGF1 2.3.10
sha3-512 2007/05/xmldsig-more#sha3-512 2.1.5
sha3-512-rsa-MGF1 2007/05/xmldsig-more#sha3-512-rsa-MGF1 2.3.10
sha384 2001/04/xmldsig-more#sha384 2.1.3
sha384-rsa-MGF1 2007/05/xmldsig-more#sha384-rsa-MGF1 2.3.10
sha512 2001/04/xmlenc#sha512 [XMLENC11]
sha512-rsa-MGF1 2007/05/xmldsig-more#sha512-rsa-MGF1 2.3.10
SPKIData 2000/09/xmldsig#SPKIData [XMLDSIG11]
tripledes-cbc 2001/04/xmlenc#tripledes-cbc [XMLENC11]
whirlpool 2007/05/xmldsig-more#whirlpool 2.1.4
whirlpool-rsa-MGF1 2007/05/xmldsig-more#whirlpool-rsa-MGF1 2.3.10
WithComments 2006/12/xmlc14n11#WithComments [CANON11]
WithComments TR/2001/06/xml-exc-c14n#WithComments [XCANON]
WithComments TR/2001/REC-xml-c14n-20010315#WithComments
[CANON10]
X509Data 2000/09/xmldsig#X509Data [XMLDSIG11]
xptr 2001/04/xmldsig-more#xptr 2.5.1
The initial "http://www.w3.org/" part of the URI is not included above.
URIの最初の「http://www.w3.org/」の部分は上記に含まれていません。
The initial "http://www.w3.org/" part of the URI is not included below.
URIの最初の「http://www.w3.org/」の部分は以下に含まれていません。
URI Sec/Doc Type
---- -------- -----
2000/09/xmldsig#base64 [RFC3275] Transform
2000/09/xmldsig#DSAKeyValue [RFC3275] Retrieval type
2000/09/xmldsig#dsa-sha1 [RFC3275] SignatureMethod
2000/09/xmldsig#enveloped-signature [RFC3275] Transform
2000/09/xmldsig#hmac-sha1 [RFC3275] SignatureMethod
2000/09/xmldsig#MgmtData [RFC3275] Retrieval type
2000/09/xmldsig#minimal 2.4 Canonicalization
2000/09/xmldsig#PGPData [RFC3275] Retrieval type
2000/09/xmldsig#rawX509Certificate [RFC3275] Retrieval type
2000/09/xmldsig#rsa-sha1 [RFC3275] SignatureMethod
2000/09/xmldsig#RSAKeyValue [RFC3275] Retrieval type
2000/09/xmldsig#sha1 [RFC3275] DigestAlgorithm
2000/09/xmldsig#SPKIData [RFC3275] Retrieval type
2000/09/xmldsig#X509Data [RFC3275] Retrieval type
2001/04/xmldsig-more#arcfour 2.6.1 EncryptionMethod
2001/04/xmldsig-more#camellia128-cbc 2.6.2 EncryptionMethod
2001/04/xmldsig-more#camellia192-cbc 2.6.2 EncryptionMethod
2001/04/xmldsig-more#camellia256-cbc 2.6.2 EncryptionMethod
2001/04/xmldsig-more#ecdsa-sha1 2.3.6 SignatureMethod
2001/04/xmldsig-more#ecdsa-sha224 2.3.6 SignatureMethod
2001/04/xmldsig-more#ecdsa-sha256 2.3.6 SignatureMethod
2001/04/xmldsig-more#ecdsa-sha384 2.3.6 SignatureMethod
2001/04/xmldsig-more#ecdsa-sha512 2.3.6 SignatureMethod
2001/04/xmldsig-more#esign-sha1 2.3.7 SignatureMethod
2001/04/xmldsig-more#esign-sha224 2.3.7 SignatureMethod
2001/04/xmldsig-more#esign-sha256 2.3.7 SignatureMethod
2001/04/xmldsig-more#esign-sha384 2.3.7 SignatureMethod
2001/04/xmldsig-more#esign-sha512 2.3.7 SignatureMethod
2001/04/xmldsig-more#hmac-md5 2.2.1 SignatureMethod
2001/04/xmldsig-more#hmac-ripemd160 2.2.3 SignatureMethod
2001/04/xmldsig-more#hmac-sha224 2.2.2 SignatureMethod
2001/04/xmldsig-more#hmac-sha256 2.2.2 SignatureMethod
2001/04/xmldsig-more#hmac-sha384 2.2.2 SignatureMethod
2001/04/xmldsig-more#hmac-sha512 2.2.2 SignatureMethod
2001/04/xmldsig-more#KeyName 3.2 Retrieval type
2001/04/xmldsig-more#KeyValue 3.2 Retrieval type
2001/04/xmldsig-more#kw-camellia128 2.6.3 EncryptionMethod
2001/04/xmldsig-more#kw-camellia192 2.6.3 EncryptionMethod
2001/04/xmldsig-more#kw-camellia256 2.6.3 EncryptionMethod
2001/04/xmldsig-more#md5 2.1.1 DigestAlgorithm
2001/04/xmldsig-more#PKCS7signedData 3.2 Retrieval type
2001/04/xmldsig-more#psec-kem 2.6.4 EncryptionMethod
2001/04/xmldsig-more#rawPGPKeyPacket 3.2 Retrieval type
2001/04/xmldsig-more#rawPKCS7signedData 3.2 Retrieval type
2001/04/xmldsig-more#rawSPKISexp 3.2 Retrieval type
2001/04/xmldsig-more#rawX509CRL 3.2 Retrieval type
2001/04/xmldsig-more#RetrievalMethod 3.2 Retrieval type
2001/04/xmldsig-more#rsa-md5 2.3.1 SignatureMethod
2001/04/xmldsig-more#rsa-sha256 2.3.2 SignatureMethod
2001/04/xmldsig-more#rsa-sha384 2.3.3 SignatureMethod
2001/04/xmldsig-more#rsa-sha512 2.3.4 SignatureMethod
2001/04/xmldsig-more#rsa-ripemd160 2.3.5 SignatureMethod
2001/04/xmldsig-more#sha224 2.1.2 DigestAlgorithm
2001/04/xmldsig-more#sha384 2.1.3 DigestAlgorithm
2001/04/xmldsig-more#xptr 2.5.1 Transform
2001/04/xmldsig-more#PKCS7signedData 3.1 KeyInfo child
2001/04/xmlenc#aes128-cbc [XMLENC11] EncryptionMethod
2001/04/xmlenc#aes192-cbc [XMLENC11] EncryptionMethod
2001/04/xmlenc#aes256-cbc [XMLENC11] EncryptionMethod
2001/04/xmlenc#dh [XMLENC11] AgreementMethod
2001/04/xmlenc#kw-aes128 [XMLENC11] EncryptionMethod
2001/04/xmlenc#kw-aes192 [XMLENC11] EncryptionMethod
2001/04/xmlenc#kw-aes256 [XMLENC11] EncryptionMethod
2001/04/xmlenc#ripemd160 [XMLENC11] DigestAlgorithm
2001/04/xmlenc#rsa-1_5 [XMLENC11] EncryptionMethod
2001/04/xmlenc#rsa-oaep-mgf1p [XMLENC11] EncryptionMethod
2001/04/xmlenc#sha256 [XMLENC11] DigestAlgorithm
2001/04/xmlenc#sha512 [XMLENC11] DigestAlgorithm
2001/04/xmlenc#tripledes-cbc [XMLENC11] EncryptionMethod
2002/06/xmldsig-filter2 [XPATH] Transform
2002/06 / xmldsig-filter2 [XPATH]変換
2002/07/decrypt#XML [DECRYPT] Transform
2002/07/decrypt#Binary [DECRYPT] Transform
2006/12/xmlc12n11# [CANON11] Canonicalization
2006/12/xmlc14n11#WithComments [CANON11] Canonicalization
2007/05/xmldsig-more#ecdsa-ripemd160 2.3.6 SignatureMethod
2007/05/xmldsig-more#ecdsa-whirlpool 2.3.5 SignatureMethod
2007/05/xmldsig-more#kw-seed128 2.6.6 EncryptionMethod
2007/05/xmldsig-more#md2-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#md5-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#MGF1 2.3.9 SignatureMethod
2007/05/xmldsig-more#ripemd128-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#ripemd160-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#rsa-pss 2.3.9 SignatureMethod
2007/05/xmldsig-more#rsa-sha224 2.3.11 SignatureMethod
2007/05/xmldsig-more#rsa-whirlpool 2.3.5 SignatureMethod
2007/05/xmldsig-more#seed128-cbc 2.6.5 EncryptionMethod
2007/05/xmldsig-more#sha1-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#sha224-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#sha256-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#sha3-224 2.1.5 DigestAlgorithm
2007/05/xmldsig-more#sha3-224-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#sha3-256 2.1.5 DigestAlgorithm
2007/05/xmldsig-more#sha3-256-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#sha3-384 2.1.5 DigestAlgorithm
2007/05/xmldsig-more#sha3-384-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#sha3-512 2.1.5 DigestAlgorithm
2007/05/xmldsig-more#sha3-512-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#sha384-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#sha512-rsa-MGF1 2.3.10 SignatureMethod
2007/05/xmldsig-more#whirlpool 2.1.4 DigestAlgorithm
2007/05/xmldsig-more#whirlpool-rsa-MGF1 2.3.10 SignatureMethod
2009/xmlenc11#kw-aes-128-pad [XMLENC11] EncryptionMethod
2009/xmlenc11#kw-aes-192-pad [XMLENC11] EncryptionMethod
2009/xmlenc11#kw-aes-256-pad [XMLENC11] EncryptionMethod
2009/xmldsig11#dsa-sha256 [XMLDSIG11] SignatureMethod
2009/xmldsig11#ECKeyValue [XMLDSIG11] Retrieval type
2009/xmldsig11#DEREncodedKeyValue [XMLDSIG11] Retrieval type
2009/xmlenc11#aes128-gcm [XMLENC11] EncryptionMethod
2009/xmlenc11#aes192-gcm [XMLENC11] EncryptionMethod
2009/xmlenc11#aes256-gcm [XMLENC11] EncryptionMethod
2009/xmlenc11#ConcatKDF [XMLENC11] EncryptionMethod
2009/xmlenc11#mgf1sha1 [XMLENC11] SignatureMethod
2009/xmlenc11#mgf1sha224 [XMLENC11] SignatureMethod
2009/xmlenc11#mgf1sha256 [XMLENC11] SignatureMethod
2009/xmlenc11#mgf1sha384 [XMLENC11] SignatureMethod
2009/xmlenc11#mgf1sha512 [XMLENC11] SignatureMethod
2009/xmlenc11#pbkdf2 [XMLENC11] EncryptionMethod
2009/xmlenc11#rsa-oaep [XMLENC11] EncryptionMethod
2009/xmlenc11#ECDH-ES [XMLENC11] EncryptionMethod
2009/xmlenc11#dh-es [XMLENC11] EncryptionMethod
2010/xmlsec-ghc#generic-hybrid [GENERIC] Generic Hybrid
2010/xmlsec-ghc#rsaes-kem [GENERIC] Generic Hybrid
2010/xmlsec-ghc#ecies-kem [GENERIC] Generic Hybrid
TR/1999/REC-xpath-19991116 [XPATH] Transform
TR/1999/REC-xslt-19991116 [XSLT] Transform
TR/2001/06/xml-exc-c14n# [XCANON] Canonicalization
TR/2001/06/xml-exc-c14n#WithComments [XCANON] Canonicalization
TR/2001/REC-xml-c14n-20010315 [CANON10] Canonicalization
TR/2001/REC-xml-c14n-20010315#WithComments
[CANON10] Canonicalization
TR/2001/REC-xmlschema-1-20010502 [Schema] Transform
The initial "http://www.w3.org/" part of the URI is not included above.
URIの最初の「http://www.w3.org/」の部分は上記に含まれていません。
W3C and IANA allocation considerations are given below.
W3CとIANAの割り当てに関する考慮事項を以下に示します。
As it is easy for people to construct their own unique URIs [RFC3986] and, if appropriate, to obtain a URI from the W3C, it is not intended that any additional "http://www.w3.org/2007/05/xmldsig-more#" URIs be created beyond those enumerated in this RFC. (W3C Namespace stability rules prohibit the creation of new URIs under "http://www.w3.org/2000/09/xmldsig#" and URIs under "http://www.w3.org/2001/04/xmldsig-more#" were frozen with the publication of [RFC4051].)
人々が独自の一意のURI [RFC3986]を構築し、適切な場合はW3CからURIを取得することは簡単であるため、追加の「http://www.w3.org/2007/05/ xmldsig-more＃ "URIは、このRFCで列挙されているものを超えて作成されます。 （W3C名前空間の安定性ルールでは、「http://www.w3.org/2000/09/xmldsig#」の下の新しいURIと「http://www.w3.org/2001/04/xmldsig-」の下のURIの作成が禁止されています[more＃ "は[RFC4051]の発行に伴い凍結されました。）
An "xmldsig-more" URI does not imply any official W3C or IETF status for these algorithms or identifiers nor does it imply that they are only useful in digital signatures. Currently, dereferencing such URIs may or may not produce a temporary placeholder document. Permission to use these URI prefixes has been given by the W3C.
「xmldsig-more」URIは、これらのアルゴリズムまたは識別子の公式のW3CまたはIETFステータスを意味するものではなく、デジタル署名でのみ有用であることを意味するものでもありません。現在、そのようなURIを逆参照すると、一時的なプレースホルダードキュメントが生成される場合と生成されない場合があります。これらのURIプレフィックスを使用する権限は、W3Cによって付与されています。
IANA has established a registry entitled "XML Security URIs". The initial contents correspond to Section 4.2 of this document with each section number in the "Sec/Doc" column augmented with a reference to this RFC (for example, "2.6.4" means "[RFC6931], Section 2.6.4").
IANAは、「XMLセキュリティURI」という名前のレジストリを確立しました。最初の内容は、このドキュメントのセクション4.2に対応し、「Sec / Doc」列の各セクション番号は、このRFCへの参照が追加されています（たとえば、「2.6.4」は「[RFC6931]、セクション2.6.4」を意味します）。 。
New entries, including new Types, will be added based on Expert Review [RFC5226]. Criterion for inclusion are (1) documentation sufficient for interoperability of the algorithm or data type and the XML syntax for its representation and use and (2) sufficient importance as normally indicated by inclusion in (2a) an approved W3C Note, Proposed Recommendation, or Recommendation or (2b) an approved IETF Standards Track document. Typically, the registry will reference a W3C or IETF document specifying such XML syntax; that document will either contain a more abstract description of the algorithm or data type or reference another document with a more abstract description.
新しいタイプを含む新しいエントリは、エキスパートレビュー[RFC5226]に基づいて追加されます。含めるための基準は、（1）アルゴリズムまたはデータ型の相互運用性に十分な文書、およびその表現と使用のためのXML構文、および（2）（2a）承認されたW3Cノート、推奨案に含めることによって通常示される十分な重要性、または推奨または（2b）承認されたIETF標準トラックドキュメント。通常、レジストリは、このようなXML構文を指定するW3CまたはIETFドキュメントを参照します。そのドキュメントは、アルゴリズムまたはデータ型のより抽象的な説明を含むか、より抽象的な説明を持つ別のドキュメントを参照します。
This RFC is concerned with documenting the URIs that designate algorithms and some data types used in connection with XML security. The security considerations vary widely with the particular algorithms, and the general security considerations for XML security are outside of the scope of this document but appear in [XMLDSIG11], [XMLENC11], [CANON10], [CANON11], and [GENERIC].
このRFCは、XMLセキュリティに関連して使用されるアルゴリズムといくつかのデータ型を指定するURIの文書化に関係しています。セキュリティに関する考慮事項は特定のアルゴリズムによって大きく異なり、XMLセキュリティに関する一般的なセキュリティ上の考慮事項はこのドキュメントの範囲外ですが、[XMLDSIG11]、[XMLENC11]、[CANON10]、[CANON11]、および[GENERIC]に記載されています。
[RFC6151] should be consulted before considering the use of MD5 as a DigestMethod or RSA-MD5 as a SignatureMethod.
[RFC6151]は、MD5をDigestMethodとして、またはRSA-MD5をSignatureMethodとして使用することを検討する前に参照する必要があります。
See [RFC6194] for SHA-1 security considerations and [RFC6151] for MD5 security considerations.
SHA-1のセキュリティに関する考慮事項については[RFC6194]を、MD5のセキュリティに関する考慮事項については[RFC6151]を参照してください。
Additional security considerations are given in connection with the description of some algorithms in the body of this document.
このドキュメントの本文にある一部のアルゴリズムの説明に関連して、セキュリティに関する追加の考慮事項が示されています。
Implementers should be aware that cryptographic algorithms become weaker with time. As new cryptoanalysis techniques are developed and computing performance improves, the work factor to break a particular cryptographic algorithm will reduce. Therefore, cryptographic implementations should be modular, allowing new algorithms to be readily inserted. That is, implementers should be prepared for the set of mandatory-to-implement algorithms to change over time.
実装者は、暗号化アルゴリズムが時間とともに弱くなることを認識する必要があります。新しい暗号分析技術が開発され、コンピューティングパフォーマンスが向上すると、特定の暗号化アルゴリズムを解読する作業要素が減少します。したがって、暗号化の実装はモジュール化する必要があり、新しいアルゴリズムを簡単に挿入できます。つまり、実装者は、実装に必須のアルゴリズムのセットが時間の経過とともに変化する準備をする必要があります。
The contributions to this document by the following people, listed in alphabetic order, are gratefully acknowledged: Benoit Claise, Adrian Farrel, Stephen Farrell, Ernst Giessmann, Frederick Hirsch, Bjoern Hoehrmann, Russ Housley, Satoru Kanno, Charlie Kaufman, Konrad Lanz, HwanJin Lee, Barry Leiba, Peter Lipp, Subramanian Moonesamy, Thomas Roessler, Hanseong Ryu, Peter Saint-Andre, and Sean Turner.
次の人々によるこのドキュメントへの貢献は、アルファベット順にリストされており、感謝の意を表します：Benoit Claise、Adrian Farrel、Stephen Farrell、Ernst Giessmann、Frederick Hirsch、Bjoern Hoehrmann、Russ Housley、菅野悟、Charlie Kaufman、Konrad Lanz、HwanJinリー、バリーレイバ、ピーターリップ、サブラマニアンムーネサミー、トーマスレスラー、ハンソンリュー、ピーターセントアンドレ、ショーンターナー。
The following contributors to [RFC4051], on which this document is based, are gratefully acknowledged: Glenn Adams, Merlin Hughs, Gregor Karlinger, Brian LaMachia, Shiho Moriai, Joseph Reagle, Russ Housley, and Joel Halpern.
このドキュメントのベースとなっている[RFC4051]への次の寄稿者に感謝の意を表します。
The following changes have been made in RFC 4051 to produce this document.
このドキュメントを作成するために、RFC 4051で次の変更が行われました。
1. Updated and added numerous RFC, W3C, and Internet-Draft references.
1. 多数のRFC、W3C、およびInternet-Draftの参照を更新および追加しました。
2. Added #ecdsa-ripemd160, #whirlpool, #ecdsa-whirlpool, #rsa-whirlpool, #seed128-cbc, and #kw-seed128.
2. ＃ecdsa-ripemd160、＃whirlpool、＃ecdsa-whirlpool、＃rsa-whirlpool、＃seed128-cbc、および＃kw-seed128が追加されました。
3. Incorporated RFC 4051 errata [Errata191].
3. RFC 4051 errata [Errata191]を組み込みました。
4. Added URI and fragment index sections.
4. Added URI and fragment index sections.
5. For MD5 and SHA-1, added references to [RFC6151] and [RFC6194].
5. MD5およびSHA-1について、[RFC6151]および[RFC6194]への参照を追加しました。
5. Added SHA-3 / Keccak placeholder section including #sha3-224, #sha3-256, #sha3-384, and #sha3-512.
5. Shaa / KCK Blackhalderセクションの数には、＃Shaa-224、＃Shaa-、＃Shaya-384が含まれます。
6. Added RSASSA-PSS sections including #sha3-224-MGF1, #sha3-256-MGF1, #sha3-384-MGF1, #sha3-512-MGF1, #md2-rsa-MGF1, #md5-rsa-MGF1, #sha1-rsa-MGF1, #sha224-rsa-MGF1, #sha256-rsa-MGF1, #sha384-rsa-MGF1, #sha512-rsa-MGF1, #ripemd128-rsa-MGF1, #ripemd160-rsa-MGF1, and #whirlpool-rsa-MGF1.
6. ＃sha3-224-MGF1、＃sha3-256-MGF1、＃sha3-384-MGF1、＃sha3-512-MGF1、＃md2-rsa-MGF1、＃md5-rsa-MGF1、＃sha1を含むRSASSA-PSSセクションを追加-rsa-MGF1、＃sha224-rsa-MGF1、＃sha256-rsa-MGF1、＃sha384-rsa-MGF1、＃sha512-rsa-MGF1、＃ripemd128-rsa-MGF1、＃ripemd160-rsa-MGF1、および#whirl -rsa-MGF1。
7. Added new URIs from Canonical XML 1.1 and XML Encryption 1.1 including: #aes128-gcm, #aes192-gcm, #aes256-gc, #ConcatKDF, #pbkdf, #rsa-oaep, #ECDH-ES, and #dh-es.
7. ＃aes128-gcm、＃aes192-gcm、＃aes256-gc、＃ConcatKDF、＃pbkdf、＃rsa-oaep、＃ECDH-ES、および＃dh-esを含むCanonical XML 1.1およびXML Encryption 1.1からの新しいURIを追加しました。
8. Added acronym subsection.
8. 頭字語のサブセクションを追加しました。
9. Added numerous URIs that are specified in W3C XML Security documents to the Indexes. These do not have sections in the body of this document -- for example, those for dsa-sha256, mgf1sha*, decrypt#XML, and xmldsig-filter2.
9. W3C XMLセキュリティドキュメントで指定されている多数のURIをインデックスに追加しました。これらには、このドキュメントの本文にセクションはありません。たとえば、dsa-sha256、mgf1sha *、decrypt＃XML、xmldsig-filter2などです。
10. Requested establishment of an IANA registry.
10. Requested establishment of an IANA registry.
11. Made various editorial changes.
11. Made various editorial changes.
Normative References
引用文献
[10118-3] ISO, "Information technology -- Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions", ISO/IEC 10118-3:2004, 2004.
[10118-3] ISO、「情報技術-セキュリティ技術-ハッシュ関数-パート3：専用ハッシュ関数」、ISO / IEC 10118-3：2004、2004。
[18033-2] ISO, "Information technology -- Security techniques -- Encryption algorithms -- Part 3: Asymmetric ciphers", ISO/IEC 18033-2:2010, 2010.
[18033-2] ISO, "Information technology -- Security techniques -- Encryption algorithms -- Part 3: Asymmetric ciphers", ISO/IEC 18033-2:2010, 2010.
[Camellia] Aoki, K., Ichikawa, T., Matsui, M., Moriai, S., Nakajima, J., and T. Tokita, "Camellia: A 128-bit Block Cipher Suitable for Multiple Platforms - Design and Analysis", 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.
[ツバキ]青木和夫、市川哲也、松井正明、森井真一、中島純一、時田徹。「ツバキ：複数のプラットフォームに適した128ビットブロック暗号-設計と解析「暗号の選択された領域、第7回年次国際ワークショップ、SAC 2000、2000年8月、Proceedings、Lecture Notes in Computer Science 2012、pp。39-56、Springer-Verlag、2001。
[FIPS180-4] US National Institute of Science and Technology, "Secure Hash Standard (SHS)", FIPS 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[FIPS180-4] US National Institute of Science and Technology, "Secure Hash Standard (SHS)", FIPS 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/ fips-180-4.pdf>.
[FIPS186-3] US National Institute of Science and Technology, "Digital Signature Standard (DSS)", FIPS 186-3, June 2009, <http://csrc.nist.gov/publications/fips/ fips186-3/fips_186-3.pdf>.
[FIPS186-3]米国国立科学技術研究所、「デジタル署名標準（DSS）」、FIPS 186-3、2009年6月、<http://csrc.nist.gov/publications/fips/ fips186-3 / fips_186 -3.pdf>。
[IEEEP1363a] IEEE, "Standard Specifications for Public Key Cryptography- Amendment 1: Additional Techniques", IEEE 1363a-2004, 2004.
[IEEEP1363a] IEEE、「公開鍵暗号化の標準仕様-修正1：追加の技術」、IEEE 1363a-2004、2004。
[RC4] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", Second Edition, John Wiley and Sons, New York, NY, 1996.
[RC4] Schneier、B。、「Applied Cryptography：Protocols、Algorithms、and Source Code in C」、Second Edition、John Wiley and Sons、ニューヨーク、ニューヨーク、1996。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[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：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, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[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月。
[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、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 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]松井雅夫、中島潤一郎、森井信一郎、「椿暗号アルゴリズムの解説」、RFC 3713、2004年4月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4050] 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.
[RFC4050] Blake-Wilson、S.、Karlinger、G.、Kobayashi、T.、Y。Wang、「Using Elliptic Curve Signature Algorithm（ECDSA）for XML Digital Signatures」、RFC 4050、2005年4月。
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RFC4055] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルで使用するためのRSA暗号化の追加のアルゴリズムと識別子」、RFC 4055 、2005年6月。
[RFC4269] Lee, H., Lee, S., Yoon, J., Cheon, D., and J. Lee, "The SEED Encryption Algorithm", RFC 4269, December 2005.
[RFC4269] Lee、H.、Lee、S.、Yoon、J.、Cheon、D。、およびJ. Lee、「The SEED Encryption Algorithm」、RFC 4269、2005年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6234] Eastlake 3rd、D。およびT. Hansen、「US Secure Hash Algorithms（SHA and SHA-based HMAC and HKDF）」、RFC 6234、2011年5月。
[X9.62] American National Standards Institute, Accredited Standards Committee X9, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62:2005, 2005.
[X9.62] American National Standards Institute、認定基準委員会X9、「金融サービス業界の公開鍵暗号化：楕円曲線デジタル署名アルゴリズム（ECDSA）」、ANSI X9.62：2005、2005。
[XMLENC10] Reagle, J. and D. Eastlake, "XML Encryption Syntax and Processing", W3C Recommendation, 10 December 2002, <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>.
[XMLENC10] Reagle、J。およびD. Eastlake、「XML暗号化構文および処理」、W3C勧告、2002年12月10日、<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/ >。
[XMLENC11] Eastlake, D., Reagle, J., Hirsch, F., and T. Roessler, "XML Encryption Syntax and Processing Version 1.1", W3C Proposed Recommendation, 24 January 2013, <http://www.w3.org/TR/2013/PR-xmlenc-core1-20130124/>.
[XMLENC11] Eastlake、D.、Reagle、J.、Hirsch、F。、およびT. Roessler、「XML Encryption Syntax and Processing Version 1.1」、W3C Proposed Recommendation、2013年1月24日、<http：//www.w3。 org / TR / 2013 / PR-xmlenc-core1-20130124 />。
[XPointer] Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer Framework", W3C Recommendation, 25 March 2003, <http://www.w3.org/TR/2003/ REC-xptr-framework-20030325/>.
[XPointer] Grosso、P.、Maler、E.、Marsh、J。、およびN. Walsh、「XPointer Framework」、W3C勧告、2003年3月25日、<http://www.w3.org/TR/2003/ REC-xptr-framework-20030325 />。
Informative References
参考引用
[CANON10] Boyer, J., "Canonical XML Version 1.0", W3C Recommendation, 15 March 2001, <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[CANON10] Boyer、J。、「Canonical XML Version 1.0」、W3C勧告、2001年3月15日、<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>。
[CANON11] Boyer, J., and G. Marcy, "Canonical XML Version 1.1", W3C Recommendation, 2 May 2008, <http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/>.
[CANON11] Boyer、J。、およびG. Marcy、「Canonical XML Version 1.1」、W3C勧告、2008年5月2日、<http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/ >。
[DECRYPT] Hughes, M., Imamura, T., and H. Maruyama, "Decryption Transform for XML Signature", W3C Recommendation, 10 December 2002, <http://www.w3.org/TR/2002/ REC-xmlenc-decrypt-20021210>.
[解読] Hughes、M.、Imamura、T。、およびH. Maruyama、「XML署名の復号化変換」、W3C勧告、2002年12月10日、<http://www.w3.org/TR/2002/ REC- xmlenc-decrypt-20021210>。
[Errata191] RFC Errata, Errata ID 191, RFC 4051, <http://www.rfc-editor.org>.
[Errata191] RFC Errata、Errata ID 191、RFC 4051、<http://www.rfc-editor.org>。
[GENERIC] Nystrom, M. and F. Hirsch, "XML Security Generic Hybrid Ciphers", W3C Working Group Note, 24 January 2013, <http://www.w3.org/TR/2013/ NOTE-xmlsec-generic-hybrid-20130124/>.
[GENERIC] Nystrom、M。、およびF. Hirsch、「XML Security Generic Hybrid Ciphers」、W3Cワーキンググループノート、2013年1月24日、<http://www.w3.org/TR/2013/ NOTE-xmlsec-generic-ハイブリッド-20130124 />。
[Keccak] Bertoni, G., Daeman, J., Peeters, M., and G. Van Assche, "The KECCAK sponge function family", January 2013, <http://keccak.noekeon.org>.
[Keccak] Bertoni, G., Daeman, J., Peeters, M., and G. Van Assche, "The KECCAK sponge function family", January 2013, <http://keccak.noekeon.org>.
[RFC3075] Eastlake 3rd, D., Reagle, J., and D. Solo, "XML-Signature Syntax and Processing", RFC 3075, March 2001.
[RFC3075] Eastlake 3rd、D.、Reagle、J。、およびD. Solo、「XML-Signature Syntax and Processing」、RFC 3075、2001年3月。
[RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[RFC3076]ボイヤーJ。、「Canonical XML Version 1.0」、RFC 3076、2001年3月。
[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology of "Foo"", RFC 3092, 1 April 2001.
[RFC3092] Eastlake 3rd、D.、Manros、C。、およびE. Raymond、「Etymology of "Foo"」、RFC 3092、2001年4月1日。
[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., and J. Reagle, "Exclusive XML Canonicalization, Version 1.0", RFC 3741, March 2004.
[RFC4010] Park, J., Lee, S., Kim, J., and J. Lee, "Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 4010, February 2005.
[RFC4010] Park、J.、Lee、S.、Kim、J。、およびJ. Lee、「暗号化メッセージ構文（CMS）でのSEED暗号化アルゴリズムの使用」、RFC 4010、2005年2月。
[RFC4051] Eastlake 3rd, D., "Additional XML Security Uniform Resource Identifiers (URIs)", RFC 4051, April 2005.
[RFC4051] Eastlake 3rd、D。、「Additional XML Security Uniform Resource Identifiers（URIs）」、RFC 4051、2005年4月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、2011年2月。
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, March 2011.
[RFC6151]ターナー、S。およびL.チェン、「MD5メッセージダイジェストおよびHMAC-MD5アルゴリズムの更新されたセキュリティに関する考慮事項」、RFC 6151、2011年3月。
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, March 2011.
[RFC6194] Polk、T.、Chen、L.、Turner、S。、およびP. Hoffman、「SHA-0およびSHA-1メッセージダイジェストアルゴリズムのセキュリティに関する考慮事項」、RFC 6194、2011年3月。
[Schema] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, 28 October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.
[スキーマ] Thompson、H.、Beech、D.、Maloney、M。、およびN. Mendelsohn、「XML Schema Part 1：Structures Second Edition」、W3C勧告、2004年10月28日、<http：//www.w3。 org / TR / 2004 / REC-xmlschema-1-20041028 />。
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, 28 October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
Biron、P.およびA. Malhotra、「XML Schema Part 2：Datatypes Second Edition」、W3C勧告、2004年10月28日、<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ >。
[SHA-3] US National Institute of Science and Technology, "SHA-3 WINNER", February 2013, <http://csrc.nist.gov/ groups/ST/hash/sha-3/winner_sha-3.html>.
[SHA-3]米国国立科学技術研究所、「SHA-3 WINNER」、2013年2月、<http://csrc.nist.gov/ groups / ST / hash / sha-3 / winner_sha-3.html> 。
[W3C] World Wide Web Consortium, <http://www.w3.org>.
[W3C] World Wide Web Consortium、<http://www.w3.org>。
[XCANON] Boyer, J., Eastlake, D., and J. Reagle, "Exclusive XML Canonicalization Version 1.0", W3C Recommendation, 18 July 2002, <http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/>.
[XCANON] Boyer、J.、Eastlake、D。、およびJ. Reagle、「Exclusive XML Canonicalization Version 1.0」、W3C勧告、2002年7月18日、<http://www.w3.org/TR/2002/REC- xml-exc-c14n-20020718 />。
[XMLDSIG10] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T. Roessler, "XML Signature Syntax and Processing (Second Edition)", W3C Recommendation, 10 June 2008, <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>.
[XMLDSIG10] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and T. Roessler, "XML Signature Syntax and Processing (Second Edition)", W3C Recommendation, 10 June 2008, <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>.
[XMLDSIG11] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., Nystrom, M., Roessler, T., and K. Yiu, "XML Signature Syntax and Processing Version 1.1", W3C Proposed Recommendation, 24 January 2013, <http://www.w3.org/TR/2013/PR-xmldsig-core1-20130124/>.
[XMLDSIG11] Eastlake、D.、Reagle、J.、Solo、D.、Hirsch、F.、Nystrom、M.、Roessler、T。、およびK. Yiu、「XML署名構文および処理バージョン1.1」、W3C提案勧告、2013年1月24日、<http://www.w3.org/TR/2013/PR-xmldsig-core1-20130124/>。
[XMLDSIG-PROP] Hirsch, F., "XML Signature Properties", W3C Proposed Recommendation, 24 January 2013, <http://www.w3.org/TR/ 2013/PR-xmldsig-properties-20130124/>.
[XMLDSIG-PROP] Hirsch、F。、「XML Signature Properties」、W3C Proposed Recommendation、2013年1月24日、<http://www.w3.org/TR/ 2013 / PR-xmldsig-properties-20130124 />。
[XMLSECXREF] Hirsch, F., Roessler, T., and K. Yiu, "XML Security Algorithm Cross-Reference", W3C Working Group Note, 24 January 2013, <http://www.w3.org/TR/2013/ NOTE-xmlsec-algorithms-20130124/>.
[XMLSECXREF] Hirsch、F.、Roessler、T。、およびK. Yiu、「XML Security Algorithm Cross-Reference」、W3C Working Group Note、2013年1月24日、<http://www.w3.org/TR/2013 / NOTE-xmlsec-algorithms-20130124 />。
[XPATH] Boyer, J., Hughes, M., and J. Reagle, "XML-Signature XPath Filter 2.0", W3C Recommendation, 8 November 2002, <http://www.w3.org/TR/2002/ REC-xmldsig-filter2-20021108/>.
[XPATH] Boyer、J.、Hughes、M。、およびJ. Reagle、「XML-Signature XPath Filter 2.0」、W3C勧告、2002年11月8日、<http://www.w3.org/TR/2002/ REC -xmldsig-filter2-20021108 />。
Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J., and J. Simeon, "XML Path Language (XPath) 2.0 (Second Edition)", W3C Recommendation, 14 December 2010, <http://www.w3.org/TR/2010/REC-xpath20-20101214/>.
Berglund、A.、Boag、S.、Chamberlin、D.、Fernandez、M.、Kay、M.、Robie、J。、およびJ. Simeon、「XML Path Language（XPath）2.0（Second Edition）」、W3C勧告、2010年12月14日、<http://www.w3.org/TR/2010/REC-xpath20-20101214/>。
[XSLT] Saxonica, M., "XSL Transformations (XSLT) Version 2.0", W3C Recommendation, 23 January 2007, <http://www.w3.org/TR/2007/REC-xslt20-20070123/>.
[XSLT] Saxonica、M。、「XSL Transformations（XSLT）Version 2.0」、W3C勧告、2007年1月23日、<http://www.w3.org/TR/2007/REC-xslt20-20070123/>。
Author's Address
著者のアドレス
Donald E. Eastlake, 3rd Huawei Technologies 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク、第3ファーウェイテクノロジーズ155 Beaver Street Milford、MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com