[要約] RFC 3275は、XMLデータの署名構文と処理方法を定義しています。このRFCの目的は、XML文書の信頼性とセキュリティを向上させるために、デジタル署名の使用を可能にすることです。
Network Working Group D. Eastlake 3rd
Request for Comments: 3275 Motorola
Obsoletes: 3075 J. Reagle
Category: Standards Track W3C
D. Solo
Citigroup
March 2002
(Extensible Markup Language) XML-Signature Syntax and Processing
（拡張可能なマークアップ言語）XML-Signature構文と処理
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2002 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
Copyright（c）2002 The Internet Society＆W3C（MIT、INRIA、KEIO）、All Rights Reserved。
Abstract
概要
This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.
このドキュメントは、XML（拡張可能なマークアップ言語）デジタル署名処理ルールと構文を指定します。XML署名は、署名または他の場所を含むXML内にあるかどうかにかかわらず、あらゆるタイプのデータの整合性、メッセージ認証、および/または署名者認証サービスを提供します。
Table of Contents
目次
1. Introduction................................................... 3
1.1 Editorial and Conformance Conventions......................... 4
1.2 Design Philosophy............................................. 4
1.3 Versions, Namespaces and Identifiers.......................... 4
1.4 Acknowledgements.............................................. 6
1.5 W3C Status.................................................... 6
2. Signature Overview and Examples................................ 7
2.1 Simple Example (Signature, SignedInfo, Methods, and References) 8
2.1.1 More on Reference........................................... 9
2.2 Extended Example (Object and SignatureProperty)............... 10
2.3 Extended Example (Object and Manifest)........................ 12
3.0 Processing Rules.............................................. 13
3.1 Core Generation............................................... 13
3.1.1 Reference Generation........................................ 13
3.1.2 Signature Generation........................................ 13
3.2 Core Validation............................................... 14
3.2.1 Reference Validation........................................ 14
3.2.2 Signature Validation........................................ 15
4.0 Core Signature Syntax......................................... 15
4.0.1 The ds:CryptoBinary Simple Type............................. 17
4.1 The Signature element......................................... 17
4.2 The SignatureValue Element.................................... 18
4.3 The SignedInfo Element........................................ 18
4.3.1 The CanonicalizationMethod Element.......................... 19
4.3.2 The SignatureMethod Element................................. 21
4.3.3 The Reference Element....................................... 21
4.3.3.1 The URI Attribute......................................... 22
4.3.3.2 The Reference Processing Model............................ 23
4.3.3.3 Same-Document URI-References.............................. 25
4.3.3.4 The Transforms Element.................................... 26
4.3.3.5 The DigestMethod Element.................................. 28
4.3.3.6 The DigestValue Element................................... 28
4.4 The KeyInfo Element........................................... 29
4.4.1 The KeyName Element......................................... 31
4.4.2 The KeyValue Element........................................ 31
4.4.2.1 The DSAKeyValue Element................................... 32
4.4.2.2 The RSAKeyValue Element................................... 33
4.4.3 The RetrievalMethod Element................................. 34
4.4.4 The X509Data Element........................................ 35
4.4.5 The PGPData Element......................................... 38
4.4.6 The SPKIData Element........................................ 39
4.4.7 The MgmtData Element........................................ 40
4.5 The Object Element............................................ 40
5.0 Additional Signature Syntax................................... 42
5.1 The Manifest Element.......................................... 42
5.2 The SignatureProperties Element............................... 43
5.3 Processing Instructions in Signature Elements................. 44
5.4 Comments in Signature Elements................................ 44
6.0 Algorithms.................................................... 44
6.1 Algorithm Identifiers and Implementation Requirements......... 44
6.2 Message Digests............................................... 46
6.2.1 SHA-1....................................................... 46
6.3 Message Authentication Codes.................................. 46
6.3.1 HMAC........................................................ 46
6.4 Signature Algorithms.......................................... 47
6.4.1 DSA......................................................... 47
6.4.2 PKCS1 (RSA-SHA1)............................................ 48
6.5 Canonicalization Algorithms................................... 49
6.5.1 Canonical XML............................................... 49
6.6 Transform Algorithms.......................................... 50
6.6.1 Canonicalization............................................ 50
6.6.2 Base64...................................................... 50
6.6.3 XPath Filtering............................................. 51
6.6.4 Enveloped Signature Transform............................... 54
6.6.5 XSLT Transform.............................................. 54
7. XML Canonicalization and Syntax Constraint Considerations...... 55
7.1 XML 1.0, Syntax Constraints, and Canonicalization............. 56
7.2 DOM/SAX Processing and Canonicalization....................... 57
7.3 Namespace Context and Portable Signatures..................... 58
8.0 Security Considerations....................................... 59
8.1 Transforms.................................................... 59
8.1.1 Only What is Signed is Secure............................... 60
8.1.2 Only What is 'Seen' Should be Signed........................ 60
8.1.3 'See' What is Signed........................................ 61
8.2 Check the Security Model...................................... 62
8.3 Algorithms, Key Lengths, Certificates, Etc.................... 62
9. Schema, DTD, Data Model, and Valid Examples.................... 63
10. Definitions................................................... 63
Appendix: Changes from RFC 3075................................... 67
References........................................................ 67
Authors' Addresses................................................ 72
Full Copyright Statement.......................................... 73
This document specifies XML syntax and processing rules for creating and representing digital signatures. XML Signatures can be applied to any digital content (data object), including XML. An XML Signature may be applied to the content of one or more resources. Enveloped or enveloping signatures are over data within the same XML document as the signature; detached signatures are over data external to the signature element. More specifically, this specification defines an XML signature element type and an XML signature application; conformance requirements for each are specified by way of schema definitions and prose respectively. This specification also includes other useful types that identify methods for referencing collections of resources, algorithms, and keying and management information.
このドキュメントは、デジタル署名を作成および表現するためのXML構文と処理ルールを指定します。XML署名は、XMLを含む任意のデジタルコンテンツ（データオブジェクト）に適用できます。XML署名は、1つ以上のリソースのコンテンツに適用できます。包み込まれた署名または包括的な署名は、署名と同じXMLドキュメント内のデータを超えています。デタッチされた署名は、署名要素の外部のデータを超えています。より具体的には、この仕様はXML署名要素タイプとXML署名アプリケーションを定義します。それぞれの適合要件は、それぞれスキーマの定義と散文によって指定されます。この仕様には、リソース、アルゴリズム、キーイングおよび管理情報のコレクションを参照する方法を特定する他の有用なタイプも含まれています。
The XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements. For further information, please see Security Considerations (section 8).
XML署名は、参照データ（オクテット）とキーを関連付ける方法です。キーが人や機関にどのように関連付けられているか、また参照および署名されるデータの意味を規範的に指定することはありません。したがって、この仕様は安全なXMLアプリケーションの重要なコンポーネントですが、特に人間から人間の基礎として署名されたXML（または他のデータ形式）を使用することに関して、すべてのアプリケーションセキュリティ/信頼の懸念に対処するには十分ではありません。コミュニケーションと合意。このようなアプリケーションは、追加のキー、アルゴリズム、処理、およびレンダリング要件を指定する必要があります。詳細については、セキュリティに関する考慮事項（セクション8）を参照してください。
For readability, brevity, and historic reasons this document uses the term "signature" to generally refer to digital authentication values of all types. Obviously, the term is also strictly used to refer to authentication values that are based on public keys and that provide signer authentication. When specifically discussing authentication values based on symmetric secret key codes we use the terms authenticators or authentication codes. (See Check the Security Model, section 8.3.)
読みやすさ、簡潔さ、および歴史的な理由については、このドキュメントでは「署名」という用語を使用して、一般にすべてのタイプのデジタル認証値を指します。明らかに、この用語は、パブリックキーに基づいて署名者認証を提供する認証値を参照するために厳密に使用されます。対称シークレットキーコードに基づいて認証値を具体的に議論する場合は、認証器または認証コードという用語を使用します。（セキュリティモデル、セクション8.3を確認してください。）
This specification provides an XML Schema [XML-schema] and DTD [XML]. The schema definition is normative.
この仕様は、XMLスキーマ[XML-Schema]とDTD [XML]を提供します。スキーマ定義は規範的です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:
「必須」、「「必要」、「必須」、「shall」、「shall "、" sulld "、" not "、" becommended "、" may "、および"オプション」は、RFC2119 [キーワード]で説明されているように解釈される：
"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"
「それらは、実際に相互操作に必要な場合、または害を引き起こす可能性のある行動を制限するために必要な場合にのみ使用する必要があります（例えば、再送信の制限）」
Consequently, we use these capitalized key words to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the Namespaces in XML specification [XML-ns] is described as "REQUIRED."
その結果、これらの大文字のキーワードを使用して、実装の相互運用性とセキュリティに影響を与えるプロトコルとアプリケーションの機能と動作よりも要件を明確に指定します。これらのキーワードは、XML文法を説明するために使用されません（大文字です）。スキーマの定義は、そのような要件を明確に説明しており、プロトコルと機能の自然言語の説明のためにこれらの用語の顕著な留保を留保したいと考えています。たとえば、XML属性は「オプション」であると説明される場合があります。XML仕様[XML-NS]の名前空間へのコンプライアンスは、「必須」と呼ばれています。
The design philosophy and requirements of this specification are addressed in the XML-Signature Requirements document [XML-Signature-RD].
この仕様の設計哲学と要件は、XML-Signature要件ドキュメント[XML-Signature-Rd]で説明されています。
No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different namespace. The XML namespace [XML-ns] URI that MUST be used by implementations of this (dated) specification is:
この構文の明示的なバージョン番号については、規定は行われていません。将来のバージョンが必要な場合は、別の名前空間を使用します。この（日付の）仕様の実装で使用する必要があるXML名前空間[XML-NS] URIは次のとおりです。
xmlns="http://www.w3.org/2000/09/xmldsig#"
This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML namespaces, the use of internal entities [XML] or our "dsig" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.
この名前空間は、この仕様で使用されるアルゴリズム識別子のプレフィックスとしても使用されます。アプリケーションはXMLおよびXMLの名前空間をサポートする必要がありますが、内部エンティティ[XML]または「DSIG」XMLネームスペースプレフィックスとデフォルト/スコープコンベンションの使用はオプションです。これらの施設を使用して、コンパクトで読みやすい例を提供します。
This specification uses Uniform Resource Identifiers [URI] to identify resources, algorithms, and semantics. The URI in the namespace declaration above is also used as a prefix for URIs under the control of this specification. For resources not under the control of this specification, we use the designated Uniform Resource Names [URN] or Uniform Resource Locators [URL] defined by its normative external specification. If an external specification has not allocated itself a Uniform Resource Identifier we allocate an identifier under our own namespace. For instance:
この仕様では、均一なリソース識別子[URI]を使用して、リソース、アルゴリズム、およびセマンティクスを識別します。上記の名前空間宣言のURIは、この仕様の制御下にあるURIのプレフィックスとしても使用されます。この仕様を管理していないリソースには、指定されたユニフォームリソース名[URN]またはその規範的な外部仕様で定義された均一なリソースロケーター[URL]を使用します。外部仕様が均一なリソース識別子を割り当てていない場合、独自の名前空間の下に識別子を割り当てます。例えば：
SignatureProperties is identified and defined by this specification's namespace: http://www.w3.org/2000/09/xmldsig#SignatureProperties
SignaturePropertiesは、この仕様の名前空間で識別および定義されています：http：//www.w3.org/2000/09/xmldsig#signatureproperties
XSLT is identified and defined by an external URI http://www.w3.org/TR/1999/REC-xslt-19991116
XSLTは、外部URI http://www.w3.org/tr/1999/rec-xslt-1999116によって識別および定義されています
SHA1 is identified via this specification's namespace and defined via a normative reference http://www.w3.org/2000/09/xmldsig#sha1 FIPS PUB 180-1. Secure Hash Standard. U.S. Department of Commerce/National Institute of Standards and Technology.
SHA1はこの仕様の名前空間で識別され、規範的な参照http://www.w3.org/2000/09/xmldsig#sha1 Fips Pub 180-1で定義されます。安全なハッシュ標準。米国商務省/国立標準技術研究所。
Finally, in order to provide for terse namespace declarations we sometimes use XML internal entities [XML] within URIs. For instance:
最後に、簡潔な名前空間宣言を提供するために、URIS内でXML内部エンティティ[XML]を使用することがあります。例えば：
<?xml version='1.0'?>
<!DOCTYPE Signature SYSTEM
"xmldsig-core-schema.dtd" [ <!ENTITY dsig
"http://www.w3.org/2000/09/xmldsig#"> ]>
<Signature xmlns="&dsig;" Id="MyFirstSignature">
<SignedInfo>
...
The contributions of the following Working Group members to this specification are gratefully acknowledged:
次のワーキンググループメンバーのこの仕様への貢献は、感謝されています。
* Mark Bartel, Accelio (Author) * John Boyer, PureEdge (Author) * Mariano P. Consens, University of Waterloo * John Cowan, Reuters Health * Donald Eastlake 3rd, Motorola (Chair, Author/Editor) * Barb Fox, Microsoft (Author) * Christian Geuer-Pollmann, University Siegen * Tom Gindin, IBM * Phillip Hallam-Baker, VeriSign Inc * Richard Himes, US Courts * Merlin Hughes, Baltimore * Gregor Karlinger, IAIK TU Graz * Brian LaMacchia, Microsoft (Author) * Peter Lipp, IAIK TU Graz * Joseph Reagle, W3C (Chair, Author/Editor) * Ed Simon, XMLsec (Author) * David Solo, Citigroup (Author/Editor) * Petteri Stenius, DONE Information, Ltd * Raghavan Srinivas, Sun * Kent Tamura, IBM * Winchel Todd Vincent III, GSU * Carl Wallace, Corsec Security, Inc. * Greg Whitehead, Signio Inc.
* マーク・バルテル、アセリオ（著者） *ジョン・ボイヤー、ピュアエッジ（著者） *マリアーノP.コンセン、ウォータールー大学ジョンコーワン、ロイターヘルス *ドナルドイーストレイク3位、モトローラ（議長、著者/編集者） *バーブフォックス、マイクロソフト（著者） * Christian Geuer-Pollmann、University Siegen * Tom Gindin、Ibm * Phillip Hallam-Baker、Verisign Inc * Richard Himes、米国裁判所 * Merlin Hughes、Baltimore * Gregor Karlinger、Iaik Tu Graz * Brian Lamacchia、Microsoft（著者） * PeterLipp、Iaik Tu Graz * Joseph Reagle、W3C（椅子、著者/編集者） * Ed Simon、XMLSec（著者） * David Solo、シティグループ（著者/編集者） * Petteri Stenius、Done Information、Ltd * Raghavan Srinivas、Sun * KentTamura、IBM * Winchel Todd Vincent III、GSU * Carl Wallace、Corsec Security、Inc。 * Greg Whitehead、Signio Inc.
As are the Last Call comments from the following:
以下からの最後のコールコメントも同様です。
* Dan Connolly, W3C * Paul Biron, Kaiser Permanente, on behalf of the XML Schema WG. * Martin J. Duerst, W3C; and Masahiro Sekiguchi, Fujitsu; on behalf of the Internationalization WG/IG. * Jonathan Marsh, Microsoft, on behalf of the Extensible Stylesheet Language WG.
* Dan Connolly、W3C * Paul Biron、Kaiser Permanente、XML Schema WG。* Martin J. Duerst、W3C;藤井正田島。国際化WG/IGを代表して。*ジョナサン・マーシュ、マイクロソフト、拡張可能なStyleSheet Language WGを代表して。
The World Wide Web Consortium Recommendation corresponding to this RFC is at:
このRFCに対応するWorld Wide Webコンソーシアムの推奨事項は次のとおりです。
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
This section provides an overview and examples of XML digital signature syntax. The specific processing is given in Processing Rules (section 3). The formal syntax is found in Core Signature Syntax (section 4) and Additional Signature Syntax (section 5).
このセクションでは、XMLデジタル署名構文の概要と例を示します。特定の処理は、処理ルール（セクション3）に記載されています。正式な構文は、コア署名構文（セクション4）と追加の署名構文（セクション5）にあります。
In this section, an informal representation and examples are used to describe the structure of the XML signature syntax. This representation and examples may omit attributes, details and potential features that are fully explained later.
このセクションでは、非公式の表現と例を使用して、XML署名構文の構造を記述します。この表現と例は、後で完全に説明される属性、詳細、および潜在的な機能を省略する場合があります。
XML Signatures are applied to arbitrary digital content (data objects) via an indirection. Data objects are digested, the resulting value is placed in an element (with other information) and that element is then digested and cryptographically signed. XML digital signatures are represented by the Signature element which has the following structure (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; and "*" denotes zero or more occurrences):
XML署名は、間接を介して任意のデジタルコンテンツ（データオブジェクト）に適用されます。データオブジェクトは消化され、結果の値は要素（他の情報を使用して）に配置され、その要素が消化され、暗号化された署名されます。XMLデジタル署名は、次の構造を持つ署名要素で表されます（ここで、「？」はゼロまたは1つの発生を意味します; "" 1つ以上の発生を意味します。
<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
(<Reference URI? >
(<Transforms>)?
<DigestMethod>
<DigestValue>
</Reference>)+
</SignedInfo>
<SignatureValue>
(<KeyInfo>)?
(<Object ID?>)*
</Signature>
Signatures are related to data objects via URIs [URI]. Within an XML document, signatures are related to local data objects via fragment identifiers. Such local data can be included within an enveloping signature or can enclose an enveloped signature. Detached signatures are over external network resources or local data objects that reside within the same XML document as sibling elements; in this case, the signature is neither enveloping (signature is parent) nor enveloped attribute (signature is child). Since a Signature element (and its Id value/name) may co-exist or be combined with other elements (and their IDs) within a single XML document, care should be taken in choosing names such that there are no subsequent collisions that violate the ID uniqueness validity constraint [XML].
署名は、uris [uri]を介したデータオブジェクトに関連しています。XMLドキュメント内では、署名はフラグメント識別子を介してローカルデータオブジェクトに関連しています。このようなローカルデータは、包み込む署名に含めることができます。または、包み込まれた署名を囲むことができます。分離された署名は、兄弟要素と同じXMLドキュメント内に存在する外部ネットワークリソースまたはローカルデータオブジェクトを超えています。この場合、署名は包囲（署名は親です）でも包括された属性（署名は子）でもありません。署名要素（およびそのID値/名前）は、単一のXMLドキュメント内の他の要素（およびそのID）と共存または組み合わせることができるため、名前を選択する際には注意が必要です。ID独自性の妥当性制約[XML]。
The following example is a detached signature of the content of the HTML4 in XML specification.
次の例は、XML仕様におけるHTML4のコンテンツの分離された署名です。
[s01] <Signature Id="MyFirstSignature"
xmlns="http://www.w3.org/2000/09/xmldsig#">
[s02] <SignedInfo>
[s03] <CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[s04] <SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
[s05] <Reference
URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06] <Transforms>
[s07] <Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[s08] </Transforms>
[s09] <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[s11] </Reference>
[s12] </SignedInfo>
[s13] <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
[s14] <KeyInfo>
[s15a] <KeyValue>
[s15b] <DSAKeyValue>
[s15c] <P>...</P><Q>...</Q><G>...</G><Y>...</Y>
[s15d] </DSAKeyValue>
[s15e] </KeyValue>
[s16] </KeyInfo>
[s17] </Signature>
[s02-12] The required SignedInfo element is the information that is actually signed. Core validation of SignedInfo consists of two mandatory processes: validation of the signature over SignedInfo and validation of each Reference digest within SignedInfo. Note that the algorithms used in calculating the SignatureValue are also included in the signed information while the SignatureValue element is outside SignedInfo.
[S02-12]必要なSignedInfo要素は、実際に署名されている情報です。SignedInfoのコア検証は、2つの必須プロセスで構成されています。SignedInfo上の署名の検証と、SignedInfo内の各参照ダイジェストの検証です。SignatureValueの計算に使用されるアルゴリズムも署名情報に含まれている間、SignatureValue要素はSignedInfoの外側にあることに注意してください。
[s03] The CanonicalizationMethod is the algorithm that is used to canonicalize the SignedInfo element before it is digested as part of the signature operation. Note that this example, and all examples in this specification, are not in canonical form.
[S03] CanonicalizationMethodは、署名操作の一部として消化される前にSignedInfo要素を正規化するために使用されるアルゴリズムです。この例と、この仕様のすべての例は、標準的な形式ではないことに注意してください。
[s04] The SignatureMethod is the algorithm that is used to convert the canonicalized SignedInfo into the SignatureValue. It is a combination of a digest algorithm and a key dependent algorithm and possibly other algorithms such as padding, for example RSA-SHA1. The algorithm names are signed to resist attacks based on substituting a weaker algorithm. To promote application interoperability we specify a set of signature algorithms that MUST be implemented, though their use is at the discretion of the signature creator. We specify additional algorithms as RECOMMENDED or OPTIONAL for implementation; the design also permits arbitrary user specified algorithms.
[S04] SignatureMethodは、標準化されたSignedInfoをSignatureValueに変換するために使用されるアルゴリズムです。これは、ダイジェストアルゴリズムと重要な依存アルゴリズム、およびRSA-Sha1などのパディングなどの他のアルゴリズムの組み合わせです。アルゴリズム名は、より弱いアルゴリズムの置換に基づいて攻撃に抵抗するために署名されています。アプリケーションの相互運用性を促進するために、実装する必要がある一連の署名アルゴリズムを指定しますが、それらの使用は署名作成者の裁量にあります。実装に推奨またはオプションとして追加のアルゴリズムを指定します。この設計では、任意のユーザー指定されたアルゴリズムも許可します。
[s05-11] Each Reference element includes the digest method and resulting digest value calculated over the identified data object. It may also include transformations that produced the input to the digest operation. A data object is signed by computing its digest value and a signature over that value. The signature is later checked via reference and signature validation.
[S05-11]各参照要素には、識別されたデータオブジェクトで計算されたダイジェスト法と結果のダイジェスト値が含まれています。また、ダイジェスト操作への入力を生成する変換が含まれる場合があります。データオブジェクトは、そのダイジェスト値とその値に対する署名を計算することにより署名されます。署名は、後で参照および署名検証によってチェックされます。
[s14-16] KeyInfo indicates the key to be used to validate the signature. Possible forms for identification include certificates, key names, and key agreement algorithms and information -- we define only a few. KeyInfo is optional for two reasons. First, the signer may not wish to reveal key information to all document processing parties. Second, the information may be known within the application's context and need not be represented explicitly. Since KeyInfo is outside of SignedInfo, if the signer wishes to bind the keying information to the signature, a Reference can easily identify and include the KeyInfo as part of the signature.
[S14-16] KeyInfoは、署名の検証に使用するキーを示します。識別のための可能なフォームには、証明書、キー名、およびキー契約のアルゴリズムと情報が含まれます。いくつかのみを定義します。KeyInfoは、2つの理由でオプションです。まず、署名者は、すべてのドキュメント処理パーティーに重要な情報を明らかにすることを望まない場合があります。第二に、情報はアプリケーションのコンテキスト内で知られている可能性があり、明示的に表現する必要はありません。KeyInfoはSignedInfoの外にいるため、署名者がキーイング情報を署名にバインドしたい場合、参照は署名の一部としてKeyInfoを簡単に識別して含めることができます。
[s05] <Reference
URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06] <Transforms>
[s07] <Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
[s08] </Transforms>
[s09] <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[s10] <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[s11] </Reference>
[s05] The optional URI attribute of Reference identifies the data object to be signed. This attribute may be omitted on at most one Reference in a Signature. (This limitation is imposed in order to ensure that references and objects may be matched unambiguously.)
[S05]参照のオプションのURI属性は、署名されるデータオブジェクトを識別します。この属性は、署名で最大1つの参照で省略できます。（この制限は、参照とオブジェクトが明確に一致するようにするために課されます。）
[s05-08] This identification, along with the transforms, is a description provided by the signer on how they obtained the signed data object in the form it was digested (i.e., the digested content). The verifier may obtain the digested content in another method so long as the digest verifies. In particular, the verifier may obtain the content from a different location such as a local store, as opposed to that specified in the URI.
[S05-08]この識別は、変換とともに、署名者が、消化された形式で署名されたデータオブジェクトをどのように取得したかについての説明です（つまり、消化された含有量）。Verifierは、ダイジェストが検証されている限り、別の方法で消化された含有量を取得できます。特に、検証者は、URIで指定されているものとは対照的に、地元の店などの異なる場所からコンテンツを取得できます。
[s06-08] Transforms is an optional ordered list of processing steps that were applied to the resource's content before it was digested. Transforms can include operations such as canonicalization, encoding/decoding (including compression/inflation), XSLT, XPath, XML schema validation, or XInclude. XPath transforms permit the signer to derive an XML document that omits portions of the source document. Consequently those excluded portions can change without affecting signature validity. For example, if the resource being signed encloses the signature itself, such a transform must be used to exclude the signature value from its own computation. If no Transforms element is present, the resource's content is digested directly. While the Working Group has specified mandatory (and optional) canonicalization and decoding algorithms, user specified transforms are permitted.
[S06-08] Transformsは、消化される前にリソースのコンテンツに適用された処理手順のオプションの順序付けられたリストです。変換には、標準化、エンコード/デコード（圧縮/インフレを含む）、XSLT、XPATH、XMLスキーマ検証、XINCLUDEなどの操作が含まれます。XPath Transforms Surce Sourceドキュメントの一部を省略するXMLドキュメントを導き出すことが署名者に許可されます。したがって、これらの除外された部分は、署名の妥当性に影響を与えることなく変化する可能性があります。たとえば、署名されているリソースが署名自体を囲む場合、そのような変換を使用して、独自の計算から署名値を除外する必要があります。変換要素が存在しない場合、リソースのコンテンツは直接消化されます。ワーキンググループは、必須の（およびオプションの）標準化およびデコードアルゴリズムを指定していますが、ユーザーが指定した変換が許可されています。
[s09-10] DigestMethod is the algorithm applied to the data after Transforms is applied (if specified) to yield the DigestValue. The signing of the DigestValue is what binds a resources content to the signer's key.
[S09-10] DigestMethodは、変換が適用された後にデータに適用されるアルゴリズム（指定されている場合）です。Digestvalueの署名は、署名者の鍵にリソースコンテンツを拘束するものです。
This specification does not address mechanisms for making statements or assertions. Instead, this document defines what it means for something to be signed by an XML Signature (integrity, message authentication, and/or signer authentication). Applications that wish to represent other semantics must rely upon other technologies, such as [XML, RDF]. For instance, an application might use a foo:assuredby attribute within its own markup to reference a Signature element. Consequently, it's the application that must understand and know how to make trust decisions given the validity of the signature and the meaning of assuredby syntax. We also define a SignatureProperties element type for the inclusion of assertions about the signature itself (e.g., signature semantics, the time of signing or the serial number of hardware used in cryptographic processes). Such assertions may be signed by including a Reference for the SignatureProperties in SignedInfo. While the signing application should be very careful about what it signs (it should understand what is in the SignatureProperty) a receiving application has no obligation to understand that semantic (though its parent trust engine may wish to). Any content about the signature generation may be located within the SignatureProperty element. The mandatory Target attribute references the Signature element to which the property applies.
この仕様は、ステートメントやアサーションを作成するためのメカニズムに対処しません。代わりに、このドキュメントは、XML署名（整合性、メッセージ認証、および/または署名者認証）によって何かが署名されることの意味を定義します。他のセマンティクスを表現したいアプリケーションは、[XML、RDF]などの他のテクノロジーに依存する必要があります。たとえば、アプリケーションはFoo：AssuredBy独自のマークアップ内のAssuredBy属性を使用して、署名要素を参照する場合があります。その結果、署名の有効性と保証された構文の意味を考慮して、信頼の決定を下す方法を理解し、知る必要があるのはアプリケーションです。また、署名自体に関するアサーションを含めるための署名プロパティの要素タイプを定義します（例えば、署名セマンティクス、署名の時間、または暗号化プロセスで使用されるハードウェアのシリアル番号）。このようなアサーションは、signesuterpropertiesの参照をsignedinfoに含めることにより署名される場合があります。署名申請書は、署名の内容について非常に注意する必要がありますが（SignaturePropertyにあるものを理解する必要があります）、受信アプリケーションにはそのセマンティックを理解する義務はありません（親の信頼エンジンは望むかもしれませんが）。署名生成に関するコンテンツは、SignatureProperty要素内に配置できます。必須ターゲット属性は、プロパティが適用される署名要素を参照します。
Consider the preceding example with an additional reference to a local Object that includes a SignatureProperty element. (Such a signature would not only be detached [p02] but enveloping [p03].)
SignatureProperty要素を含むローカルオブジェクトへの追加の参照を備えた前の例を考えてください。（そのような署名は、[P02]だけでなく、[P03]を包みます。）
[ ] <Signature Id="MySecondSignature" ...>
[p01] <SignedInfo>
[ ] ...
[p02] <Reference URI="http://www.w3.org/TR/xml-stylesheet/">
[ ] ...
[p03] <Reference URI="#AMadeUpTimeStamp"
[p04]
Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">
[p05] <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[p06] <DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[p07] </Reference>
[p08] </SignedInfo>
[p09] ...
[p10] <Object>
[p11] <SignatureProperties>
[p12] <SignatureProperty Id="AMadeUpTimeStamp"
Target="#MySecondSignature">
[p13] <timestamp xmlns="http://www.ietf.org/rfcXXXX.txt">
[p14] <date>19990908</date>
[p15] <time>14:34:34:34</time>
[p16] </timestamp>
[p17] </SignatureProperty>
[p18] </SignatureProperties>
[p19] </Object>
[p20]</Signature>
[p04] The optional Type attribute of Reference provides information about the resource identified by the URI. In particular, it can indicate that it is an Object, SignatureProperty, or Manifest element. This can be used by applications to initiate special processing of some Reference elements. References to an XML data element within an Object element SHOULD identify the actual element pointed to. Where the element content is not XML (perhaps it is binary or encoded data) the reference should identify the Object and the Reference Type, if given, SHOULD indicate Object. Note that Type is advisory and no action based on it or checking of its correctness is required by core behavior.
[P04]参照のオプションの型属性は、URIによって識別されたリソースに関する情報を提供します。特に、それがオブジェクト、SignatureProperty、またはマニフェスト要素であることを示すことができます。これは、いくつかの参照要素の特別な処理を開始するためにアプリケーションで使用できます。オブジェクト要素内のXMLデータ要素への参照は、指し示された実際の要素を識別する必要があります。要素コンテンツがXMLではない場合（おそらくそれはバイナリまたはエンコードされたデータです）、参照はオブジェクトを識別し、参照タイプが与えられた場合、オブジェクトを示す必要があります。タイプはアドバイザリーであり、それに基づいたアクションやその正しさのチェックは、コアの動作によって必要とされることに注意してください。
[p10] Object is an optional element for including data objects within the signature element or elsewhere. The Object can be optionally typed and/or encoded.
[P10]オブジェクトは、署名要素または他の場所にデータオブジェクトを含めるためのオプションの要素です。オブジェクトは、オプションで入力および/またはエンコードすることができます。
[p11-18] Signature properties, such as time of signing, can be optionally signed by identifying them from within a Reference. (These properties are traditionally called signature "attributes" although that term has no relationship to the XML term "attribute".)
[P11-18]署名時間などの署名プロパティは、参照内からそれらを識別することによりオプションで署名できます。（これらのプロパティは伝統的に署名「属性」と呼ばれていますが、その用語はXML用語「属性」とは関係ありません。）
The Manifest element is provided to meet additional requirements not directly addressed by the mandatory parts of this specification. Two requirements and the way the Manifest satisfies them follow.
マニフェスト要素は、この仕様の必須部分で直接対処されない追加の要件を満たすために提供されます。2つの要件とマニフェストがそれらを満たす方法。
First, applications frequently need to efficiently sign multiple data objects even where the signature operation itself is an expensive public key signature. This requirement can be met by including multiple Reference elements within SignedInfo since the inclusion of each digest secures the data digested. However, some applications may not want the core validation behavior associated with this approach because it requires every Reference within SignedInfo to undergo reference validation -- the DigestValue elements are checked. These applications may wish to reserve reference validation decision logic to themselves. For example, an application might receive a signature valid SignedInfo element that includes three Reference elements. If a single Reference fails (the identified data object when digested does not yield the specified DigestValue) the signature would fail core validation. However, the application may wish to treat the signature over the two valid Reference elements as valid or take different actions depending on which fails. To accomplish this, SignedInfo would reference a Manifest element that contains one or more Reference elements (with the same structure as those in SignedInfo). Then, reference validation of the Manifest is under application control.
第一に、アプリケーションは、署名操作自体が高価な公開キーの署名である場合でも、複数のデータオブジェクトに効率的に署名する必要があることがよくあります。この要件は、各ダイジェストを含めるとダイジェストされたデータを保護するため、SignedInfoに複数の参照要素を含めることで満たすことができます。ただし、一部のアプリケーションでは、このアプローチに関連付けられたコア検証動作を必要としない場合があります。これは、SignedInfo内のすべての参照が参照検証を受ける必要があるためです。消化率要素がチェックされます。これらのアプリケーションは、参照検証決定のロジックを自分自身に留保することを望んでいる場合があります。たとえば、アプリケーションは、3つの参照要素を含む署名有効なSignedInfo要素を受信する場合があります。単一の参照が故障した場合（消化したときに識別されたデータオブジェクトが指定されたダイジェストバリューを生成しない）、署名はコア検証に失敗します。ただし、アプリケーションは、2つの有効な参照要素に対する署名を有効なものとして扱うか、失敗に応じて異なるアクションを実行することをお勧めします。これを達成するために、Signedinfoは、1つ以上の参照要素を含むマニフェスト要素を参照します（SignedInfoの構造と同じ構造を持つ）。次に、マニフェストの参照検証はアプリケーション制御下にあります。
Second, consider an application where many signatures (using different keys) are applied to a large number of documents. An inefficient solution is to have a separate signature (per key) repeatedly applied to a large SignedInfo element (with many References); this is wasteful and redundant. A more efficient solution is to include many references in a single Manifest that is then referenced from multiple Signature elements.
第二に、多くの署名（異なるキーを使用）が多数のドキュメントに適用されるアプリケーションを検討します。非効率的な解決策は、大きなSignedInfo要素（多くの参照を含む）に繰り返し適用される別の署名（キーごと）を持つことです。これは無駄で冗長です。より効率的な解決策は、複数の署名要素から参照される単一のマニフェストに多くの参照を含めることです。
The example below includes a Reference that signs a Manifest found within the Object element.
以下の例には、オブジェクト要素内で見つかったマニフェストに署名する参照が含まれています。
[ ] ...
[m01] <Reference URI="#MyFirstManifest"
[m02] Type="http://www.w3.org/2000/09/xmldsig#Manifest">
[m03] <DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
[m04] <DigestValue>345x3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[m05] </Reference>
[ ] ...
[m06] <Object>
[m07] <Manifest Id="MyFirstManifest">
[m08] <Reference>
[m09] ...
[m10] </Reference>
[m11] <Reference>
[m12] ...
[m13] </Reference>
[m14] </Manifest>
[m15] </Object>
The sections below describe the operations to be performed as part of signature generation and validation.
以下のセクションでは、署名の生成と検証の一部として実行される操作について説明します。
The REQUIRED steps include the generation of Reference elements and the SignatureValue over SignedInfo.
必要な手順には、参照要素の生成とSignedInfo上の署名バリューが含まれます。
For each data object being signed:
署名されている各データオブジェクトについて：
1. Apply the Transforms, as determined by the application, to the data object. 2. Calculate the digest value over the resulting data object. 3. Create a Reference element, including the (optional) identification of the data object, any (optional) transform elements, the digest algorithm and the DigestValue. (Note, it is the canonical form of these references that are signed in 3.1.2 and validated in 3.2.1.)
1. アプリケーションによって決定された変換をデータオブジェクトに適用します。2.結果のデータオブジェクトでダイジェスト値を計算します。3.データオブジェクトの（オプションの）識別、任意の（オプションの）変換要素、ダイジェストアルゴリズム、ダイジェストバリューを含む参照要素を作成します。（3.1.2で署名され、3.2.1で検証されているのは、これらの参照の標準的な形式です。）
1. Create SignedInfo element with SignatureMethod, CanonicalizationMethod and Reference(s). 2. Canonicalize and then calculate the SignatureValue over SignedInfo based on algorithms specified in SignedInfo.
1. SignatureMethod、CanonicalizationMethod、および参照を使用してSignedInfo要素を作成します。2. signedinfoで指定されたアルゴリズムに基づいて、signedInfo上の署名バリューを正規化して計算します。
3. Construct the Signature element that includes SignedInfo, Object(s) (if desired, encoding may be different than that used for signing), KeyInfo (if required), and SignatureValue.
3. SignedInfo、オブジェクト（必要に応じて、エンコードは署名に使用されるものとは異なる場合があります）、keyInfo（必要に応じて）、signaturevalueを含む署名要素を作成します。
Note, if the Signature includes same-document references, [XML] or [XML-schema] validation of the document might introduce changes that break the signature. Consequently, applications should be careful to consistently process the document or refrain from using external contributions (e.g., defaults and entities).
署名に同じドキュメント参照が含まれている場合、[XML]または[XML-Schema]ドキュメントの検証により、署名を破る変更が導入される可能性があります。したがって、アプリケーションは、ドキュメントを一貫して処理するか、外部の貢献（デフォルトやエンティティなど）の使用を控えるように注意する必要があります。
The REQUIRED steps of core validation include (1) reference validation, the verification of the digest contained in each Reference in SignedInfo, and (2) the cryptographic signature validation of the signature calculated over SignedInfo.
コア検証の必要な手順には、（1）参照検証、SignedInfoの各参照に含まれるダイジェストの検証、および（2）SignedInfoで計算された署名の暗号化署名検証が含まれます。
Note, there may be valid signatures that some signature applications are unable to validate. Reasons for this include failure to implement optional parts of this specification, inability or unwillingness to execute specified algorithms, or inability or unwillingness to dereference specified URIs (some URI schemes may cause undesirable side effects), etc.
一部の署名アプリケーションが検証できないという有効な署名があるかもしれません。この理由には、この仕様のオプションの部分を実装できなかったこと、指定されたアルゴリズムを実行できない、または不可能性、または指定されたURIを避難する不能または不本意（一部のURIスキームは望ましくない副作用を引き起こす可能性があります）など。
Comparison of values in reference and signature validation are over the numeric (e.g., integer) or decoded octet sequence of the value. Different implementations may produce different encoded digest and signature values when processing the same resources because of variances in their encoding, such as accidental white space. But if one uses numeric or octet comparison (choose one) on both the stated and computed values these problems are eliminated.
参照と署名検証の値の比較は、値の数値（整数など）またはデコードされたオクテットシーケンスを介しています。実装が異なると、偶発的な空白などのエンコードの分散のため、同じリソースを処理するときに、異なるエンコードされたダイジェスト値と署名値が生成される場合があります。ただし、指定された値と計算値の両方で数値比較またはOctet比較（1つを選択）を使用する場合、これらの問題は排除されます。
1. Canonicalize the SignedInfo element based on the CanonicalizationMethod in SignedInfo. 2. For each Reference in SignedInfo: 2.1 Obtain the data object to be digested. (For example, the signature application may dereference the URI and execute Transforms provided by the signer in the Reference element, or it may obtain the content through other means such as a local cache.) 2.2 Digest the resulting data object using the DigestMethod specified in its Reference specification. 2.3 Compare the generated digest value against DigestValue in the SignedInfo Reference; if there is any mismatch, validation fails.
1. SignedInfoのCanonicalizationMethodに基づいて、SignedInfo要素を正規化します。2. signedinfoの各参照について：2.1消化するデータオブジェクトを取得します。（たとえば、署名アプリケーションは、参照要素で署名者が提供するURIおよび実行された変換を実行するか、ローカルキャッシュなどの他の手段を介してコンテンツを取得する場合があります。）その参照仕様。2.3 SignedInfoリファレンスの消化率と生成されたダイジェスト値を比較します。不一致がある場合、検証は失敗します。
Note, SignedInfo is canonicalized in step 1. The application must ensure that the CanonicalizationMethod has no dangerous side affects, such as rewriting URIs, (see CanonicalizationMethod (section 4.3)) and that it Sees What is Signed, which is the canonical form.
注、SignedInfoはステップ1で正規化されています。アプリケーションは、標準化のメソッドにurisの書き換えなど、危険な副作用がないことを確認する必要があります（CanonicalizationMethod（セクション4.3）を参照）、署名されているもの、標準形式であることを確認する必要があります。
1. Obtain the keying information from KeyInfo or from an external source. 2. Obtain the canonical form of the SignatureMethod using the CanonicalizationMethod and use the result (and previously obtained KeyInfo) to confirm the SignatureValue over the SignedInfo element.
1. KeyInfoまたは外部ソースからキーイング情報を取得します。2. CanonicalizationMethodを使用してSignatureMethodの標準形式を取得し、結果（および以前に取得したKeyInfo）を使用して、SignedInfo要素を介した署名数値を確認します。
Note, KeyInfo (or some transformed version thereof) may be signed via a Reference element. Transformation and validation of this reference (3.2.1) is orthogonal to Signature Validation which uses the KeyInfo as parsed.
注意、KeyInfo（またはその変換バージョン）は、参照要素を介して署名される場合があります。このリファレンスの変換と検証（3.2.1）は、keyInfoを解析して使用する署名検証の直交です。
Additionally, the SignatureMethod URI may have been altered by the canonicalization of SignedInfo (e.g., absolutization of relative URIs) and it is the canonical form that MUST be used. However, the required canonicalization [XML-C14N] of this specification does not change URIs.
さらに、SignatureMethod URIは、SignedInfo（例えば、相対URIの絶対化）の標準化によって変更された可能性があり、使用する必要があるのは標準的な形式です。ただし、この仕様の必要な正規化[XML-C14N]はURIを変化させません。
The general structure of an XML signature is described in Signature Overview (section 2). This section provides detailed syntax of the core signature features. Features described in this section are mandatory to implement unless otherwise indicated. The syntax is defined via DTDs and [XML-Schema] with the following XML preamble, declaration, and internal entity.
XML署名の一般的な構造については、署名の概要（セクション2）で説明されています。このセクションでは、コア署名機能の詳細な構文を提供します。このセクションで説明する機能は、特に示されない限り実装することが必須です。構文は、次のXMLプリアンブル、宣言、および内部エンティティを使用して、DTDSおよび[XML-Schema]を介して定義されます。
Schema Definition:
スキーマ定義：
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE schema
PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
"http://www.w3.org/2001/XMLSchema.dtd"
[
<!ATTLIST schema
xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#">
<!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'>
<!ENTITY % p ''>
<!ENTITY % s ''>
]>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
targetNamespace="http://www.w3.org/2000/09/xmldsig#"
version="0.1" elementFormDefault="qualified">
DTD:
DTD：
<!--
<！ -
The following entity declarations enable external/flexible content in the Signature content model.
次のエンティティ宣言により、署名コンテンツモデルで外部/柔軟なコンテンツが可能になります。
#PCDATA emulates schema:string; when combined with element types it emulates schema mixed="true".
#pcdataはスキーマをエミュレートします：string;要素タイプと組み合わせると、スキーマMixed = "true"をエミュレートします。
%foo.ANY permits the user to include their own element types from
other namespaces, for example:
<!ENTITY % KeyValue.ANY '| ecds:ECDSAKeyValue'>
...
<!ELEMENT ecds:ECDSAKeyValue (#PCDATA) >
-->
- >
<!ENTITY % Object.ANY ''>
<!ENTITY % Method.ANY ''>
<!ENTITY % Transform.ANY ''>
<!ENTITY % SignatureProperty.ANY ''>
<!ENTITY % KeyInfo.ANY ''>
<!ENTITY % KeyValue.ANY ''>
<!ENTITY % PGPData.ANY ''>
<!ENTITY % X509Data.ANY ''>
<!ENTITY % SPKIData.ANY ''>
This specification defines the ds:CryptoBinary simple type for representing arbitrary-length integers (e.g., "bignums") in XML as octet strings. The integer value is first converted to a "big endian" bitstring. The bitstring is then padded with leading zero bits so that the total number of bits == 0 mod 8 (so that there are an integral number of octets). If the bitstring contains entire leading octets that are zero, these are removed (so the high-order octet is always non-zero). This octet string is then base64 [MIME] encoded. (The conversion from integer to octet string is equivalent to IEEE 1363's I2OSP [1363] with minimal length).
この仕様では、XMLの任意の長さの整数（「ビグノム」など）をオクテット文字列として表現するためのDS：Cryptobinary Simple Typeを定義します。整数値は、最初に「ビッグエンディアン」ビットストリングに変換されます。次に、ビットストリングには、ビットの総数== 0 mod 8（統合数のオクテットがあるように）の総数がゼロビットでパッドにされます。ビットストリングにゼロの先頭オクテット全体が含まれている場合、これらは削除されます（したがって、高次のオクテットは常にゼロではありません）。このオクテット文字列は、base64 [mime]エンコードされます。（整数からOctet弦への変換は、長さが最小限のIEEE 1363のI2OSP [1363]と同等です）。
This type is used by "bignum" values such as RSAKeyValue and DSAKeyValue. If a value can be of type base64Binary or ds:CryptoBinary they are defined as base64Binary. For example, if the signature algorithm is RSA or DSA then SignatureValue represents a bignum and could be ds:CryptoBinary. However, if HMAC-SHA1 is the signature algorithm then SignatureValue could have leading zero octets that must be preserved. Thus SignatureValue is generically defined as of type base64Binary.
このタイプは、rsakeyvalueやdsakeyvalueなどの「bignum」値で使用されます。値がbase64binaryまたはds：cryptobinaryである場合、base64binaryとして定義されます。たとえば、署名アルゴリズムがRSAまたはDSAの場合、SignatureValueはBignumを表し、DS：Cryptobinaryになる可能性があります。ただし、HMAC-Sha1が署名アルゴリズムである場合、SignatureValueは保存する必要があるゼロオクテットを獲得することができます。したがって、SignatureValueは、base64binary型として一般的に定義されます。
Schema Definition:
スキーマ定義：
<simpleType name="CryptoBinary">
<restriction base="base64Binary">
</restriction>
</simpleType>
The Signature element is the root element of an XML Signature. Implementation MUST generate laxly schema valid [XML-schema] Signature elements as specified by the following schema:
署名要素は、XML署名のルート要素です。実装は、次のスキーマで指定されているように、Laxlyスキーマ有効[XML-Schema]署名要素を生成する必要があります。
Schema Definition:
スキーマ定義：
<element name="Signature" type="ds:SignatureType"/> <complexType name="SignatureType"> <sequence> <element ref="ds:SignedInfo"/> <element ref="ds:SignatureValue"/> <element ref="ds:KeyInfo" minOccurs="0"/> <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType> DTD:
<要素name = "signature" type = "ds：signaturetype"/> <complextype name = "signaturetype"> <sequence> <要素ref = "ds：signedinfo"/> <要素ref = "ds：signaturevalue"/> <要素ref = "ds：keyinfo" minoccurs = "0"/> <rement ref = "ds：object" minoccurs = "0" maxoccurs = "bounded"/> </sequence> <属性名= "id" type = "id "use =" optional "/> </complextype> dtd：
<!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?,
Object*) >
<!ATTLIST Signature
xmlns CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#'
Id ID #IMPLIED >
The SignatureValue element contains the actual value of the digital signature; it is always encoded using base64 [MIME]. While we identify two SignatureMethod algorithms, one mandatory and one optional to implement, user specified algorithms may be used as well.
SignatureValue要素には、デジタル署名の実際の値が含まれています。Base64 [MIME]を使用して常にエンコードされます。2つのSignatureMethodアルゴリズムを識別しますが、1つは必須であり、1つは実装するオプションですが、ユーザーが指定したアルゴリズムも使用できます。
Schema Definition:
スキーマ定義：
<element name="SignatureValue" type="ds:SignatureValueType"/>
<complexType name="SignatureValueType">
<simpleContent>
<extension base="base64Binary">
<attribute name="Id" type="ID" use="optional"/>
</extension>
</simpleContent>
</complexType>
DTD:
DTD：
<!ELEMENT SignatureValue (#PCDATA) >
<!ATTLIST SignatureValue
Id ID #IMPLIED>
The structure of SignedInfo includes the canonicalization algorithm, a signature algorithm, and one or more references. The SignedInfo element may contain an optional ID attribute that will allow it to be referenced by other signatures and objects.
SignedInfoの構造には、Canonicalization Algorithm、署名アルゴリズム、および1つ以上の参照が含まれます。SignedInfo要素には、他の署名やオブジェクトによって参照できるオプションのID属性が含まれている場合があります。
SignedInfo does not include explicit signature or digest properties (such as calculation time, cryptographic device serial number, etc.). If an application needs to associate properties with the signature or digest, it may include such information in a SignatureProperties element within an Object element.
SignedInfoには、明示的な署名またはダイジェストプロパティ（計算時間、暗号化デバイスのシリアル番号など）は含まれません。アプリケーションがプロパティを署名またはダイジェストに関連付ける必要がある場合、そのような情報をオブジェクト要素内の署名プロパリティ要素に含めることができます。
Schema Definition:
スキーマ定義：
<element name="SignedInfo" type="ds:SignedInfoType"/>
<complexType name="SignedInfoType">
<sequence>
<element ref="ds:CanonicalizationMethod"/>
<element ref="ds:SignatureMethod"/>
<element ref="ds:Reference" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
DTD:
DTD：
<!ELEMENT SignedInfo (CanonicalizationMethod,
SignatureMethod, Reference+) >
<!ATTLIST SignedInfo
Id ID #IMPLIED
CanonicalizationMethod is a required element that specifies the canonicalization algorithm applied to the SignedInfo element prior to performing signature calculations. This element uses the general structure for algorithms described in Algorithm Identifiers and Implementation Requirements (section 6.1). Implementations MUST support the REQUIRED canonicalization algorithms.
CanonicalizationMethodは、署名計算を実行する前にSigneDINFO要素に適用される正規化アルゴリズムを指定する必須要素です。この要素は、アルゴリズム識別子と実装要件で説明されているアルゴリズムの一般構造を使用します（セクション6.1）。実装は、必要な正規化アルゴリズムをサポートする必要があります。
Alternatives to the REQUIRED canonicalization algorithms (section 6.5), such as Canonical XML with Comments (section 6.5.1) or a minimal canonicalization (such as CRLF and charset normalization), may be explicitly specified but are NOT REQUIRED. Consequently, their use may not interoperate with other applications that do not support the specified algorithm (see XML Canonicalization and Syntax Constraint Considerations, section 7). Security issues may also arise in the treatment of entity processing and comments if non-XML aware canonicalization algorithms are not properly constrained (see section 8.2: Only What is "Seen" Should be Signed).
コメント（セクション6.5.1）または最小限の標準化（CRLFや炭化正規化など）を備えた標準XMLなど、必要な正規化アルゴリズム（セクション6.5）の代替案は、明示的に指定されている可能性がありますが、必要ありません。したがって、それらの使用は、指定されたアルゴリズムをサポートしていない他のアプリケーションと相互運用することはできません（XML CanOnicalization and Syntax Constraintの考慮事項、セクション7を参照）。また、XML以外の標準化アルゴリズムが適切に制約されていない場合、エンティティ処理とコメントの処理ではセキュリティの問題が発生する場合があります（セクション8.2：「見られる」もののみを参照してください）。
The way in which the SignedInfo element is presented to the canonicalization method is dependent on that method. The following applies to algorithms which process XML as nodes or characters:
SignedInfo要素が標準化法に提示される方法は、その方法に依存します。以下は、XMLをノードまたは文字として処理するアルゴリズムに適用されます。
* XML based canonicalization implementations MUST be provided with a [XPath] node-set originally formed from the document containing the SignedInfo and currently indicating the SignedInfo, its descendants, and the attribute and namespace nodes of SignedInfo and its descendant elements.
* XMLベースの正規化の実装は、SignedInfoを含むドキュメントから元々形成された[XPath]ノードセットを提供する必要があり、現在SignedInfo、その子孫、SignedInfoおよびその子孫の属性と名前空間ノードを示しています。
* Text based canonicalization algorithms (such as CRLF and charset normalization) should be provided with the UTF-8 octets that represent the well-formed SignedInfo element, from the first character to the last character of the XML representation, inclusive. This includes the entire text of the start and end tags of the SignedInfo element as well as all descendant markup and character data (i.e., the text) between those tags. Use of text based canonicalization of SignedInfo is NOT RECOMMENDED.
* テキストベースの標準化アルゴリズム（CRLFや炭化の正規化など）は、最初の文字からXML表現の最後の文字まで、包括的である、よく形成されたSignedInfo要素を表すUTF-8オクテットを提供する必要があります。これには、SignedInfo要素の開始タグと終了タグのテキスト全体と、それらのタグ間のすべての子孫マークアップおよびキャラクターデータ（つまり、テキスト）が含まれます。SignedInfoのテキストベースの正規化の使用は推奨されません。
We recommend applications that implement a text-based instead of XML-based canonicalization -- such as resource constrained apps -- generate canonicalized XML as their output serialization so as to mitigate interoperability and security concerns. For instance, such an implementation SHOULD (at least) generate standalone XML instances [XML].
リソースが制約されたアプリなど、XMLベースの標準化の代わりにテキストベースを実装するアプリケーションを推奨することをお勧めします。これは、相互運用性とセキュリティの懸念を緩和するために、出力シリアル化として標準化されたXMLを生成します。たとえば、このような実装は、（少なくとも）スタンドアロンXMLインスタンス[XML]を生成する必要があります。
NOTE: The signature application must exercise great care in accepting and executing an arbitrary CanonicalizationMethod. For example, the canonicalization method could rewrite the URIs of the References being validated. Or, the method could massively transform SignedInfo so that validation would always succeed (i.e., converting it to a trivial signature with a known key over trivial data). Since CanonicalizationMethod is inside SignedInfo, in the resulting canonical form it could erase itself from SignedInfo or modify the SignedInfo element so that it appears that a different canonicalization function was used! Thus a Signature which appears to authenticate the desired data with the desired key, DigestMethod, and SignatureMethod, can be meaningless if a capricious CanonicalizationMethod is used.
注：署名アプリケーションは、任意の標準化の受け入れと実行に細心の注意を払わなければなりません。たとえば、標準化法は、検証されている参照のURIを書き換えることができます。または、この方法はSignedInfoを大幅に変換して、常に検証が成功する（つまり、些細なデータよりも既知のキーを使用して些細な署名に変換する）。CanonicalizationMethodはsignedinfo内にあるため、結果の標準形態では、signedinfoから消去したり、signedinfo要素を変更して、異なる標準化関数が使用されたように見えるようになります。したがって、目的のキー、DigestMethod、およびSignatureMethodを使用して目的のデータを認証するように見える署名は、気まぐれなCanonicalizationMethodを使用する場合、意味がありません。
Schema Definition:
スキーマ定義：
<element name="CanonicalizationMethod"
type="ds:CanonicalizationMethodType"/>
<complexType name="CanonicalizationMethodType" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
<!-- (0,unbounded) elements from (1,1) namespace -->
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
DTD:
DTD：
<!ELEMENT CanonicalizationMethod (#PCDATA %Method.ANY;)* >
<!ATTLIST CanonicalizationMethod
Algorithm CDATA #REQUIRED >
SignatureMethod is a required element that specifies the algorithm used for signature generation and validation. This algorithm identifies all cryptographic functions involved in the signature operation (e.g., hashing, public key algorithms, MACs, padding, etc.). This element uses the general structure here for algorithms described in section 6.1: Algorithm Identifiers and Implementation Requirements. While there is a single identifier, that identifier may specify a format containing multiple distinct signature values.
SignatureMethodは、署名の生成と検証に使用されるアルゴリズムを指定する必要な要素です。このアルゴリズムは、署名操作に関与するすべての暗号化関数（ハッシュ、公開キーアルゴリズム、MAC、パディングなど）を識別します。この要素は、セクション6.1：アルゴリズムの識別子と実装要件で説明されているアルゴリズムについて、ここで一般構造を使用します。単一の識別子がありますが、その識別子は複数の異なる署名値を含む形式を指定できます。
Schema Definition:
スキーマ定義：
<element name="SignatureMethod" type="ds:SignatureMethodType"/>
<complexType name="SignatureMethodType" mixed="true">
<sequence>
<element name="HMACOutputLength" minOccurs="0"
type="ds:HMACOutputLengthType"/>
<any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
<!-- (0,unbounded) elements from (1,1) external namespace -->
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
DTD:
DTD：
<!ELEMENT SignatureMethod
(#PCDATA|HMACOutputLength %Method.ANY;)* >
<!ATTLIST SignatureMethod
Algorithm CDATA #REQUIRED >
Reference is an element that may occur one or more times. It specifies a digest algorithm and digest value, and optionally an identifier of the object being signed, the type of the object, and/or a list of transforms to be applied prior to digesting. The identification (URI) and transforms describe how the digested content (i.e., the input to the digest method) was created. The Type attribute facilitates the processing of referenced data. For example, while this specification makes no requirements over external data, an application may wish to signal that the referent is a Manifest. An optional ID attribute permits a Reference to be referenced from elsewhere.
参照は、1回以上発生する可能性のある要素です。ダイジェストアルゴリズムとダイジェスト値、およびオプションで署名されているオブジェクトの識別子、オブジェクトのタイプ、および/または消化前に適用される変換のリストを指定します。識別（URI）と変換は、消化されたコンテンツ（つまり、消化法への入力）がどのように作成されたかを説明しています。型属性は、参照されるデータの処理を容易にします。たとえば、この仕様は外部データよりも要件を作成していませんが、アプリケーションは指示対象がマニフェストであることを示すことを望む場合があります。オプションのID属性により、参照を他の場所から参照することができます。
Schema Definition:
スキーマ定義：
<element name="Reference" type="ds:ReferenceType"/>
<complexType name="ReferenceType">
<sequence>
<element ref="ds:Transforms" minOccurs="0"/>
<element ref="ds:DigestMethod"/>
<element ref="ds:DigestValue"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
<attribute name="URI" type="anyURI" use="optional"/>
<attribute name="Type" type="anyURI" use="optional"/>
</complexType>
DTD:
DTD：
<!ELEMENT Reference (Transforms?, DigestMethod, DigestValue) >
<!ATTLIST Reference
Id ID #IMPLIED
URI CDATA #IMPLIED
Type CDATA #IMPLIED>
The URI attribute identifies a data object using a URI-Reference, as specified by RFC2396 [URI]. The set of allowed characters for URI attributes is the same as for XML, namely [Unicode]. However, some Unicode characters are disallowed from URI references including all non-ASCII characters and the excluded characters listed in RFC2396 [URI, section 2.4]. However, the number sign (#), percent sign (%), and square bracket characters re-allowed in RFC 2732 [URI-Literal] are permitted. Disallowed characters must be escaped as follows:
URI属性は、RFC2396 [URI]で指定されているように、URI参照を使用してデータオブジェクトを識別します。URI属性の許可された文字のセットは、XML、つまり[Unicode]の場合と同じです。ただし、一部のユニコード文字は、すべての非ASCII文字やRFC2396にリストされている除外された文字を含むURI参照から許可されていません[URI、セクション2.4]。ただし、RFC 2732 [URI-LITERAL]で再認可された数字サイン（＃）、パーセントサイン（％）、および四角いブラケット文字は許可されています。許可されていないキャラクターは、次のように逃げなければなりません。
1. Each disallowed character is converted to [UTF-8] as one or more octets. 2. Any octets corresponding to a disallowed character are escaped with the URI escaping mechanism (that is, converted to %HH, where HH is the hexadecimal notation of the octet value). 3. The original character is replaced by the resulting character sequence.
1. 許可されていない各文字は、1つ以上のオクテットとして[UTF-8]に変換されます。2.許可されていない文字に対応するオクテットは、URI脱出メカニズム（つまり、％HHに変換されます。ここで、HHはオクテット値の16進表です）で逃げます。3.元の文字は、結果の文字シーケンスに置き換えられます。
XML signature applications MUST be able to parse URI syntax. We RECOMMEND they be able to dereference URIs in the HTTP scheme. Dereferencing a URI in the HTTP scheme MUST comply with the Status Code Definitions of [HTTP] (e.g., 302, 305 and 307 redirects are followed to obtain the entity-body of a 200 status code response). Applications should also be cognizant of the fact that protocol parameter and state information, (such as HTTP cookies, HTML device profiles or content negotiation), may affect the content yielded by dereferencing a URI.
XML署名アプリケーションは、URI構文を解析できる必要があります。HTTPスキームでURIを拒否できることをお勧めします。HTTPスキームでURIを繰り返すと、[http]のステータスコード定義に準拠する必要があります（たとえば、302、305、および307リダイレクトに続いて、200ステータスコード応答のエンティティボディを取得します）。アプリケーションは、プロトコルパラメーターと状態情報（HTTP Cookie、HTMLデバイスプロファイル、コンテンツネゴシエーションなど）が、URIの繰り返しによって生成されるコンテンツに影響を与える可能性があるという事実も認識する必要があります。
If a resource is identified by more than one URI, the most specific should be used (e.g., http://www.w3.org/2000/06/interop-pressrelease.html.en instead of http://www.w3.org/2000/06/interop-pressrelease). (See the Reference Validation (section 3.2.1) for a further information on reference processing.)
リソースが複数のURIによって識別されている場合、最も具体的なものを使用する必要があります（例：http://www.w3.org/2000/06/interop-pressrelease.html.en.org/2000/06/interpressrelease）。（参照処理の詳細については、参照検証（セクション3.2.1）を参照してください。）
If the URI attribute is omitted altogether, the receiving application is expected to know the identity of the object. For example, a lightweight data protocol might omit this attribute given the identity of the object is part of the application context. This attribute may be omitted from at most one Reference in any particular SignedInfo, or Manifest.
URI属性が完全に省略されている場合、受信アプリケーションはオブジェクトのIDを知ることが期待されます。たとえば、オブジェクトのIDがアプリケーションコンテキストの一部であるため、軽量のデータプロトコルはこの属性を省略する可能性があります。この属性は、特定のSignedInfoまたはマニフェストの最大1つの参照から省略できます。
The optional Type attribute contains information about the type of object being signed. This is represented as a URI. For example:
オプションの型属性には、署名されているオブジェクトのタイプに関する情報が含まれています。これはURIとして表されます。例えば：
Type="http://www.w3.org/2000/09/xmldsig#Object"
Type="http://www.w3.org/2000/09/xmldsig#Manifest"
The Type attribute applies to the item being pointed at, not its contents. For example, a reference that identifies an Object element containing a SignatureProperties element is still of type #Object. The type attribute is advisory. No validation of the type information is required by this specification.
型属性は、その内容ではなく、指摘されているアイテムに適用されます。たとえば、SignatureProperties要素を含むオブジェクト要素を識別するリファレンスは、まだ＃Objectのタイプです。タイプ属性はアドバイザリーです。この仕様では、タイプ情報の検証は必要ありません。
Note: XPath is RECOMMENDED. Signature applications need not conform to [XPath] specification in order to conform to this specification. However, the XPath data model, definitions (e.g., node-sets) and syntax is used within this document in order to describe functionality for those that want to process XML-as-XML (instead of octets) as part of signature generation. For those that want to use these features, a conformant [XPath] implementation is one way to implement these features, but it is not required. Such applications could use a sufficiently functional replacement to a node-set and implement only those XPath expression behaviors REQUIRED by this specification. However, for simplicity we generally will use XPath terminology without including this qualification on every point. Requirements over "XPath node-sets" can include a node-set functional equivalent. Requirements over XPath processing can include application behaviors that are equivalent to the corresponding XPath behavior.
注：XPathをお勧めします。署名アプリケーションは、この仕様に準拠するために[XPath]仕様に準拠する必要はありません。ただし、XML-As-XML（オクテットの代わりに）を署名生成の一部として処理したいものの機能を記述するために、XPathデータモデル、定義（ノードセットなど）、および構文がこのドキュメント内で使用されます。これらの機能を使用したい人にとっては、コンフォーマント[xpath]実装はこれらの機能を実装する1つの方法ですが、必須ではありません。このようなアプリケーションは、ノードセットに十分に機能的な置換を使用し、この仕様に必要なXPATH式の動作のみを実装できます。ただし、簡単にするために、一般に、すべてのポイントにこの資格を含めることなくXpath用語を使用します。「XPathノードセット」を介した要件には、ノードセットの機能等価物を含めることができます。XPath処理に関する要件には、対応するXPathの動作に相当するアプリケーション動作を含めることができます。
The data-type of the result of URI dereferencing or subsequent Transforms is either an octet stream or an XPath node-set.
URIの解釈またはその後の変換の結果のデータタイプは、OctetストリームまたはXPathノードセットのいずれかです。
The Transforms specified in this document are defined with respect to the input they require. The following is the default signature application behavior:
このドキュメントで指定された変換は、必要な入力に関して定義されます。以下は、デフォルトの署名アプリケーション動作です。
* If the data object is an octet stream and the next transform requires a node-set, the signature application MUST attempt to parse the octets yielding the required node-set via [XML] well-formed processing. * If the data object is a node-set and the next transform requires octets, the signature application MUST attempt to convert the node-set to an octet stream using Canonical XML [XML-C14N].
* データオブジェクトがオクテットストリームであり、次の変換にノードセットが必要な場合、署名アプリケーションは[XML]よく形成された処理を介して必要なノードセットを生成するオクテットを解析しようと試みなければなりません。*データオブジェクトがノードセットであり、次の変換にオクテットが必要な場合、署名アプリケーションは、標準XML [XML-C14N]を使用してノードセットをオクテットストリームに変換しようと試みなければなりません。
Users may specify alternative transforms that override these defaults in transitions between transforms that expect different inputs. The final octet stream contains the data octets being secured. The digest algorithm specified by DigestMethod is then applied to these data octets, resulting in the DigestValue.
ユーザーは、異なる入力を期待する変換間の遷移でこれらのデフォルトをオーバーライドする代替変換を指定できます。最終的なオクテットストリームには、保護されているデータオクテットが含まれています。DigestMethodで指定されたDigestアルゴリズムは、これらのデータオクテットに適用され、DigestValueが発生します。
Unless the URI-Reference is a 'same-document' reference as defined in [URI, Section 4.2], the result of dereferencing the URI-Reference MUST be an octet stream. In particular, an XML document identified by URI is not parsed by the signature application unless the URI is a same-document reference or unless a transform that requires XML parsing is applied. (See Transforms (section 4.3.3.1).)
URI-Referenceが[URI、セクション4.2]で定義されている「同じドキュメント」参照でない限り、URIの参照が拒否された結果はオクテットストリームでなければなりません。特に、URIによって識別されるXMLドキュメントは、URIが同じドキュメントリファレンスである場合、またはXML解析を必要とする変換が適用されない限り、署名アプリケーションによって解析されません。（変換（セクション4.3.3.1）を参照してください。）
When a fragment is preceded by an absolute or relative URI in the URI-Reference, the meaning of the fragment is defined by the resource's MIME type. Even for XML documents, URI dereferencing (including the fragment processing) might be done for the signature application by a proxy. Therefore, reference validation might fail if fragment processing is not performed in a standard way (as defined in the following section for same-document references). Consequently, we RECOMMEND that the URI attribute not include fragment identifiers and that such processing be specified as an additional XPath Transform.
フラグメントの前に、URI参照に絶対的または相対的なURIが先行する場合、フラグメントの意味はリソースのMIMEタイプによって定義されます。XMLドキュメントであっても、URIの解釈（フラグメント処理を含む）は、プロキシによる署名アプリケーションのために行われる場合があります。したがって、フラグメント処理が標準的な方法で実行されない場合、参照検証は失敗する可能性があります（同じドキュメント参照については、次のセクションで定義されています）。その結果、URI属性にはフラグメント識別子が含まれておらず、そのような処理を追加のXPath変換として指定することをお勧めします。
When a fragment is not preceded by a URI in the URI-Reference, XML signature applications MUST support the null URI and barename XPointer. We RECOMMEND support for the same-document XPointers '#xpointer(/)' and '#xpointer(id('ID'))' if the application also intends to support any canonicalization that preserves comments. (Otherwise URI="#foo" will automatically remove comments before the canonicalization can even be invoked.) All other support for XPointers is OPTIONAL, especially all support for barename and other XPointers in external resources since the application may not have control over how the fragment is generated (leading to interoperability problems and validation failures).
フラグメントの前にURIリファレンスのURIが先行しない場合、XML署名アプリケーションはnull URIおよびBarename XPointerをサポートする必要があります。アプリケーションがコメントを保持する標準化もサポートする予定の場合は、同じドキュメントxpointers '#xpointer（/）'および '#xpointer（id（' id '））をサポートすることをお勧めします。（それ以外の場合は、URI = "＃foo"は、標準化が呼び出される前にコメントを自動的に削除します。）Xpointersの他のすべてのサポートはオプションです。特に、アプリケーションが外部リソースのBarenameやその他のXpointerのすべてのサポートはオプションです。フラグメントが生成されます（相互運用性の問題と検証障害につながります）。
The following examples demonstrate what the URI attribute identifies and how it is dereferenced:
次の例は、URI属性が何を識別し、どのように宣言されるかを示しています。
URI="http://example.com/bar.xml" Identifies the octets that represent the external resource 'http://example.com/bar.xml', that is probably an XML document given its file extension. URI="http://example.com/bar.xml#chapter1" Identifies the element with ID attribute value 'chapter1' of the external XML resource 'http://example.com/bar.xml', provided as an octet stream. Again, for the sake of interoperability, the element identified as 'chapter1' should be obtained using an XPath transform rather than a URI fragment (barename XPointer resolution in external resources is not REQUIRED in this specification). URI="" Identifies the node-set (minus any comment nodes) of the XML resource containing the signature URI="#chapter1" Identifies a node-set containing the element with ID attribute value 'chapter1' of the XML resource containing the signature. XML Signature (and its applications) modify this node-set to include the element plus all descendents including namespaces and attributes -- but not comments.
uri = "http://example.com/bar.xml"は、外部リソース「http://example.com/bar.xml」を表すオクテットを識別します。uri = "http://example.com/bar.xml#chapter1" octetとして提供される外部xmlリソース 'http://example.com/bar.xml'のID属性値 'Chapter1'の要素を識別します。ストリーム。繰り返しますが、相互運用性のために、URIフラグメントではなくXpath変換を使用して「章1」として識別される要素を取得する必要があります（この仕様では、外部リソースのBarename XPointer解像度は必要ありません）。uri = "" signature uri = "＃Chapter1"を含むXMLリソースのノードセット（コメントノードをマイナス）を識別します。。XML署名（およびそのアプリケーション）は、このノードセットを変更して、要素と名前空間や属性を含むすべての子孫を含むがコメントではない。
Dereferencing a same-document reference MUST result in an XPath node-set suitable for use by Canonical XML [XML-C14N]. Specifically, dereferencing a null URI (URI="") MUST result in an XPath node-set that includes every non-comment node of the XML document containing the URI attribute. In a fragment URI, the characters after the number sign ('#') character conform to the XPointer syntax [Xptr]. When processing an XPointer, the application MUST behave as if the root node of the XML document containing the URI attribute were used to initialize the XPointer evaluation context. The application MUST behave as if the result of XPointer processing were a node-set derived from the resultant location-set as follows:
同じドキュメントの参照を参照すると、Canonical XML [XML-C14N]が使用するのに適したXPathノードセットになる必要があります。具体的には、null uri（uri = ""）の逆効果は、uri属性を含むxmlドキュメントのすべての非commentノードを含むxpathノードセットになる必要があります。フラグメントURIでは、数字記号（ '＃'）の後の文字がxpointer構文[xptr]に適合します。XPointerを処理する場合、XPointer属性を含むXMLドキュメントのルートノードを使用して、XPointer評価コンテキストを初期化するためにアプリケーションが動作する必要があります。アプリケーションは、Xpointer処理の結果が、次のように結果の位置設定から派生したノードセットであるかのように動作する必要があります。
1. discard point nodes 2. replace each range node with all XPath nodes having full or partial content within the range 3. replace the root node with its children (if it is in the node-set) 4. replace any element node E with E plus all descendants of E (text, comment, PI, element) and all namespace and attribute nodes of E and its descendant elements. 5. if the URI is not a full XPointer, then delete all comment nodes
1. 廃棄ポイントノード2.各範囲ノードをすべてのXpathノードに置き換えます。範囲内の完全または部分コンテンツを備えた3.ルートノードを子供に置き換えます（ノードセットにある場合）4。任意の要素ノードEをE Plusに置き換えますEのすべての子孫（テキスト、コメント、PI、要素）およびEおよびその子孫要素のすべての名前空間と属性ノード。5. URIが完全なXPointerでない場合は、すべてのコメントノードを削除します
The second to last replacement is necessary because XPointer typically indicates a subtree of an XML document's parse tree using just the element node at the root of the subtree, whereas Canonical XML treats a node-set as a set of nodes in which absence of descendant nodes results in absence of their representative text from the canonical form.
Xpointerは通常、サブツリーのルートにある要素ノードのみを使用してXMLドキュメントの解析ツリーのサブツリーを示すのに対し、標準的なXMLはノードセットを下位ノードのないノードのセットとして扱うため、最後の交換が必要です。標準形式からの代表的なテキストがない場合になります。
The last step is performed for null URIs, barename XPointers and child sequence XPointers. It's necessary because when [XML-C14N] is passed a node-set, it processes the node-set as is: with or without comments. Only when it's called with an octet stream does it invoke its own XPath expressions (default or without comments). Therefore to retain the default behavior of stripping comments when passed a node-set, they are removed in the last step if the URI is not a full XPointer. To retain comments while selecting an element by an identifier ID, use the following full XPointer: URI='#xpointer(id('ID'))'. To retain comments while selecting the entire document, use the following full XPointer: URI='#xpointer(/)'. This XPointer contains a simple XPath expression that includes the root node, which the second to last step above replaces with all nodes of the parse tree (all descendants, plus all attributes, plus all namespaces nodes).
最後のステップは、null uris、barename xpointers、および子シーケンスxpointersに対して実行されます。[xml-c14n]がノードセットに渡されると、コメントの有無にかかわらずノードセットを処理するため、必要です。Octetストリームで呼び出された場合にのみ、独自のXpath式（デフォルトまたはコメントなし）を呼び出します。したがって、ノードセットに合格したときにコメントをストリッピングするデフォルトの動作を保持するために、URIが完全なXPointerでない場合、それらは最後のステップで削除されます。識別子IDで要素を選択しながらコメントを保持するには、次の完全なXpointer：uri = '＃xpointer（id（' id '））'を使用します。ドキュメント全体を選択しながらコメントを保持するには、次の完全なXpointer：uri = '＃xpointer（/）'を使用します。このXpointerには、ルートノードを含む単純なXPath式が含まれています。これは、上記の2番目のステップが解析ツリーのすべてのノード（すべての子孫、すべての属性、およびすべての名前空間ノード）に置き換えられます。
The optional Transforms element contains an ordered list of Transform elements; these describe how the signer obtained the data object that was digested. The output of each Transform serves as input to the next Transform. The input to the first Transform is the result of dereferencing the URI attribute of the Reference element. The output from the last Transform is the input for the DigestMethod algorithm. When transforms are applied the signer is not signing the native (original) document but the resulting (transformed) document. (See Only What is Signed is Secure (section 8.1).)
オプションの変換要素には、変換要素の順序付けられたリストが含まれています。これらは、署名者が消化されたデータオブジェクトをどのように取得したかを説明しています。各変換の出力は、次の変換への入力として機能します。最初の変換への入力は、参照要素のURI属性を繰り返し回避した結果です。最後の変換からの出力は、DigestMethodアルゴリズムの入力です。Transformsが適用されると、署名者はネイティブ（元の）ドキュメントに署名するのではなく、結果の（変換）ドキュメントに署名しています。（署名されているのは安全です（セクション8.1）。）
Each Transform consists of an Algorithm attribute and content parameters, if any, appropriate for the given algorithm. The Algorithm attribute value specifies the name of the algorithm to be performed, and the Transform content provides additional data to govern the algorithm's processing of the transform input. (See Algorithm Identifiers and Implementation Requirements (section 6).) As described in The Reference Processing Model (section 4.3.3.2), some transforms take an XPath node-set as input, while others require an octet stream. If the actual input matches the input needs of the transform, then the transform operates on the unaltered input. If the transform input requirement differs from the format of the actual input, then the input must be converted.
各変換は、特定のアルゴリズムに適したアルゴリズム属性とコンテンツパラメーターで構成されています。アルゴリズム属性値は、実行されるアルゴリズムの名前を指定し、変換コンテンツはアルゴリズムの変換入力の処理を管理する追加データを提供します。（参照処理モデル（セクション4.3.3.2）で説明されているように、アルゴリズムの識別子と実装要件（セクション6）を参照してください（セクション6）を参照してください。いくつかの変換はXPathノードセットを入力として取りますが、他の変換はオクテットストリームを必要とします。実際の入力が変換の入力ニーズと一致する場合、変換は変更されていない入力で動作します。変換入力要件が実際の入力の形式と異なる場合、入力を変換する必要があります。
Some Transforms may require explicit MIME type, charset (IANA registered "character set"), or other such information concerning the data they are receiving from an earlier Transform or the source data, although no Transform algorithm specified in this document needs such explicit information. Such data characteristics are provided as parameters to the Transform algorithm and should be described in the specification for the algorithm.
一部の変換では、明示的なMIMEタイプ、CharSet（IANA登録「文字セット」）、または以前の変換またはソースデータから受信しているデータに関するその他の情報が必要になる場合がありますが、このドキュメントで指定された変換アルゴリズムはそのような明示的な情報を必要としません。このようなデータ特性は、変換アルゴリズムのパラメーターとして提供され、アルゴリズムの仕様で説明する必要があります。
Examples of transforms include but are not limited to base64 decoding [MIME], canonicalization [XML-C14N], XPath filtering [XPath], and XSLT [XSLT]. The generic definition of the Transform element also allows application-specific transform algorithms. For example, the transform could be a decompression routine given by a Java class appearing as a base64 encoded parameter to a Java Transform algorithm. However, applications should refrain from using application-specific transforms if they wish their signatures to be verifiable outside of their application domain. Transform Algorithms (section 6.6) define the list of standard transformations.
変換の例には、Base64デコード[MIME]、CanOnicalization [XML-C14N]、XPathフィルタリング[XPath]、およびXSLT [XSLT]が含まれますが、これらに限定されません。変換要素の汎用定義は、アプリケーション固有の変換アルゴリズムも可能にします。たとえば、変換は、Java変換アルゴリズムにbase64エンコードされたパラメーターとして表示されるJavaクラスによって与えられる減圧ルーチンになる可能性があります。ただし、アプリケーションドメインの外で署名を検証できるようにしたい場合は、アプリケーション固有の変換の使用を控える必要があります。変換アルゴリズム（セクション6.6）は、標準変換のリストを定義します。
Schema Definition:
スキーマ定義：
<element name="Transforms" type="ds:TransformsType"/>
<complexType name="TransformsType">
<sequence>
<element ref="ds:Transform" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="Transform" type="ds:TransformType"/> <complexType name="TransformType" mixed="true"> <choice minOccurs="0" maxOccurs="unbounded"> <any namespace="##other" processContents="lax"/> <!-- (1,1) elements from (0,unbounded) namespaces --> <element name="XPath" type="string"/> </choice> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType> DTD:
<要素name = "transform" type = "ds：transformtype"/> <complextype name = "transformtype" mixed = "true"> <choice minoccurs = "0" maxoccurs = "unbounded"> <any namespace = "## other"ProcessContents =" lax "/> <！ - （1,1）要素（0、unbounded）名前空間 - > <要素name =" xpath "type =" string "/> </choice> <属性name =「アルゴリズム」type = "anyuri" use = "必須"/> </complextype> dtd：
<!ELEMENT Transforms (Transform+)>
<!ELEMENT Transform (#PCDATA|XPath %Transform.ANY;)* >
<!ATTLIST Transform
Algorithm CDATA #REQUIRED >
<!ELEMENT XPath (#PCDATA) >
DigestMethod is a required element that identifies the digest algorithm to be applied to the signed object. This element uses the general structure here for algorithms specified in Algorithm Identifiers and Implementation Requirements (section 6.1).
DigestMethodは、署名されたオブジェクトに適用されるダイジェストアルゴリズムを識別する必要な要素です。この要素は、アルゴリズム識別子と実装要件で指定されたアルゴリズムについて、ここで一般構造を使用します（セクション6.1）。
If the result of the URI dereference and application of Transforms is an XPath node-set (or sufficiently functional replacement implemented by the application) then it must be converted as described in the Reference Processing Model (section 4.3.3.2). If the result of URI dereference and application of transforms is an octet stream, then no conversion occurs (comments might be present if the Canonical XML with Comments was specified in the Transforms). The digest algorithm is applied to the data octets of the resulting octet stream.
URIの規制と変換の適用の結果がXPathノードセット（またはアプリケーションによって実装された十分に機能的な置換）である場合、参照処理モデル（セクション4.3.3.2）で説明されているように変換する必要があります。URIの規制と変換の適用の結果がオクテットストリームである場合、変換は発生しません（変換でコメントを含む標準XMLが指定された場合、コメントが存在する可能性があります）。ダイジェストアルゴリズムは、結果のオクテットストリームのデータオクテットに適用されます。
Schema Definition:
スキーマ定義：
<element name="DigestMethod" type="ds:DigestMethodType"/>
<complexType name="DigestMethodType" mixed="true">
<sequence>
<any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
DTD:
DTD：
<!ELEMENT DigestMethod (#PCDATA %Method.ANY;)* >
<!ATTLIST DigestMethod
Algorithm CDATA #REQUIRED >
DigestValue is an element that contains the encoded value of the digest. The digest is always encoded using base64 [MIME].
DigestValueは、Digestのエンコードされた値を含む要素です。ダイジェストは、Base64 [Mime]を使用して常にエンコードされます。
Schema Definition:
スキーマ定義：
<element name="DigestValue" type="ds:DigestValueType"/>
<simpleType name="DigestValueType">
<restriction base="base64Binary"/>
</simpleType>
DTD:
DTD：
<!ELEMENT DigestValue (#PCDATA) >
<!-- base64 encoded digest value -->
KeyInfo is an optional element that enables the recipient(s) to obtain the key needed to validate the signature. KeyInfo may contain keys, names, certificates and other public key management information, such as in-band key distribution or key agreement data. This specification defines a few simple types but applications may extend those types or all together replace them with their own key identification and exchange semantics using the XML namespace facility. [XML-ns] However, questions of trust of such key information (e.g., its authenticity or strength) are out of scope of this specification and left to the application.
KeyInfoは、受信者が署名を検証するために必要なキーを取得できるようにするオプションの要素です。KeyINFOには、帯域内のキー配布や主要な契約データなど、キー、名前、証明書、およびその他の公開キー管理情報が含まれる場合があります。この仕様ではいくつかの単純なタイプを定義しますが、アプリケーションはこれらのタイプを拡張するか、すべてを一緒にXML名空間施設を使用して独自の重要な識別と交換セマンティクスに置き換えます。[XML-NS]ただし、このような重要な情報（例えば、その信ity性や強さ）の信頼の質問は、この仕様の範囲外であり、アプリケーションに任されています。
If KeyInfo is omitted, the recipient is expected to be able to identify the key based on application context. Multiple declarations within KeyInfo refer to the same key. While applications may define and use any mechanism they choose through inclusion of elements from a different namespace, compliant versions MUST implement KeyValue (section 4.4.2) and SHOULD implement RetrievalMethod (section 4.4.3).
KeyInfoが省略されている場合、受信者はアプリケーションコンテキストに基づいてキーを識別できると予想されます。KeyInfo内の複数の宣言は、同じキーを参照しています。アプリケーションは、異なる名前空間から要素を含めることで選択したメカニズムを定義および使用する場合がありますが、準拠バージョンはキーバリュー（セクション4.4.2）を実装する必要があり、retirevalMethod（セクション4.4.3）を実装する必要があります。
The schema/DTD specifications of many of KeyInfo's children (e.g., PGPData, SPKIData, X509Data) permit their content to be extended/complemented with elements from another namespace. This may be done only if it is safe to ignore these extension elements while claiming support for the types defined in this specification. Otherwise, external elements, including alternative structures to those defined by this specification, MUST be a child of KeyInfo. For example, should a complete XML-PGP standard be defined, its root element MUST be a child of KeyInfo. (Of course, new structures from external namespaces can incorporate elements from the &dsig; namespace via features of the type definition language. For instance, they can create a DTD that mixes their own and dsig qualified elements, or a schema that permits, includes, imports, or derives new types based on &dsig; elements.) The following list summarizes the KeyInfo types that are allocated to an identifier in the &dsig; namespace; these can be used within the RetrievalMethod Type attribute to describe a remote KeyInfo structure.
KeyInfoの多くの子供（PGPDATA、SPKIDATA、X509DATAなど）の多くのスキーマ/DTD仕様により、コンテンツを別の名前空間からの要素で拡張/補完することができます。これは、この仕様で定義されているタイプのサポートを主張しながら、これらの拡張要素を無視しても安全である場合にのみ行うことができます。それ以外の場合、この仕様で定義されたものに対する代替構造を含む外部要素は、KeyInfoの子供でなければなりません。たとえば、完全なXML-PGP標準を定義する場合、そのルート要素はKeyInfoの子でなければなりません。（もちろん、外部の名前空間からの新しい構造は、タイプ定義言語の機能を介して＆dsig;名前空間の要素を組み込むことができます。たとえば、独自の要素とDSIGの適格な要素を混合するDTD、または許可するスキーマを作成できます。＆dsig;要素に基づいて新しいタイプを導入するか、導入します。）次のリストは、＆dsigの識別子に割り当てられたkeyinfoタイプを要約しています。名前空間;これらは、RetrievalMethod型属性内で使用して、リモートKeyINFO構造を記述できます。
* http://www.w3.org/2000/09/xmldsig#DSAKeyValue * http://www.w3.org/2000/09/xmldsig#RSAKeyValue * http://www.w3.org/2000/09/xmldsig#X509Data * http://www.w3.org/2000/09/xmldsig#PGPData * http://www.w3.org/2000/09/xmldsig#SPKIData * http://www.w3.org/2000/09/xmldsig#MgmtData
* http://www.w3.org/2000/09/xmldsig#dsakeyvalue * http://www.w3.org/2000/09/xmldsig#rsakeyvalue * http://www.w3.org/2000/09/XMLDSIG＃x509DATA * http://www.w3.org/2000/09/xmldsig#pgpdata * http://www.w3.org/2000/09/xmldsig#spkidata * http://www.w.w.w.w.w.w3.org//2000/09/xmldsig＃mgmtdata
In addition to the types above for which we define an XML structure, we specify one additional type to indicate a binary (ASN.1 DER) X.509 Certificate.
XML構造を定義する上記のタイプに加えて、バイナリ（ASN.1 der）X.509証明書を示すために1つの追加タイプを指定します。
* http://www.w3.org/2000/09/xmldsig#rawX509Certificate
* http://www.w3.org/2000/09/xmldsig#rawX509Certificate
Schema Definition:
スキーマ定義：
<element name="KeyInfo" type="ds:KeyInfoType"/>
<complexType name="KeyInfoType" mixed="true">
<choice maxOccurs="unbounded">
<element ref="ds:KeyName"/>
<element ref="ds:KeyValue"/>
<element ref="ds:RetrievalMethod"/>
<element ref="ds:X509Data"/>
<element ref="ds:PGPData"/>
<element ref="ds:SPKIData"/>
<element ref="ds:MgmtData"/>
<any processContents="lax" namespace="##other"/>
<!-- (1,1) elements from (0,unbounded) namespaces -->
</choice>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
DTD:
DTD：
<!ELEMENT KeyInfo (#PCDATA|KeyName|KeyValue|RetrievalMethod|
X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY;)* >
<!ATTLIST KeyInfo
Id ID #IMPLIED >
The KeyName element contains a string value (in which white space is significant) which may be used by the signer to communicate a key identifier to the recipient. Typically, KeyName contains an identifier related to the key pair used to sign the message, but it may contain other protocol-related information that indirectly identifies a key pair. (Common uses of KeyName include simple string names for keys, a key index, a distinguished name (DN), an email address, etc.)
KeyName要素には、署名者がキー識別子を受信者に伝えるために使用できる文字列値（ホワイトスペースが重要）が含まれています。通常、KeyNameにはメッセージの署名に使用されるキーペアに関連する識別子が含まれていますが、間接的にキーペアを識別する他のプロトコル関連情報が含まれている場合があります。（KeyNameの一般的な用途には、キーの単純な文字列名、キーインデックス、著名な名前（DN）、電子メールアドレスなどが含まれます）
Schema Definition:
スキーマ定義：
<element name="KeyName" type="string"/>
DTD:
DTD：
<!ELEMENT KeyName (#PCDATA) >
The KeyValue element contains a single public key that may be useful in validating the signature. Structured formats for defining DSA (REQUIRED) and RSA (RECOMMENDED) public keys are defined in Signature Algorithms (section 6.4). The KeyValue element may include externally defined public key values represented as PCDATA or element types from an external namespace.
KeyValue要素には、署名の検証に役立つ単一の公開キーが含まれています。DSA（必須）およびRSA（推奨）を定義するための構造化された形式は、署名アルゴリズム（セクション6.4）で定義されています。KeyValue要素には、PCDATAとして表される外部から定義された公開キー値または外部ネームスペースの要素タイプを含めることができます。
Schema Definition:
スキーマ定義：
<element name="KeyValue" type="ds:KeyValueType"/>
<complexType name="KeyValueType" mixed="true">
<choice>
<element ref="ds:DSAKeyValue"/>
<element ref="ds:RSAKeyValue"/>
<any namespace="##other" processContents="lax"/>
</choice>
</complexType>
DTD:
DTD：
<!ELEMENT KeyValue (#PCDATA|DSAKeyValue|RSAKeyValue
%KeyValue.ANY;)* >
Identifier Type="http://www.w3.org/2000/09/xmldsig#DSAKeyValue" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ= "http://www.w3.org/2000/09/xmldsig#dsakeyvalue"（これは、retirevalmethodまたは参照要素内で使用するために、指示対象のタイプを識別することができます）
DSA keys and the DSA signature algorithm are specified in [DSS]. DSA public key values can have the following fields:
DSAキーとDSA署名アルゴリズムは[DSS]で指定されています。DSA公開鍵の値には、次のフィールドを持つことができます。
P a prime modulus meeting the [DSS] requirements Q an integer in the range 2**159 < Q < 2**160 which is a prime divisor of P-1 G an integer with certain properties with respect to P and Q Y G**X mod P (where X is part of the private key and not made public) J (P - 1) / Q seed a DSA prime generation seed pgenCounter a DSA prime generation counter
P A [DSS]要件を満たすプライムモジュラスq範囲の整数2 ** 159 <Q <2 ** 160は、P-1 Gのプライム除数です。X mod P（xは秘密鍵の一部であり、公開されていない）
Parameter J is available for inclusion solely for efficiency as it is calculatable from P and Q. Parameters seed and pgenCounter are used in the DSA prime number generation algorithm specified in [DSS]. As such, they are optional, but must either both be present or both be absent. This prime generation algorithm is designed to provide assurance that a weak prime is not being used and it yields a P and Q value. Parameters P, Q, and G can be public and common to a group of users. They might be known from application context. As such, they are optional but P and Q must either both appear or both be absent. If all of P, Q, seed, and pgenCounter are present, implementations are not required to check if they are consistent and are free to use either P and Q or seed and pgenCounter. All parameters are encoded as base64 [MIME] values.
パラメーターJは、PおよびQから計算可能であるため、効率のためだけに含めるために使用できます。パラメーターシードとPGENCounterは、[DSS]で指定されたDSAプライムナンバー生成アルゴリズムで使用されます。そのため、オプションですが、両方が存在するか、両方である必要があります。このプライムジェネレーションアルゴリズムは、弱いプライムが使用されておらず、PとQ値を生成するという保証を提供するように設計されています。パラメーターP、Q、およびGは、ユーザーのグループに公開され、共通することができます。それらはアプリケーションのコンテキストから知られているかもしれません。そのため、それらはオプションですが、PとQは両方とも表示されるか、両方が存在しない必要があります。すべてのp、q、種子、およびpgencounterが存在する場合、実装は一貫性があり、p、q、またはシードとpgencounterのいずれかを自由に使用できるかどうかを確認する必要はありません。すべてのパラメーターは、base64 [mime]値としてエンコードされます。
Arbitrary-length integers (e.g., "bignums" such as RSA moduli) are represented in XML as octet strings as defined by the ds:CryptoBinary type.
任意の長さの整数（例：RSAモジュリなどの「ビグノム」）は、XMLで、DS：Cryptobinary Typeで定義されているオクテット文字列として表されます。
Schema Definition:
スキーマ定義：
<element name="DSAKeyValue" type="ds:DSAKeyValueType"/>
<complexType name="DSAKeyValueType">
<sequence>
<sequence minOccurs="0">
<element name="P" type="ds:CryptoBinary"/>
<element name="Q" type="ds:CryptoBinary"/>
</sequence>
<element name="G" type="ds:CryptoBinary" minOccurs="0"/>
<element name="Y" type="ds:CryptoBinary"/>
<element name="J" type="ds:CryptoBinary" minOccurs="0"/>
<sequence minOccurs="0">
<element name="Seed" type="ds:CryptoBinary"/>
<element name="PgenCounter" type="ds:CryptoBinary"/>
</sequence>
</sequence>
</complexType>
DTD Definition:
DTD定義：
<!ELEMENT DSAKeyValue ((P, Q)?, G?, Y, J?, (Seed, PgenCounter)?) >
<!ELEMENT P (#PCDATA) >
<!ELEMENT Q (#PCDATA) >
<!ELEMENT G (#PCDATA) >
<!ELEMENT Y (#PCDATA) >
<!ELEMENT J (#PCDATA) >
<!ELEMENT Seed (#PCDATA) >
<!ELEMENT PgenCounter (#PCDATA) >
Identifier Type="http://www.w3.org/2000/09/xmldsig#RSAKeyValue" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ= "http://www.w3.org/2000/09/xmldsig#rsakeyvalue"（これは、retirevalmethodまたは参照要素内で使用するために、指示対象のタイプを識別できます）
RSA key values have two fields: Modulus and Exponent.
RSAキー値には、弾性率と指数の2つのフィールドがあります。
<RSAKeyValue>
<Modulus>
xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRg
BUwUlV5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
Arbitrary-length integers (e.g., "bignums" such as RSA moduli) are represented in XML as octet strings as defined by the ds:CryptoBinary type.
任意の長さの整数（例：RSAモジュリなどの「ビグノム」）は、XMLで、DS：Cryptobinary Typeで定義されているオクテット文字列として表されます。
Schema Definition:
スキーマ定義：
<element name="RSAKeyValue" type="ds:RSAKeyValueType"/>
<complexType name="RSAKeyValueType">
<sequence>
<element name="Modulus" type="ds:CryptoBinary"/>
<element name="Exponent" type="ds:CryptoBinary"/>
</sequence>
</complexType>
DTD Definition:
DTD定義：
<!ELEMENT RSAKeyValue (Modulus, Exponent) >
<!ELEMENT Modulus (#PCDATA) >
<!ELEMENT Exponent (#PCDATA) >
A RetrievalMethod element within KeyInfo is used to convey a reference to KeyInfo information that is stored at another location. For example, several signatures in a document might use a key verified by an X.509v3 certificate chain appearing once in the document or remotely outside the document; each signature's KeyInfo can reference this chain using a single RetrievalMethod element instead of including the entire chain with a sequence of X509Certificate elements.
KeyInfo内の検索値要素は、別の場所に保存されているKeyINFO情報への参照を伝えるために使用されます。たとえば、ドキュメント内のいくつかの署名は、ドキュメントに一度表示されるX.509V3証明書チェーンによって検証されたキーを使用する場合、またはドキュメントの外側にリモートで表示される場合があります。各署名のKeyInfoは、X509Certificate要素のシーケンスでチェーン全体を含める代わりに、単一の回収値要素を使用してこのチェーンを参照できます。
RetrievalMethod uses the same syntax and dereferencing behavior as Reference's URI (section 4.3.3.1) and the Reference Processing Model (section 4.3.3.2) except that there is no DigestMethod or DigestValue child elements and presence of the URI is mandatory.
retrievalMethodは、参照のURI（セクション4.3.3.1）および参照処理モデル（セクション4.3.3.2）と同じ構文と逆方向の動作を使用します。
Type is an optional identifier for the type of data to be retrieved. The result of dereferencing a RetrievalMethod Reference for all KeyInfo types defined by this specification (section 4.4) with a corresponding XML structure is an XML element or document with that element as the root. The rawX509Certificate KeyInfo (for which there is no XML structure) returns a binary X509 certificate.
タイプは、取得するデータのタイプのオプションの識別子です。対応するXML構造を使用してこの仕様（セクション4.4）で定義されたすべてのKeyINFOタイプの検索値参照を繰り返し回避した結果は、その要素をルートとしてXML要素またはドキュメントです。rawx509Certificate keyInfo（XML構造がない）は、バイナリX509証明書を返します。
Schema Definition:
スキーマ定義：
<element name="RetrievalMethod" type="ds:RetrievalMethodType"/>
<complexType name="RetrievalMethodType">
<sequence>
<element ref="ds:Transforms" minOccurs="0"/>
</sequence>
<attribute name="URI" type="anyURI"/>
<attribute name="Type" type="anyURI" use="optional"/>
</complexType>
DTD:
DTD：
<!ELEMENT RetrievalMethod (Transforms?) >
<!ATTLIST RetrievalMethod
URI CDATA #REQUIRED
Type CDATA #IMPLIED >
Identifier Type="http://www.w3.org/2000/09/xmldsig#X509Data" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ= "http://www.w3.org/2000/09/xmldsig#x509data"（これは、retirevalmethodまたは参照要素内で使用できます。
An X509Data element within KeyInfo contains one or more identifiers of keys or X509 certificates (or certificates' identifiers or a revocation list). The content of X509Data is:
KeyInfo内のX509DATA要素には、キーまたはX509証明書（または証明書の識別子または失効リスト）の1つ以上の識別子が含まれています。x509Dataの含有量は次のとおりです。
1. At least one element, from the following set of element types; any of these may appear together or more than once if (if and only if) each instance describes or is related to the same certificate: 2. o The X509IssuerSerial element, which contains an X.509 issuer distinguished name/serial number pair that SHOULD be compliant with RFC 2253 [LDAP-DN], o The X509SubjectName element, which contains an X.509 subject distinguished name that SHOULD be compliant with RFC 2253 [LDAP-DN], o The X509SKI element, which contains the base64 encoded plain (i.e., non-DER-encoded) value of a X509 V.3 SubjectKeyIdentifier extension. o The X509Certificate element, which contains a base64-encoded [X509v3] certificate, and o Elements from an external namespace which accompanies/complements any of the elements above. o The X509CRL element, which contains a base64-encoded certificate revocation list (CRL) [X509v3].
1. 次の要素タイプのセットから、少なくとも1つの要素。これらのいずれかが一緒に表示される場合があります（場合にのみ）各インスタンスが同じ証明書を記述または関連している場合、次の証明書を説明していますか。RFC 2253 [LDAP-DN]、o X509SubjectName要素に準拠している。すなわち、X509 v.3件名の値の値）の値x509 v.3の値拡張機能。o base64エンコード[x509v3]証明書を含むx509certificate要素、および上記の要素のいずれかを伴う/補完する外部名空間のo要素を含むo。o base64エンコード証明書取消リスト（CRL）[X509V3]を含むX509CRL要素。
Any X509IssuerSerial, X509SKI, and X509SubjectName elements that appear MUST refer to the certificate or certificates containing the validation key. All such elements that refer to a particular individual certificate MUST be grouped inside a single X509Data element and if the certificate to which they refer appears, it MUST also be in that X509Data element.
表示されるX509ISSUERSERIAL、X509SKI、およびX509SubjectName要素は、検証キーを含む証明書または証明書を参照する必要があります。特定の個々の証明書を参照するすべての要素は、単一のx509Data要素内にグループ化する必要があり、それらが参照する証明書が表示される場合は、そのx509Data要素にも含まれている必要があります。
Any X509IssuerSerial, X509SKI, and X509SubjectName elements that relate to the same key but different certificates MUST be grouped within a single KeyInfo but MAY occur in multiple X509Data elements.
同じキーに関連するが異なる証明書に関連するX509ISSUERSERIAL、X509SKI、およびX509SubjectName要素は、単一のkeyInfo内でグループ化する必要がありますが、複数のx509Data要素で発生する場合があります。
All certificates appearing in an X509Data element MUST relate to the validation key by either containing it or being part of a certification chain that terminates in a certificate containing the validation key.
X509DATA要素に表示されるすべての証明書は、検証キーを含むか、検証キーを含む証明書で終了する認定チェーンの一部であることにより、検証キーに関連する必要があります。
No ordering is implied by the above constraints. The comments in the following instance demonstrate these constraints:
上記の制約によって注文は暗示されていません。次の例のコメントは、これらの制約を示しています。
<KeyInfo>
<X509Data> <!-- two pointers to certificate-A -->
<X509IssuerSerial>
<X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
<X509SerialNumber>12345678</X509SerialNumber>
</X509IssuerSerial>
<X509SKI>31d97bd7</X509SKI>
</X509Data>
<X509Data><!-- single pointer to certificate-B -->
<X509SubjectName>Subject of Certificate B</X509SubjectName>
</X509Data>
<X509Data> <!-- certificate chain -->
<!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->
<X509Certificate>MIICXTCCA..</X509Certificate>
<!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=US
issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
<X509Certificate>MIICPzCCA...</X509Certificate>
<!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
<X509Certificate>MIICSTCCA...</X509Certificate>
</X509Data>
</KeyInfo>
Note, there is no direct provision for a PKCS#7 encoded "bag" of certificates or CRLs. However, a set of certificates and CRLs can occur within an X509Data element and multiple X509Data elements can occur in a KeyInfo. Whenever multiple certificates occur in an X509Data element, at least one such certificate must contain the public key which verifies the signature.
注意してください、証明書またはCRLの「バッグ」をエンコードしたPKCS＃7の直接的な規定はありません。ただし、x509Data要素内で一連の証明書とCRLが発生する可能性があり、keyInfoで複数のx509Data要素が発生する可能性があります。X509DATA要素で複数の証明書が発生する場合はいつでも、少なくとも1つのそのような証明書には、署名を検証する公開キーを含める必要があります。
Also, strings in DNames (X509IssuerSerial,X509SubjectName, and KeyNameif appropriate) should be encoded as follows:
また、dnamesの文字列（x509IssuerSerial、x509SubjectName、およびKeynameif適切）は、次のようにエンコードする必要があります。
* Consider the string as consisting of Unicode characters. * Escape occurrences of the following special characters by prefixing it with the "\" character: a "#" character occurring at the beginning of the string or one of the characters ",", "+", """, "\", "<", ">" or ";" * Escape all occurrences of ASCII control characters (Unicode range \x00 - \x 1f) by replacing them with "\" followed by a two digit hex number showing its Unicode number. * Escape any trailing white space by replacing "\ " with "\20". * Since a XML document logically consists of characters, not octets, the resulting Unicode string is finally encoded according to the character encoding used for producing the physical representation of the XML document.
* ユニコード文字で構成される文字列を考慮してください。*「\」文字を付けて次の特殊文字の脱出：文字列の先頭または文字の先頭で発生する「＃」文字」、 "、" "、" ""、 "\"、"<"、 ">"または ";" * ASCII制御文字のすべての出現（Unicode範囲\ x00- \ x 1f）を「\」に置き換え、その後にユニコード番号を示す2桁の六角形の数字をエスケープします。「\」を「\ 20」に置き換えて、任意の後続の空白。 * XMLドキュメントは論理的にオクテットではなく文字で構成されているため、結果のユニコード文字列は、XMLドキュメントの物理的表現を生成するために使用される文字エンコードに従って最終的にエンコードされます。
Schema Definition:
スキーマ定義：
<element name="X509Data" type="ds:X509DataType"/>
<complexType name="X509DataType">
<sequence maxOccurs="unbounded">
<choice>
<element name="X509IssuerSerial"
type="ds:X509IssuerSerialType"/>
<element name="X509SKI" type="base64Binary"/>
<element name="X509SubjectName" type="string"/>
<element name="X509Certificate" type="base64Binary"/>
<element name="X509CRL" type="base64Binary"/>
<any namespace="##other" processContents="lax"/>
</choice>
</sequence>
</complexType>
<complexType name="X509IssuerSerialType">
<sequence>
<element name="X509IssuerName" type="string"/>
<element name="X509SerialNumber" type="integer"/>
</sequence>
</complexType>
DTD:
<!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName
| X509Certificate | X509CRL)+ %X509.ANY;)>
<!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) >
<!ELEMENT X509IssuerName (#PCDATA) >
<!ELEMENT X509SubjectName (#PCDATA) >
<!ELEMENT X509SerialNumber (#PCDATA) >
<!ELEMENT X509SKI (#PCDATA) >
<!ELEMENT X509Certificate (#PCDATA) >
<!ELEMENT X509CRL (#PCDATA) >
<!-- Note, this DTD and schema permit X509Data to be empty; this is precluded by the text in KeyInfo Element (section 4.4) which states that at least one element from the dsig namespace should be present in the PGP, SPKI, and X509 structures. This is easily expressed for the other key types, but not for X509Data because of its rich structure. -->
<！ - 注、このDTDとスキーマはx509Dataを空にすることを許可します。これは、DSIGネームスペースの少なくとも1つの要素がPGP、SPKI、およびX509構造に存在する必要があることを示すKeyINFO要素（セクション4.4）のテキストによって排除されています。これは、他のキータイプで簡単に表現できますが、豊富な構造のためX509Dataでは簡単に表現できます。 - >
Identifier Type="http://www.w3.org/2000/09/xmldsig#PGPData" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ= "http://www.w3.org/2000/09/xmldsig#pgpdata"（これは、retirevalmethodまたは参照要素内で使用できます。
The PGPData element within KeyInfo is used to convey information related to PGP public key pairs and signatures on such keys. The PGPKeyID's value is a base64Binary sequence containing a standard PGP public key identifier as defined in [PGP, section 11.2]. The PGPKeyPacket contains a base64-encoded Key Material Packet as defined in [PGP, section 5.5]. These children element types can be complemented/extended by siblings from an external namespace within PGPData, or PGPData can be replaced all together with an alternative PGP XML structure as a child of KeyInfo. PGPData must contain one PGPKeyID and/or one PGPKeyPacket and 0 or more elements from an external namespace.
KeyInfo内のPGPDATA要素は、そのようなキーのPGP公開キーのペアと署名に関連する情報を伝えるために使用されます。PGPKEYIDの値は、[PGP、セクション11.2]で定義されている標準のPGP公開キー識別子を含むBase64Bynaryシーケンスです。PGPKEYPACKETには、[PGP、セクション5.5]で定義されているBase64エンコードされたキーマテリアルパケットが含まれています。これらの子供の要素タイプは、PGPDATA内の外部名空間から兄弟によって補完/拡張されるか、PGPDATAは、KeyInfoの子供としての代替PGP XML構造にまとめて置き換えることができます。PGPDATAには、1つのPGPKEYIDおよび/または1つのPGPKEYPACKET、および外部ネームスペースから0以上の要素を含める必要があります。
Schema Definition:
スキーマ定義：
<element name="PGPData" type="ds:PGPDataType"/>
<complexType name="PGPDataType">
<choice>
<sequence>
<element name="PGPKeyID" type="base64Binary"/>
<element name="PGPKeyPacket" type="base64Binary"
minOccurs="0"/>
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<sequence>
<element name="PGPKeyPacket" type="base64Binary"/>
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</choice>
</complexType>
DTD:
DTD：
<!ELEMENT PGPData ((PGPKeyID, PGPKeyPacket?) | (PGPKeyPacket)
%PGPData.ANY;) >
<!ELEMENT PGPKeyPacket (#PCDATA) >
<!ELEMENT PGPKeyID (#PCDATA) >
Identifier Type="http://www.w3.org/2000/09/xmldsig#SPKIData" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ= "http://www.w3.org/2000/09/xmldsig#spkidata"（これは、retirevalmethodまたは参照要素内で使用できます。
The SPKIData element within KeyInfo is used to convey information related to SPKI public key pairs, certificates and other SPKI data. SPKISexp is the base64 encoding of a SPKI canonical S-expression. SPKIData must have at least one SPKISexp; SPKISexp can be complemented/extended by siblings from an external namespace within SPKIData, or SPKIData can be entirely replaced with an alternative SPKI XML structure as a child of KeyInfo.
KeyInfo内のSpkidata要素は、SPKIの公開キーペア、証明書、その他のSPKIデータに関連する情報を伝えるために使用されます。spkisexpは、SPKI標準的なS発現のbase64エンコードです。spkidataには少なくとも1つのspkisexpが必要です。spkisexpは、spkidata内の外部名空間から兄弟によって補完/拡張できます。また、spkidataは、keyinfoの子供としての代替SPKI XML構造に完全に置き換えることができます。
Schema Definition:
スキーマ定義：
<element name="SPKIData" type="ds:SPKIDataType"/>
<complexType name="SPKIDataType">
<sequence maxOccurs="unbounded">
<element name="SPKISexp" type="base64Binary"/>
<any namespace="##other" processContents="lax" minOccurs="0"/>
</sequence>
</complexType>
DTD:
DTD：
<!ELEMENT SPKIData (SPKISexp %SPKIData.ANY;) >
<!ELEMENT SPKISexp (#PCDATA) >
Identifier Type="http://www.w3.org/2000/09/xmldsig#MgmtData" (this can be used within a RetrievalMethod or Reference element to identify the referent's type)
識別子タイプ= "http://www.w3.org/2000/09/xmldsig#mgmtdata"（これは、retirevalmethodまたは参照要素内で使用できます。
The MgmtData element within KeyInfo is a string value used to convey in-band key distribution or agreement data. For example, DH key exchange, RSA key encryption, etc. Use of this element is NOT RECOMMENDED. It provides a syntactic hook where in-band key distribution or agreement data can be placed. However, superior interoperable child elements of KeyInfo for the transmission of encrypted keys and for key agreement are being specified by the W3C XML Encryption Working Group and they should be used instead of MgmtData.
KeyInfo内のMGMTDATA要素は、帯域内のキーディストリビューションまたは契約データを伝達するために使用される文字列値です。たとえば、DHキーエクスチェンジ、RSAキー暗号化など。この要素の使用は推奨されません。インバンドの主要な配布または契約データを配置できる構文フックを提供します。ただし、暗号化されたキーの送信およびキー契約のためのKeyINFOの優れた相互運用可能な子要素は、W3C XML暗号化ワーキンググループによって指定されており、MGMTDATAの代わりに使用する必要があります。
Schema Definition:
スキーマ定義：
<element name="MgmtData" type="string"/>
DTD:
DTD：
<!ELEMENT MgmtData (#PCDATA)>
Identifier Type="http://www.w3.org/2000/09/xmldsig#Object" (this can be used within a Reference element to identify the referent's type)
識別子タイプ= "http://www.w3.org/2000/09/xmldsig#object"（これは参照要素内で使用して、参照者のタイプを識別できます）
Object is an optional element that may occur one or more times. When present, this element may contain any data. The Object element may include optional MIME type, ID, and encoding attributes.
オブジェクトは、1回以上発生する可能性のあるオプションの要素です。存在する場合、この要素にはデータが含まれている場合があります。オブジェクト要素には、オプションのMIMEタイプ、ID、およびエンコード属性が含まれる場合があります。
The Object's Encoding attributed may be used to provide a URI that identifies the method by which the object is encoded (e.g., a binary file).
オブジェクトのエンコード属性は、オブジェクトがエンコードされる方法（バイナリファイルなど）を識別するURIを提供するために使用できます。
The MimeType attribute is an optional attribute which describes the data within the Object (independent of its encoding). This is a string with values defined by [MIME]. For example, if the Object contains base64 encoded PNG, the Encoding may be specified as 'base64' and the MimeType as 'image/png'. This attribute is purely advisory; no validation of the MimeType information is required by this specification. Applications which require normative type and encoding information for signature validation should specify Transforms with well defined resulting types and/or encodings.
MIMETYPE属性は、オブジェクト内のデータを記述するオプションの属性です（エンコーディングとは無関係です）。これは、[mime]で定義された値を持つ文字列です。たとえば、オブジェクトにbase64エンコードされたPNGが含まれている場合、エンコードは「base64」として、「画像/png」としてmimetypeとして指定できます。この属性は純粋にアドバイザリーです。この仕様では、MIMETYPE情報の検証は必要ありません。署名検証のために規範的なタイプとエンコーディング情報を必要とするアプリケーションは、適切に定義された結果のタイプおよび/またはエンコーディングを備えた変換を指定する必要があります。
The Object's Id is commonly referenced from a Reference in SignedInfo, or Manifest. This element is typically used for enveloping signatures where the object being signed is to be included in the signature element. The digest is calculated over the entire Object element including start and end tags.
オブジェクトのIDは、一般にSignedInfoまたはマニフェストのリファレンスから参照されます。この要素は通常、署名されているオブジェクトが署名要素に含まれる署名の包囲に使用されます。ダイジェストは、開始タグとエンドタグを含むオブジェクト要素全体にわたって計算されます。
Note, if the application wishes to exclude the <Object> tags from the digest calculation, the Reference must identify the actual data object (easy for XML documents) or a transform must be used to remove the Object tags (likely where the data object is non-XML). Exclusion of the object tags may be desired for cases where one wants the signature to remain valid if the data object is moved from inside a signature to outside the signature (or vice versa), or where the content of the Object is an encoding of an original binary document and it is desired to extract and decode so as to sign the original bitwise representation.
注アプリケーションがDigest計算から<Object>タグを除外したい場合、参照は実際のデータオブジェクト（XMLドキュメントで簡単）を識別する必要があります。非XML）。オブジェクトタグの除外は、データオブジェクトが署名内から署名の外側（またはその逆）に移動された場合（またはその逆）、またはオブジェクトのコンテンツがのエンコードである場合に署名を有効なままにしたい場合に望まれる場合があります。元のバイナリドキュメントと、元のビットワイズ表現に署名するように抽出およびデコードすることが望まれます。
Schema Definition:
スキーマ定義：
<element name="Object" type="ds:ObjectType"/> <complexType name="ObjectType" mixed="true"> <sequence minOccurs="0" maxOccurs="unbounded"> <any namespace="##any" processContents="lax"/> </sequence> <attribute name="Id" type="ID" use="optional"/> <attribute name="MimeType" type="string" use="optional"/> <attribute name="Encoding" type="anyURI" use="optional"/> </complexType> DTD:
<要素name = "object" type = "ds：objecttype"/> <complexType name = "objectType" mixed = "true"> <sequence minoccurs = "0" maxoccurs = "unbounded"> <any namespace = "## any"ProcessContents =" lax "/> </sequence> <属性name =" id "type =" id "use =" optional "/> <属性name =" mimetype "type =" string "use =" optional "/>><属性name = "encoding" type = "anyuri" use = "optional"/> </complextype> dtd：
<!ELEMENT Object (#PCDATA|Signature|SignatureProperties|Manifest
%Object.ANY;)* >
<!ATTLIST Object
Id ID #IMPLIED
MimeType CDATA #IMPLIED
Encoding CDATA #IMPLIED >
This section describes the optional to implement Manifest and SignatureProperties elements and describes the handling of XML processing instructions and comments. With respect to the elements Manifest and SignatureProperties, this section specifies syntax and little behavior -- it is left to the application. These elements can appear anywhere the parent's content model permits; the Signature content model only permits them within Object.
このセクションでは、マニフェストおよび署名プロパティの要素を実装するオプションについて説明し、XML処理の指示とコメントの処理について説明します。要素がマニフェストと署名プロパティに関して、このセクションは構文と小さな動作を指定します - アプリケーションに任されています。これらの要素は、親のコンテンツモデルが許す場所に表示できます。署名コンテンツモデルは、オブジェクト内でのみ許可します。
Identifier Type="http://www.w3.org/2000/09/xmldsig#Manifest" (this can be used within a Reference element to identify the referent's type)
識別子タイプ= "http://www.w3.org/2000/09/xmldsig#manifest"（これは参照要素内で使用して、参照者のタイプを識別できます）
The Manifest element provides a list of References. The difference from the list in SignedInfo is that it is application defined which, if any, of the digests are actually checked against the objects referenced and what to do if the object is inaccessible or the digest compare fails. If a Manifest is pointed to from SignedInfo, the digest over the Manifest itself will be checked by the core signature validation behavior. The digests within such a Manifest are checked at the application's discretion. If a Manifest is referenced from another Manifest, even the overall digest of this two level deep Manifest might not be checked.
マニフェスト要素は、参照のリストを提供します。SignedInfoのリストとの違いは、それが定義されたアプリケーションであることです。これは、もしあれば、Digestが実際に参照されたオブジェクトに対してチェックされ、オブジェクトがアクセスできないか、ダイジェストの比較が失敗した場合に何をするかです。マニフェストがSignedinfoから指されている場合、マニフェストのダイジェスト自体がコア署名検証動作によってチェックされます。このようなマニフェスト内のダイジェストは、アプリケーションの裁量でチェックされます。マニフェストが別のマニフェストから参照されている場合、この2つのレベルの深いマニフェストの全体的なダイジェストでさえチェックされない可能性があります。
Schema Definition:
スキーマ定義：
<element name="Manifest" type="ds:ManifestType"/> <complexType name="ManifestType"> <sequence> <element ref="ds:Reference" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType> DTD:
<要素name = "manifest" type = "ds：manifesttype"/> <complextype name = "manifesttype"> <sequence> <要素ref = "ds：参照" maxoccurs = "unbounded"/> </sequence> <属性名name= "id" type = "id" use = "optional"/> </complexType> dtd：
<!ELEMENT Manifest (Reference+) >
<!ATTLIST Manifest
Id ID #IMPLIED >
Identifier Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties" (this can be used within a Reference element to identify the referent's type)
識別子タイプ= "http://www.w3.org/2000/09/xmldsig#signatureproperties"（これは参照要素内で使用して、指示対象のタイプを識別できます）
Additional information items concerning the generation of the signature(s) can be placed in a SignatureProperty element (i.e., date/time stamp or the serial number of cryptographic hardware used in signature generation).
署名の生成に関する追加情報項目は、署名プロパティ要素（つまり、日付/タイムスタンプまたは署名生成で使用される暗号化ハードウェアのシリアル数）に配置できます。
Schema Definition:
スキーマ定義：
<element name="SignatureProperties"
type="ds:SignaturePropertiesType"/>
<complexType name="SignaturePropertiesType">
<sequence>
<element ref="ds:SignatureProperty" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
<element name="SignatureProperty" type="ds:SignaturePropertyType"/> <complexType name="SignaturePropertyType" mixed="true"> <choice maxOccurs="unbounded"> <any namespace="##other" processContents="lax"/> <!-- (1,1) elements from (1,unbounded) namespaces --> </choice> <attribute name="Target" type="anyURI" use="required"/> <attribute name="Id" type="ID" use="optional"/> </complexType> DTD:
<要素name = "SignatureProperty" Type = "ds：SignaturePropertyType"/> <complexType name = "signaturePropertyType" Mixed = "true"> <choice maxoccurs = "unbounded"> <any namespace = "## other" processcontents = ""/> <！ - （1,1）（1、unbounded）namespacesからの要素 - > </choice> <属性name ="ターゲット "type =" anyuri "use ="必須 "/> <属性name = ="id" type = "id" use = "optional"/> </complexType> dtd：
<!ELEMENT SignatureProperties (SignatureProperty+) >
<!ATTLIST SignatureProperties
Id ID #IMPLIED >
<!ELEMENT SignatureProperty (#PCDATA %SignatureProperty.ANY;)* >
<!ATTLIST SignatureProperty
Target CDATA #REQUIRED
Id ID #IMPLIED >
No XML processing instructions (PIs) are used by this specification.
この仕様では、XML処理命令（PI）は使用されません。
Note that PIs placed inside SignedInfo by an application will be signed unless the CanonicalizationMethod algorithm discards them. (This is true for any signed XML content.) All of the CanonicalizationMethods identified within this specification retain PIs. When a PI is part of content that is signed (e.g., within SignedInfo or referenced XML documents) any change to the PI will obviously result in a signature failure.
CanonicalizationMethodアルゴリズムがそれらを破棄しない限り、アプリケーションによってSignedInfo内に配置されたPIは署名されることに注意してください。（これは、署名されたXMLコンテンツに当てはまります。）この仕様内で特定されたすべてのCanonicalizationMethodsは、PIを保持します。PIが署名されているコンテンツの一部である場合（例：SignedInfoまたは参照XMLドキュメント内）、PIへの変更は明らかに署名障害になります。
XML comments are not used by this specification.
XMLコメントは、この仕様では使用されません。
Note that unless CanonicalizationMethod removes comments within SignedInfo or any other referenced XML (which [XML-C14N] does), they will be signed. Consequently, if they are retained, a change to the comment will cause a signature failure. Similarly, the XML signature over any XML data will be sensitive to comment changes unless a comment-ignoring canonicalization/transform method, such as the Canonical XML [XML-C14N], is specified.
CanonicalizationMethodがSignedInfoまたはその他の参照されたXML（[XML-C14N]が行う）内でコメントを削除しない限り、署名されることに注意してください。その結果、それらが保持されている場合、コメントを変更すると署名の失敗が発生します。同様に、XMLデータ上のXML署名は、標準XML [XML-C14N]などのコメントに無知な標準化/変換法が指定されていない限り、コメントの変更に敏感です。
This section identifies algorithms used with the XML digital signature specification. Entries contain the identifier to be used in Signature elements, a reference to the formal specification, and definitions, where applicable, for the representation of keys and the results of cryptographic operations.
このセクションでは、XMLデジタル署名仕様で使用されるアルゴリズムを識別します。エントリには、署名要素で使用される識別子、正式な仕様への参照、および該当する場合、キーの表現と暗号化操作の結果のために定義が含まれています。
Algorithms are identified by URIs that appear as an attribute to the element that identifies the algorithms' role (DigestMethod, Transform, SignatureMethod, or CanonicalizationMethod). All algorithms used herein take parameters but in many cases the parameters are implicit. For example, a SignatureMethod is implicitly given two parameters: the keying info and the output of CanonicalizationMethod. Explicit additional parameters to an algorithm appear as content elements within the algorithm role element. Such parameter elements have a descriptive element name, which is frequently algorithm specific, and MUST be in the XML Signature namespace or an algorithm specific namespace.
アルゴリズムは、アルゴリズムの役割（DigestMethod、Transform、SignatureMethod、またはCanonicalizationMethod）を識別する要素の属性として表示されるURIによって識別されます。ここで使用されるすべてのアルゴリズムはパラメーターを取りますが、多くの場合、パラメーターは暗黙的です。たとえば、SignatureMethodには、キーイング情報とCanonicalizationMethodの出力という2つのパラメーターが暗黙的に与えられます。アルゴリズムへの明示的な追加パラメーターは、アルゴリズムの役割要素内のコンテンツ要素として表示されます。このようなパラメーター要素には、記述要素名があり、これは頻繁にアルゴリズム固有であり、XML署名名空間またはアルゴリズム固有の名前空間にある必要があります。
This specification defines a set of algorithms, their URIs, and requirements for implementation. Requirements are specified over implementation, not over requirements for signature use. Furthermore, the mechanism is extensible; alternative algorithms may be used by signature applications.
この仕様は、アルゴリズムのセット、そのURI、および実装の要件を定義します。要件は、署名使用の要件を超えてではなく、実装よりも指定されています。さらに、メカニズムは拡張可能です。代替アルゴリズムは、署名アプリケーションで使用できます。
Digest 1. Required SHA1 http://www.w3.org/2000/09/xmldsig#sha1 Encoding 1. Required base64 http://www.w3.org/2000/09/xmldsig#base64 MAC 1. Required HMAC-SHA1 http://www.w3.org/2000/09/xmldsig#hmac-sha1 Signature 1. Required DSAwithSHA1 (DSS) http://www.w3.org/2000/09/xmldsig#dsa-sha1 2. Recommended RSAwithSHA1 http://www.w3.org/2000/09/xmldsig#rsa-sha1 Canonicalization 1. Required Canonical XML (omits comments) http://www.w3.org/TR/2001/REC-xml-c14n-20010315 2. Recommended Canonical XML with Comments http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments Transform 1. Optional XSLT http://www.w3.org/TR/1999/REC-xslt-19991116 2. Recommended XPath http://www.w3.org/TR/1999/REC-xpath-19991116 3. Required Enveloped Signature* http://www.w3.org/2000/09/xmldsig#enveloped-signature
消化1.必要なSHA1 http://www.w3.org/2000/09/xmldsig#sha1エンコード1.Sha1 http://www.w3.org/2000/09/xmldsig#hmac-sha1署名1.必須dsawithsha1（dss）http://www.w3.org/2000/09/xmldsig#dsa-sha1 2.Rsawithsha1 http://www.w3.org/2000/09/xmldsig#rsa-sha1 Canonicalization 1.必要な標準XML（省略コメント）http://www.w3.org/tr/2001/rec-xml-c1n-4n-20010315 2.コメント付きの推奨標準XML http://www.w3.org/tr/2001/rec-xml-c14n-20010315#withcomments変換1.オプションのxslt http://ww.w3.org/tr/1999/Rec-XSLT-19991116 2.推奨Xpath http://www.w3.org/tr/1999/rec-xpath-1999116 3.必要な封筒* http://www.w3.org/2000/09/xmldsig#包み込まれた署名
* The Enveloped Signature transform removes the Signature element from the calculation of the signature when the signature is within the content that it is being signed. This MAY be implemented via the RECOMMENDED XPath specification specified in 6.6.4: Enveloped Signature Transform; it MUST have the same effect as that specified by the XPath Transform.
* 包括的な署名変換は、署名が署名されているコンテンツ内にある場合、署名の計算から署名要素を削除します。これは、6.6.4で指定された推奨されるXpath仕様を介して実装できます。XPath変換によって指定された効果と同じ効果が必要です。
Only one digest algorithm is defined herein. However, it is expected that one or more additional strong digest algorithms will be developed in connection with the US Advanced Encryption Standard effort. Use of MD5 [MD5] is NOT RECOMMENDED because recent advances in cryptanalysis have cast doubt on its strength.
ここでは、1つのダイジェストアルゴリズムのみが定義されています。ただし、米国の高度な暗号化標準的な取り組みに関連して、1つまたは複数の追加の強力なダイジェストアルゴリズムが開発されることが予想されます。最近の暗号化の進歩がその強さに疑問を投げかけているため、MD5 [MD5]の使用は推奨されません。
Identifier: http://www.w3.org/2000/09/xmldsig#sha1
識別子：http：//www.w3.org/2000/09/xmldsig#sha1
The SHA-1 algorithm [SHA-1] takes no explicit parameters. An example of an SHA-1 DigestAlg element is:
SHA-1アルゴリズム[SHA-1]は、明示的なパラメーターを取得しません。SHA-1 Digestalg Elementの例は次のとおりです。
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
A SHA-1 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream. For example, the DigestValue element for the message digest:
SHA-1ダイジェストは160ビット文字列です。DigestValue要素の内容は、20オクテットのOctetストリームと見なされるこのビット文字列のbase64エンコードでなければなりません。たとえば、メッセージダイジェストのDigestValue要素：
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
from Appendix A of the SHA-1 standard would be:
SHA-1標準の付録Aから：
<DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
MAC algorithms take two implicit parameters, their keying material determined from KeyInfo and the octet stream output by CanonicalizationMethod. MACs and signature algorithms are syntactically identical but a MAC implies a shared secret key.
MACアルゴリズムは、KeyInfoから決定されたキーイング材料とCanonicalizationMethodによるオクテットストリーム出力から決定された2つの暗黙的なパラメーターを取ります。Macと署名アルゴリズムは構文的に同一ですが、Macは共有された秘密キーを意味します。
Identifier: http://www.w3.org/2000/09/xmldsig#hmac-sha1
識別子：http：//www.w3.org/2000/09/xmldsig#hmac-sha1
The HMAC algorithm (RFC2104 [HMAC]) 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 SignatureMethod element:
HMACアルゴリズム（RFC2104 [HMAC]）は、ビットの切り捨ての長さをパラメーターとして取得します。パラメーターが指定されていない場合、ハッシュのすべてのビットが出力されます。HMAC SignatureMethod要素の例：
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1">
<HMACOutputLength>128</HMACOutputLength>
</SignatureMethod>
The output of the HMAC algorithm is ultimately the output (possibly truncated) of the chosen digest algorithm. This value shall be base64 encoded in the same straightforward fashion as the output of the digest algorithms. Example: the SignatureValue element for the HMAC-SHA1 digest
HMACアルゴリズムの出力は、最終的に選択したダイジェストアルゴリズムの出力（おそらく切り捨てられた）です。この値は、Digestアルゴリズムの出力と同じ簡単な方法でベース64でエンコードされます。例：HMAC-SHA1ダイジェストの署名バリュー要素
9294727A 3638BB1C 13F48EF8 158BFC9D
9294727a 3638bb1c 13f48ef8 158bfc9d
from the test vectors in [HMAC] would be
[hmac]のテストベクトルから
<SignatureValue>kpRyejY4uxwT9I74FYv8nQ==</SignatureValue>
Schema Definition:
スキーマ定義：
<simpleType name="HMACOutputLengthType">
<restriction base="integer"/>
</simpleType>
DTD:
DTD：
<!ELEMENT HMACOutputLength (#PCDATA)>
Signature algorithms take two implicit parameters, their keying material determined from KeyInfo and the octet stream output by CanonicalizationMethod. Signature and MAC algorithms are syntactically identical but a signature implies public key cryptography.
署名アルゴリズムは、KeyINFOから決定されたキーイング材料とCanOnicalizationMethodによって決定されたキーイング材料の2つの暗黙的なパラメーターを取ります。署名とMacのアルゴリズムは構文的に同一ですが、署名は公開キーの暗号化を意味します。
Identifier: http://www.w3.org/2000/09/xmldsig#dsa-sha1
識別子：http：//www.w3.org/2000/09/xmldsig#dsa-sha1
The DSA algorithm [DSS] takes no explicit parameters. An example of a DSA SignatureMethod element is:
DSAアルゴリズム[DSS]は、明示的なパラメーターを取得しません。DSA SignatureMethod要素の例は次のとおりです。
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
The output of the DSA 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. Integer to octet-stream conversion must be done according to the I2OSP operation defined in the RFC 2437 [PKCS1] specification with a l parameter equal to 20. For example, the SignatureValue element for a DSA signature (r, s) with values specified in hexadecimal:
DSAアルゴリズムの出力は、通常ペア（r、s）で言及される整数のペアで構成されています。署名値は、2つのオクテットストリームの連結のベース64エンコードで構成されています。これは、その順序での値rとsのオクテットエンコードからそれぞれ生じるものです。オクテットストリームへの変換への整数は、20に等しいLパラメーターを使用してRFC 2437 [PKCS1]仕様で定義されたI2OSP操作に従って行う必要があります。：
r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0 s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8
R = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0 S = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8C8C88C8C8
from the example in Appendix 5 of the DSS standard would be
DSS標準の付録5の例から
<SignatureValue>
i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==
</SignatureValue>
Identifier: http://www.w3.org/2000/09/xmldsig#rsa-sha1
識別子：http：//www.w3.org/2000/09/xmldsig#rsa-sha1
The expression "RSA algorithm" as used in this document refers to the RSASSA-PKCS1-v1_5 algorithm described in RFC 2437 [PKCS1]. The RSA algorithm takes no explicit parameters. An example of an RSA SignatureMethod element is:
このドキュメントで使用されている「RSAアルゴリズム」という式は、RFC 2437 [PKCS1]で説明されているRSASSA-PKCS1-V1_5アルゴリズムを指します。RSAアルゴリズムは明示的なパラメーターを取得しません。RSA SignatureMethod要素の例は次のとおりです。
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
The SignatureValue content for an RSA signature is the base64 [MIME] encoding of the octet string computed as per RFC 2437 [PKCS1, section 8.1.1: Signature generation for the RSASSA-PKCS1-v1_5 signature scheme]. As specified in the EMSA-PKCS1-V1_5-ENCODE function RFC 2437 [PKCS1, 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署名のSignatureValueコンテンツは、RFC 2437 [PKCS1、セクション8.1.1：RSASSA-PKCS1-V1_5署名スキームの署名生成]に従って計算されたOctet StringのBase64 [MIME]エンコードです。EMSA-PKCS1-V1_5-ENCODE関数RFC 2437 [PKCS1、セクション9.2.1]で指定されているように、署名関数への値入力には、ハッシュ関数の事前に設定されたアルゴリズムオブジェクト識別子が含まれている必要がありますが、ASNSの可用性を含める必要があります。.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 |プレフィックス|ハッシュ
where "|" is concatenation, "01", "FF", and "00" are fixed octets of the corresponding hexadecimal value, "hash" is the SHA1 digest of the data, and "prefix" is the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 [RFC 2437], that is,
ここで「|」「01」、「ff」、および「00」は、対応する六十分値の固定オクテットであり、「ハッシュ」はデータのSHA1ダイジェストであり、「プレフィックス」はASN.1 BER SHA1アルゴリズム指定のプレフィックスが必要なASN.1 BER SHA1アルゴリズム指定のプレフィックスです。PKCS1 [RFC 2437]で、つまり
hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
ヘックス30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14
This prefix is included to make it easier to use standard cryptographic libraries. The FF octet MUST be repeated the maximum number of times such that the value of the quantity being CRYPTed is one octet shorter than the RSA modulus.
このプレフィックスは、標準の暗号化ライブラリを使いやすくするために含まれています。FFオクテットは、登く量の値がRSAモジュラスよりも短い1オクテットであるように、最大回数を繰り返す必要があります。
The resulting base64 [MIME] string is the value of the child text node of the SignatureValue element, e.g.,
結果のbase64 [mime]文字列は、署名数値要素の子テキストノードの値です。
<SignatureValue>
IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639
In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
</SignatureValue>
If canonicalization is performed over octets, the canonicalization algorithms take two implicit parameters: the content and its charset. The charset is derived according to the rules of the transport protocols and media types (e.g., RFC2376 [XML-MT] defines the media types for XML). This information is necessary to correctly sign and verify documents and often requires careful server side configuration.
標準化がオクテットを介して実行される場合、標準化アルゴリズムは2つの暗黙的なパラメーターを取ります：コンテンツとその炭化。charsetは、輸送プロトコルとメディアタイプのルールに従って導出されます（例：RFC2376 [XML-MT]は、XMLのメディアタイプを定義します）。この情報は、ドキュメントを正しく署名および検証するために必要であり、多くの場合、サーバー側の慎重な構成が必要です。
Various canonicalization algorithms require conversion to [UTF-8]. The two algorithms below understand at least [UTF-8] and [UTF-16] as input encodings. We RECOMMEND that externally specified algorithms do the same. Knowledge of other encodings is OPTIONAL.
さまざまな標準化アルゴリズムが[UTF-8]への変換が必要です。以下の2つのアルゴリズムは、少なくとも[UTF-8]および[UTF-16]を入力エンコーディングとして理解しています。外部で指定されたアルゴリズムが同じことをすることをお勧めします。他のエンコーディングの知識はオプションです。
Various canonicalization algorithms transcode from a non-Unicode encoding to Unicode. The two algorithms below perform text normalization during transcoding [NFC, NFC-Corrigendum]. We RECOMMEND that externally specified canonicalization algorithms do the same. (Note, there can be ambiguities in converting existing charsets to Unicode, for an example see the XML Japanese Profile [XML-Japanese] Note.)
さまざまな標準化アルゴリズムは、非ユニコードエンコードからUnicodeに変換されます。以下の2つのアルゴリズムは、トランスコーディング中にテキスト正規化を実行します[NFC、NFC-Corrigendum]。外部で指定された標準化アルゴリズムが同じことを行うことをお勧めします。（既存の充電器をUnicodeに変換することにはあいまいなことがあります。たとえば、XML日本のプロファイル[XML-Japanese]注を参照してください。）
Identifier for REQUIRED Canonical XML (omits comments): http://www.w3.org/TR/2001/REC-xml-c14n-20010315
必要な正規XMLの識別子（コメントを省略）：http：//www.w3.org/tr/2001/rec-xml-c14n-20010315
Identifier for Canonical XML with Comments: http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
コメント付き標準XMLの識別子：http：//www.w3.org/tr/2001/rec-xml-c14n-20010315#withcomments
An example of an XML canonicalization element is:
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
The normative specification of Canonical XML is [XML-C14N]. The algorithm is capable of taking as input either an octet stream or an XPath node-set (or sufficiently functional alternative). The algorithm produces an octet stream as output. Canonical XML is easily parameterized (via an additional URI) to omit or retain comments.
標準的なXMLの規範的仕様は[XML-C14N]です。アルゴリズムは、オクテットストリームまたはXPathノードセット（または十分に機能的な代替）のいずれかを入力として取得できます。アルゴリズムは、出力としてオクテットストリームを生成します。標準的なXMLは、コメントを省略または保持するために（追加のURIを介して）簡単にパラメーター化されます。
A Transform algorithm has a single implicit parameter: an octet stream from the Reference or the output of an earlier Transform.
変換アルゴリズムには、単一の暗黙的なパラメーターがあります。参照からのオクテットストリームまたは以前の変換の出力です。
Application developers are strongly encouraged to support all transforms listed in this section as RECOMMENDED unless the application environment has resource constraints that would make such support impractical. Compliance with this recommendation will maximize application interoperability and libraries should be available to enable support of these transforms in applications without extensive development.
アプリケーション開発者は、アプリケーション環境にそのようなサポートが非現実的になるリソースの制約がない限り、このセクションにリストされているすべての変換を推奨するようにサポートすることを強くお勧めします。この推奨事項へのコンプライアンスは、アプリケーションの相互運用性を最大化し、広範な開発なしでアプリケーションでこれらの変換のサポートを可能にするためにライブラリを利用できるようにする必要があります。
Any canonicalization algorithm that can be used for CanonicalizationMethod (such as those in Canonicalization Algorithms (section 6.5)) can be used as a Transform.
CanonicalizationMethod（Canonicalization Algorithms（セクション6.5）など）に使用できる標準化アルゴリズムは、変換として使用できます。
Identifiers: http://www.w3.org/2000/09/xmldsig#base64
識別子：http：//www.w3.org/2000/09/xmldsig#base64
The normative specification for base64 decoding transforms is [MIME]. The base64 Transform element has no content. The input is decoded by the algorithms. This transform is useful if an application needs to sign the raw data associated with the encoded content of an element.
base64デコード変換の規範的仕様は[mime]です。base64変換要素にはコンテンツがありません。入力はアルゴリズムによってデコードされます。この変換は、アプリケーションが要素のエンコードされたコンテンツに関連付けられた生データに署名する必要がある場合に役立ちます。
This transform requires an octet stream for input. If an XPath node-set (or sufficiently functional alternative) is given as input, then it is converted to an octet stream by performing operations logically equivalent to 1) applying an XPath transform with expression self::text(), then 2) taking the string-value of the node-set. Thus, if an XML element is identified by a barename XPointer in the Reference URI, and its content consists solely of base64 encoded character data, then this transform automatically strips away the start and end tags of the identified element and any of its descendant elements as well as any descendant comments and processing instructions. The output of this transform is an octet stream.
この変換には、入力用のオクテットストリームが必要です。Xpathノードセット（または十分に機能的な代替）が入力として与えられている場合、1）XPath変換を式でself :: text（）、2）に適用することにより、Xpath変換を適用することにより、octetストリームに変換されます。ノードセットの文字列値。したがって、XML要素が参照URIのBarename XPointerによって識別され、そのコンテンツがBase64エンコードされた文字データのみで構成されている場合、この変換は、特定された要素とその子孫要素の開始タグとそのすべての末端のタグを自動的に取り除きます。同様に、子孫のコメントや処理手順。この変換の出力はオクテットストリームです。
Identifier: http://www.w3.org/TR/1999/REC-xpath-19991116
識別子：http：//www.w3.org/tr/1999/rec-xpath-19991116
The normative specification for XPath expression evaluation is [XPath]. The XPath expression to be evaluated appears as the character content of a transform parameter child element named XPath.
XPath発現評価の規範的仕様は[XPath]です。評価されるXpath式は、XPathという名前の変換パラメーター子要素の文字含有量として表示されます。
The input required by this transform is an XPath node-set. Note that if the actual input is an XPath node-set resulting from a null URI or barename XPointer dereference, then comment nodes will have been omitted. If the actual input is an octet stream, then the application MUST convert the octet stream to an XPath node-set suitable for use by Canonical XML with Comments. (A subsequent application of the REQUIRED Canonical XML algorithm would strip away these comments.) In other words, the input node-set should be equivalent to the one that would be created by the following process:
この変換で必要な入力は、XPathノードセットです。実際の入力がnull uriまたはbarename xpointerの規制否定に起因するxpathノードセットである場合、コメントノードは省略されていることに注意してください。実際の入力がOctetストリームの場合、アプリケーションは、コメント付きのCanonical XMLが使用するのに適したXPathノードセットにOctetストリームを変換する必要があります。（必要な正規XMLアルゴリズムの後続のアプリケーションは、これらのコメントを取り除きます。）言い換えれば、入力ノードセットは、次のプロセスで作成されるものと同等でなければなりません。
1. Initialize an XPath evaluation context by setting the initial node equal to the input XML document's root node, and set the context position and size to 1. 2. Evaluate the XPath expression (//. | //@* | //namespace::*)
1. 入力XMLドキュメントのルートノードに等しい初期ノードを設定してXPath評価コンテキストを初期化し、コンテキストの位置とサイズを1に設定します。*）
The evaluation of this expression includes all of the document's nodes (including comments) in the node-set representing the octet stream.
この式の評価には、オクテットストリームを表すノードセットのすべてのドキュメントのノード（コメントを含む）が含まれます。
The transform output is also an XPath node-set. The XPath expression appearing in the XPath parameter is evaluated once for each node in the input node-set. The result is converted to a boolean. If the boolean is true, then the node is included in the output node-set. If the boolean is false, then the node is omitted from the output node-set.
変換出力もXPathノードセットです。XPathパラメーターに表示されるXPath式は、入力ノードセットの各ノードについて1回評価されます。結果はブールに変換されます。ブールが真の場合、ノードは出力ノードセットに含まれています。ブールが偽の場合、出力ノードセットからノードが省略されます。
Note: Even if the input node-set has had comments removed, the comment nodes still exist in the underlying parse tree and can separate text nodes. For example, the markup <e>Hello, <!-- comment -->world!</e> contains two text nodes. Therefore, the expression self::text()[string()="Hello, world!"] would fail. Should this problem arise in the application, it can be solved by either canonicalizing the document before the XPath transform to physically remove the comments or by matching the node based on the parent element's string value (e.g., by using the expression self::text()[string(parent::e)="Hello, world!"]).
注：入力ノードセットにコメントが削除されている場合でも、コメントノードは依然として基礎となる解析ツリーに存在し、テキストノードを分離できます。たとえば、マークアップ<e>こんにちは、<！ - コメント - > world！</e>には2つのテキストノードが含まれています。したがって、式self :: text（）[string（）= "hello、world！"]は失敗します。この問題がアプリケーションで発生した場合、XPathがコメントを物理的に削除する前にドキュメントを正規化するか、親要素の文字列値に基づいてノードを一致させることによって解決できます（例：式＃：テキスト（例：）[string（parent :: e）= "hello、world！"]）。
The primary purpose of this transform is to ensure that only specifically defined changes to the input XML document are permitted after the signature is affixed. This is done by omitting precisely those nodes that are allowed to change once the signature is affixed, and including all other input nodes in the output. It is the responsibility of the XPath expression author to include all nodes whose change could affect the interpretation of the transform output in the application context.
この変換の主な目的は、署名が貼られた後に入力XMLドキュメントの特異的に定義された変更のみが許可されるようにすることです。これは、署名が貼られた後に変更が許可されているノードを正確に省略し、出力に他のすべての入力ノードを含めることによって行われます。XPath式の著者の責任は、アプリケーションのコンテキストでの変換出力の解釈に変化に影響を与える可能性のあるすべてのノードを含めることです。
An important scenario would be a document requiring two enveloped signatures. Each signature must omit itself from its own digest calculations, but it is also necessary to exclude the second signature element from the digest calculations of the first signature so that adding the second signature does not break the first signature.
重要なシナリオは、2つの包囲された署名を必要とするドキュメントです。各署名は独自のダイジェスト計算から省略する必要がありますが、2番目の署名を追加しても最初の署名が壊れないように、最初の署名のダイジェスト計算から2番目の署名要素を除外する必要もあります。
The XPath transform establishes the following evaluation context for each node of the input node-set:
XPath変換は、入力ノードセットの各ノードの次の評価コンテキストを確立します。
* A context node equal to a node of the input node-set. * A context position, initialized to 1. * A context size, initialized to 1. * A library of functions equal to the function set defined in [XPath] plus a function named here. * A set of variable bindings. No means for initializing these is defined. Thus, the set of variable bindings used when evaluating the XPath expression is empty, and use of a variable reference in the XPath expression results in an error. * The set of namespace declarations in scope for the XPath expression.
* 入力ノードセットのノードに等しいコンテキストノード。* 1に初期化されたコンテキスト位置。 *コンテキストサイズ。*可変バインディングのセット。これらを初期化するための手段は定義されていません。したがって、XPath式を評価するときに使用される可変バインディングのセットは空であり、XPath式で変数参照を使用するとエラーが発生します。* Xpath式の範囲の名前空間宣言のセット。
As a result of the context node setting, the XPath expressions appearing in this transform will be quite similar to those used in [XSLT], except that the size and position are always 1 to reflect the fact that the transform is automatically visiting every node (in XSLT, one recursively calls the command apply-templates to visit the nodes of the input tree).
コンテキストノード設定の結果として、この変換に表示されるXPath式は[XSLT]で使用されているXPath式と非常に似ていますが、変換がすべてのノードに自動的に訪問しているという事実を反映するサイズと位置が常に1であることを除きます（XSLTでは、入力ツリーのノードにアクセスするためにコマンドを再帰的に呼び出します。
The function here() is defined as follows:
ここの関数（）は次のように定義されます。
Function: node-set here() The here function returns a node-set containing the attribute or processing instruction node or the parent element of the text node that directly bears the XPath expression. This expression results in an error if the containing XPath expression does not appear in the same XML document against which the XPath expression is being evaluated.
関数：ここでノードセット（）here関数は、xpath式を直接担うテキストノードの属性または処理命令ノードを含むノードセットを返します。この式は、XPath式が評価されているのと同じXMLドキュメントに含まれていないXPATH式が表示されない場合、エラーが発生します。
As an example, consider creating an enveloped signature (a Signature element that is a descendant of an element being signed). Although the signed content should not be changed after signing, the elements within the Signature element are changing (e.g., the digest value must be put inside the DigestValue and the SignatureValue must be subsequently calculated). One way to prevent these changes from invalidating the digest value in DigestValue is to add an XPath Transform that omits all Signature elements and their descendants. For example,
例として、包み込まれた署名（署名されている要素の子孫である署名要素）を作成することを検討してください。署名後に署名されたコンテンツを変更してはなりませんが、署名要素内の要素は変更されています（たとえば、ダイジェスト値をダイジェストバリュー内に配置する必要があり、その後署名値を計算する必要があります）。これらの変更がダイジェスト値のダイジェスト値を無効にするのを防ぐ1つの方法は、すべての署名要素とその子孫を省略するXPath変換を追加することです。例えば、
<Document>
...
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
<Reference URI="">
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
<XPath xmlns:dsig="&dsig;">
not(ancestor-or-self::dsig:Signature)
</XPath>
</Transform>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue></DigestValue>
</Reference>
</SignedInfo>
<SignatureValue></SignatureValue>
</Signature>
...
</Document>
Due to the null Reference URI in this example, the XPath transform input node-set contains all nodes in the entire parse tree starting at the root node (except the comment nodes). For each node in this node-set, the node is included in the output node-set except if the node or one of its ancestors, has a tag of Signature that is in the namespace given by the replacement text for the entity &dsig;.
この例のNULL参照URIのため、XPath変換入力ノードセットには、ルートノード（コメントノードを除く）から始まる解析ツリー全体のすべてのノードが含まれます。このノードセットの各ノードについては、ノードが祖先またはその祖先のいずれかを除き、出力ノードセットにノードが含まれており、エンティティの交換テキストで与えられた名前空間にある署名のタグがあります。
A more elegant solution uses the here function to omit only the Signature containing the XPath Transform, thus allowing enveloped signatures to sign other signatures. In the example above, use the XPath element:
よりエレガントなソリューションでは、here関数を使用してXpath変換を含む署名のみを省略し、包み込まれた署名が他の署名に署名できるようにします。上記の例では、XPath要素を使用します。
<XPath xmlns:dsig="&dsig;">
count(ancestor-or-self::dsig:Signature |
here()/ancestor::dsig:Signature[1]) >
count(ancestor-or-self::dsig:Signature)</XPath>
Since the XPath equality operator converts node sets to string values before comparison, we must instead use the XPath union operator (|). For each node of the document, the predicate expression is true if and only if the node-set containing the node and its Signature element ancestors does not include the enveloped Signature element containing the XPath expression (the union does not produce a larger set if the enveloped Signature element is in the node-set given by ancestor-or-self::Signature).
Xpath Equalityオペレーターは、比較前にノードセットを文字列値に変換するため、代わりにXpath Unionオペレーター（|）を使用する必要があります。ドキュメントの各ノードについて、Nodeを含むノードセットとその署名要素の先祖には、XPath式を含む包括的な署名要素が含まれていない場合にのみ、述語式は真です（組合は、より大きなセットを生成しません。包み込まれた署名要素は、祖先またはself :: signatureによって与えられるノードセットにあります）。
Identifier: http://www.w3.org/2000/09/xmldsig#enveloped-signature
識別子：http：//www.w3.org/2000/09/xmldsig#enveloped-signature
An enveloped signature transform T removes the whole Signature element containing T from the digest calculation of the Reference element containing T. The entire string of characters used by an XML processor to match the Signature with the XML production element is removed. The output of the transform is equivalent to the output that would result from replacing T with an XPath transform containing the following XPath parameter element:
封筒の署名変換Tは、Tを含む参照要素のダイジェスト計算からTを含む署名要素全体を削除します。XMLプロセッサで使用される文字列全体の署名とXML生産要素を一致させるために使用される文字列全体が削除されます。変換の出力は、Tを次のXPathパラメーター要素を含むXPath変換に置き換えることから生じる出力に相当します。
<XPath xmlns:dsig="&dsig;">
count(ancestor-or-self::dsig:Signature |
here()/ancestor::dsig:Signature[1]) >
count(ancestor-or-self::dsig:Signature)</XPath>
The input and output requirements of this transform are identical to those of the XPath transform, but may only be applied to a node-set from its parent XML document. Note that it is not necessary to use an XPath expression evaluator to create this transform. However, this transform MUST produce output in exactly the same manner as the XPath transform parameterized by the XPath expression above.
この変換の入力要件と出力要件は、XPath変換の要件と同一ですが、親XMLドキュメントのノードセットにのみ適用できます。XPath Expression Evaluatorを使用してこの変換を作成する必要はないことに注意してください。ただし、この変換は、上記のXPath式によってパラメーター化されたXPath変換とまったく同じ方法で出力を生成する必要があります。
Identifier: http://www.w3.org/TR/1999/REC-xslt-19991116
識別子：http：//www.w3.org/tr/1999/rec-xslt-19991116
The normative specification for XSL Transformations is [XSLT]. Specification of a namespace-qualified stylesheet element, which MUST be the sole child of the Transform element, indicates that the specified style sheet should be used. Whether this instantiates in-line processing of local XSLT declaration within the resource is determined by the XSLT processing model; the ordered application of multiple stylesheet may require multiple Transforms. No special provision is made for the identification of a remote stylesheet at a given URI because it can be communicated via an xsl:include or xsl:import within the stylesheet child of the Transform.
XSL変換の規範的仕様は[XSLT]です。変換要素の唯一の子でなければならない名前空間認定のスタイルシート要素の仕様は、指定されたスタイルシートを使用する必要があることを示しています。これがリソース内のローカルXSLT宣言のインライン処理をインスタンス化するかどうかは、XSLT処理モデルによって決定されます。複数のスタイルシートの順序付けられたアプリケーションには、複数の変換が必要になる場合があります。XSLを介して通信できるため、特定のURIでのリモートスタイルシートを識別するための特別な規定はありません。
This transform requires an octet stream as input. If the actual input is an XPath node-set, then the signature application should attempt to convert it to octets (apply Canonical XML]) as described in the Reference Processing Model (section 4.3.3.2).
この変換には、入力としてのオクテットストリームが必要です。実際の入力がXPathノードセットの場合、署名アプリケーションは、参照処理モデル（セクション4.3.3.2）で説明されているように、オクテット（適用XML）に変換しようとする必要があります。
The output of this transform is an octet stream. The processing rules for the XSL style sheet or transform element are stated in the XSLT specification [XSLT]. We RECOMMEND that XSLT transform authors use an output method of xml for XML and HTML. As XSLT implementations do not produce consistent serializations of their output, we further RECOMMEND inserting a transform after the XSLT transform to canonicalize the output. These steps will help to ensure interoperability of the resulting signatures among applications that support the XSLT transform. Note that if the output is actually HTML, then the result of these steps is logically equivalent [XHTML].
この変換の出力はオクテットストリームです。XSLスタイルシートまたは変換要素の処理ルールは、XSLT仕様[XSLT]に記載されています。XSLT変換著者は、XMLおよびHTMLにXMLの出力方法を使用することをお勧めします。XSLTの実装は、その出力の一貫したシリアル化を生成しないため、XSLT変換後に出力を正規化するために変換を挿入することをお勧めします。これらの手順は、XSLT変換をサポートするアプリケーション間の結果の署名の相互運用性を確保するのに役立ちます。出力が実際にHTMLの場合、これらのステップの結果は論理的に等しい[XHTML]であることに注意してください。
Digital signatures only work if the verification calculations are performed on exactly the same bits as the signing calculations. If the surface representation of the signed data can change between signing and verification, then some way to standardize the changeable aspect must be used before signing and verification. For example, even for simple ASCII text there are at least three widely used line ending sequences. If it is possible for signed text to be modified from one line ending convention to another between the time of signing and signature verification, then the line endings need to be canonicalized to a standard form before signing and verification or the signatures will break.
デジタル署名は、署名計算とまったく同じビットで検証計算が実行される場合にのみ機能します。署名されたデータの表面表現が署名と検証の間に変更できる場合、署名と検証の前に、変更可能な側面を標準化する何らかの方法を使用する必要があります。たとえば、単純なASCIIテキストであっても、少なくとも3つの広く使用されているラインエンディングシーケンスがあります。署名と署名の検証の間に、ある行の終了条約から別の行に署名されたテキストを変更できる場合、署名と検証または署名が破損する前に、ラインエンディングを標準フォームに正規化する必要があります。
XML is subject to surface representation changes and to processing which discards some surface information. For this reason, XML digital signatures have a provision for indicating canonicalization methods in the signature so that a verifier can use the same canonicalization as the signer.
XMLは、表面表現の変更と、一部の表面情報を破棄する処理の対象となります。このため、XMLデジタル署名には、検証者が署名者と同じ標準化を使用できるように、署名に正規化方法を示すための規定があります。
Throughout this specification we distinguish between the canonicalization of a Signature element and other signed XML data objects. It is possible for an isolated XML document to be treated as if it were binary data so that no changes can occur. In that case, the digest of the document will not change and it need not be canonicalized if it is signed and verified as such. However, XML that is read and processed using standard XML parsing and processing techniques is frequently changed such that some of its surface representation information is lost or modified. In particular, this will occur in many cases for the Signature and enclosed SignedInfo elements since they, and possibly an encompassing XML document, will be processed as XML.
この仕様を通して、署名要素の正規化と他の署名されたXMLデータオブジェクトの標準化を区別します。孤立したXMLドキュメントが、変更が発生しないようにバイナリデータであるかのように扱われる可能性があります。その場合、ドキュメントのダイジェストは変更されず、署名および検証されている場合は標準化する必要はありません。ただし、標準のXML解析および処理技術を使用して読み取りおよび処理されるXMLは、表面表現情報の一部が失われたり変更されたりするように頻繁に変更されます。特に、これは多くの場合、署名および囲まれたSignedInfo要素に対して発生します。これは、それらがXMLとして処理される可能性があるため、おそらくXMLドキュメントを包み込む可能性があるためです。
Similarly, these considerations apply to Manifest, Object, and SignatureProperties elements if those elements have been digested, their DigestValue is to be checked, and they are being processed as XML.
同様に、これらの考慮事項は、それらの要素が消化されている場合、それらの消化率をチェックし、XMLとして処理されている場合、マニフェスト、オブジェクト、および署名プロパティの要素に適用されます。
The kinds of changes in XML that may need to be canonicalized can be divided into four categories. There are those related to the basic [XML], as described in 7.1 below. There are those related to [DOM], [SAX], or similar processing as described in 7.2 below. Third, there is the possibility of coded character set conversion, such as between UTF-8 and UTF-16, both of which all [XML] compliant processors are required to support, which is described in the paragraph immediately below. And, fourth, there are changes that related to namespace declaration and XML namespace attribute context as described in 7.3 below.
標準化する必要があるXMLの変化の種類は、4つのカテゴリに分割できます。以下7.1で説明されているように、基本[XML]に関連するものがあります。以下の7.2で説明されているように、[dom]、[sax]、または同様の処理に関連するものがあります。第三に、UTF-8とUTF-16の間など、コード化された文字セット変換の可能性があります。どちらもすべての[XML]コンプライアンスプロセッサがサポートする必要があります。そして、第四に、以下の7.3で説明されているように、名前空間宣言とXML名属性のコンテキストに関連する変更があります。
Any canonicalization algorithm should yield output in a specific fixed coded character set. All canonicalization algorithms identified in this document use UTF-8 (without a byte order mark (BOM)) and do not provide character normalization. We RECOMMEND that signature applications create XML content (Signature elements and their descendents/content) in Normalization Form C [NFC, NFC-Corrigendum] and check that any XML being consumed is in that form as well; (if not, signatures may consequently fail to validate). Additionally, none of these algorithms provide data type normalization. Applications that normalize data types in varying formats (e.g., (true, false) or (1,0)) may not be able to validate each other's signatures.
標準化アルゴリズムは、特定の固定コード化された文字セットに出力を生成する必要があります。このドキュメントで特定されたすべての標準化アルゴリズムは、UTF-8を使用して（バイト順序マーク（BOM））、文字の正規化を提供しません。署名アプリケーションは、XMLコンテンツ（署名要素とその子孫/コンテンツ）を正規化フォームC [NFC、NFC-Corrigendum]で作成し、消費されているXMLもその形式であることを確認することをお勧めします。（そうでない場合、署名はその結果、検証に失敗する場合があります）。さらに、これらのアルゴリズムはいずれもデータ型の正規化を提供していません。さまざまな形式でデータ型を正常化するアプリケーション（例：（真、false）または（1,0））は、互いの署名を検証できない場合があります。
XML 1.0 [XML] defines an interface where a conformant application reading XML is given certain information from that XML and not other information. In particular, 1. line endings are normalized to the single character #xA by dropping #xD characters if they are immediately followed by a #xA and replacing them with #xA in all other cases, 2. missing attributes declared to have default values are provided to the application as if present with the default value, 3. character references are replaced with the corresponding character, 4. entity references are replaced with the corresponding declared entity, 5. attribute values are normalized by 5.1 replacing character and entity references as above, 5.2 replacing occurrences of #x9, #xA, and #xD with #x20 (space) except that the sequence #xD#xA is replaced by a single space, and 5.3 if the attribute is not declared to be CDATA, stripping all leading and trailing spaces and replacing all interior runs of spaces with a single space.
XML 1.0 [XML]は、XMLを読み取る適切なアプリケーションに他の情報ではなく、そのXMLから特定の情報が与えられるインターフェイスを定義します。特に、1。ラインエンディングは、#XAがすぐに#XAが続き、他のすべての場合に＃XAを置き換える場合、#XD文字をドロップすることにより、単一文字＃XAに正規化されます。デフォルト値が存在するかのようにアプリケーションに提供されます。3。文字参照は対応する文字に置き換えられます。4。エンティティ参照は、対応する宣言されたエンティティに置き換えられます。5。、、5.2＃x9、＃xa、および#xdの発生を＃x20（space）に置き換えると、シーケンス＃xd＃xaが単一のスペースに置き換えられ、属性がcdataであると宣言されていない場合は5.3を除去し、すべてをリードするすべてのリーディングそして、後続のスペースとすべての内部のスペースを単一のスペースに置き換えます。
Note that items (2), (4), and (5.3) depend on the presence of a schema, DTD or similar declarations. The Signature element type is laxly schema valid [XML-schema], consequently external XML or even XML within the same document as the signature may be (only) well-formed or from another namespace (where permitted by the signature schema); the noted items may not be present. Thus, a signature with such content will only be verifiable by other signature applications if the following syntax constraints are observed when generating any signed material including the SignedInfo element:
項目（2）、（4）、および（5.3）は、スキーマ、DTDまたは同様の宣言の存在に依存することに注意してください。署名要素タイプはLaxly Schema valid [XML-Schema]であるため、署名と同じドキュメント内の外部XMLまたはXMLでさえ、（のみ）よく形成されるか、別の名前空間（署名スキーマで許可されている場合）からです。著名なアイテムが存在しない場合があります。したがって、そのようなコンテンツを含む署名は、SignedInfo要素を含む署名型資料を生成するときに次の構文制約が観察される場合にのみ、他の署名アプリケーションによって検証されます。
1. attributes having default values be explicitly present, 2. all entity references (except "amp", "lt", "gt", "apos", "quot", and other character entities not representable in the encoding chosen) be expanded, 3. attribute value white space be normalized
1. デフォルト値を持つ属性は明示的に存在する属性、2。すべてのエンティティ参照（「amp」、「lt」、「gt」、「apos」、「quot」、および選択したエンコーディングで表されない他の文字エンティティを拡張する）、3。属性値ホワイトスペースは正規化されます
In addition to the canonicalization and syntax constraints discussed above, many XML applications use the Document Object Model [DOM] or the Simple API for XML [SAX]. DOM maps XML into a tree structure of nodes and typically assumes it will be used on an entire document with subsequent processing being done on this tree. SAX converts XML into a series of events such as a start tag, content, etc. In either case, many surface characteristics such as the ordering of attributes and insignificant white space within start/end tags is lost. In addition, namespace declarations are mapped over the nodes to which they apply, losing the namespace prefixes in the source text and, in most cases, losing where namespace declarations appeared in the original instance.
上記の標準化と構文の制約に加えて、多くのXMLアプリケーションは、XML [SAX]のドキュメントオブジェクトモデル[DOM]または単純なAPIを使用しています。domはXMLをノードのツリー構造にマッピングし、通常、ドキュメント全体で使用されると仮定し、その後の処理がこのツリーで行われます。SAXは、XMLを開始タグ、コンテンツなどの一連のイベントに変換します。どちらの場合も、属性の順序付けや開始/エンドタグ内の重要でない空白などの多くの表面特性が失われます。さらに、名前空間宣言は、適用されるノードにマッピングされ、ソーステキストの名前空間プレフィックスを失い、ほとんどの場合、元のインスタンスで名前空間宣言が表示された場所を失います。
If an XML Signature is to be produced or verified on a system using DOM or SAX processing, a canonical method is needed to serialize the relevant part of a DOM tree or sequence of SAX events. XML canonicalization specifications, such as [XML-C14N], are based only on information which is preserved by DOM and SAX. For an XML Signature to be verifiable by an implementation using DOM or SAX, not only must the XML 1.0 syntax constraints given in the previous section be followed, but an appropriate XML canonicalization MUST be specified so that the verifier can re-serialize DOM/SAX mediated input into the same octet stream that was signed.
XML署名をDOMまたはSAX処理を使用してシステムで作成または検証する場合、DOMツリーの関連部分またはSAXイベントのシーケンスをシリアル化するために標準的な方法が必要です。[XML-C14N]などのXML Canonicalization仕様は、DOMとSAXによって保存されている情報のみに基づいています。DOMまたはSAXを使用した実装によって検証可能であるXML署名の場合、前のセクションに記載されているXML 1.0構文の制約を追跡する必要があるだけでなく、適切なXML標準化を指定して、検証者がDOM/SAXを再統合できるように指定する必要があります。署名された同じオクテットストリームへの媒介入力。
In [XPath] and consequently the Canonical XML data model an element has namespace nodes that correspond to those declarations within the element and its ancestors:
[xpath]およびその結果、標準的なXMLデータモデルでは、要素には要素とその祖先内の宣言に対応する名前空間ノードがあります。
"Note: An element E has namespace nodes that represent its namespace declarations as well as any namespace declarations made by its ancestors that have not been overridden in E's declarations, the default namespace if it is non-empty, and the declaration of the prefix xml." [XML-C14N]
「注：要素Eには、名前空間宣言を表す名前空間ノードと、eの宣言で上書きされていない先祖、デフォルトの名前空間が空である場合はデフォルトの名前空間、およびプレフィックスXMLの宣言が行われた名前空間宣言を表す名前空間ノードがあります。。」[XML-C14N]
When serializing a Signature element or signed XML data that's the child of other elements using these data models, that Signature element and its children, may contain namespace declarations from its ancestor context. In addition, the Canonical XML and Canonical XML with Comments algorithms import all xml namespace attributes (such as xml:lang) from the nearest ancestor in which they are declared to the apex node of canonicalized XML unless they are already declared at that node. This may frustrate the intent of the signer to create a signature in one context which remains valid in another. For example, given a signature which is a child of B and a grandchild of A:
署名要素を使用して他の要素の子である署名要素または署名されたXMLデータをシリアル化する場合、その署名要素とその子供には、祖先のコンテキストからの名前空間宣言を含む場合があります。さらに、コメントアルゴリズムを備えた標準XMLおよび標準XMLは、すべてのXMLネームスペース属性（XML：Langなど）を、そのノードで既に宣言されていない限り、標準化されたXMLの頂点ノードに宣言されている最も近い祖先からインポートします。これは、署名者があるコンテキストで署名を作成する意図を苛立たせます。たとえば、Bの子供であり、Aの孫である署名が与えられます。
<A xmlns:n1="&foo;">
<B xmlns:n2="&bar;">
<Signature xmlns="&dsig;"> ...
<Reference URI="#signme"/> ...
</Signature>
<C ID="signme" xmlns="&baz;"/>
</B>
</A>
when either the element B or the signed element C is moved into a [SOAP] envelope for transport:
要素bまたは署名された要素cが輸送用の[石鹸]エンベロープに移動される場合：
<SOAP:Envelope
xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
...
<SOAP:Body>
<B xmlns:n2="&bar;">
<Signature xmlns="&dsig;">
...
</Signature>
<C ID="signme" xmlns="&baz;"/>
</B>
</SOAP:Body>
</SOAP:Envelope>
The canonical form of the signature in this context will contain new namespace declarations from the SOAP:Envelope context, invalidating the signature. Also, the canonical form will lack namespace declarations it may have originally had from element A's context, also invalidating the signature. To avoid these problems, the application may:
このコンテキストでの署名の標準形式には、SOAPからの新しい名前空間宣言：エンベロープコンテキスト、署名の無効化が含まれます。また、標準形式には、元々要素Aのコンテキストから持っていた名前空間宣言がなく、署名も無効にします。これらの問題を回避するために、アプリケーションは次のとおりです。
1. Rely upon the enveloping application to properly divorce its body (the signature payload) from the context (the envelope) before the signature is validated. Or, 2. Use a canonicalization method that "repels/excludes" instead of "attracts" ancestor context. [XML-C14N] purposefully attracts such context.
1. 包み込みアプリケーションに頼って、署名が検証される前に、コンテキスト（エンベロープ）から身体（署名ペイロード）を適切に離婚します。または、2。祖先のコンテキストを「引き付ける」のではなく、「反発/除外」する正規化方法を使用します。[XML-C14N]は、意図的にそのようなコンテキストを引き付けます。
The XML Signature specification provides a very flexible digital signature mechanism. Implementors must give consideration to their application threat models and to the following factors.
XML署名仕様は、非常に柔軟なデジタル署名メカニズムを提供します。実装者は、アプリケーションの脅威モデルと次の要因を考慮する必要があります。
A requirement of this specification is to permit signatures to "apply to a part or totality of a XML document." (See [XML-Signature-RD, section 3.1.3].) The Transforms mechanism meets this requirement by permitting one to sign data derived from processing the content of the identified resource. For instance, applications that wish to sign a form, but permit users to enter a limited field data without invalidating a previous signature on the form might use [XPath] to exclude those portions the user needs to change. Transforms may be arbitrarily specified and may include encoding transforms, canonicalization instructions or even XSLT transformations. Three cautions are raised with respect to this feature in the following sections.
この仕様の要件は、署名が「XMLドキュメントの一部または全体性に適用される」ことを許可することです。（[XML-Signature-Rd、セクション3.1.3]を参照してください。）変換メカニズムは、特定されたリソースのコンテンツの処理から派生したデータに署名することを許可することにより、この要件を満たしています。たとえば、フォームに署名したいが、フォーム上の以前の署名を無効にすることなくユーザーが限られたフィールドデータを入力できるようにするアプリケーション[XPath]を使用して、ユーザーが変更する必要がある部分を除外する場合があります。変換は任意に指定されている場合があり、エンコード変換、標準化命令、またはXSLT変換などが含まれます。次のセクションでは、この機能に関して3つの注意が掲載されています。
Note, core validation behavior does not confirm that the signed data was obtained by applying each step of the indicated transforms. (Though it does check that the digest of the resulting content matches that specified in the signature.) For example, some applications may be satisfied with verifying an XML signature over a cached copy of already transformed data. Other applications might require that content be freshly dereferenced and transformed.
注意してください。コア検証動作は、指定された変換の各ステップを適用することによって署名されたデータが取得されたことを確認しません。（ただし、署名で指定された結果のコンテンツのダイジェストが一致することを確認します。）たとえば、一部のアプリケーションは、すでに変換されたデータのキャッシュされたコピーを介してXML署名を確認することに満足する場合があります。他のアプリケーションでは、コンテンツを新たに参照して変換する必要がある場合があります。
First, obviously, signatures over a transformed document do not secure any information discarded by transforms: only what is signed is secure.
第一に、明らかに、変換されたドキュメント上の署名は、変換によって破棄される情報を保護しません：署名されているのは安全です。
Note that the use of Canonical XML [XML-C14N] ensures that all internal entities and XML namespaces are expanded within the content being signed. All entities are replaced with their definitions and the canonical form explicitly represents the namespace that an element would otherwise inherit. Applications that do not canonicalize XML content (especially the SignedInfo element) SHOULD NOT use internal entities and SHOULD represent the namespace explicitly within the content being signed since they cannot rely upon canonicalization to do this for them. Also, users concerned with the integrity of the element type definitions associated with the XML instance being signed may wish to sign those definitions as well (i.e., the schema, DTD, or natural language description associated with the namespace/identifier).
Canonical XML [XML-C14N]の使用により、すべての内部エンティティとXMLネームスペースが署名されているコンテンツ内で拡張されるようにすることに注意してください。すべてのエンティティは定義に置き換えられ、標準形式は要素が継承する名前空間を明示的に表します。XMLコンテンツ（特にSignedInfo要素）を正規化しないアプリケーションは、内部エンティティを使用してはならず、署名されているコンテンツ内の名前空間を明示的に表す必要があります。また、署名されているXMLインスタンスに関連付けられた要素タイプ定義の整合性に関係するユーザーは、これらの定義にも署名することを望む場合があります（つまり、名前空間/識別子に関連付けられたスキーマ、DTD、または自然言語の説明）。
Second, an envelope containing signed information is not secured by the signature. For instance, when an encrypted envelope contains a signature, the signature does not protect the authenticity or integrity of unsigned envelope headers nor its ciphertext form, it only secures the plaintext actually signed.
第二に、署名された情報を含むエンベロープは、署名によって保護されていません。たとえば、暗号化されたエンベロープに署名が含まれている場合、署名は、署名されていないエンベロープヘッダーの信頼性または完全性を保護しない場合、その暗号形式フォームでは、実際に署名されたプラーンテキストのみを保護します。
Additionally, the signature secures any information introduced by the transform: only what is "seen" (that which is represented to the user via visual, auditory or other media) should be signed. If signing is intended to convey the judgment or consent of a user (an automated mechanism or person), then it is normally necessary to secure as exactly as practical the information that was presented to that user. Note that this can be accomplished by literally signing what was presented, such as the screen images shown a user. However, this may result in data which is difficult for subsequent software to manipulate. Instead, one can sign the data along with whatever filters, style sheets, client profile or other information that affects its presentation.
さらに、署名は、変換によって導入された情報を保護します。「見られる」もの（視覚、聴覚、または他のメディアを介してユーザーに表されるもの）のみに署名する必要があります。署名がユーザー（自動化されたメカニズムまたは個人）の判断または同意を伝えることを目的としている場合、通常、そのユーザーに提示された情報を正確に実用的に保護する必要があります。これは、ユーザーが表示される画面画像など、提示されたものに文字通り署名することで実現できることに注意してください。ただし、これにより、後続のソフトウェアが操作するのが困難なデータになる可能性があります。代わりに、プレゼンテーションに影響を与えるフィルター、スタイルシート、クライアントプロファイル、またはその他の情報とともにデータに署名できます。
Just as a user should only sign what he or she "sees," persons and automated mechanism that trust the validity of a transformed document on the basis of a valid signature should operate over the data that was transformed (including canonicalization) and signed, not the original pre-transformed data. This recommendation applies to transforms specified within the signature as well as those included as part of the document itself. For instance, if an XML document includes an embedded style sheet [XSLT] it is the transformed document that should be represented to the user and signed. To meet this recommendation where a document references an external style sheet, the content of that external resource should also be signed via a signature Reference, otherwise the content of that external content might change which alters the resulting document without invalidating the signature.
ユーザーが自分が「見る」もののみに署名する必要があるように、有効な署名に基づいて変換されたドキュメントの有効性を信頼する人と自動化されたメカニズムは、変換されたデータ（標準化を含む）および署名ではなく署名されたデータに対して動作する必要があります元の事前に変換されたデータ。この推奨事項は、署名内で指定された変換と、ドキュメント自体の一部として含まれる変換に適用されます。たとえば、XMLドキュメントに組み込みスタイルシート[XSLT]が含まれている場合、それはユーザーに表現して署名するべき変換されたドキュメントです。ドキュメントが外部スタイルシートを参照するこの推奨事項を満たすために、その外部リソースのコンテンツも署名リファレンスを介して署名する必要があります。そうしないと、その外部コンテンツのコンテンツは、署名を無効にすることなく結果のドキュメントを変更する可能性があります。
Some applications might operate over the original or intermediary data but should be extremely careful about potential weaknesses introduced between the original and transformed data. This is a trust decision about the character and meaning of the transforms that an application needs to make with caution. Consider a canonicalization algorithm that normalizes character case (lower to upper) or character composition ('e and accent' to 'accented-e'). An adversary could introduce changes that are normalized and consequently inconsequential to signature validity but material to a DOM processor. For instance, by changing the case of a character one might influence the result of an XPath selection. A serious risk is introduced if that change is normalized for signature validation but the processor operates over the original data and returns a different result than intended.
一部のアプリケーションは、元のデータまたは中間データに対して動作する場合がありますが、元のデータと変換されたデータの間に導入された潜在的な弱点に非常に注意する必要があります。これは、アプリケーションが注意して行う必要がある変換の性格と意味に関する信頼の決定です。文字ケース（下から上から上）または文字組成（「eおよびアクセント」から「アクセント-e」）を正規化する正規化アルゴリズムを考えてください。敵は、正規化された変更を導入し、その結果、署名の妥当性に取るに足らないが、DOMプロセッサに材料を導入することができます。たとえば、キャラクターのケースを変更することにより、Xpath選択の結果に影響を与える可能性があります。その変更が署名検証のために正規化されているが、プロセッサは元のデータで動作し、意図したものとは異なる結果を返す場合、深刻なリスクが導入されます。
As a result:
結果として：
* All documents operated upon and generated by signature applications MUST be in [NFC, NFC-Corrigendum] (otherwise intermediate processors might unintentionally break the signature) * Encoding normalizations SHOULD NOT be done as part of a signature transform, or (to state it another way) if normalization does occur, the application SHOULD always "see" (operate over) the normalized form.
* 署名アプリケーションによって操作および生成されたすべてのドキュメントは、[NFC、NFC-Corrigendum]（それ以外の場合は中間プロセッサが署名を意図せずに破る可能性がある）にある必要があります））正規化が発生した場合、アプリケーションは常に正規化されたフォームを「操作」（操作する）必要があります。
This specification uses public key signatures and keyed hash authentication codes. These have substantially different security models. Furthermore, it permits user specified algorithms which may have other models.
この仕様では、公開キーの署名を使用し、キー付きハッシュ認証コードを使用します。これらには、セキュリティモデルが大幅に異なります。さらに、他のモデルを持つ可能性のあるユーザーが指定したアルゴリズムを許可します。
With public key signatures, any number of parties can hold the public key and verify signatures while only the parties with the private key can create signatures. The number of holders of the private key should be minimized and preferably be one. Confidence by verifiers in the public key they are using and its binding to the entity or capabilities represented by the corresponding private key is an important issue, usually addressed by certificate or online authority systems.
公開キーの署名を使用すると、任意の数の当事者が公開キーを保持し、署名を検証できますが、秘密鍵を持つ当事者のみが署名を作成できます。秘密鍵の所有者の数は最小化され、できれば1つである必要があります。使用している公開鍵の検証者による信頼と、対応する秘密鍵で表されるエンティティまたは機能への拘束は、通常は証明書またはオンライン当局システムで対処される重要な問題です。
Keyed hash authentication codes, based on secret keys, are typically much more efficient in terms of the computational effort required but have the characteristic that all verifiers need to have possession of the same key as the signer. Thus any verifier can forge signatures.
シークレットキーに基づいたキー付きハッシュ認証コードは、通常、必要な計算作業に関してはるかに効率的ですが、すべての検証者が署名者と同じキーを所有する必要があるという特徴があります。したがって、すべての検証者は署名を偽造できます。
This specification permits user provided signature algorithms and keying information designators. Such user provided algorithms may have different security models. For example, methods involving biometrics usually depend on a physical characteristic of the authorized user that can not be changed the way public or secret keys can be and may have other security model differences.
この仕様により、ユーザーは署名アルゴリズムとキーイング情報指定子を提供できます。このようなユーザー提供されたアルゴリズムには、セキュリティモデルが異なる場合があります。たとえば、生体認証を含む方法は通常、公共または秘密の鍵が他のセキュリティモデルの違いを持つ可能性がある方法で変更できない認可されたユーザーの物理的特性に依存します。
8.3 Algorithms, Key Lengths, Certificates, Etc.
8.3 アルゴリズム、キー長、証明書など。
The strength of a particular signature depends on all links in the security chain. This includes the signature and digest algorithms used, the strength of the key generation [RANDOM] and the size of the key, the security of key and certificate authentication and distribution mechanisms, certificate chain validation policy, protection of cryptographic processing from hostile observation and tampering, etc.
特定の署名の強さは、セキュリティチェーン内のすべてのリンクに依存します。これには、使用される署名およびダイジェストアルゴリズム、キー生成の強度[ランダム]とキーのサイズ、キーおよび証明書認証および配布メカニズムのセキュリティ、証明書チェーン検証ポリシー、敵対的な観察からの暗号化処理の保護、改ざんが含まれます。、など
Care must be exercised by applications in executing the various algorithms that may be specified in an XML signature and in the processing of any "executable content" that might be provided to such algorithms as parameters, such as XSLT transforms. The algorithms specified in this document will usually be implemented via a trusted library, but even there perverse parameters might cause unacceptable processing or memory demand. Even more care may be warranted with application defined algorithms.
XML署名で指定される可能性のあるさまざまなアルゴリズムの実行およびXSLT変換などのパラメーターなどのアルゴリズムに提供される可能性のある「実行可能コンテンツ」の処理において、アプリケーションが注意する必要があります。このドキュメントで指定されているアルゴリズムは通常、信頼できるライブラリを介して実装されますが、邪悪なパラメーターであっても、受け入れられない処理またはメモリの需要を引き起こす可能性があります。アプリケーション定義のアルゴリズムでは、さらに注意が必要です。
The security of an overall system will also depend on the security and integrity of its operating procedures, its personnel, and on the administrative enforcement of those procedures. All the factors listed in this section are important to the overall security of a system; however, most are beyond the scope of this specification.
システム全体のセキュリティは、その運用手順、その職員のセキュリティと整合性、およびそれらの手順の管理施行にも依存します。このセクションにリストされているすべての要因は、システムの全体的なセキュリティにとって重要です。ただし、ほとんどはこの仕様の範囲を超えています。
XML Signature Schema Instance http://www.w3.org/Signature/Drafts/xmldsig-core/xmldsig-core-schema.xsd Valid XML schema instance based on the 20001024 Schema/DTD [XML-Schema].
XML Signature Schema Instance http://www.w3.org/signature/drafts/xmldsig-core/xmldsig-core-schema.xsd有効なXMLスキーマインスタンス20001024スキーマ/DTD [XML-Schema]に基づく。
XML Signature DTD http://www.w3.org/Signature/Drafts/xmldsig-core/xmldsig-core-schema.dtd
XML署名DTD http://www.w3.org/signature/drafts/xmldsig-core/xmldsig-core-schema.dtd
RDF Data Model http://www.w3.org/Signature/Drafts/xmldsig-core/xmldsig-datamodel-20000112.gif
RDFデータモデルhttp://www.w3.org/signature/drafts/xmldsig-core/xmldsig-datamodel-20012.gif
XML Signature Object Example http://www.w3.org/Signature/Drafts/xmldsig-core/signature-example.xml A cryptographical fabricated XML example that includes foreign content and validates under the schema, it also uses schemaLocation to aid automated schema fetching and validation.
XML Signature Objectの例http://www.w3.org/signature/drafts/xmldsig-core/signature-example.xmlは、外国のコンテンツを含む暗号化された製造されたXML例です。また、スキーマの下での外国のコンテンツを検証します。フェッチングと検証。
RSA XML Signature Example http://www.w3.org/Signature/Drafts/xmldsig-core/signature-example-rsa.xml An XML Signature example with generated cryptographic values by Merlin Hughes and validated by Gregor Karlinger.
RSA XML署名の例http://www.w3.org/signature/drafts/xmldsig-core/signature-example-rsa.xml an XML署名例は、Merlin Hughesによって生成された暗号化値を備え、Gregor Karlingerによって検証されました。
DSA XML Signature Example http://www.w3.org/Signature/Drafts/xmldsig-core/signature-example-dsa.xml Similar to above but uses DSA.
DSA XML署名の例http://www.w3.org/signature/drafts/xmldsig-core/signature-example-dsa.xmlは上記と同様ですが、DSAを使用します。
Authentication Code (Protected Checksum) A value generated from the application of a shared key to a message via a cryptographic algorithm such that it has the properties of message authentication (and integrity) but not signer authentication. Equivalent to protected checksum, "A checksum that is computed for a data object by means that protect against active attacks that would attempt to change the checksum to make it match changes made to the data object." [SEC]
認証コード（保護されたチェックサム）共有キーのアプリケーションから生成された値は、メッセージ認証（および整合性）のプロパティを備えているが、署名者認証ではないように、暗号化アルゴリズムを介してメッセージにメッセージに送信されます。保護されたチェックサムに相当する「データオブジェクトのチェックサムは、データオブジェクトに加えられた変更を一致させるためにチェックサムを変更しようとするアクティブな攻撃から保護することを意味します。」[秒]
Authentication, Message The property, given an authentication code/protected checksum, that tampering with both the data and checksum, so as to introduce changes while seemingly preserving integrity, are still detected. "A signature should identify what is signed, making it impracticable to falsify or alter either the signed matter or the signature without detection." [Digital Signature Guidelines, ABA]. Authentication, Signer The property of the identity of the signer is as claimed. "A signature should indicate who signed a document, message or record, and should be difficult for another person to produce without authorization." [Digital Signature Guidelines, ABA] Note, signer authentication is an application decision (e.g., does the signing key actually correspond to a specific identity) that is supported by, but out of the scope of, this specification. Checksum "A value that (a) is computed by a function that is dependent on the contents of a data object and (b) is stored or transmitted together with the object, for the purpose of detecting changes in the data." [SEC] Core The syntax and processing defined by this specification, including core validation. We use this term to distinguish other markup, processing, and applications semantics from our own. Data Object (Content/Document) The actual binary/octet data being operated on (transformed, digested, or signed) by an application -- frequently an HTTP entity [HTTP]. Note that the proper noun Object designates a specific XML element. Occasionally we refer to a data object as a document or as a resource's content. The term element content is used to describe the data between XML start and end tags [XML]. The term XML document is used to describe data objects which conform to the XML specification [XML]. Integrity "The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner." [SEC] A simple checksum can provide integrity from incidental changes in the data; message authentication is similar but also protects against an active attack to alter the data whereby a change in the checksum is introduced so as to match the change in the data. Object An XML Signature element wherein arbitrary (non-core) data may be placed. An Object element is merely one type of digital data (or document) that can be signed via a Reference.
認証、認証コード/保護されたチェックサムを与えられたプロパティにメッセージとチェックサムの両方を改ざんし、整合性を維持しながら変更を導入するために、まだ検出されます。「署名が署名されているものを識別し、検出せずに署名された問題または署名を変更または変更することは実行不可能にする必要があります。」[デジタル署名ガイドライン、ABA]。認証、署名者署名者の身元の財産は主張されています。「署名は、誰がドキュメント、メッセージ、または記録に署名したかを示す必要があり、他の人が許可なしに作成することは困難なはずです。」[デジタル署名ガイドライン、ABA]注、署名者認証は、アプリケーションの決定（例えば、署名キーは実際には特定のIDに対応する）であるが、この仕様の範囲でサポートされているが、範囲外である。Checksum「（a）は、データオブジェクトの内容に依存する関数によって計算され、（b）データの変更を検出する目的で、オブジェクトとともに保存または送信される値によって計算される値。」[SEC]コア検証を含む、この仕様で定義された構文と処理。この用語を使用して、他のマークアップ、処理、およびアプリケーションセマンティクスを独自のマークアップ、処理、およびアプリケーションのセマンティクスを区別します。データオブジェクト（コンテンツ/ドキュメント）アプリケーションによって操作されている実際のバイナリ/オクテットデータ（変換、消化、または署名）で操作されています - 頻繁にHTTPエンティティ[HTTP]。固定名詞オブジェクトは、特定のXML要素を指定することに注意してください。時折、データオブジェクトをドキュメントまたはリソースのコンテンツとして参照します。要素コンテンツという用語は、XMLの開始タグ[XML]間のデータを記述するために使用されます。XMLドキュメントという用語は、XML仕様[XML]に準拠するデータオブジェクトを記述するために使用されます。整合性「データが変更されていない、破壊されていない、または不正なまたは偶発的な方法で失われていないプロパティ。」[SEC]単純なチェックサムは、データの偶発的な変更から完全性を提供できます。メッセージ認証は類似していますが、データの変更に合わせてチェックサムの変更が導入されるデータを変更するためのアクティブな攻撃からも保護します。オブジェクト任意の（非コア）データを配置できるXML署名要素。オブジェクト要素は、参照を介して署名できるデジタルデータ（またはドキュメント）の1つにすぎません。
Resource
"A resource can be anything that has identity. Familiar examples
include an electronic document, an image, a service (e.g.,
'today's weather report for Los Angeles'), and a collection of
other resources.... The resource is the conceptual mapping to an
entity or set of entities, not necessarily the entity which
corresponds to that mapping at any particular instance in time.
Thus, a resource can remain constant even when its content---the
entities to which it currently corresponds---changes over time,
provided that the conceptual mapping is not changed in the
process." [URI] In order to avoid a collision of the term entity
within the URI and XML specifications, we use the term data
object, content or document to refer to the actual bits/octets
being operated upon.
Signature
Formally speaking, a value generated from the application of a
private key to a message via a cryptographic algorithm such that
it has the properties of integrity, message authentication and/or
signer authentication. (However, we sometimes use the term
signature generically such that it encompasses Authentication Code
values as well, but we are careful to make the distinction when
the property of signer authentication is relevant to the
exposition.) A signature may be (non-exclusively) described as
detached, enveloping, or enveloped.
Signature, Application
An application that implements the MANDATORY (REQUIRED/MUST)
portions of this specification; these conformance requirements are
over application behavior, the structure of the Signature element
type and its children (including SignatureValue) and the specified
algorithms.
Signature, Detached
The signature is over content external to the Signature element,
and can be identified via a URI or transform. Consequently, the
signature is "detached" from the content it signs. This
definition typically applies to separate data objects, but it also
includes the instance where the Signature and data object reside
within the same XML document but are sibling elements.
Signature, Enveloping
The signature is over content found within an Object element of
the signature itself. The Object (or its content) is identified
via a Reference (via a URI fragment identifier or transform).
Signature, Enveloped
The signature is over the XML content that contains the signature
as an element. The content provides the root XML document
element. Obviously, enveloped signatures must take care not to
include their own value in the calculation of the SignatureValue.
Transform The processing of a data from its source to its derived form. Typical transforms include XML Canonicalization, XPath, and XSLT. Validation, Core The core processing requirements of this specification requiring signature validation and SignedInfo reference validation. Validation, Reference The hash value of the identified and transformed content, specified by Reference, matches its specified DigestValue. Validation, Signature The SignatureValue matches the result of processing SignedInfo with CanonicalizationMethod and SignatureMethod as specified in Core Validation (section 3.2). Validation, Trust/Application The application determines that the semantics associated with a signature are valid. For example, an application may validate the time stamps or the integrity of the signer key -- though this behavior is external to this core specification.
データの処理をソースから派生フォームに変換します。典型的な変換には、XML Canonicalization、XPath、およびXSLTが含まれます。検証、署名検証とSigneDINFO参照検証を必要とするこの仕様のコア処理要件をコアします。検証、参照されたコンテンツのハッシュ値を参照して、参照によって指定されたものは、指定されたダイジェストバリューと一致します。検証、署名SignatureValueは、コア検証で指定されているように、CanOnicalizationMethodおよびSignatureMethodを使用してSignedInfoを処理した結果と一致します（セクション3.2）。検証、信頼/アプリケーションアプリケーションは、署名に関連するセマンティクスが有効であると判断します。たとえば、アプリケーションはタイムスタンプまたは署名者キーの完全性を検証する場合がありますが、この動作はこのコア仕様の外部です。
Appendix: Changes from RFC 3075
付録：RFC 3075からの変更
Numerous minor editorial changes were made. In addition, the following substantive changes have occurred based on interoperation experience or other considerations:
多数のマイナーな編集の変更が行われました。さらに、次の実質的な変更は、相互操作の経験またはその他の考慮事項に基づいて発生しました。
1. Minor but incompatible changes in the representation of DSA keys. In particular, the optionality of several fields was changed and two fields were re-ordered.
1. DSAキーの表現におけるマイナーだが互換性のない変化。特に、いくつかのフィールドのオプションが変更され、2つのフィールドが再注文されました。
2. Minor change in the X509Data KeyInfo structure to allow multiple CRLs to be grouped with certificates and other X509 information. Previously CRLs had to occur singly and each in a separate X509Data structure.
2. X509DATA KeyINFO構造のわずかな変更により、複数のCRLを証明書およびその他のX509情報でグループ化できるようにします。以前はCRLSが単独で発生し、それぞれが別のx509Data構造で発生する必要がありました。
3. Incompatible change in the type of PGPKeyID, which had previously been string, to the more correct base64Binary since it is actually a binary quantity.
3. 以前はひもだったpgpkeyidのタイプの互換性のない変化は、実際にはバイナリ量であるため、より正しいbase64binaryになりました。
4. Several warnings have been added. Of particular note, because it reflects a problem actually encountered in use and is the only warning added that has its own little section, is the warning of canonicalization problems when the namespace context of signed material changes.
4. いくつかの警告が追加されました。特に注目に値するのは、実際に使用されている問題を反映しており、独自のセクションを持つ唯一の警告であるため、署名された素材の変更の名前空間コンテキストが標準化された問題の警告です。
References
参考文献
[ABA] Digital Signature Guidelines. http://www.abanet.org/scitech/ec/isc/dsgfree.html
[ABA]デジタル署名ガイドライン。http://www.abanet.org/scitech/ec/isc/dsgfree.html
[DOM] Document Object Model (DOM) Level 1 Specification. W3C Recommendation. V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, L. Wood. October 1998. http://www.w3.org/TR/1998/REC-DOM-Level-1- 19981001/
[DOM]ドキュメントオブジェクトモデル（DOM）レベル1仕様。W3Cの推奨。V.アピアオ、S。バーン、M。チャンピオン、S。アイザック、I。ジェイコブス、A。ルース、G。ニコル、J。ロビー、R。スター、C。ウィルソン、L。ウッド。1998年10月。http：//www.w3.org/tr/1998/recdom-level-1-19981001/
[DSS] FIPS PUB 186-2 . Digital Signature Standard (DSS). U.S. Department of Commerce/National Institute of Standards and Technology. http://csrc.nist.gov/publications/fips/fips186- 2/fips186-2.pdf
[DSS] Fips Pub 186-2。デジタル署名標準（DSS）。米国商務省/国立標準技術研究所。http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[HTTP] Fielding, R. Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP] Fielding、R。Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC2616、1999年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[LDAP-DN] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[LDAP-DN] Wahl、M.、Kille、S。、およびT. Howes、「Lightweight Directory Access Protocol（V3）：UTF-8文字列識別名の表現」、RFC 2253、1997年12月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Mime] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[NFC] TR15, Unicode Normalization Forms. M. Davis, M. Drst. Revision 18: November 1999. http://www.unicode.org/unicode/reports/tr15/tr15- 18.html. NFC-Corrigendum Normalization Corrigendum. The Unicode Consortium. http://www.unicode.org/unicode/uni2errata/ Normalization_Corrigendum.html.
[NFC] TR15、ユニコード正規化フォーム。M.デイビス、M。Drst。改訂18：1999年11月。http：//www.unicode.org/unicode/reports/tr15/tr15-18.html。NFC-Corrigendum正規化回心。ユニコードコンソーシアム。http://www.unicode.org/unicode/uni2errata/ remarization_corrigendum.html。
[PGP] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[PGP] Callas、J.、Donnerhacke、L.、Finney、H。およびR. Thayer、「OpenPGPメッセージ形式」、RFC 2440、1998年11月。
[RANDOM] Eastlake, 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[ランダム] Eastlake、3rd、D.、Crocker、S。and J. Schiller、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。
[RDF] Resource Description Framework (RDF) Schema Specification 1.0. W3C Candidate Recommendation. D. Brickley, R.V. Guha. March 2000. http://www.w3.org/TR/2000/CR-rdf-schema-20000327/ Resource Description Framework (RDF) Model and Syntax Specification. W3C Recommendation. O. Lassila, R. Swick. February 1999. http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
[RDF]リソース説明フレームワーク（RDF）スキーマ仕様1.0。W3C候補の推奨。D.ブリックリー、R.V。グハ。2000年3月。http：//www.w3.org/tr/2000/cr-rdf-schema-20000327/リソース説明フレームワーク（RDF）モデルと構文仕様。W3Cの推奨。O.ラシラ、R。スウィック。1999年2月。http：//www.w3.org/tr/1999/rec-rdf-syntax-19990222/
[1363] IEEE 1363: Standard Specifications for Public Key Cryptography. August 2000.
[1363] IEEE 1363：公開キー暗号化の標準仕様。2000年8月。
[PKCS1] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998.
[PKCS1] Kaliski、B。and J. Staddon、「PKCS＃1：RSA暗号化仕様バージョン2.0」、RFC 2437、1998年10月。
[SAX] SAX: The Simple API for XML. D. Megginson, et al. May 1998. http://www.megginson.com/SAX/index.html (THIS PAGE OUT OF DATE; GO TO www.saxproject.org)
[SAX] SAX：XMLのシンプルなAPI。D. Megginson、et al。1998年5月。http://www.megginson.com/sax/index.html（このページは古くなっています。www.saxproject.orgにアクセスしてください）
[SEC] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.
[Sec] Shirey、R。、「Internet Security Glossary」、FYI 36、RFC 2828、2000年5月。
[SHA-1] FIPS PUB 180-1. Secure Hash Standard. U.S. Department of Commerce/National Institute of Standards and Technology. http://csrc.nist.gov/publications/fips/fips180- 1/fip180-1.txt
[Sha-1] Fips Pub 180-1。安全なハッシュ標準。米国商務省/国立標準技術研究所。http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt
[SOAP] Simple Object Access Protocol (SOAP) Version 1.1. W3C Note. D. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S. Thatte, D. Winer. May 2001. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[SOAP] Simple Object Access Protocol（SOAP）バージョン1.1。W3Cノート。D. Box、D。Ehnebuske、G。Kakivaya、A。Layman、N。Mendelsohn、H。FrystykNielsen、S。Shatte、D。Winer。2001年5月。http://www.w3.org/tr/2000/note-soap-20000508/
[Unicode] The Unicode Consortium. The Unicode Standard. http://www.unicode.org/unicode/standard/ standard.html
[Unicode] Unicodeコンソーシアム。ユニコード標準。http://www.unicode.org/unicode/standard/ Standard.html
[UTF-16] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[UTF-16] Hoffman、P。およびF. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、2000年2月。
[UTF-8] Yergeau, R., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF-8] Yergeau、R。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：汎用構文」、RFC 2396、1998年8月。
[URI-Literal] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[Uri-Literal] Hinden、R.、Carpenter、B。and L. Masinter、「URLのリテラルIPv6アドレスの形式」、RFC 2732、1999年12月。
[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
[urn] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[X509v3] ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open Systems Interconnection - The Directory Authentication Framework" ISO/IEC 9594-8:1997.
[X509V3] ITU-T推奨X.509バージョン3（1997）。「情報技術 - オープンシステムの相互接続 - ディレクトリ認証フレームワーク」ISO/IEC 9594-8：1997。
[XHTML 1.0] XHTML(tm) 1.0: The Extensible Hypertext Markup Language. W3C Recommendation. S. Pemberton, D. Raggett, et al. January 2000. http://www.w3.org/TR/2000/REC-xhtml1-20000126/
[XHTML 1.0] XHTML（TM）1.0：拡張可能なハイパーテキストマークアップ言語。W3Cの推奨。S.ペンバートン、D。ラゲット、他2000年1月。http：//www.w3.org/tr/2000/rec-xhtml1-20000126/
[XLink] XML Linking Language. W3C Recommendation. S. DeRose, E. Maler, D. Orchard. June 2001. http://www.w3.org/TR/2000/REC-xlink-20010627/
[xlink] xmlリンク言語。W3Cの推奨。S.デロース、E。マラー、D。オーチャード。2001年6月。http：//www.w3.org/tr/2000/rec-xlink-20010627/
[XML] Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation. T. Bray, E. Maler, J. Paoli, C. M. Sperberg-McQueen. October 2000. http://www.w3.org/TR/2000/REC-xml-20001006
[XML]拡張可能なマークアップ言語（XML）1.0（第2版）。W3Cの推奨。T.ブレイ、E。マラー、J。パオリ、C。M。スペルバーグ-mcqueen。2000年10月。http：//www.w3.org/tr/2000/rec-xml-20001006
[XML-C14N] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[XML-C14N] Boyer、J。、「Canonical XMLバージョン1.0」、RFC 3076、2001年3月。
[XML-Japanese] XML Japanese Profile. W3C Note. M. Murata April 2000 http://www.w3.org/TR/2000/NOTE-japanese-xml-20000414/
[XML-Japanese] XML日本のプロファイル。W3Cノート。M.ムラタ2000年4月http://www.w3.org/tr/2000/note-japanese-xml-20000414/
[XML-MT] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, July 1998.
[XML-MT]ホワイトヘッド、E。およびM.ムラタ、「XMLメディアタイプ」、RFC 2376、1998年7月。
[XML-ns] Namespaces in XML. W3C Recommendation. T. Bray, D. Hollander, A. Layman. January 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114
[XML-NS] XMLの名前空間。W3Cの推奨。T.ブレイ、D。ホランダー、A。レイマン。1999年1月。http://www.w3.org/tr/1999/rec-xml-names-19990114
[XML-schema] XML Schema Part 1: Structures. W3C Recommendation. D. Beech, M. Maloney, N. Mendelsohn, H. Thompson. May 2001. http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ XML Schema Part 2: Datatypes W3C Recommendation. P. Biron, A. Malhotra. May 2001. http://www.w3.org/TR/2001/REC-xmlschema-2- 20010502/
[XML-Schema] XMLスキーマパート1：構造。W3Cの推奨。D.ビーチ、M。マロニー、N。メンデルソーン、H。トンプソン。2001年5月。http：//www.w3.org/tr/2001/rec-xmlschema-1-20010502/ xmlスキーマパート2：データ型W3C推奨。P.ビロン、A。マルホトラ。2001年5月。http：//www.w3.org/tr/2001/rec-xmlschema-2- 20010502/
[XML-Signature-RD] Reagle, J., "XML Signature Requirements", RFC 2807, July 2000.
[XML-Signature-Rd] Reagle、J。、「XML Signature Recomations」、RFC 2807、2000年7月。
[XPath] XML Path Language (XPath) Version 1.0. W3C Recommendation. J. Clark, S. DeRose. October 1999. http://www.w3.org/TR/1999/REC-xpath-19991116
[XPath] XMLパス言語（XPath）バージョン1.0。W3Cの推奨。J.クラーク、S。デロース。1999年10月。http：//www.w3.org/tr/1999/rec-xpath-19991116
[XPointer] XML Pointer Language (XPointer). W3C Working Draft. S. DeRose, R. Daniel, E. Maler. January 2001. http://www.w3.org/TR/2001/WD-xptr-20010108
[Xpointer] XMLポインター言語（XPointer）。W3Cワーキングドラフト。S.デロース、R。ダニエル、E。マラー。2001年1月。http：//www.w3.org/tr/2001/wd-xptr-20010108
[XSL] Extensible Stylesheet Language (XSL). W3C Proposed Recommendation. S. Adler, A. Berglund, J. Caruso, S. Deach, P. Grosso, E. Gutentag, A. Milowski, S. Parnell, J. Richman, S. Zilles. August 2001. http://www.w3.org/TR/2001/PR-xsl-20010828/
[XSL]拡張可能なスタイルシート言語（XSL）。W3C提案勧告。S. Adler、A。Berglund、J。Caruso、S。Deach、P。Grosso、E。Gutentag、A。Milowski、S。Parnell、J。Richman、S。Zilles。2001年8月。http：//www.w3.org/tr/2001/pr-xsl-20010828/
[XSLT] XSL Transforms (XSLT) Version 1.0. W3C Recommendation. J. Clark. November 1999. http://www.w3.org/TR/1999/REC-xslt-19991116.html
[XSLT] XSL変換（XSLT）バージョン1.0。W3Cの推奨。J.クラーク。1999年11月。http://www.w3.org/tr/1999/rec-xslt-1991116.html
Authors' Addresses
著者のアドレス
Donald E. Eastlake 3rd Motorola, 20 Forbes Boulevard Mansfield, MA 02048 USA
ドナルドE.イーストレイク第3モトローラ、20フォーブス大通りマンスフィールド、マサチューセッツ州02048 USA
Phone: 1-508-851-8280 EMail: Donald.Eastlake@motorola.com
電話：1-508-851-8280メール：donald.eastlake@motorola.com
Joseph M. Reagle Jr., W3C Massachusetts Institute of Technology Laboratory for Computer Science NE43-350, 545 Technology Square Cambridge, MA 02139
Joseph M. Reagle Jr.、W3C Massachusetts Institute of Technology Laboratory for Computer Science NE43-350、545 Technology Square Cambridge、MA 02139
Phone: +1.617.258.7621
EMail: reagle@w3.org
David Solo Citigroup 909 Third Ave, 16th Floor NY, NY 10043 USA
David Solo Citigroup 909 Third Ave、16階、ニューヨーク州10043 USA
Phone +1-212-559-2900 EMail: dsolo@alum.mit.edu
電話1-212-559-2900メール：dsolo@alum.mit.edu
Full Copyright Statement
完全な著作権声明
Copyright (c) 2002 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved.
Copyright（c）2002 The Internet Society＆W3C（MIT、INRIA、KEIO）、All Rights Reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。